{"id":452,"date":"2026-09-08T20:15:00","date_gmt":"2026-09-08T18:15:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/?p=452"},"modified":"2026-10-24T02:25:45","modified_gmt":"2026-10-24T00:25:45","slug":"automatyzacja-walidacji-zdarzen-ga4-i-meta-capi-w-bigquery","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/pl\/digital-analytics-pl\/tutorials-pl\/automatyzacja-walidacji-zdarzen-ga4-i-meta-capi-w-bigquery\/","title":{"rendered":"Automatyzacja walidacji zdarze\u0144 GA4 i Meta CAPI w BigQuery"},"content":{"rendered":"
Uzgodnienie danych GA4 i Meta CAPI pokazuje, kt\u00f3re oczekiwane zdarzenia biznesowe maj\u0105 potwierdzenie w poszczeg\u00f3lnych \u017ar\u00f3d\u0142ach. Rozbie\u017cno\u015b\u0107 nie wyja\u015bnia jednak przyczyny: zgoda, r\u00f3\u017cne definicje zdarze\u0144, op\u00f3\u017anienia przetwarzania i b\u0142\u0119dy techniczne mog\u0105 dawa\u0107 ten sam wynik. GA4 nie musi te\u017c zawiera\u0107 wy\u0142\u0105cznie danych przegl\u0105darkowych.<\/p>\n
1. Najpierw definicja oczekiwanej zgodno\u015bci<\/h2>\n
Punktem wyj\u015bcia jest wiarygodna lista zdarze\u0144 biznesowych, na przyk\u0142ad potwierdzonych zam\u00f3wie\u0144. Por\u00f3wnanie tylko dw\u00f3ch tabel \u015bledzenia nie wykryje zdarzenia brakuj\u0105cego w obu. Sama lista referencyjna r\u00f3wnie\u017c wymaga kontroli kompletno\u015bci.<\/p>\n
\u0179r\u00f3d\u0142a \u0142\u0105czy sta\u0142y klucz. UUIDv4 jest mo\u017cliwo\u015bci\u0105, a nie obowi\u0105zkiem ani metod\u0105 szyfrowania. Ponowna wysy\u0142ka tego samego zdarzenia zachowuje identyfikator; r\u00f3\u017cne zdarzenia otrzymuj\u0105 r\u00f3\u017cne identyfikatory. Dodatkowy zakres zapobiega kolizjom mi\u0119dzy sklepami i \u017ar\u00f3d\u0142ami danych.<\/p>\n
Nazwy zdarze\u0144 wymagaj\u0105 jawnego przypisania, na przyk\u0142ad GA4 purchase<\/code> i Meta Purchase<\/code> do wsp\u00f3lnego typu purchase<\/code>. transaction_id<\/code> w GA4, w\u0142asny parametr uzgadniania i event_id<\/code> Meta to osobne pola. Usuwanie powt\u00f3rzonych zakup\u00f3w GA4 i deduplikacja Pixel\/CAPI maj\u0105 odr\u0119bne regu\u0142y. Zgodno\u015b\u0107 w BigQuery nie dowodzi atrybucji reklamowej ani skutecznej deduplikacji w Meta.<\/p>\nOsobna lista referencyjna ujawnia brak potwierdzenia po obu stronach. Pr\u00f3by wysy\u0142ki s\u0105 agregowane przed por\u00f3wnaniem.<\/figcaption><\/figure>\n
2. Trzy przygotowane tabele przed por\u00f3wnaniem<\/h2>\n
Poni\u017cszy przyk\u0142ad wymaga w\u0142asnych tabel. Po\u0142\u0105czenie GA4 nie tworzy ich automatycznie; najpierw potrzebne s\u0105 procesy wczytywania i kontrola jako\u015bci danych.<\/p>\n
\n
expected_events<\/code>: dok\u0142adnie jeden wiersz na scope_id<\/code>, event_kind<\/code> i event_id<\/code>, a tak\u017ce business_time<\/code> jako rzeczywisty czas zdarzenia biznesowego oraz pola BOOL expected_ga4<\/code> i expected_meta<\/code>. TRUE oznacza przewidzian\u0105 i dozwolon\u0105 identyfikowaln\u0105 wysy\u0142k\u0119 do us\u0142ugi; FALSE brak takiego oczekiwania; NULL stan nierozstrzygni\u0119ty.<\/li>\n
ga4_observations<\/code>: jeden wiersz na faktycznie wyeksportowane zdarzenie, z tym samym kluczem z\u0142o\u017conym i czasem wczytania loaded_at<\/code>. Ponowny odczyt tego samego wiersza eksportu nie mo\u017ce tworzy\u0107 kolejnej obserwacji. Zdarzenia rzeczywi\u015bcie zarejestrowane wielokrotnie pozostaj\u0105 widoczne.<\/li>\n
capi_attempts<\/code>: jeden wiersz na pr\u00f3b\u0119 wysy\u0142ki i powi\u0105zane zdarzenie, z kluczem, loaded_at<\/code> i receipt_state<\/code>. Dozwolone stany to received<\/code>, rejected<\/code> i unknown<\/code>. Stan received<\/code> wymaga potwierdzenia mo\u017cliwego do przypisania konkretnemu zdarzeniu.<\/li>\n<\/ul>\n
Samo HTTP 200 nie dowodzi atrybucji. Odpowied\u017a z liczb\u0105 odebranych zdarze\u0144 wymaga prawid\u0142owego powi\u0105zania z \u017c\u0105daniem. Niejasna lub cz\u0119\u015bciowa odpowied\u017a zbiorcza nie pozwala oznaczy\u0107 wszystkich zdarze\u0144 jako odebrane. B\u0142\u0119dne i niepewne pr\u00f3by pozostaj\u0105 w logu; p\u00f3\u017aniejsze udane powt\u00f3rzenia tworz\u0105 kolejne wpisy. Tokeny dost\u0119pu i pe\u0142ne dane klient\u00f3w nie nale\u017c\u0105 do tego dziennika kontroli.<\/p>\n
Puste identyfikatory, wielokrotne klucze parametr\u00f3w, nieznane nazwy zdarze\u0144 i obserwacje bez wpisu referencyjnego wymagaj\u0105 osobnych list b\u0142\u0119d\u00f3w. Niepoprawne rekordy nie mog\u0105 znika\u0107 bez \u015bladu. scope_id<\/code> okre\u015bla sta\u0142e powi\u0105zanie sklepu, us\u0142ugi lub strumienia GA4 i \u017ar\u00f3d\u0142a danych Meta.<\/p>\n
3. Ocena dnia biznesowego i agregacja powt\u00f3rze\u0144<\/h2>\n
Przyk\u0142adowe zapytanie ocenia dzie\u0144 biznesowy UTC sprzed czterech dni. Zapewnia to odst\u0119p dla zwyk\u0142ych op\u00f3\u017anie\u0144, ale nie gwarantuje kompletno\u015bci. Eksport, lista referencyjna i log CAPI musz\u0105 by\u0107 wystarczaj\u0105co aktualne przed ocen\u0105. Brak tabeli oznacza problem wczytywania, a nie dow\u00f3d zerowej liczby zdarze\u0144.<\/p>\n
Dzienne tabele GA4 stosuj\u0105 stref\u0119 czasow\u0105 us\u0142ugi. Dokumentacja opisuje event_timestamp<\/code> jako czas odbioru; wysy\u0142ka i zdarzenie biznesowe mog\u0105 nast\u0119powa\u0107 w r\u00f3\u017cnym czasie. Dlatego oceniany dzie\u0144 pochodzi tutaj z business_time<\/code>. Przygotowane tabele obserwacji musz\u0105 zawiera\u0107 odpowiednie p\u00f3\u017aniejsze dane. Odczyt wy\u0142\u0105cznie tabeli GA4 nazwanej dat\u0105 zdarzenia biznesowego nie zawsze wystarcza.<\/p>\n
-- GoogleSQL. Prepared tables are defined in the article.\n-- @run_time is supplied by BigQuery Scheduled Queries.\nDECLARE target_day DATE DEFAULT DATE_SUB(DATE(@run_time, 'UTC'), INTERVAL 4 DAY);\nDECLARE observed_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP();\n\nCREATE TEMP TABLE expected AS\nSELECT scope_id, event_kind, event_id, expected_ga4, expected_meta\nFROM `project_id.monitoring.expected_events`\nWHERE business_time >= TIMESTAMP(target_day, 'UTC')\n AND business_time < TIMESTAMP(DATE_ADD(target_day, INTERVAL 1 DAY), 'UTC');\n\nASSERT (\n SELECT COUNT(*) = 0 FROM expected\n WHERE scope_id IS NULL OR TRIM(scope_id) = ''\n OR event_kind IS NULL OR TRIM(event_kind) = ''\n OR event_id IS NULL OR TRIM(event_id) = ''\n) AS 'Invalid key in expected events';\n\nASSERT NOT EXISTS (\n SELECT 1 FROM expected\n GROUP BY scope_id, event_kind, event_id\n HAVING COUNT(*) > 1\n) AS 'Duplicate business-event key';\n\nCREATE TEMP TABLE result AS\nWITH ga4 AS (\n SELECT g.scope_id, g.event_kind, g.event_id, COUNT(*) AS ga4_rows\n FROM `project_id.monitoring.ga4_observations` g\n JOIN expected e USING (scope_id, event_kind, event_id)\n WHERE g.loaded_at <= observed_at\n GROUP BY g.scope_id, g.event_kind, g.event_id\n),\ncapi AS (\n SELECT c.scope_id, c.event_kind, c.event_id,\n COUNT(*) AS capi_attempts,\n COUNTIF(c.receipt_state = 'received') AS capi_receipts,\n COUNTIF(c.receipt_state = 'unknown') AS capi_unknown\n FROM `project_id.monitoring.capi_attempts` c\n JOIN expected e USING (scope_id, event_kind, event_id)\n WHERE c.loaded_at <= observed_at\n GROUP BY c.scope_id, c.event_kind, c.event_id\n)\nSELECT target_day AS business_day, observed_at AS checked_at, e.*,\n COALESCE(g.ga4_rows, 0) AS ga4_rows,\n COALESCE(c.capi_attempts, 0) AS capi_attempts,\n COALESCE(c.capi_receipts, 0) AS capi_receipts,\n COALESCE(c.capi_unknown, 0) AS capi_unknown\nFROM expected e\nLEFT JOIN ga4 g USING (scope_id, event_kind, event_id)\nLEFT JOIN capi c USING (scope_id, event_kind, event_id);\n\nSELECT *,\n CASE\n WHEN expected_ga4 IS NULL OR expected_meta IS NULL THEN 'SCOPE_UNKNOWN'\n WHEN NOT expected_ga4 OR NOT expected_meta THEN 'OUTSIDE_JOINT_SCOPE'\n WHEN ga4_rows > 0 AND capi_receipts > 0 THEN 'OBSERVED_BOTH'\n WHEN ga4_rows = 0 AND capi_receipts = 0 THEN 'UNCONFIRMED_BOTH'\n WHEN ga4_rows = 0 THEN 'UNCONFIRMED_GA4'\n ELSE 'UNCONFIRMED_CAPI'\n END AS reconciliation_status,\n ga4_rows > 1 AS repeated_ga4_rows,\n (expected_ga4 = FALSE AND ga4_rows > 0)\n OR (expected_meta = FALSE AND capi_attempts > 0) AS unexpected_transmission\nFROM result;<\/code><\/pre>\n
Agregacja zapobiega zamianie dw\u00f3ch wierszy GA4 i trzech pr\u00f3b CAPI w sze\u015b\u0107 pozornych zdarze\u0144 biznesowych. Powt\u00f3rzenia pozostaj\u0105 widoczne jako liczby. UNCONFIRMED<\/code> oznacza brak potwierdzenia w dost\u0119pnych danych, niekoniecznie wadliwy tag. unexpected_transmission<\/code> osobno wskazuje wysy\u0142k\u0119 nieprzewidzian\u0105 wed\u0142ug listy referencyjnej.<\/p>\n
Przyk\u0142ad nie stanowi kompletnego procesu wczytywania. Dost\u0119p do tabel wymaga odpowiedniego partycjonowania lub ogranicze\u0144, uprawnie\u0144 i sprawdzenia koszt\u00f3w. Wyniki powinny zawiera\u0107 dzie\u0144 biznesowy i czas kontroli. Ponowna ocena ma zast\u0119powa\u0107 starsze dzienne stany, zamiast dopisywa\u0107 duplikaty zmieniaj\u0105ce wska\u017anik.<\/p>\n
4. Alarm o wyniku, a nie tylko o wykonaniu SQL<\/h2>\n
Widok latest_reconciliation<\/code> zawiera dok\u0142adnie najnowszy pomy\u015blnie obliczony stan dla dnia biznesowego i klucza. Osobne zapytanie poni\u017cej zwraca wy\u0142\u0105cznie dni przekraczaj\u0105ce przyk\u0142adowy pr\u00f3g. Minimum 100 i granica pi\u0119ciu procent wymagaj\u0105 uzasadnienia; nie s\u0105 uniwersaln\u0105 norm\u0105 jako\u015bci.<\/p>\n
-- A separate scheduled SELECT over the latest successful snapshot.\nWITH counts AS (\n SELECT business_day,\n COUNTIF(expected_ga4 AND expected_meta) AS comparable,\n COUNTIF(expected_ga4 AND expected_meta\n AND (ga4_rows = 0 OR capi_receipts = 0)) AS unconfirmed\n FROM `project_id.monitoring.latest_reconciliation`\n GROUP BY business_day\n),\nrates AS (\n SELECT *, 100 * SAFE_DIVIDE(unconfirmed, comparable) AS rate_pct\n FROM counts\n)\nSELECT *\nFROM rates\nWHERE comparable >= 100 AND rate_pct > 5;<\/code><\/pre>\n
Przy braku por\u00f3wnywalnych zdarze\u0144 SAFE_DIVIDE<\/code> pozostawia wska\u017anik nieznany. Zdarzenia poza wsp\u00f3lnym zakresem i nierozstrzygni\u0119te oczekiwania nie wchodz\u0105 do mianownika. Osobne kontrole musz\u0105 obejmowa\u0107 te przypadki, nieoczekiwan\u0105 wysy\u0142k\u0119, niepoprawne ID, powt\u00f3rzenia i niekompletne dop\u0142ywy danych.<\/p>\n
Metryka Scheduled Query last_execution_job_rows<\/code> zlicza wiersze wyniku, a nie warto\u015b\u0107 rate_pct<\/code>. Regu\u0142a Monitoring ograniczona do zapytania zwracaj\u0105cego naruszenia mo\u017ce alarmowa\u0107 przy liczbie wierszy wi\u0119kszej od zera. Poprzednia warto\u015b\u0107 mo\u017ce pozosta\u0107 po b\u0142\u0119dzie lub wy\u0142\u0105czeniu zadania. B\u0142\u0119dy wykonania i aktualno\u015b\u0107 wymagaj\u0105 wi\u0119c osobnego monitorowania; zachowany stary alarm nie jest nowym wynikiem dziennym.<\/p>\n
\n
Pytania i odpowiedzi<\/h2>\n
Czy ID uzgadniania wymaga wymiaru niestandardowego GA4?<\/h3>\n
Nie do odczytu parametru rzeczywi\u015bcie wyeksportowanego w event_params<\/code>. Rejestracja nie gwarantuje jednak wys\u0142ania ani eksportu. Brakuj\u0105ce lub wielokrotne klucze wymagaj\u0105 wykrywania podczas wczytywania.<\/p>\n
Czy wystarcza 48 godzin i uruchomienie o 06:00 UTC?<\/h3>\n
Nie. GA4 mo\u017ce uzupe\u0142nia\u0107 tabele przez kilka dni kalendarzowych i czasami ponownie przetwarza\u0107 dane historyczne. Wysy\u0142ka CAPI i lokalny log maj\u0105 odr\u0119bne op\u00f3\u017anienia. Czas oczekiwania, kontrola aktualno\u015bci i ponowna ocena starszych dni nale\u017c\u0105 do jednego procesu; sta\u0142a godzina nie gwarantuje zako\u0144czenia eksportu.<\/p>\n
Czy ads_storage zast\u0119puje kontrol\u0119 zgody dla Meta?<\/h3>\n
Nie. Yes<\/code>, No<\/code>, Unset<\/code> i brak warto\u015bci nie rozstrzygaj\u0105 automatycznie o zezwoleniu dla innej us\u0142ugi. Oczekiwania musz\u0105 wynika\u0107 z faktycznej, udokumentowanej konfiguracji us\u0142ugi i decyzji. Celowo niewys\u0142ane zdarzenie nie oznacza awarii technicznej, a stan nieznany nie oznacza zgody.<\/p>\n<\/div>\n
![\"Osobna](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/dia-450-reconciliation-20261024-pl.png\")