Monitoring tagów na produkcji: alerty o spadku zdarzeń w GA4 i BigQuery

Co mierzyć w monitoringu tagów: wskaźniki zdrowia danych

Dobry monitoring sprawdza kilka wskaźników, które razem pokazują, czy tagi działają i czy dane są wiarygodne. Sama liczba odsłon nie wystarczy, bo wiele awarii dotyczy tylko jednego zdarzenia lub jednego parametru.

Zacznij od trzech pierwszych wierszy, bo dotyczą przychodu. Pozostałe dodawaj stopniowo, gdy pierwsze alerty przestaną generować fałszywe alarmy.

Alerty w GA4: niestandardowe statystyki krok po kroku

Niestandardowe statystyki (custom insights) w GA4 to najszybszy sposób na alert o spadku zdarzeń, bo nie wymagają BigQuery ani kodu. Możesz ustawić warunek procentowej zmiany albo pozwolić GA4 wykrywać anomalie i dostawać powiadomienie e-mail.

1. Otwórz listę statystyk. Na stronie głównej GA4 przejdź do karty statystyk i wyświetl wszystkie, a następnie wybierz tworzenie nowej od zera. Potrzebujesz roli edytora lub administratora.
2. Wybierz częstotliwość. Dostępne są opcje godzinowa, dzienna, tygodniowa i miesięczna. Godzinowa działa tylko dla danych internetowych.
3. Ustaw segment. Domyślnie wszyscy użytkownicy; możesz zawęzić warunek np. do kraju lub urządzenia.
4. Zdefiniuj warunek. Metryka (np. liczba zdarzeń kluczowych lub przychód), warunek (np. spadek procentowy większy niż) i wartość. Alternatywą jest opcja wykrywania anomalii, w której GA4 sam ocenia, czy zmiana odbiega od normy.
5. Dodaj adresy e-mail. Bez nich statystyka pojawi się tylko w panelu GA4.
6. Nazwij statystykę opisowo, np. „Zakupy – spadek dzień do dnia o ponad 40%”.

Zestaw startowy dla sklepu to cztery statystyki: dzienny spadek zakupów, dzienny spadek przychodu, godzinowa anomalia odsłon i dzienny spadek dodań do koszyka. Dla serwisu leadowego zamień zakupy na zdarzenie kluczowe wysłania formularza.

Statystyki w GA4 mają ograniczenia. Dane są przetwarzane z opóźnieniem, więc alert dzienny dotyczy zwykle poprzedniego dnia, a godzinowe wykrywanie anomalii przy małym ruchu bywa nadwrażliwe. Powiadomienia trafiają tylko na e-mail. Jeśli potrzebujesz własnych progów, porównania z danymi sklepu albo powiadomień na Slacku, przejdź do BigQuery.

Monitoring tagów w BigQuery: zapytanie porównujące dzień z historią

BigQuery pozwala porównać wczorajszą liczbę zdarzeń z historią przy uwzględnieniu dnia tygodnia, co znacznie ogranicza fałszywe alarmy. Warunkiem jest działający eksport GA4 – jak go skonfigurować, opisujemy w tekście o połączeniu GA4 z BigQuery.

Poniższe zapytanie liczy kluczowe zdarzenia z ostatnich 29 dni i zwraca te, których wczoraj było mniej niż 70% średniej z tego samego dnia tygodnia w czterech poprzednich tygodniach:

WITH dzienne AS (
  SELECT
    PARSE_DATE('%Y%m%d', event_date) AS dzien,
    event_name,
    COUNT(*) AS zdarzenia
  FROM `twoj-projekt.analytics_123456789.events_*`
  WHERE _TABLE_SUFFIX BETWEEN
        FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE('Europe/Warsaw'), INTERVAL 29 DAY))
    AND FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE('Europe/Warsaw'), INTERVAL 1 DAY))
    AND event_name IN ('page_view', 'add_to_cart', 'begin_checkout', 'purchase', 'generate_lead')
  GROUP BY 1, 2
),
porownanie AS (
  SELECT
    event_name,
    SUM(IF(dzien = DATE_SUB(CURRENT_DATE('Europe/Warsaw'), INTERVAL 1 DAY), zdarzenia, 0)) AS wczoraj_n,
    AVG(IF(dzien < DATE_SUB(CURRENT_DATE('Europe/Warsaw'), INTERVAL 1 DAY)
           AND EXTRACT(DAYOFWEEK FROM dzien) =
               EXTRACT(DAYOFWEEK FROM DATE_SUB(CURRENT_DATE('Europe/Warsaw'), INTERVAL 1 DAY)),
           zdarzenia, NULL)) AS srednia_n
  FROM dzienne
  GROUP BY 1
)
SELECT
  event_name,
  wczoraj_n,
  ROUND(srednia_n) AS srednia_n,
  ROUND(SAFE_DIVIDE(wczoraj_n, srednia_n), 2) AS wskaznik
FROM porownanie
WHERE SAFE_DIVIDE(wczoraj_n, srednia_n) < 0.7;

Kilka uwag technicznych. Filtr na _TABLE_SUFFIX ogranicza skanowanie do tabel dziennych z ostatnich 29 dni, a tabele events_intraday_ nie spełniają warunku zakresu, więc nie są liczone podwójnie. Pora pojawienia się tabeli dziennej nie jest stała, dlatego kontrolę uruchamiaj w drugiej połowie dnia albo dodaj warunek sprawdzający, czy tabela z wczoraj już istnieje. Zapytanie skanuje tylko kilka kolumn, ale przy dużych usługach i tak warto pilnować kosztów; sposoby opisujemy w artykule o kosztach BigQuery w marketingu.

Na tej samej zasadzie zbudujesz kontrole jakości. Udział zakupów z pustym lub nieustawionym ecommerce.transaction_id, liczba identyfikatorów transakcji występujących więcej niż raz czy odsetek zdarzeń z wartością privacy_info.analytics_storage równą „Yes” to kolejne kolumny tego samego raportu. Jak interpretować zdublowane zakupy, wyjaśniamy w tekście o duplikatach transakcji w GA4.

Najcenniejsza kontrola porównuje GA4 z systemem sklepu. Jeśli dzienna liczba zamówień trafia do BigQuery (z bazy sklepu, eksportu z platformy lub CRM), wystarczy proste złączenie:

SELECT
  s.dzien,
  s.zamowienia_sklep,
  g.zakupy_ga4,
  ROUND(SAFE_DIVIDE(g.zakupy_ga4, s.zamowienia_sklep), 2) AS pokrycie
FROM `twoj-projekt.sklep.zamowienia_dzienne` AS s
LEFT JOIN (
  SELECT
    PARSE_DATE('%Y%m%d', event_date) AS dzien,
    COUNT(DISTINCT ecommerce.transaction_id) AS zakupy_ga4
  FROM `twoj-projekt.analytics_123456789.events_*`
  WHERE _TABLE_SUFFIX BETWEEN
        FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE('Europe/Warsaw'), INTERVAL 14 DAY))
    AND FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE('Europe/Warsaw'), INTERVAL 1 DAY))
    AND event_name = 'purchase'
  GROUP BY 1
) AS g
  ON g.dzien = s.dzien
WHERE s.dzien >= DATE_SUB(CURRENT_DATE('Europe/Warsaw'), INTERVAL 14 DAY)
ORDER BY s.dzien DESC;

Pokrycie stale niższe niż 1 jest normalne, bo część klientów odmawia zgody lub używa blokerów. Sygnałem awarii jest nagła zmiana poziomu. Załóżmy, że przez ostatnie tygodnie GA4 rejestrował ok. 0,85 zamówień ze sklepu, a wczoraj 0,5 – to niemal na pewno problem z tagiem lub banerem. Wartość wyższa niż 1 sugeruje z kolei duplikaty albo zamówienia testowe.

Automatyczne powiadomienia: zapytania harmonogramowane i Apps Script

Wynik zapytania trzeba zamienić w powiadomienie. Najprostsza droga wykorzystuje powiadomienia e-mail o błędzie zapytania harmonogramowanego, a bardziej elastyczna – skrypt Apps Script wysyłający wiadomość na Slacka.

Wariant 1: zapytanie harmonogramowane z wymuszonym błędem. Zapisz wynik kontroli w tabeli tymczasowej i zakończ skrypt instrukcją, która przerywa go błędem, gdy znaleziono anomalie. W ustawieniach harmonogramu włącz powiadomienia e-mail – właściciel zapytania dostanie wiadomość o niepowodzeniu.

CREATE TEMP TABLE anomalie AS
SELECT 'purchase' AS event_name;  -- tutaj wklej zapytanie kontrolne z poprzedniej sekcji

SELECT IF(
  (SELECT COUNT(*) FROM anomalie) > 0,
  ERROR('Monitoring tagów: spadek zdarzeń GA4 – sprawdź tagi'),
  'OK'
);

Wariant 2: Apps Script i webhook. Zapytanie harmonogramowane codziennie nadpisuje tabelę monitoring.anomalie_wczoraj, a skrypt uruchamiany wyzwalaczem czasowym odczytuje ją i wysyła podsumowanie. W projekcie Apps Script włącz usługę zaawansowaną BigQuery, a adres webhooka zapisz we właściwościach skryptu, nie w kodzie.

function sprawdzMonitoringTagow() {
  var projectId = 'twoj-projekt';
  var sql = 'SELECT event_name, wczoraj_n, srednia_n, wskaznik ' +
            'FROM `twoj-projekt.monitoring.anomalie_wczoraj`';
  var wynik = BigQuery.Jobs.query({ query: sql, useLegacySql: false, timeoutMs: 60000 }, projectId);
  var wiersze = wynik.rows || [];
  if (wiersze.length === 0) return;

  var linie = wiersze.map(function (r) {
    return r.f[0].v + ': wczoraj ' + r.f[1].v + ', średnio ' + r.f[2].v + ' (wskaźnik ' + r.f[3].v + ')';
  });
  var webhook = PropertiesService.getScriptProperties().getProperty('SLACK_WEBHOOK');
  UrlFetchApp.fetch(webhook, {
    method: 'post',
    contentType: 'application/json',
    payload: JSON.stringify({ text: 'Monitoring tagów – spadki zdarzeń:\n' + linie.join('\n') })
  });
}

Ten sam wzorzec stosuje się przy kontroli kont reklamowych; przykłady takich skryptów znajdziesz w tekście o skryptach Google Ads wyłapujących anomalie budżetu, a budowę przepływów z powiadomieniami bez programowania w poradniku o automatyzacji raportów w n8n.

Testy syntetyczne: robot sprawdzający ścieżkę zakupu

Test syntetyczny to skrypt, który regularnie otwiera wybrane strony w przeglądarce bez interfejsu i sprawdza, czy tagi wysłały oczekiwane żądania. Wykrywa awarię w ciągu minut, a nie dopiero następnego dnia.

Poniższy przykład w Playwright otwiera stronę produktu, akceptuje baner zgód i sprawdza, czy do GA4 trafiły zdarzenia page_view i view_item. Uwzględnia to, że tag Google potrafi wysyłać kilka zdarzeń w jednym żądaniu, w treści zamiast w adresie.

const { chromium } = require('playwright');

(async () => {
  const browser = await chromium.launch();
  const page = await browser.newPage();
  const zdarzenia = [];

  page.on('request', (req) => {
    if (!req.url().includes('/g/collect')) return;
    const dane = req.url() + '\n' + (req.postData() || '');
    (dane.match(/(?:^|[?&\n])en=[^&\n]+/g) || []).forEach((m) => {
      zdarzenia.push(decodeURIComponent(m.split('=')[1]));
    });
  });

  await page.goto('https://twojsklep.pl/produkt/testowy/?pi_robot=1');
  await page.click('#akceptuj-wszystkie').catch(() => {}); // selektor Twojej platformy zgód
  await page.waitForTimeout(6000);
  await browser.close();

  const ok = zdarzenia.includes('page_view') && zdarzenia.includes('view_item');
  console.log(ok ? 'OK' : 'BŁĄD, wysłane zdarzenia: ' + JSON.stringify(zdarzenia));
  process.exit(ok ? 0 : 1);
})();

Skrypt uruchamiaj co 15–60 minut z serwera lub usługi CI i podłącz kod wyjścia do powiadomień. Pełnego zakupu nie testuj w ten sposób na produkcji – ścieżkę zamówienia sprawdzaj na środowisku testowym z osobnym strumieniem danych. Ruch z robota oznacz jako wewnętrzny, np. ustawiając w tagu parametr traffic_type o wartości internal, gdy adres zawiera znacznik pi_robot, albo dodając adres IP serwera do definicji ruchu wewnętrznego, i wyklucz go filtrem danych.

Jeśli korzystasz z serwerowego kontenera GTM, dołóż monitoring infrastruktury: alerty o odsetku błędów 5xx i czasie odpowiedzi w Cloud Monitoring albo w panelu dostawcy hostingu. Porównanie opcji hostingu znajdziesz w tekście o hostingu server-side GTM.

Jak ustawić progi i procedurę reakcji, żeby alerty nie były szumem

Alert, który często fałszywie alarmuje, szybko przestaje być czytany. Progi dopasuj do wolumenu i sezonowości, a dla każdego alertu przygotuj krótką procedurę reakcji.

• Przy małym ruchu porównuj dane tygodniowe zamiast dziennych albo podnieś próg – przy kilku zakupach dziennie spadek o 50% bywa przypadkiem.
• W okresach promocji, takich jak Black Friday, porównanie z poprzednimi tygodniami zawyży oczekiwania w drugą stronę; na ten czas dodaj ręczną kontrolę zamówień w sklepie.
• Po publikacji nowej wersji kontenera sprawdzaj alerty z większą uwagą przez 48 godzin.

Procedura po otrzymaniu alertu:

1. Sprawdź, czy spadek widać też w danych sklepu lub CRM. Jeśli tak, problem może być biznesowy, a nie techniczny.
2. Sprawdź historię wersji kontenera GTM i wdrożeń strony z ostatnich dni.
3. Otwórz stronę w podglądzie GTM i w karcie Network, zgodnie z procedurą, jak sprawdzić, czy tag działa.
4. Zweryfikuj zdarzenia w DebugView; typowe przyczyny braków opisujemy w liście problemów z DebugView w GA4.
5. Po naprawie zapisz incydent: datę, przyczynę i okres z niepełnymi danymi.

Monitoring nie zastępuje okresowego przeglądu kontenera. Przed sezonem wykonaj pełny audyt tagów przed Black Friday. Wszystkie poradniki diagnostyczne znajdziesz w podtemacie Debugowanie tagów, a informacje o eksporcie danych na stronie narzędzia BigQuery.