{"id":460,"date":"2026-09-11T12:50:00","date_gmt":"2026-09-11T10:50:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/?p=460"},"modified":"2026-10-26T11:59:00","modified_gmt":"2026-10-26T10:59:00","slug":"automatisierte-datenqualitats-alarme-fur-ga4-mit-looker-studio-bigquery","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/digital-analytics-de\/tutorials-de\/automatisierte-datenqualitats-alarme-fur-ga4-mit-looker-studio-bigquery\/","title":{"rendered":"Automatisierte Datenqualit\u00e4ts-Alarme f\u00fcr GA4 mit Looker Studio & BigQuery"},"content":{"rendered":"

Ein Trackingfehler kann unbemerkt bleiben, obwohl die Website normal funktioniert. Ein t\u00e4glicher Mengenvergleich liefert daf\u00fcr Hinweise: Wie viele Ereignisse wurden exportiert, und wie stark weicht die Zahl vom \u00fcblichen Wochentag ab? BigQuery berechnet den Vergleich; Looker Studio zeigt die Ergebnisse. Eine Benachrichtigung braucht zus\u00e4tzlich eine eingerichtete Alarmregel.<\/p>\n

Das folgende Beispiel pr\u00fcft vier Ereignisnamen. Es kontrolliert weder alle Parameter noch die vollst\u00e4ndige Messkette. Ein auff\u00e4lliger Wert kann auch durch Kampagnen, Feiertage oder ge\u00e4nderte Einwilligungen entstehen.<\/p>\n

1. Erst Datenverf\u00fcgbarkeit, dann Ereigniszahl<\/h2>\n

Der Vergleich verwendet den Tag vor vier Tagen und denselben Wochentag der acht vorherigen Wochen. Der Pr\u00fcftag geht nicht in den Referenzmittelwert ein. Der zeitliche Abstand l\u00e4sst Raum f\u00fcr versp\u00e4tete Exporte, beweist aber keine Vollst\u00e4ndigkeit. F\u00fcr GA4 gibt es keinen allgemein garantierten t\u00e4glichen Exportzeitpunkt; insbesondere ist 05:30 UTC keine sichere Grenze.<\/p>\n

Eine fehlende Tagestabelle bleibt ein unbekannter Wert. Nur bei vorhandener Tabelle wird ein nicht vorkommendes Ereignis als null gez\u00e4hlt. Auch eine vorhandene Tabelle kann unvollst\u00e4ndig sein. session_start<\/code> bezeichnet hier die Anzahl dieses Ereignisses, keine nachgebildete GA4-Sitzungskennzahl.<\/p>\n

\"Verf\u00fcgbarkeit,
Verf\u00fcgbarkeit, Vergleich und Zustellung sind getrennte Pr\u00fcfungen. Eine Abweichung von bisher immer gleichen Werten muss als \u00c4nderung sichtbar werden.<\/figcaption><\/figure>\n

2. SQL-Beispiel mit getrennten Fehlerzust\u00e4nden<\/h2>\n

Projekt, Dataset und alle Vorkommen der Berichtszeitzone sind anzupassen. Die Abfrage erwartet GA4-Tagestabellen mit kompatiblem Schema. Fehlen s\u00e4mtliche passenden Tabellen oder Zugriffsrechte, scheitert der Job; daf\u00fcr ist eine eigene Betriebs\u00fcberwachung erforderlich. Vor der Zeitplanung geh\u00f6ren ein BigQuery-Probelauf und eine Kostenpr\u00fcfung zum Einsatz.<\/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> muss acht sein. Bei fehlender Basis entsteht INCOMPLETE_BASELINE<\/code>, bei fehlendem Pr\u00fcftag MISSING_EXPORT<\/code>. Eine konstante Vergleichsbasis erlaubt keine Division durch die Standardabweichung: Achtmal 100 und anschlie\u00dfend null ergibt deshalb CONSTANT_BASELINE_CHANGE<\/code>. Achtmal 100 und erneut 100 ergibt NO_CHANGE<\/code>.<\/p>\n
Bei schwankender Basis beschreibt der z-Wert den Abstand zum Mittelwert im Verh\u00e4ltnis 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 \u2212 100) \/ 10 = \u22123. Die Standardabweichung beschreibt, wie stark die Vergleichswerte auseinanderliegen. Die Grenzen \u22122 und +3 sind hier Untersuchungsregeln, keine kalibrierten Signifikanztests. Acht Beobachtungen sind wenig; mehrere gleichzeitige Pr\u00fcfungen und geringe Ereigniszahlen erh\u00f6hen das Risiko unpassender Hinweise. WITHIN_RULE<\/code> bedeutet lediglich, dass diese Regel nicht anschl\u00e4gt.<\/p>\n
3. Speicherung und Alarmzustellung<\/h2>\n
    \n
  1. Ein Monitoring-Dataset in einer passenden BigQuery-Region anlegen. Lese- und Schreibrechte der ausf\u00fchrenden Identit\u00e4t pr\u00fcfen.<\/li>\n
  2. Die Abfrage zun\u00e4chst manuell ausf\u00fchren. Erwartet werden vier Zeilen einschlie\u00dflich evaluated_at<\/code> und alert_flag<\/code>. Kostenabsch\u00e4tzung beachten: Der Tabellenbereich umfasst 57 Tage, obwohl nur neun Vergleichstage ben\u00f6tigt werden.<\/li>\n
  3. Die Zeitplanung nach beobachteter Exportverf\u00fcgbarkeit w\u00e4hlen. F\u00fcr den aktuellen Pr\u00fcfstand kann die Zieltabelle bei jedem erfolgreichen Lauf ersetzt werden. Eine zus\u00e4tzliche Historie ben\u00f6tigt Laufkennung und eine Regel gegen doppelte Wiederholungen; blindes Anh\u00e4ngen erzeugt sonst Duplikate.<\/li>\n
  4. In Looker Studio den aktuellen Pr\u00fcfstand anzeigen: Datum, Ereignis, Anzahl, Referenzmittel, Status und Auswertungszeit. Pro-Diagrammwarnungen unterst\u00fctzen E-Mail-Benachrichtigungen; die Bedingungen gelten f\u00fcr Standardfilter. Eine Report-Zustellung an Google Chat ist nicht dasselbe wie ein bedingter Datenalarm.<\/li>\n
  5. F\u00fcr Cloud Monitoring eine gesonderte Abfrage nur mit Alarmzeilen ausf\u00fchren. Die automatisch bereitgestellte Metrik bigquerydatatransfer.googleapis.com\/transfer_config\/last_execution_job_rows<\/code> z\u00e4hlt Ergebniszeilen, keine z-Werte. Auf die passende config_id<\/code> filtern und bei einem Wert \u00fcber null alarmieren.<\/li>\n<\/ol>\n
    Die Alarmabfrage darf erst nach dem erfolgreichen Berechnungslauf starten und muss Aktualit\u00e4t, erwartetes Pr\u00fcfdatum und die vier Ergebniszeilen kontrollieren. Ein alter fehlerfreier Tabellenstand darf keinen neuen ausgefallenen Lauf verdecken. Auch Jobfehler und ausbleibende L\u00e4ufe brauchen eigene Warnungen: Die zuletzt gemeldete Zeilenzahl kann nach einem Ausfall unver\u00e4ndert bestehen bleiben. Benachrichtigungskan\u00e4le anschlie\u00dfend mit kontrollierten Testf\u00e4llen pr\u00fcfen.<\/p>\n
    4. Abnahme vor dem t\u00e4glichen Betrieb<\/h2>\n