English
Deutsch
PolskiGA4-Daten per Sprache abfragen und mit SQL prüfen
Management Summary
Conversational Analytics übersetzt Fragen in Auswertungen von Daten in BigQuery, dem Datenlager von Google Cloud. Für exportierte GA4-Ereignisse erleichtert das den Einstieg in Analysen zu Käufen oder Besuchsverhalten. Die Qualität hängt jedoch von klaren Kennzahlen und passenden Tabellen ab. Ein Vergleich mit einer unabhängig formulierten SQL-Abfrage macht Ergebnisse nachvollziehbar und zeigt, ob dieselbe Frage tatsächlich auf derselben Datengrundlage beantwortet wurde.
Inhalt
- Eine verständliche Frage ist erst der Anfang
- Was Conversational Analytics übernimmt
- Ein kleiner Messvertrag
- Die Referenz bleibt bewusst einfach
- Dieselbe Frage, dieselben Daten
- Warum GA4 trotzdem eine andere Zahl zeigen kann
- Kosten vor dem Lauf prüfen
- Measurement Summary
- Fragen und Antworten
- Werkzeuge und Vertiefung
- Quellen
Eine verständliche Frage ist erst der Anfang
Wie viele Käufe gab es gestern? Die Frage klingt eindeutig. Im Datenexport können damit Kaufereignisse, verschiedene Transaktionskennungen oder vollständig abgeglichene Bestellungen gemeint sein. Alle drei Zahlen können voneinander abweichen. Eine hilfreiche Analyse beginnt deshalb mit einer kurzen Definition.
Was Conversational Analytics übernimmt
Google hat die allgemeine Verfügbarkeit von Conversational Analytics in BigQuery am 30. Juni 2026 angekündigt. Fragen in natürlicher Sprache lassen sich in Abfragen und Auswertungen überführen. Für die Analyse eigener GA4-Daten ist ein eingerichteter BigQuery-Export erforderlich. Das öffentliche Beispiel unten benötigt keinen Export aus einer eigenen Property. Der Assistent erzeugt keine fehlenden historischen Ereignisse. Die Verfügbarkeit der jeweiligen Oberfläche und die erforderlichen Cloud-Berechtigungen müssen zum verwendeten Projekt passen.
Ein kleiner Messvertrag
Für eine erste Prüfung eignet sich eine eng begrenzte Frage: Anzahl der purchase-Ereignisse je event_date in Tagestabellen für vergangene Daten zwischen zwei festen Daten. Dazu gehören der konkrete Datensatz, die Property-Zeitzone und der Zeitpunkt der Abfrage. Diese Definition zählt Ereignisse, keine deduplizierten Bestellungen. Rückerstattungen und Umsatz bleiben ausdrücklich außerhalb dieser Kennzahl.
Die Referenz bleibt bewusst einfach
Die folgende SQL-Abfrage zählt purchase-Zeilen im öffentlichen GA4-Beispieldatensatz. Der Zeitraum ist historisch und dient als reproduzierbare Vorlage. Für einen eigenen Export müssen Projekt, Datensatz und Daten angepasst werden. Die Abfrage wurde hier nicht gegen BigQuery ausgeführt; ein Ergebniswert wird deshalb nicht behauptet. Der öffentliche Beispieldatensatz enthält absichtlich veränderte Daten und eignet sich zum Üben, nicht zur Prüfung echter Geschäftszahlen. Die Abfrage liefert für Tage ohne purchase-Ereignis keine Zeile. Ein fehlender Tag belegt daher allein keine Datenlücke. Für eine lückenlose Datumsreihe mit Nullwerten ist eine Kalendertabelle mit LEFT JOIN erforderlich.
SELECT event_date, COUNT(*) AS purchase_events
FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20210101' AND '20210107'
AND event_name = 'purchase'
GROUP BY event_date
ORDER BY event_date;Dieselbe Frage, dieselben Daten
Ein passender Auftrag an den Assistenten benennt dieselben Tabellen, denselben Zeitraum, dasselbe Ereignis und dieselbe Gruppierung. Danach werden SQL und Ergebnis gemeinsam geprüft: Stimmen Datumsgrenzen, Filter und Zeilenzahl? Ein zusätzliches UNNEST von items kann Ereigniszeilen vervielfachen. Eine Zählung verschiedener transaction_id beantwortet bereits eine andere Frage. Eine plausibel klingende Zusammenfassung ersetzt diesen Abgleich nicht.
Warum GA4 trotzdem eine andere Zahl zeigen kann
Der Rohdatenexport und die Analytics-Oberfläche sind unterschiedliche Auswertungswege. Identität, Modellierung, Attributionslogik und Datenstand können Vergleiche beeinflussen. Google ergänzt tägliche Exporttabellen bei verspäteten Ereignissen noch bis zu drei Tage nach dem Ereignisdatum. Ein gespeicherter Prüfzeitpunkt hilft, echte Abfragefehler von verändertem Datenbestand zu trennen.
Kosten vor dem Lauf prüfen
Ein Dry Run prüft die Abfrage und schätzt die verarbeiteten Daten, ohne das Ergebnis zu berechnen. Ein begrenzter Tabellenzeitraum und gezielt ausgewählte Spalten halten den Umfang nachvollziehbar. Für produktive Läufe gehören ein passendes Kostenlimit und die Prüfung der tatsächlich ausgeführten Jobs zum Ablauf. Ein reines LIMIT begrenzt die gelesenen Daten nicht zuverlässig.
Measurement Summary
Messgröße ist die Zahl der purchase-Ereigniszeilen je event_date. Referenz und KI-Abfrage müssen Zeitraum, Tabellen, Filter und Datenstand teilen. Zu prüfen sind fehlende Tage, doppelte Ergebniszeilen und Differenzen pro Tag. Kein authentifizierter BigQuery-Lauf oder gemessener Genauigkeitswert ist Bestandteil dieses Beitrags.
Fragen und Antworten
Sind purchase-Ereignisse gleich Bestellungen?
Nicht zwingend. Mehrfach gesendete Ereignisse oder fehlende Transaktionskennungen können den Vergleich verändern. Die gewählte Referenz zählt ausdrücklich Ereigniszeilen.
Belegt eine Übereinstimmung korrekte Geschäftszahlen?
Die Übereinstimmung bestätigt zunächst dieselbe Berechnung auf denselben Daten. Fehler bei der Erfassung können in beiden Ergebnissen enthalten sein.
Prüft der GA4-Antwortprüfer auch BigQuery-SQL?
Das bestehende Werkzeug vergleicht Advisor-Antworten mit runReport aus der GA4 Data API. Für BigQuery ist ein eigener SQL- und Ergebnisabgleich erforderlich.
Werkzeuge und Vertiefung
- GA4-BigQuery-Abfragebaukasten
- BigQuery-Abfrage- und UNNEST-Generator für GA4
- GA4 Advisor & runReport prüfen
- BigQuery-Kosten beim GA4-Export: Welche Tabellen und Spalten eine Abfrage liest und der kostenlose Probelauf
Interaktiver Lernpfad zur Analytics-Messung
Quellen
Passend dazu
