{"id":451,"date":"2026-09-08T15:45:00","date_gmt":"2026-09-08T13:45:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/?p=451"},"modified":"2026-10-24T02:25:45","modified_gmt":"2026-10-24T00:25:45","slug":"automatisierte-ga4-meta-capi-event-validierung-in-bigquery","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/digital-analytics-de\/tutorials-de\/automatisierte-ga4-meta-capi-event-validierung-in-bigquery\/","title":{"rendered":"Automatisierte GA4- & Meta-CAPI-Event-Validierung in BigQuery"},"content":{"rendered":"
Ein Abgleich zwischen GA4 und Meta CAPI zeigt, welche erwarteten Gesch\u00e4ftsvorg\u00e4nge in den jeweiligen Datenquellen nachweisbar sind. Eine Abweichung erkl\u00e4rt aber noch nicht die Ursache: Einwilligung, unterschiedliche Ereignisdefinitionen, versp\u00e4tete Verarbeitung und technische Fehler k\u00f6nnen dasselbe Muster erzeugen. GA4 ist zudem nicht automatisch ein reiner Browserdatenstrom.<\/p>\n
1. Erst festlegen, was \u00fcberhaupt \u00fcbereinstimmen soll<\/h2>\n
Die Grundlage ist eine verl\u00e4ssliche Liste der Gesch\u00e4ftsvorg\u00e4nge, etwa best\u00e4tigter Bestellungen. Ein Vergleich nur zwischen zwei Tracking-Tabellen \u00fcbersieht Vorg\u00e4nge, die in beiden fehlen. Auch die Referenzliste ben\u00f6tigt eine eigene Vollst\u00e4ndigkeitskontrolle.<\/p>\n
Ein stabiler Schl\u00fcssel verbindet die Quellen. UUIDv4 ist eine M\u00f6glichkeit, keine Pflicht und kein Verschl\u00fcsselungsverfahren. Derselbe Vorgang beh\u00e4lt bei Wiederholungen dieselbe Kennung. Unterschiedliche Vorg\u00e4nge erhalten unterschiedliche Kennungen. Ein zus\u00e4tzlicher Geltungsbereich verhindert Kollisionen zwischen Shops oder Datenquellen.<\/p>\n
Die Ereignisnamen brauchen eine ausdr\u00fcckliche Zuordnung, zum Beispiel GA4 purchase<\/code> und Meta Purchase<\/code> zum gemeinsamen Typ purchase<\/code>. Die GA4-Bestellkennung transaction_id<\/code>, ein eigener Abgleichparameter und Metas event_id<\/code> sind verschiedene Felder. GA4-Kaufdubletten und Meta-Pixel\/CAPI-Deduplizierung folgen jeweils eigenen Regeln. Ein BigQuery-Treffer beweist keine Werbezuordnung und keine erfolgreiche Deduplizierung bei Meta.<\/p>\nEine eigene Referenzliste macht auch beidseitig fehlende Nachweise sichtbar. Versandversuche werden vor dem Vergleich zusammengefasst.<\/figcaption><\/figure>\n
2. Drei vorbereitete Tabellen statt ungepr\u00fcfter Rohdaten<\/h2>\n
Das folgende Beispiel setzt eigene Tabellen voraus. Die Tabellen entstehen nicht automatisch durch die Verkn\u00fcpfung mit GA4; Einleseprozesse und Qualit\u00e4tspr\u00fcfungen m\u00fcssen zuerst eingerichtet werden.<\/p>\n
\n
expected_events<\/code>: genau eine Zeile je scope_id<\/code>, event_kind<\/code> und event_id<\/code>; dazu business_time<\/code> als tats\u00e4chlicher Gesch\u00e4ftszeitpunkt sowie expected_ga4<\/code> und expected_meta<\/code> als BOOL. TRUE bedeutet, dass eine identifizierbare \u00dcbermittlung f\u00fcr diesen Dienst vorgesehen und zul\u00e4ssig ist; FALSE bedeutet nicht erwartet; NULL bedeutet ungekl\u00e4rt.<\/li>\n
ga4_observations<\/code>: eine Zeile je tats\u00e4chlich exportiertem Ereignis, mit demselben zusammengesetzten Schl\u00fcssel und loaded_at<\/code> als Einlesezeitpunkt. Eine erneute Einlesung derselben Exportzeile darf keine zus\u00e4tzliche Beobachtung erzeugen. Tats\u00e4chlich mehrfach aufgezeichnete Ereignisse bleiben dagegen sichtbar.<\/li>\n
capi_attempts<\/code>: eine Zeile je Versandversuch und zugeh\u00f6rigem Ereignis, mit Schl\u00fcssel, loaded_at<\/code> und receipt_state<\/code>. Zul\u00e4ssige Zust\u00e4nde sind received<\/code>, rejected<\/code> und unknown<\/code>. Nur ein eindeutig zuordenbarer Empfangsnachweis erh\u00e4lt received<\/code>.<\/li>\n<\/ul>\n
HTTP 200 allein ist kein Attributionsnachweis. Bei einer Antwort mit Empfangsanzahl muss auch die Zuordnung zur Anfrage stimmen. Eine unklare oder teilweise Batch-Antwort darf nicht pauschal jedes Ereignis als empfangen markieren. Fehler und unklare Versuche bleiben im Protokoll; sp\u00e4tere erfolgreiche Wiederholungen werden zus\u00e4tzlich erfasst. Zugriffstoken und vollst\u00e4ndige Kundendaten geh\u00f6ren nicht in dieses Pr\u00fcfprotokoll.<\/p>\n
Leere Kennungen, doppelte Parameterwerte, unbekannte Ereignisnamen und Beobachtungen ohne Referenzvorgang ben\u00f6tigen eigene Fehlerlisten. Ung\u00fcltige Datens\u00e4tze d\u00fcrfen nicht still verschwinden. scope_id<\/code> umfasst die feste Zuordnung zwischen Shop, GA4-Property beziehungsweise Stream und Meta-Datenquelle.<\/p>\n
3. Den Gesch\u00e4ftstag auswerten und Wiederholungen zusammenfassen<\/h2>\n
Die Abfrage bewertet beispielhaft einen vier Tage zur\u00fcckliegenden UTC-Gesch\u00e4ftstag. Das schafft Abstand zu normalen Nachl\u00e4ufen, garantiert aber keine Vollst\u00e4ndigkeit. Vor dem Lauf m\u00fcssen Export, Referenzliste und CAPI-Protokoll ausreichend aktuell sein. Fehlende Tabellen sind ein Ladefehler, kein Beweis f\u00fcr null Ereignisse.<\/p>\n
GA4-Tagestabellen richten sich nach der Property-Zeitzone. Die Dokumentation beschreibt event_timestamp<\/code> als Empfangszeitpunkt; \u00dcbertragung und Gesch\u00e4ftsvorgang k\u00f6nnen auseinanderliegen. Deshalb stammt der bewertete Tag hier aus business_time<\/code>. Die vorbereiteten Beobachtungstabellen m\u00fcssen passende sp\u00e4tere Eing\u00e4nge enthalten. Nur die t\u00e4gliche GA4-Tabelle des Gesch\u00e4ftstags einzulesen reicht daf\u00fcr nicht generell.<\/p>\n
-- GoogleSQL. Prepared tables are defined in the article.\n-- @run_time is supplied by BigQuery Scheduled Queries.\nDECLARE target_day DATE DEFAULT DATE_SUB(DATE(@run_time, 'UTC'), INTERVAL 4 DAY);\nDECLARE observed_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP();\n\nCREATE TEMP TABLE expected AS\nSELECT scope_id, event_kind, event_id, expected_ga4, expected_meta\nFROM `project_id.monitoring.expected_events`\nWHERE business_time >= TIMESTAMP(target_day, 'UTC')\n AND business_time < TIMESTAMP(DATE_ADD(target_day, INTERVAL 1 DAY), 'UTC');\n\nASSERT (\n SELECT COUNT(*) = 0 FROM expected\n WHERE scope_id IS NULL OR TRIM(scope_id) = ''\n OR event_kind IS NULL OR TRIM(event_kind) = ''\n OR event_id IS NULL OR TRIM(event_id) = ''\n) AS 'Invalid key in expected events';\n\nASSERT NOT EXISTS (\n SELECT 1 FROM expected\n GROUP BY scope_id, event_kind, event_id\n HAVING COUNT(*) > 1\n) AS 'Duplicate business-event key';\n\nCREATE TEMP TABLE result AS\nWITH ga4 AS (\n SELECT g.scope_id, g.event_kind, g.event_id, COUNT(*) AS ga4_rows\n FROM `project_id.monitoring.ga4_observations` g\n JOIN expected e USING (scope_id, event_kind, event_id)\n WHERE g.loaded_at <= observed_at\n GROUP BY g.scope_id, g.event_kind, g.event_id\n),\ncapi AS (\n SELECT c.scope_id, c.event_kind, c.event_id,\n COUNT(*) AS capi_attempts,\n COUNTIF(c.receipt_state = 'received') AS capi_receipts,\n COUNTIF(c.receipt_state = 'unknown') AS capi_unknown\n FROM `project_id.monitoring.capi_attempts` c\n JOIN expected e USING (scope_id, event_kind, event_id)\n WHERE c.loaded_at <= observed_at\n GROUP BY c.scope_id, c.event_kind, c.event_id\n)\nSELECT target_day AS business_day, observed_at AS checked_at, e.*,\n COALESCE(g.ga4_rows, 0) AS ga4_rows,\n COALESCE(c.capi_attempts, 0) AS capi_attempts,\n COALESCE(c.capi_receipts, 0) AS capi_receipts,\n COALESCE(c.capi_unknown, 0) AS capi_unknown\nFROM expected e\nLEFT JOIN ga4 g USING (scope_id, event_kind, event_id)\nLEFT JOIN capi c USING (scope_id, event_kind, event_id);\n\nSELECT *,\n CASE\n WHEN expected_ga4 IS NULL OR expected_meta IS NULL THEN 'SCOPE_UNKNOWN'\n WHEN NOT expected_ga4 OR NOT expected_meta THEN 'OUTSIDE_JOINT_SCOPE'\n WHEN ga4_rows > 0 AND capi_receipts > 0 THEN 'OBSERVED_BOTH'\n WHEN ga4_rows = 0 AND capi_receipts = 0 THEN 'UNCONFIRMED_BOTH'\n WHEN ga4_rows = 0 THEN 'UNCONFIRMED_GA4'\n ELSE 'UNCONFIRMED_CAPI'\n END AS reconciliation_status,\n ga4_rows > 1 AS repeated_ga4_rows,\n (expected_ga4 = FALSE AND ga4_rows > 0)\n OR (expected_meta = FALSE AND capi_attempts > 0) AS unexpected_transmission\nFROM result;<\/code><\/pre>\n
Die Gruppierung verhindert, dass zwei GA4-Zeilen und drei CAPI-Versuche sechs vermeintliche Vorg\u00e4nge erzeugen. Wiederholungen bleiben als Anzahl sichtbar. UNCONFIRMED<\/code> bedeutet fehlenden Nachweis im betrachteten Datenbestand, nicht automatisch einen defekten Tag. unexpected_transmission<\/code> kennzeichnet au\u00dferdem \u00dcbermittlungen, die laut Referenz nicht vorgesehen waren.<\/p>\n
Das Beispiel ist kein vollst\u00e4ndiger Einleseprozess. Tabellenzugriffe m\u00fcssen passend partitioniert oder begrenzt, Berechtigungen eingerichtet und Kosten vorab gepr\u00fcft werden. Ergebnisse mit Gesch\u00e4ftstag und Pr\u00fcfzeit speichern; erneute Auswertungen d\u00fcrfen \u00e4ltere Tagesst\u00e4nde gezielt ersetzen, statt die Fehlerquote durch angeh\u00e4ngte Doppelzeilen zu ver\u00e4ndern.<\/p>\n
4. Einen Befund alarmieren, nicht nur einen erfolgreichen SQL-Lauf<\/h2>\n
Eine nachgelagerte Ansicht latest_reconciliation<\/code> enth\u00e4lt genau den j\u00fcngsten erfolgreich berechneten Stand je Gesch\u00e4ftstag und Schl\u00fcssel. Die folgende separate Abfrage liefert nur Tage oberhalb eines beispielhaften Schwellenwerts. Die Mindestmenge von 100 und die Grenze von f\u00fcnf Prozent sind zu begr\u00fcnden, keine allgemein g\u00fcltigen Qualit\u00e4tsnormen.<\/p>\n
-- A separate scheduled SELECT over the latest successful snapshot.\nWITH counts AS (\n SELECT business_day,\n COUNTIF(expected_ga4 AND expected_meta) AS comparable,\n COUNTIF(expected_ga4 AND expected_meta\n AND (ga4_rows = 0 OR capi_receipts = 0)) AS unconfirmed\n FROM `project_id.monitoring.latest_reconciliation`\n GROUP BY business_day\n),\nrates AS (\n SELECT *, 100 * SAFE_DIVIDE(unconfirmed, comparable) AS rate_pct\n FROM counts\n)\nSELECT *\nFROM rates\nWHERE comparable >= 100 AND rate_pct > 5;<\/code><\/pre>\n
Bei einer leeren Vergleichsmenge bleibt die Quote mit SAFE_DIVIDE<\/code> unbekannt. F\u00e4lle au\u00dferhalb des gemeinsamen Umfangs und ungekl\u00e4rte Erwartungen z\u00e4hlen nicht in diesen Nenner. Eigene Kontrollen m\u00fcssen solche F\u00e4lle, unerwartete \u00dcbermittlungen, ung\u00fcltige IDs, Wiederholungen und unvollst\u00e4ndige Datenzufl\u00fcsse \u00fcberwachen.<\/p>\n
Die Scheduled-Query-Metrik last_execution_job_rows<\/code> z\u00e4hlt Ergebniszeilen, nicht den Wert von rate_pct<\/code>. F\u00fcr die reine Alarmabfrage kann eine gefilterte Monitoring-Regel mit Zeilenzahl gr\u00f6\u00dfer null verwendet werden. Der letzte Wert kann bei einem fehlgeschlagenen oder abgeschalteten Auftrag weiter bestehen bleiben. Deshalb sind Ausf\u00fchrungsfehler und Aktualit\u00e4t separat zu \u00fcberwachen; ein dauerhaft gespeicherter alter Alarm ist kein neuer Tagesbefund.<\/p>\n
\n
Fragen und Antworten<\/h2>\n
Ist eine benutzerdefinierte GA4-Dimension f\u00fcr die Abgleich-ID n\u00f6tig?<\/h3>\n
F\u00fcr den Zugriff auf einen tats\u00e4chlich exportierten Parameter in event_params<\/code> nicht. Registrierung garantiert jedoch weder \u00dcbertragung noch Export. Fehlende oder mehrfach vorhandene Schl\u00fcssel m\u00fcssen beim Einlesen erkannt werden.<\/p>\n
Reichen 48 Stunden und ein Lauf um 06:00 UTC?<\/h3>\n
Nein. GA4 kann Tagestabellen \u00fcber mehrere Kalendertage erg\u00e4nzen und gelegentlich historische Daten neu verarbeiten. Auch CAPI-Versand und das eigene Protokoll haben eigene Verz\u00f6gerungen. Wartezeit, Aktualit\u00e4tspr\u00fcfung und erneute Auswertung \u00e4lterer Tage geh\u00f6ren zusammen; eine feste Uhrzeit garantiert keinen abgeschlossenen Export.<\/p>\n
Ersetzt ads_storage die Pr\u00fcfung der Meta-Einwilligung?<\/h3>\n
Nein. Yes<\/code>, No<\/code>, Unset<\/code> und ein fehlender Wert beschreiben nicht automatisch die Erlaubnis f\u00fcr einen anderen Dienst. Die Erwartungen m\u00fcssen aus der tats\u00e4chlich geltenden, dokumentierten Dienstkonfiguration und Entscheidung entstehen. Ein bewusst nicht gesendetes Ereignis ist keine technische St\u00f6rung; ein unbekannter Zustand ist keine Zustimmung.<\/p>\n<\/div>\n
![\"Eine](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/dia-450-reconciliation-20261024-de.png\")