Automatisierte Datenqualitäts-Alarme für GA4 mit Looker Studio & BigQuery

Ein Trackingfehler kann unbemerkt bleiben, obwohl die Website normal funktioniert. Ein täglicher Mengenvergleich liefert dafür Hinweise: Wie viele Ereignisse wurden exportiert, und wie stark weicht die Zahl vom üblichen Wochentag ab? BigQuery berechnet den Vergleich; Looker Studio zeigt die Ergebnisse. Eine Benachrichtigung braucht zusätzlich eine eingerichtete Alarmregel.

Das folgende Beispiel prüft vier Ereignisnamen. Es kontrolliert weder alle Parameter noch die vollständige Messkette. Ein auffälliger Wert kann auch durch Kampagnen, Feiertage oder geänderte Einwilligungen entstehen.

1. Erst Datenverfügbarkeit, dann Ereigniszahl

Der Vergleich verwendet den Tag vor vier Tagen und denselben Wochentag der acht vorherigen Wochen. Der Prüftag geht nicht in den Referenzmittelwert ein. Der zeitliche Abstand lässt Raum für verspätete Exporte, beweist aber keine Vollständigkeit. Für GA4 gibt es keinen allgemein garantierten täglichen Exportzeitpunkt; insbesondere ist 05:30 UTC keine sichere Grenze.

Eine fehlende Tagestabelle bleibt ein unbekannter Wert. Nur bei vorhandener Tabelle wird ein nicht vorkommendes Ereignis als null gezählt. Auch eine vorhandene Tabelle kann unvollständig sein. session_start bezeichnet hier die Anzahl dieses Ereignisses, keine nachgebildete GA4-Sitzungskennzahl.

2. SQL-Beispiel mit getrennten Fehlerzuständen

Projekt, Dataset und alle Vorkommen der Berichtszeitzone sind anzupassen. Die Abfrage erwartet GA4-Tagestabellen mit kompatiblem Schema. Fehlen sämtliche passenden Tabellen oder Zugriffsrechte, scheitert der Job; dafür ist eine eigene Betriebsüberwachung erforderlich. Vor der Zeitplanung gehören ein BigQuery-Probelauf und eine Kostenprüfung zum Einsatz.

-- 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 muss acht sein. Bei fehlender Basis entsteht INCOMPLETE_BASELINE, bei fehlendem Prüftag MISSING_EXPORT. Eine konstante Vergleichsbasis erlaubt keine Division durch die Standardabweichung: Achtmal 100 und anschließend null ergibt deshalb CONSTANT_BASELINE_CHANGE. Achtmal 100 und erneut 100 ergibt NO_CHANGE.

Bei schwankender Basis beschreibt der z-Wert den Abstand zum Mittelwert im Verhältnis zur Streuung der acht Vergleichswerte. Bei einem Mittelwert von 100, einer Stichproben-Standardabweichung von 10 und einem neuen Wert von 70 ergibt sich beispielsweise (70 − 100) / 10 = −3. Die Standardabweichung beschreibt, wie stark die Vergleichswerte auseinanderliegen. Die Grenzen −2 und +3 sind hier Untersuchungsregeln, keine kalibrierten Signifikanztests. Acht Beobachtungen sind wenig; mehrere gleichzeitige Prüfungen und geringe Ereigniszahlen erhöhen das Risiko unpassender Hinweise. WITHIN_RULE bedeutet lediglich, dass diese Regel nicht anschlägt.

3. Speicherung und Alarmzustellung

1. Ein Monitoring-Dataset in einer passenden BigQuery-Region anlegen. Lese- und Schreibrechte der ausführenden Identität prüfen.
2. Die Abfrage zunächst manuell ausführen. Erwartet werden vier Zeilen einschließlich evaluated_at und alert_flag. Kostenabschätzung beachten: Der Tabellenbereich umfasst 57 Tage, obwohl nur neun Vergleichstage benötigt werden.
3. Die Zeitplanung nach beobachteter Exportverfügbarkeit wählen. Für den aktuellen Prüfstand kann die Zieltabelle bei jedem erfolgreichen Lauf ersetzt werden. Eine zusätzliche Historie benötigt Laufkennung und eine Regel gegen doppelte Wiederholungen; blindes Anhängen erzeugt sonst Duplikate.
4. In Looker Studio den aktuellen Prüfstand anzeigen: Datum, Ereignis, Anzahl, Referenzmittel, Status und Auswertungszeit. Pro-Diagrammwarnungen unterstützen E-Mail-Benachrichtigungen; die Bedingungen gelten für Standardfilter. Eine Report-Zustellung an Google Chat ist nicht dasselbe wie ein bedingter Datenalarm.
5. Für Cloud Monitoring eine gesonderte Abfrage nur mit Alarmzeilen ausführen. Die automatisch bereitgestellte Metrik bigquerydatatransfer.googleapis.com/transfer_config/last_execution_job_rows zählt Ergebniszeilen, keine z-Werte. Auf die passende config_id filtern und bei einem Wert über null alarmieren.

Die Alarmabfrage darf erst nach dem erfolgreichen Berechnungslauf starten und muss Aktualität, erwartetes Prüfdatum und die vier Ergebniszeilen kontrollieren. Ein alter fehlerfreier Tabellenstand darf keinen neuen ausgefallenen Lauf verdecken. Auch Jobfehler und ausbleibende Läufe brauchen eigene Warnungen: Die zuletzt gemeldete Zeilenzahl kann nach einem Ausfall unverändert bestehen bleiben. Benachrichtigungskanäle anschließend mit kontrollierten Testfällen prüfen.

4. Abnahme vor dem täglichen Betrieb

• Konstante Basis mit Totalverlust: Änderung wird gemeldet, kein falsches Normal.
• Fehlende Tagestabelle: fehlender Export, keine erfundene Ereignisnull.
• Fehlende Referenzwoche: Vergleich ausgesetzt.
• Unveränderte konstante Basis: keine Änderung.
• Fehlgeschlagener Job oder alter Ergebnisstand: Betriebswarnung unabhängig vom fachlichen Status.

Die Statusentscheidung wurde isoliert mit synthetischen Fällen geprüft. Das ist kein Nachweis einer funktionierenden BigQuery-, Pro- oder Cloud-Monitoring-Installation. Bei täglichen Prüfungen mit vier Tagen Abstand entstehen ausdrücklich keine sofortigen Ausfallmeldungen. Ein schnellerer Meldeweg benötigt eine gesonderte Prüfung vorläufiger Daten.

Praxiskontrolle: Wochentagsbasis ohne den Prüftag

Der GA4-Anomalieprüfer vergleicht einen gewählten Berichtstag jetzt mit demselben Wochentag der acht vorherigen Wochen. Ein Donnerstag wird mit acht Donnerstagen verglichen. Der Prüftag bleibt aus Referenzmittelwert und Stichproben-Standardabweichung ausgeschlossen. Ein starker Einbruch kann damit nicht seine eigene Vergleichsbasis nach unten ziehen.

Das Werkzeug liest Sitzungen, Nutzer insgesamt, Seiten-/Bildschirmaufrufe, Key Events, Ereignisanzahl, Gesamtumsatz und Interaktionsrate über die lesende Data API. Vorausgewählt ist der Tag vor vier Tagen, um Verarbeitungszeit einzuräumen. Dieser Abstand bestätigt jedoch keine vollständigen Daten. Die Berichtszeitzone der Property und die Antwortmetadaten bleiben maßgeblich.

1. Einen abgeschlossenen Tag wählen und die acht im Ergebnis genannten Referenztage prüfen.
2. Fehlt ein erforderliches Datum in der Antwort, wird der Vergleich ausgesetzt. Fehlende Zeilen werden nicht still durch null ersetzt; eine ausdrücklich gemeldete null bleibt null.
3. Den beschreibenden z-Wert anhand der gewählten Schwelle untersuchen. Bei einer konstanten Basis erscheint entweder keine Änderung oder eine Abweichung von diesem konstanten Wert, ohne Division durch null.
4. Die neun Vergleichstage als CSV herunterladen und Auffälligkeiten mit Releases, Kampagnen, Feiertagen und weiteren Befunden abgleichen.

Acht Beobachtungen bilden eine kleine Vergleichsbasis. Die Hinweise sind keine kalibrierten Signifikanztests; sieben gleichzeitige Kennzahlprüfungen können Zufallstreffer erzeugen. Gleiche Wochentage beseitigen weder Trends und Sonderaktionen noch Einwilligungsänderungen oder Verarbeitungsverzögerungen. Ein unauffälliger Wert belegt keine vollständige Messung, ein auffälliger Wert keine Ursache. Dies ist ein manuelles Untersuchungswerkzeug, kein zeitgesteuerter Alarmdienst.

Quellen: Google-runReport-Referenz, Kennzahldefinitionen sowie NIST zur Ausreißererkennung und ihren Voraussetzungen.

Quellen

• GA4: Exportzeiten und Grenzen
• GA4: Exportschema
• Bestand der Tabellen
• Stichproben-Standardabweichung
• Geplante Abfragen einrichten
• Alarm anhand der Ergebniszeilenzahl und Betriebsgrenzen
• Pro-Diagrammwarnungen
• Ausreißer und Annahmen über die Datenverteilung