{"id":461,"date":"2026-09-11T17:15:00","date_gmt":"2026-09-11T15:15:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/?p=461"},"modified":"2026-10-26T11:59:00","modified_gmt":"2026-10-26T10:59:00","slug":"automatyczne-alerty-jakosci-danych-ga4-w-looker-studio-i-bigquery","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/pl\/digital-analytics-pl\/tutorials-pl\/automatyczne-alerty-jakosci-danych-ga4-w-looker-studio-i-bigquery\/","title":{"rendered":"Automatyczne alerty jako\u015bci danych GA4 w Looker Studio i BigQuery"},"content":{"rendered":"
Awaria pomiaru mo\u017ce pozosta\u0107 niezauwa\u017cona, mimo \u017ce strona dzia\u0142a poprawnie. Dzienna kontrola liczby zdarze\u0144 dostarcza wskaz\u00f3wki: ile zdarze\u0144 trafi\u0142o do eksportu i jak wynik r\u00f3\u017cni si\u0119 od por\u00f3wnywalnego dnia tygodnia? BigQuery oblicza por\u00f3wnanie, a Looker Studio pokazuje wyniki. Powiadomienie wymaga dodatkowo skonfigurowanej regu\u0142y alertu.<\/p>\n
Przyk\u0142ad sprawdza cztery nazwy zdarze\u0144. Nie weryfikuje wszystkich parametr\u00f3w ani ca\u0142ego procesu pomiaru. Kampanie, \u015bwi\u0119ta i zmiany zg\u00f3d r\u00f3wnie\u017c mog\u0105 powodowa\u0107 odchylenia.<\/p>\n
1. Dost\u0119pno\u015b\u0107 danych przed liczb\u0105 zdarze\u0144<\/h2>\n
Sprawdzany jest dzie\u0144 sprzed czterech dni oraz ten sam dzie\u0144 tygodnia z o\u015bmiu wcze\u015bniejszych tygodni. Dzie\u0144 badany nie wchodzi do \u015bredniej odniesienia. Op\u00f3\u017anienie daje czas na eksport, ale nie potwierdza kompletno\u015bci. GA4 nie gwarantuje jednej godziny zako\u0144czenia eksportu dziennego; 05:30 UTC nie jest bezpieczn\u0105 granic\u0105.<\/p>\n
Brak tabeli dziennej pozostaje warto\u015bci\u0105 nieznan\u0105. Brak zdarzenia oznacza zero dopiero przy istniej\u0105cej tabeli. Istniej\u0105ca tabela te\u017c mo\u017ce by\u0107 niepe\u0142na. session_start<\/code> oznacza tutaj liczb\u0119 takich zdarze\u0144, a nie odtworzon\u0105 metryk\u0119 sesji GA4.<\/p>\nDost\u0119pno\u015b\u0107, por\u00f3wnanie i dostarczenie wymagaj\u0105 osobnych kontroli. Zmiana wzgl\u0119dem sta\u0142ej bazy nie mo\u017ce zosta\u0107 uznana za wynik bez odchyle\u0144.<\/figcaption><\/figure>\n
2. Przyk\u0142ad SQL z oddzielnymi stanami b\u0142\u0119d\u00f3w<\/h2>\n
Projekt, zestaw danych i ka\u017cde wyst\u0105pienie strefy raportowania wymagaj\u0105 dostosowania. Zapytanie oczekuje tabel dziennych GA4 o zgodnym schemacie. Brak wszystkich pasuj\u0105cych tabel lub uprawnie\u0144 powoduje b\u0142\u0105d zadania; ten przypadek wymaga oddzielnego nadzoru dzia\u0142ania. Przed ustawieniem harmonogramu potrzebne s\u0105 pr\u00f3bne wykonanie w BigQuery i oszacowanie kosztu.<\/p>\n
-- GoogleSQL; replace project, dataset and reporting timezone.\nWITH dates AS (\n SELECT d AS metric_date,\n DATE_SUB(CURRENT_DATE('Europe\/Warsaw'), INTERVAL 4 DAY) AS target_date\n FROM UNNEST(GENERATE_DATE_ARRAY(\n DATE_SUB(CURRENT_DATE('Europe\/Warsaw'), INTERVAL 60 DAY),\n DATE_SUB(CURRENT_DATE('Europe\/Warsaw'), INTERVAL 4 DAY),\n INTERVAL 7 DAY)) AS d\n),\navailable AS (\n SELECT table_name\n FROM `project_id.analytics_XXXXXXXXX.INFORMATION_SCHEMA.TABLES`\n WHERE table_type = 'BASE TABLE'\n),\ncounts AS (\n SELECT PARSE_DATE('%Y%m%d', event_date) AS metric_date,\n event_name, COUNT(*) AS event_count\n FROM `project_id.analytics_XXXXXXXXX.events_*`\n WHERE _TABLE_SUFFIX BETWEEN\n FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE('Europe\/Warsaw'), INTERVAL 60 DAY))\n AND FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE('Europe\/Warsaw'), INTERVAL 4 DAY))\n AND event_name IN ('purchase', 'add_to_cart', 'begin_checkout', 'session_start')\n GROUP BY 1, 2\n),\ngrid AS (\n SELECT d.metric_date, d.target_date, n AS event_name,\n IF(a.table_name IS NULL, NULL, COALESCE(c.event_count, 0)) AS event_count\n FROM dates AS d\n CROSS JOIN UNNEST(['purchase', 'add_to_cart', 'begin_checkout', 'session_start']) AS n\n LEFT JOIN available AS a\n ON a.table_name = CONCAT('events_', FORMAT_DATE('%Y%m%d', d.metric_date))\n LEFT JOIN counts AS c ON c.metric_date = d.metric_date AND c.event_name = n\n),\nstats AS (\n SELECT target_date AS metric_date, event_name,\n MAX(IF(metric_date = target_date, event_count, NULL)) AS event_count,\n COUNT(IF(metric_date < target_date, event_count, NULL)) AS reference_days,\n AVG(IF(metric_date < target_date, event_count, NULL)) AS expected_avg,\n STDDEV_SAMP(IF(metric_date < target_date, event_count, NULL)) AS reference_sd\n FROM grid\n GROUP BY target_date, event_name\n),\nscored AS (\n SELECT *,\n IF(reference_days = 8,\n SAFE_DIVIDE(event_count - expected_avg, reference_sd), NULL) AS z_score\n FROM stats\n),\nclassified AS (\n SELECT *,\n CASE\n WHEN event_count IS NULL THEN 'MISSING_EXPORT'\n WHEN reference_days != 8 THEN 'INCOMPLETE_BASELINE'\n WHEN reference_sd = 0 AND event_count != expected_avg THEN 'CONSTANT_BASELINE_CHANGE'\n WHEN reference_sd = 0 THEN 'NO_CHANGE'\n WHEN z_score < -2.0 THEN 'DROP'\n WHEN z_score > 3.0 THEN 'SPIKE'\n ELSE 'WITHIN_RULE'\n END AS quality_status\n FROM scored\n)\nSELECT *, CURRENT_TIMESTAMP() AS evaluated_at,\n IF(quality_status IN ('NO_CHANGE', 'WITHIN_RULE'), 0, 1) AS alert_flag\nFROM classified\nORDER BY event_name;\n<\/code><\/pre>\n
reference_days<\/code> musi wynosi\u0107 osiem. Brak odniesienia daje INCOMPLETE_BASELINE<\/code>, a brak dnia badanego \u2014 MISSING_EXPORT<\/code>. Sta\u0142a baza nie pozwala na dzielenie przez odchylenie standardowe: osiem warto\u015bci 100 i nast\u0119pnie zero daje wi\u0119c CONSTANT_BASELINE_CHANGE<\/code>. Osiem warto\u015bci 100 i ponownie 100 daje NO_CHANGE<\/code>.<\/p>\n
Przy zmiennej bazie wynik z opisuje odleg\u0142o\u015b\u0107 od \u015bredniej wzgl\u0119dem rozrzutu o\u015bmiu warto\u015bci odniesienia. Na przyk\u0142ad \u015brednia 100, odchylenie standardowe pr\u00f3by 10 i nowa warto\u015b\u0107 70 daj\u0105 (70 \u2212 100) \/ 10 = \u22123. Odchylenie standardowe okre\u015bla, jak bardzo warto\u015bci odniesienia r\u00f3\u017cni\u0105 si\u0119 mi\u0119dzy sob\u0105. Progi \u22122 i +3 s\u0105 regu\u0142ami do dalszej analizy, nie skalibrowanymi testami istotno\u015bci. Osiem obserwacji to ma\u0142a podstawa; wiele r\u00f3wnoczesnych kontroli i niewielkie liczby zdarze\u0144 mog\u0105 prowadzi\u0107 do myl\u0105cych wskaza\u0144. WITHIN_RULE<\/code> oznacza wy\u0142\u0105cznie brak uruchomienia tej regu\u0142y.<\/p>\n
3. Zapis wynik\u00f3w i wysy\u0142anie alert\u00f3w<\/h2>\n\n
Utworzenie zestawu danych monitoringu w odpowiednim regionie BigQuery. Kontrola uprawnie\u0144 odczytu i zapisu to\u017csamo\u015bci wykonuj\u0105cej zadanie.<\/li>\n
Pr\u00f3bne wykonanie zapytania. Oczekiwane s\u0105 cztery wiersze z evaluated_at<\/code> i alert_flag<\/code>. Kontrola kosztu: zakres tabel obejmuje 57 dni, cho\u0107 potrzebnych jest dziewi\u0119\u0107 dat por\u00f3wnania.<\/li>\n
Dob\u00f3r harmonogramu na podstawie obserwowanej dost\u0119pno\u015bci eksportu. Tabela bie\u017c\u0105cego wyniku mo\u017ce by\u0107 zast\u0119powana po ka\u017cdym udanym przebiegu. Oddzielna historia wymaga identyfikatora wykonania i obs\u0142ugi powt\u00f3rze\u0144; dopisywanie bez kontroli tworzy duplikaty.<\/li>\n
Prezentacja daty, zdarzenia, liczby, \u015bredniej odniesienia, statusu i czasu oceny w Looker Studio. Alerty wykres\u00f3w Pro obs\u0142uguj\u0105 e-mail i dzia\u0142aj\u0105 na filtrach domy\u015blnych. Wysy\u0142ka raportu do Google Chat jest inn\u0105 funkcj\u0105 ni\u017c warunkowy alert danych.<\/li>\n
Dla Cloud Monitoring oddzielne zapytanie zwracaj\u0105ce tylko wiersze alarmowe. Automatyczna metryka bigquerydatatransfer.googleapis.com\/transfer_config\/last_execution_job_rows<\/code> liczy wiersze wyniku, nie warto\u015bci z. Potrzebny jest filtr w\u0142a\u015bciwego config_id<\/code> i pr\u00f3g powy\u017cej zera.<\/li>\n<\/ol>\n
Zapytanie alarmowe powinno nast\u0119powa\u0107 po udanym obliczeniu oraz sprawdza\u0107 \u015bwie\u017co\u015b\u0107, oczekiwan\u0105 dat\u0119 i wszystkie cztery wiersze. Stary poprawny wynik nie mo\u017ce zas\u0142ania\u0107 awarii nowego przebiegu. B\u0142\u0119dy zada\u0144 i brak kolejnego wykonania wymagaj\u0105 osobnych ostrze\u017ce\u0144: ostatnia liczba wierszy mo\u017ce utrzymywa\u0107 si\u0119 po awarii. Kana\u0142y powiadomie\u0144 wymagaj\u0105 kontroli na przygotowanych przypadkach testowych.<\/p>\n
4. Kontrole przed codziennym u\u017cyciem<\/h2>\n
\n
Sta\u0142a baza i ca\u0142kowity zanik zdarze\u0144: zg\u0142oszona zmiana, bez fa\u0142szywego wyniku normalnego.<\/li>\n
Brak tabeli dziennej: brak eksportu, bez wymy\u015blonego zera zdarze\u0144.<\/li>\n
Brak tygodnia odniesienia: por\u00f3wnanie wstrzymane.<\/li>\n
Niezmieniona sta\u0142a baza: brak zmiany.<\/li>\n
B\u0142\u0105d zadania lub stary wynik: ostrze\u017cenie operacyjne niezale\u017cne od statusu jako\u015bci.<\/li>\n<\/ul>\n
Decyzj\u0119 o statusie sprawdzono w izolacji na danych syntetycznych. Nie potwierdza to dzia\u0142ania instalacji BigQuery, Pro ani Cloud Monitoring. Codzienna kontrola z czterodniowym op\u00f3\u017anieniem nie zapewnia natychmiastowych alert\u00f3w awarii. Szybsze wykrywanie wymaga osobnej oceny danych wst\u0119pnych.<\/p>\n
\n
Pytania i odpowiedzi<\/h2>\n
Dlaczego uzupe\u0142nienie brak\u00f3w zerami nie wystarcza?<\/h3>\n
Bez siatki dat znikaj\u0105 dni bez zdarze\u0144. Uzupe\u0142nienie ka\u017cdej luki zerem myli jednak brak eksportu z zaobserwowanym dniem zerowym. Przyk\u0142ad sprawdza r\u00f3wnie\u017c istnienie tabeli.<\/p>\n
Czy wskazanie dowodzi awarii pomiaru?<\/h3>\n
Nie. Analiza potrzebuje dodatkowych informacji: wdro\u017ce\u0144, zmian CMP, kampanii, b\u0142\u0119d\u00f3w serwera i stanu eksportu. Regu\u0142a liczby zdarze\u0144 nie ustala przyczyny ani nie weryfikuje warto\u015bci poszczeg\u00f3lnych parametr\u00f3w.<\/p>\n<\/div>\n
<\/p>\n
Kontrola w praktyce: baza dni tygodnia bez sprawdzanego dnia<\/h2>\n
![\"Dost\u0119pno\u015b\u0107,](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/dia-459-alerts-20261024-pl.png\")