Automatyczne alerty jakości danych GA4 w Looker Studio i BigQuery

Awaria pomiaru może pozostać niezauważona, mimo że strona działa poprawnie. Dzienna kontrola liczby zdarzeń dostarcza wskazówki: ile zdarzeń trafiło do eksportu i jak wynik różni się od porównywalnego dnia tygodnia? BigQuery oblicza porównanie, a Looker Studio pokazuje wyniki. Powiadomienie wymaga dodatkowo skonfigurowanej reguły alertu.

Przykład sprawdza cztery nazwy zdarzeń. Nie weryfikuje wszystkich parametrów ani całego procesu pomiaru. Kampanie, święta i zmiany zgód również mogą powodować odchylenia.

1. Dostępność danych przed liczbą zdarzeń

Sprawdzany jest dzień sprzed czterech dni oraz ten sam dzień tygodnia z ośmiu wcześniejszych tygodni. Dzień badany nie wchodzi do średniej odniesienia. Opóźnienie daje czas na eksport, ale nie potwierdza kompletności. GA4 nie gwarantuje jednej godziny zakończenia eksportu dziennego; 05:30 UTC nie jest bezpieczną granicą.

Brak tabeli dziennej pozostaje wartością nieznaną. Brak zdarzenia oznacza zero dopiero przy istniejącej tabeli. Istniejąca tabela też może być niepełna. session_start oznacza tutaj liczbę takich zdarzeń, a nie odtworzoną metrykę sesji GA4.

2. Przykład SQL z oddzielnymi stanami błędów

Projekt, zestaw danych i każde wystąpienie strefy raportowania wymagają dostosowania. Zapytanie oczekuje tabel dziennych GA4 o zgodnym schemacie. Brak wszystkich pasujących tabel lub uprawnień powoduje błąd zadania; ten przypadek wymaga oddzielnego nadzoru działania. Przed ustawieniem harmonogramu potrzebne są próbne wykonanie w BigQuery i oszacowanie kosztu.

-- GoogleSQL; replace project, dataset and reporting timezone.
WITH dates AS (
  SELECT d AS metric_date,
    DATE_SUB(CURRENT_DATE('Europe/Warsaw'), INTERVAL 4 DAY) AS target_date
  FROM UNNEST(GENERATE_DATE_ARRAY(
    DATE_SUB(CURRENT_DATE('Europe/Warsaw'), INTERVAL 60 DAY),
    DATE_SUB(CURRENT_DATE('Europe/Warsaw'), INTERVAL 4 DAY),
    INTERVAL 7 DAY)) AS d
),
available AS (
  SELECT table_name
  FROM `project_id.analytics_XXXXXXXXX.INFORMATION_SCHEMA.TABLES`
  WHERE table_type = 'BASE TABLE'
),
counts AS (
  SELECT PARSE_DATE('%Y%m%d', event_date) AS metric_date,
    event_name, COUNT(*) AS event_count
  FROM `project_id.analytics_XXXXXXXXX.events_*`
  WHERE _TABLE_SUFFIX BETWEEN
    FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE('Europe/Warsaw'), INTERVAL 60 DAY))
    AND FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE('Europe/Warsaw'), INTERVAL 4 DAY))
    AND event_name IN ('purchase', 'add_to_cart', 'begin_checkout', 'session_start')
  GROUP BY 1, 2
),
grid AS (
  SELECT d.metric_date, d.target_date, n AS event_name,
    IF(a.table_name IS NULL, NULL, COALESCE(c.event_count, 0)) AS event_count
  FROM dates AS d
  CROSS JOIN UNNEST(['purchase', 'add_to_cart', 'begin_checkout', 'session_start']) AS n
  LEFT JOIN available AS a
    ON a.table_name = CONCAT('events_', FORMAT_DATE('%Y%m%d', d.metric_date))
  LEFT JOIN counts AS c ON c.metric_date = d.metric_date AND c.event_name = n
),
stats AS (
  SELECT target_date AS metric_date, event_name,
    MAX(IF(metric_date = target_date, event_count, NULL)) AS event_count,
    COUNT(IF(metric_date < target_date, event_count, NULL)) AS reference_days,
    AVG(IF(metric_date < target_date, event_count, NULL)) AS expected_avg,
    STDDEV_SAMP(IF(metric_date < target_date, event_count, NULL)) AS reference_sd
  FROM grid
  GROUP BY target_date, event_name
),
scored AS (
  SELECT *,
    IF(reference_days = 8,
      SAFE_DIVIDE(event_count - expected_avg, reference_sd), NULL) AS z_score
  FROM stats
),
classified AS (
  SELECT *,
    CASE
      WHEN event_count IS NULL THEN 'MISSING_EXPORT'
      WHEN reference_days != 8 THEN 'INCOMPLETE_BASELINE'
      WHEN reference_sd = 0 AND event_count != expected_avg THEN 'CONSTANT_BASELINE_CHANGE'
      WHEN reference_sd = 0 THEN 'NO_CHANGE'
      WHEN z_score < -2.0 THEN 'DROP'
      WHEN z_score > 3.0 THEN 'SPIKE'
      ELSE 'WITHIN_RULE'
    END AS quality_status
  FROM scored
)
SELECT *, CURRENT_TIMESTAMP() AS evaluated_at,
  IF(quality_status IN ('NO_CHANGE', 'WITHIN_RULE'), 0, 1) AS alert_flag
FROM classified
ORDER BY event_name;

reference_days musi wynosić osiem. Brak odniesienia daje INCOMPLETE_BASELINE, a brak dnia badanego — MISSING_EXPORT. Stała baza nie pozwala na dzielenie przez odchylenie standardowe: osiem wartości 100 i następnie zero daje więc CONSTANT_BASELINE_CHANGE. Osiem wartości 100 i ponownie 100 daje NO_CHANGE.

Przy zmiennej bazie wynik z opisuje odległość od średniej względem rozrzutu ośmiu wartości odniesienia. Na przykład średnia 100, odchylenie standardowe próby 10 i nowa wartość 70 dają (70 − 100) / 10 = −3. Odchylenie standardowe określa, jak bardzo wartości odniesienia różnią się między sobą. Progi −2 i +3 są regułami do dalszej analizy, nie skalibrowanymi testami istotności. Osiem obserwacji to mała podstawa; wiele równoczesnych kontroli i niewielkie liczby zdarzeń mogą prowadzić do mylących wskazań. WITHIN_RULE oznacza wyłącznie brak uruchomienia tej reguły.

3. Zapis wyników i wysyłanie alertów

1. Utworzenie zestawu danych monitoringu w odpowiednim regionie BigQuery. Kontrola uprawnień odczytu i zapisu tożsamości wykonującej zadanie.
2. Próbne wykonanie zapytania. Oczekiwane są cztery wiersze z evaluated_at i alert_flag. Kontrola kosztu: zakres tabel obejmuje 57 dni, choć potrzebnych jest dziewięć dat porównania.
3. Dobór harmonogramu na podstawie obserwowanej dostępności eksportu. Tabela bieżącego wyniku może być zastępowana po każdym udanym przebiegu. Oddzielna historia wymaga identyfikatora wykonania i obsługi powtórzeń; dopisywanie bez kontroli tworzy duplikaty.
4. Prezentacja daty, zdarzenia, liczby, średniej odniesienia, statusu i czasu oceny w Looker Studio. Alerty wykresów Pro obsługują e-mail i działają na filtrach domyślnych. Wysyłka raportu do Google Chat jest inną funkcją niż warunkowy alert danych.
5. Dla Cloud Monitoring oddzielne zapytanie zwracające tylko wiersze alarmowe. Automatyczna metryka bigquerydatatransfer.googleapis.com/transfer_config/last_execution_job_rows liczy wiersze wyniku, nie wartości z. Potrzebny jest filtr właściwego config_id i próg powyżej zera.

Zapytanie alarmowe powinno następować po udanym obliczeniu oraz sprawdzać świeżość, oczekiwaną datę i wszystkie cztery wiersze. Stary poprawny wynik nie może zasłaniać awarii nowego przebiegu. Błędy zadań i brak kolejnego wykonania wymagają osobnych ostrzeżeń: ostatnia liczba wierszy może utrzymywać się po awarii. Kanały powiadomień wymagają kontroli na przygotowanych przypadkach testowych.

4. Kontrole przed codziennym użyciem

• Stała baza i całkowity zanik zdarzeń: zgłoszona zmiana, bez fałszywego wyniku normalnego.
• Brak tabeli dziennej: brak eksportu, bez wymyślonego zera zdarzeń.
• Brak tygodnia odniesienia: porównanie wstrzymane.
• Niezmieniona stała baza: brak zmiany.
• Błąd zadania lub stary wynik: ostrzeżenie operacyjne niezależne od statusu jakości.

Decyzję o statusie sprawdzono w izolacji na danych syntetycznych. Nie potwierdza to działania instalacji BigQuery, Pro ani Cloud Monitoring. Codzienna kontrola z czterodniowym opóźnieniem nie zapewnia natychmiastowych alertów awarii. Szybsze wykrywanie wymaga osobnej oceny danych wstępnych.

Kontrola w praktyce: baza dni tygodnia bez sprawdzanego dnia

Detektor anomalii GA4 porównuje teraz wybrany dzień raportowy z tym samym dniem tygodnia z ośmiu poprzednich tygodni. Czwartek jest porównywany z ośmioma czwartkami. Sprawdzany dzień nie wchodzi do średniej odniesienia ani odchylenia standardowego próby. Silny spadek nie obniża więc własnej bazy.

Narzędzie odczytuje sesje, wszystkich użytkowników, wyświetlenia stron/ekranów, kluczowe zdarzenia, liczbę zdarzeń, łączne przychody i współczynnik zaangażowania przez Data API tylko do odczytu. Domyślnie wybrany jest dzień sprzed czterech dni, aby uwzględnić czas przetwarzania. Ten odstęp nie potwierdza jednak kompletności danych. Nadal istotne są strefa raportowania usługi i metadane odpowiedzi.

1. Wybór zakończonego dnia i kontrola ośmiu dat odniesienia pokazanych w wyniku.
2. Jeżeli w odpowiedzi brakuje wymaganej daty, porównanie zostaje wstrzymane. Brak wiersza nie jest po cichu zastępowany zerem; jawnie raportowane zero pozostaje zerem.
3. Ocena opisowego wyniku z względem wybranego progu. Dla stałej bazy pokazywany jest brak zmiany lub zmiana względem stałej wartości, bez dzielenia przez zero.
4. Pobranie dziewięciu porównywanych dat jako CSV i zestawienie wskazań z wdrożeniami, kampaniami, świętami i innymi dowodami.

Osiem obserwacji to niewielka baza. Wskazania nie są skalibrowanymi testami istotności, a siedem równoczesnych kontroli metryk może dawać przypadkowe wyniki. Porównanie tych samych dni tygodnia nie usuwa trendów, akcji specjalnych, zmian zgód ani opóźnień przetwarzania. Brak wskazania nie dowodzi kompletności pomiaru, a wskazanie nie ustala przyczyny. To narzędzie do ręcznej analizy, nie usługa cyklicznych alarmów.

Źródła: dokumentacja Google runReport, definicje metryk i NIST o wykrywaniu obserwacji odstających i jego założeniach.

Źródła

• GA4: czas eksportu i ograniczenia
• GA4: schemat eksportu
• Wykaz tabel
• Odchylenie standardowe próby
• Konfiguracja zapytań cyklicznych
• Alert według liczby wierszy i ograniczenia działania
• Alerty wykresów Pro
• Obserwacje odstające i założenia o rozkładzie danych