{"id":27695,"date":"2026-10-28T09:17:00","date_gmt":"2026-10-28T08:17:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=27695"},"modified":"2026-10-29T22:56:09","modified_gmt":"2026-10-29T21:56:09","slug":"bigquery-conversational-check-de","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/digital-analytics-de\/bigquery-conversational-check-de\/","title":{"rendered":"GA4-Daten per Sprache abfragen und mit SQL pr\u00fcfen"},"content":{"rendered":"

Eine verst\u00e4ndliche Frage ist erst der Anfang<\/h2>\n

Wie viele K\u00e4ufe gab es gestern? Die Frage klingt eindeutig. Im Datenexport k\u00f6nnen damit Kaufereignisse, verschiedene Transaktionskennungen oder vollst\u00e4ndig abgeglichene Bestellungen gemeint sein. Alle drei Zahlen k\u00f6nnen voneinander abweichen. Eine hilfreiche Analyse beginnt deshalb mit einer kurzen Definition.<\/p>\n

Was Conversational Analytics \u00fcbernimmt<\/h2>\n

Google hat die allgemeine Verf\u00fcgbarkeit von Conversational Analytics in BigQuery am 30. Juni 2026 angek\u00fcndigt. Fragen in nat\u00fcrlicher Sprache lassen sich in Abfragen und Auswertungen \u00fcberf\u00fchren. F\u00fcr die Analyse eigener GA4-Daten ist ein eingerichteter BigQuery-Export erforderlich. Das \u00f6ffentliche Beispiel unten ben\u00f6tigt keinen Export aus einer eigenen Property. Der Assistent erzeugt keine fehlenden historischen Ereignisse. Die Verf\u00fcgbarkeit der jeweiligen Oberfl\u00e4che und die erforderlichen Cloud-Berechtigungen m\u00fcssen zum verwendeten Projekt passen.<\/p>\n

Ein kleiner Messvertrag<\/h2>\n

F\u00fcr eine erste Pr\u00fcfung eignet sich eine eng begrenzte Frage: Anzahl der purchase-Ereignisse je event_date in Tagestabellen f\u00fcr vergangene Daten zwischen zwei festen Daten. Dazu geh\u00f6ren der konkrete Datensatz, die Property-Zeitzone und der Zeitpunkt der Abfrage. Diese Definition z\u00e4hlt Ereignisse, keine deduplizierten Bestellungen. R\u00fcckerstattungen und Umsatz bleiben ausdr\u00fccklich au\u00dferhalb dieser Kennzahl.<\/p>\n

\"Frage<\/figure>\n

Die Referenz bleibt bewusst einfach<\/h2>\n

Die folgende SQL-Abfrage z\u00e4hlt purchase-Zeilen im \u00f6ffentlichen GA4-Beispieldatensatz. Der Zeitraum ist historisch und dient als reproduzierbare Vorlage. F\u00fcr einen eigenen Export m\u00fcssen Projekt, Datensatz und Daten angepasst werden. Die Abfrage wurde hier nicht gegen BigQuery ausgef\u00fchrt; ein Ergebniswert wird deshalb nicht behauptet. Der \u00f6ffentliche Beispieldatensatz enth\u00e4lt absichtlich ver\u00e4nderte Daten und eignet sich zum \u00dcben, nicht zur Pr\u00fcfung echter Gesch\u00e4ftszahlen. Die Abfrage liefert f\u00fcr Tage ohne purchase-Ereignis keine Zeile. Ein fehlender Tag belegt daher allein keine Datenl\u00fccke. F\u00fcr eine l\u00fcckenlose Datumsreihe mit Nullwerten ist eine Kalendertabelle mit LEFT JOIN erforderlich.<\/p>\n

SELECT event_date, COUNT(*) AS purchase_events\nFROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`\nWHERE _TABLE_SUFFIX BETWEEN '20210101' AND '20210107'\n  AND event_name = 'purchase'\nGROUP BY event_date\nORDER BY event_date;<\/code><\/pre>\n
Dieselbe Frage, dieselben Daten<\/h2>\n
Ein passender Auftrag an den Assistenten benennt dieselben Tabellen, denselben Zeitraum, dasselbe Ereignis und dieselbe Gruppierung. Danach werden SQL und Ergebnis gemeinsam gepr\u00fcft: Stimmen Datumsgrenzen, Filter und Zeilenzahl? Ein zus\u00e4tzliches UNNEST von items kann Ereigniszeilen vervielfachen. Eine Z\u00e4hlung verschiedener transaction_id beantwortet bereits eine andere Frage. Eine plausibel klingende Zusammenfassung ersetzt diesen Abgleich nicht.<\/p>\n
Warum GA4 trotzdem eine andere Zahl zeigen kann<\/h2>\n
Der Rohdatenexport und die Analytics-Oberfl\u00e4che sind unterschiedliche Auswertungswege. Identit\u00e4t, Modellierung, Attributionslogik und Datenstand k\u00f6nnen Vergleiche beeinflussen. Google erg\u00e4nzt t\u00e4gliche Exporttabellen bei versp\u00e4teten Ereignissen noch bis zu drei Tage nach dem Ereignisdatum. Ein gespeicherter Pr\u00fcfzeitpunkt hilft, echte Abfragefehler von ver\u00e4ndertem Datenbestand zu trennen.<\/p>\n
Kosten vor dem Lauf pr\u00fcfen<\/h2>\n
Ein Dry Run pr\u00fcft die Abfrage und sch\u00e4tzt die verarbeiteten Daten, ohne das Ergebnis zu berechnen. Ein begrenzter Tabellenzeitraum und gezielt ausgew\u00e4hlte Spalten halten den Umfang nachvollziehbar. F\u00fcr produktive L\u00e4ufe geh\u00f6ren ein passendes Kostenlimit und die Pr\u00fcfung der tats\u00e4chlich ausgef\u00fchrten Jobs zum Ablauf. Ein reines LIMIT begrenzt die gelesenen Daten nicht zuverl\u00e4ssig.<\/p>\n
Measurement Summary<\/h2>\n
Messgr\u00f6\u00dfe ist die Zahl der purchase-Ereigniszeilen je event_date. Referenz und KI-Abfrage m\u00fcssen Zeitraum, Tabellen, Filter und Datenstand teilen. Zu pr\u00fcfen sind fehlende Tage, doppelte Ergebniszeilen und Differenzen pro Tag. Kein authentifizierter BigQuery-Lauf oder gemessener Genauigkeitswert ist Bestandteil dieses Beitrags.<\/p>\n
\n
Fragen und Antworten<\/h2>\n
Sind purchase-Ereignisse gleich Bestellungen?<\/h3>\n
Nicht zwingend. Mehrfach gesendete Ereignisse oder fehlende Transaktionskennungen k\u00f6nnen den Vergleich ver\u00e4ndern. Die gew\u00e4hlte Referenz z\u00e4hlt ausdr\u00fccklich Ereigniszeilen.<\/p>\n
Belegt eine \u00dcbereinstimmung korrekte Gesch\u00e4ftszahlen?<\/h3>\n
Die \u00dcbereinstimmung best\u00e4tigt zun\u00e4chst dieselbe Berechnung auf denselben Daten. Fehler bei der Erfassung k\u00f6nnen in beiden Ergebnissen enthalten sein.<\/p>\n
Pr\u00fcft der GA4-Antwortpr\u00fcfer auch BigQuery-SQL?<\/h3>\n
Das bestehende Werkzeug vergleicht Advisor-Antworten mit runReport aus der GA4 Data API. F\u00fcr BigQuery ist ein eigener SQL- und Ergebnisabgleich erforderlich.<\/p>\n<\/div>\n
Werkzeuge und Vertiefung<\/h2>\n