![\"Ablauf](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/ga4-bigquery-export-de.png\")
Schritt 1: Den Export einschalten<\/h2>\n
Die Verkn\u00fcpfung entsteht in GA4 unter Verwaltung im Bereich Produktverkn\u00fcpfungen \u00fcber BigQuery-Verkn\u00fcpfungen. Daf\u00fcr sind Bearbeitungsrechte an der GA4-Property und Inhaberrechte am Ziel-Projekt in der Google Cloud n\u00f6tig, mit aktivierter BigQuery-API. Die Konfiguration fragt nach dem Cloud-Projekt, einem Speicherort, den einzubeziehenden Datenstreams und einer Exporth\u00e4ufigkeit.<\/p>\n
Zwei H\u00e4ufigkeiten stehen zur Wahl, und sie verhalten sich unterschiedlich. T\u00e4glich<\/strong> schreibt eine Tabelle pro Tag, Zwei Einschr\u00e4nkungen sind wichtig, bevor darauf gebaut wird. Der Export wirkt nicht r\u00fcckwirkend<\/strong> \u2013 er beginnt am Tag der Verkn\u00fcpfung, es wird keine Historie nachgeholt, weshalb sich ein fr\u00fches Einschalten auch ohne unmittelbaren Verwendungszweck lohnt. Und Standard-Properties unterliegen einem dokumentierten t\u00e4glichen Exportlimit von einer Million Events pro Tag; wird es \u00fcberschritten, kann der Export ausgesetzt werden \u2013 das aktuelle Volumen ist also gegen das Limit in Googles Dokumentation zu pr\u00fcfen, bevor der Export tragende Funktion bekommt.<\/p>\n Auf BigQuery-Seite umfasst die kostenlose Stufe 10 GiB Speicher und 1 TiB verarbeitete Abfragedaten pro Monat, was f\u00fcr eine einzelne, manuell erkundete Property gro\u00dfz\u00fcgig bemessen ist.<\/p>\n Stichproben im Export zu vermeiden ist keine Technik \u2013 es ergibt sich daraus, dass der Export der unaggregierte Event-Strom ist und kein Bericht. Drei getrennte Reduktionen der Oberfl\u00e4che fehlen dort schlicht:<\/p>\n Keine dieser drei Reduktionen betrifft die exportierten Tabellen. Der Gegenwert: Alles, was die Oberfl\u00e4che auf den Rohdaten aufbaut \u2013 modellierte Conversions, datengetriebene Attribution, ihre eigene Sitzungsdefinition \u2013, fehlt ebenfalls. Genau deshalb stimmen Summen aus BigQuery und Summen aus der Oberfl\u00e4che nicht exakt \u00fcberein.<\/p>\n Jede Zeile ist ein Event. Wer aus einer klassischen SQL-Welt kommt, stolpert vor allem dar\u00fcber, dass die interessanten Werte keine Spalten sind: Sie stecken in Eine Sitzung hat keine eigene Spalte. Sie wird rekonstruiert, indem Vor allem Analytischen belegt eine Abfrage, dass Daten ankommen und die Tabellenreferenz stimmt:<\/p>\n Der Die Abfrage, die die Oberfl\u00e4che nicht liefern kann, ist eine vollst\u00e4ndige Seitenabfolge je Sitzung. Ein Wert aus Jede Zeile ist der Weg einer Sitzung in ihrer Reihenfolge, mit entfernter Domain und Query-Zeichenfolge, damit identische Seiten zusammenfallen. Von hier aus beantwortet dieselbe Struktur pr\u00e4zisere Fragen: eine Einschr\u00e4nkung auf Sitzungen mit einem bestimmten Event, das Z\u00e4hlen, wie oft eine Seite einer anderen vorausgeht, oder das Messen, wie viele Schritte einem Kauf vorangehen.<\/p>\n Zwei Erwartungen sind zu kl\u00e4ren, bevor diese Daten in einen Bericht wandern. Zahlen aus dem Export lassen sich nicht exakt mit der GA4-Oberfl\u00e4che in Deckung bringen, und das ist Absicht und kein Fehler, dem nachzujagen w\u00e4re: Die Oberfl\u00e4che legt Modellierung und eine eigene Sitzungslogik \u00fcber die Rohdaten, die dort nicht enthalten sind. Und der Export enth\u00e4lt Daten auf Event-Ebene zu identifizierbaren Ger\u00e4ten \u2013 dieselbe Einwilligungsgrundlage und Aufbewahrungsdisziplin wie f\u00fcr Analytics-Daten gilt daher auch f\u00fcr das Dataset in der Cloud, einschlie\u00dflich der Frage, wer Zugriff auf das Projekt erh\u00e4lt.<\/p>\n Mit dem Suffix-Filter aus Schritt 4 nicht, ohne ihn unter Umst\u00e4nden schon. Der Platzhalter events_* trifft auch die Tabellen events_intraday_YYYYMMDD, denn deren Name beginnt ebenfalls mit events_. F\u00fcr sie lautet _TABLE_SUFFIX dann nicht 20260926, sondern intraday_20260926.<\/p>\n Die Bedingung Doppelt z\u00e4hlen kann eine Abfrage erst, wenn sie ohne Suffix-Filter oder mit einem zu weiten Muster beide Tabellenarten erfasst und f\u00fcr denselben Tag beide vorliegen. Eine Abfrage, die beide Quellen mischt, sollte deshalb je Tag nur eine davon z\u00e4hlen.<\/p>\n Nein. BigQuery rechnet nach den Bytes ab, die eine Abfrage lesen muss, und LIMIT begrenzt nur die Ausgabe, nachdem die Daten gelesen sind. Weil BigQuery spaltenweise speichert, sparen dagegen zwei andere Ma\u00dfnahmen: die Auswahl nur der ben\u00f6tigten Spalten statt SELECT * und der Filter auf _TABLE_SUFFIX, der ganze Tagestabellen aus der Rechnung nimmt.<\/p>\n Nein. Die Aufbewahrungsdauer in den GA4-Einstellungen betrifft die Daten in GA4 selbst. Was einmal nach BigQuery exportiert wurde, liegt dort als eigene Kopie im Cloud-Projekt und bleibt, bis es dort gel\u00f6scht wird. Ohne weiteres Zutun w\u00e4chst das Dataset also Tag f\u00fcr Tag, und mit ihm der Speicher, der die kostenlosen 10 GiB irgendwann \u00fcbersteigen kann.<\/p>\n Die Aufbewahrungsdisziplin, die der Artikel auch f\u00fcr das Dataset verlangt, ist deshalb in BigQuery einzurichten. Daf\u00fcr l\u00e4sst sich am Dataset eine Standard-Ablaufzeit f\u00fcr Tabellen setzen (in der API das Feld defaultTableExpirationMs); neue Tagestabellen werden dann nach dieser Frist automatisch gel\u00f6scht. Sie wirkt nur auf Tabellen, die nach der \u00c4nderung entstehen; \u00e4ltere Tabellen brauchen eine eigene Ablaufzeit oder werden von Hand entfernt.<\/p>\n Ja, BigQuery l\u00e4uft dann als Sandbox, allerdings mit zwei Einschr\u00e4nkungen, die f\u00fcr GA4 ins Gewicht fallen. Tabellen in der Sandbox laufen nach 60 Tagen ab, der t\u00e4gliche Export h\u00e4lt also nie mehr als rund zwei Monate vor. Und der Streaming-Export steht dort nicht zur Verf\u00fcgung. F\u00fcr das Kennenlernen der Daten reicht das; wer eine lange Zeitreihe aufbauen will, braucht ein Rechnungskonto, auch wenn die Nutzung innerhalb der kostenlosen Stufe bleibt.<\/p>\n<\/div>\nevents_YYYYMMDD<\/code>, \u00fcblicherweise am Folgetag verf\u00fcgbar; f\u00fcr Standard-Properties ist das kostenfrei enthalten. Streaming<\/strong> schreibt fortlaufend nach events_intraday_YYYYMMDD<\/code> und wird zu den Streaming-Insert-Preisen von BigQuery abgerechnet. Um die Daten kennenzulernen und f\u00fcr die meisten Auswertungen gen\u00fcgt der t\u00e4gliche Export allein.<\/p>\nSchritt 2: Was \u201eohne Stichproben\u201c tats\u00e4chlich bedeutet<\/h2>\n
\n
(other)<\/code>-Zeile.<\/strong> Erzeugt eine Dimension mehr verschiedene Werte, als ein Bericht fassen kann, wird der Rest in einen einzigen (other)<\/code>-Topf zusammengezogen \u2013 ein echtes Problem bei Seitenpfaden, Produkt-IDs oder Suchbegriffen.<\/li>\nSchritt 3: Die Form der Daten<\/h2>\n
event_params<\/code>, einem wiederholten Record aus Schl\u00fcssel-Wert-Paaren, in dem der Wert selbst ein Struct mit je einem Feld pro Datentyp ist.<\/p>\n\n\n
\n \nFeld<\/th>\n Typ<\/th>\n Inhalt<\/th>\n<\/tr>\n<\/thead>\n \n event_date<\/code><\/td>\nSTRING<\/td>\n Der Tag als YYYYMMDD<\/code>, passend zum Tabellensuffix.<\/td>\n<\/tr>\n\n event_timestamp<\/code><\/td>\nINT64<\/td>\n Mikrosekunden seit Epoch \u2013 der Sortierschl\u00fcssel innerhalb einer Sitzung.<\/td>\n<\/tr>\n \n event_name<\/code><\/td>\nSTRING<\/td>\n page_view<\/code>, session_start<\/code>, purchase<\/code> sowie eigene Events.<\/td>\n<\/tr>\n\n user_pseudo_id<\/code><\/td>\nSTRING<\/td>\n Die Client-Kennung \u2013 ein Ger\u00e4t oder Browser, keine Person.<\/td>\n<\/tr>\n \n event_params<\/code><\/td>\nREPEATED RECORD<\/td>\n Schl\u00fcssel-Wert-Paare: ga_session_id<\/code>, page_location<\/code>, page_title<\/code> und weitere.<\/td>\n<\/tr>\n\n items<\/code><\/td>\nREPEATED RECORD<\/td>\n Am Event h\u00e4ngende E-Commerce-Produkte.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n user_pseudo_id<\/code> mit dem Parameter ga_session_id<\/code> kombiniert wird \u2013 Sitzungs-IDs sind nur innerhalb eines Clients eindeutig.<\/p>\nSchritt 4: Eine erste Abfrage zur Best\u00e4tigung, dass der Export l\u00e4uft<\/h2>\n
SELECT\n event_date,\n COUNT(*) AS events,\n COUNT(DISTINCT user_pseudo_id) AS users\nFROM `project.analytics_XXXXXXXXX.events_*`\nWHERE _TABLE_SUFFIX BETWEEN '20260920' AND '20260926'\nGROUP BY event_date\nORDER BY event_date;<\/code><\/pre>\n_TABLE_SUFFIX<\/code>-Filter ist keine optionale Ordnungsfrage. Der Platzhalter events_*<\/code> adressiert s\u00e4mtliche Tagestabellen des Datasets auf einmal, und ohne Suffix-Filter durchsucht die Abfrage die gesamte Exporthistorie \u2013 abgerechnet nach gelesenen Bytes.<\/p>\nSchritt 5: Rohe Nutzerpfade auslesen<\/h2>\n
event_params<\/code> wird \u00fcber eine skalare Unterabfrage auf UNNEST<\/code> gelesen \u2013 das ist die Redewendung, die sich zu merken lohnt, denn sie kehrt in jeder GA4-Abfrage wieder:<\/p>\nWITH page_views AS (\n SELECT\n user_pseudo_id,\n (SELECT value.int_value FROM UNNEST(event_params)\n WHERE key = 'ga_session_id') AS session_id,\n event_timestamp,\n (SELECT value.string_value FROM UNNEST(event_params)\n WHERE key = 'page_location') AS page_location\n FROM `project.analytics_XXXXXXXXX.events_*`\n WHERE _TABLE_SUFFIX BETWEEN '20260920' AND '20260926'\n AND event_name = 'page_view'\n)\nSELECT\n CONCAT(user_pseudo_id, '-', CAST(session_id AS STRING)) AS session_key,\n COUNT(*) AS page_views,\n STRING_AGG(\n REGEXP_EXTRACT(page_location, r'^https?:\/\/[^\/]+([^?#]*)'),\n ' > ' ORDER BY event_timestamp\n ) AS path\nFROM page_views\nWHERE session_id IS NOT NULL\nGROUP BY session_key\nHAVING page_views > 1\nORDER BY page_views DESC\nLIMIT 100;<\/code><\/pre>\nInnerhalb der Leitplanken bleiben<\/h2>\n
Fragen und Antworten<\/h2>\n
Z\u00e4hlt events_* bei eingeschaltetem Streaming-Export Events doppelt?<\/h3>\n
_TABLE_SUFFIX BETWEEN '20260920' AND '20260926'<\/code> schlie\u00dft diese Tabellen aus, weil der Vergleich zeichenweise erfolgt und der Buchstabe i hinter allen Ziffern einsortiert wird. Wer die Daten des laufenden Tages aus der Intraday-Tabelle braucht, muss sie deshalb ausdr\u00fccklich einbeziehen, zum Beispiel mit einer zus\u00e4tzlichen Bedingung _TABLE_SUFFIX = 'intraday_20260927'<\/code>.<\/p>\nSenkt LIMIT 100 die Kosten einer Abfrage?<\/h3>\n
Gilt die in GA4 eingestellte Aufbewahrungsdauer auch f\u00fcr die Tabellen in BigQuery?<\/h3>\n
Funktioniert der Export auch ohne Rechnungskonto in der Google Cloud?<\/h3>\n