GA4-Rohdaten mit BigQuery nutzen: Export, Datenschema & erste SQL-Abfragen

Q: Warum brauche ich UNNEST in BigQuery?

Weil GA4-Ereignisdaten verschachtelt sind: event_params ist ein REPEATED RECORD – ein Array aus Schlüssel-Wert-Paaren, nicht eine flache Spalte. Um einen einzelnen Parameter (z. B. die Seiten-URL) herauszuholen, entpackst du das Array mit einer UNNEST-Unterabfrage und filterst auf den passenden key. Dieses Muster ist der zentrale Mechanismus beim Arbeiten mit dem GA4-Export.

TL;DR

Der BigQuery-Export liefert dir die GA4-Ereignis-Rohdaten – ohne Sampling, ohne Data-Thresholding und ohne die Kardinalitätsgrenzen der Standard-Berichte.
Was du brauchst: ein Google-Cloud-Projekt mit Abrechnungskonto, GA4-Administratorrechte und ein paar SQL-Grundlagen. Der Export selbst ist kostenlos; Kosten entstehen erst über dem Free Tier (1 TiB Abfragen, 10 GiB Speicher pro Monat).
Die zwei Stolpersteine: das verschachtelte Schema (event_params als REPEATED RECORD → UNNEST nötig) und dass es keine fertige Session-Tabelle gibt – Sessions baust du selbst aus user_pseudo_id und ga_session_id.
Diese Anleitung führt durch Einrichtung, Schema, erste SQL-Abfragen, Kostenkontrolle und DSGVO.

Irgendwann stößt jede GA4-Auswertung an eine Wand: Sampling in großen Explorations, unterdrückte Zeilen durch Data-Thresholding, (other)-Sammelzeilen bei hoher Kardinalität. Der saubere Ausweg heißt BigQuery-Export – dort liegen die unbeschnittenen Ereignis-Rohdaten. Diese Anleitung ist bewusst kein Fünf-Minuten-Tutorial: Sie führt dich durch die Einrichtung, erklärt das eigenwillige Datenschema und gibt dir erste, funktionierende SQL-Abfragen an die Hand.

Warum BigQuery – und wann es sich lohnt

Der BigQuery-Export ist Googles offizieller Weg, GA4-Rohdaten aus dem Tool herauszubekommen. Der entscheidende Vorteil: Die Daten sind unsampled und vollständig. Genau die Effekte, die Standard-Berichte begrenzen, entfallen hier – kein Sampling, kein Thresholding, keine Kardinalitätsgrenze. Wie diese Effekte in der GA4-Oberfläche entstehen, erklärt der Ratgeber zu Datenschwellen und Sampling in GA4; BigQuery ist die verlässliche Antwort darauf.

Ehrlich zur Einordnung: Für viele Alltagsfragen reichen die GA4-Standard-Berichte oder Looker Studio. BigQuery lohnt sich, wenn du präzise, granulare oder individuelle Auswertungen brauchst, große Datenmengen unverfälscht analysieren willst oder GA4-Daten mit anderen Datenquellen zusammenführen möchtest. Es ist ein Werkzeug für den nächsten Reifegrad – nicht für jede Property zwingend, aber für datengetriebene Teams ein echter Sprung.

Voraussetzungen

Bevor du startest, brauchst du drei Dinge: ein Google-Cloud-Projekt mit aktiviertem Abrechnungskonto (das ist auch für die kostenlose Nutzung nötig – ohne hinterlegte Abrechnung kein Export), Administratorrechte in der GA4-Property und BigQuery-Berechtigungen im Cloud-Projekt. SQL-Grundkenntnisse sind das vierte, informelle Muss – ohne sie liegen die Rohdaten zwar da, aber ungenutzt.

Wichtig: Der Export ist kostenlos zu aktivieren, und die exportierten Daten sind unsampled. Kosten entstehen erst durch die Google-Cloud-Nutzung oberhalb des Free Tiers (dazu unten mehr). Das schreckt viele unnötig ab – kleine bis mittlere Sites bleiben oft monatelang im kostenlosen Rahmen.

Schritt 1: Den Export einrichten

Die Verknüpfung richtest du in der GA4-Verwaltung ein: unter den Property-Einstellungen die BigQuery-Verknüpfung anlegen, das Cloud-Projekt auswählen und den Export konfigurieren. Zwei Entscheidungen sind dabei zentral:

Datenstandort: Du wählst, wo BigQuery die Daten speichert – US oder EU. Für DSGVO-Setups ist der EU-Standort in der Regel die richtige Wahl. Diese Entscheidung triffst du bewusst, sie lässt sich später nicht einfach umziehen.
Export-Typ: Der tägliche Export (events_YYYYMMDD) ist Standard und für die meisten ausreichend. Zusätzlich gibt es den Streaming-Export (events_intraday_YYYYMMDD) für nahezu Echtzeit-Daten – nützlich, aber mit eigenen Kosten und Eigenheiten.

Nach der Einrichtung dauert es bis zu 24 Stunden, bis die erste Tabelle erscheint. Rückwirkend werden keine Daten exportiert – der Export beginnt ab Aktivierung. Deshalb gilt: je früher aktiviert, desto mehr Historie hast du später. Selbst wer BigQuery noch nicht nutzt, sollte den Export früh anschalten, um Daten zu sammeln.

Schritt 2: Das Datenschema verstehen (der wichtigste Teil)

Hier scheitern die meisten Einsteiger – nicht an der Technik, sondern am ungewohnten Schema. GA4 exportiert eine Tabelle pro Tag: events_YYYYMMDD. Bei aktiviertem Streaming kommt events_intraday_YYYYMMDD für den laufenden Tag dazu. Jede Zeile ist ein einzelnes Ereignis (nicht eine Sitzung, nicht ein Nutzer).

Der entscheidende Punkt: Viele Felder sind verschachtelt. event_params ist kein flaches Feld, sondern ein REPEATED RECORD – ein Array aus Schlüssel-Wert-Paaren mit typisierten Wertspalten (string_value, int_value, double_value usw.). Um einen einzelnen Parameter (etwa die Seiten-URL) herauszuholen, brauchst du deshalb UNNEST. Das ist der eine Mechanismus, den du verstehen musst.

Weitere Schlüsselfelder:

user_pseudo_id – die pseudonyme Nutzer-ID (kein Klarname). Damit zählst du Nutzer.
event_name, event_date, event_timestamp – Name, Datum, Zeitstempel des Ereignisses.
kein natives Session-Feld: GA4 hat in BigQuery keine fertige Session-Tabelle. Die Session-ID (ga_session_id) steckt selbst in event_params. Eine „Sitzung" rekonstruierst du, indem du user_pseudo_id mit ga_session_id kombinierst.

Diese drei Eigenheiten – verschachtelte Parameter, keine Session-Tabelle, Ereignis-pro-Zeile – erklären, warum scheinbar einfache Fragen in BigQuery zunächst kompliziert wirken. Wer sie einmal verstanden hat, dem geht der Rest leicht von der Hand.

Schritt 3: Erste SQL-Abfragen

Fangen wir konkret an. Diese Abfrage holt Datum, Ereignisname und die Seiten-URL heraus – das klassische UNNEST-Muster:

SELECT
  event_date,
  event_name,
  (SELECT value.string_value
   FROM UNNEST(event_params)
   WHERE key = 'page_location') AS page_location
FROM `projekt.analytics_XXXXXX.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260101' AND '20260107'
  AND event_name = 'page_view'

Zwei Dinge sind hier wichtig. Erstens das Unterabfrage-Muster mit UNNEST(event_params), um einen Parameter per key zu ziehen. Zweitens der _TABLE_SUFFIX-Filter: Statt eine riesige Tabelle abzufragen, begrenzt du über das Datum im Tabellennamen die eingelesenen Daten – das spart Kosten (dazu Schritt 4).

Nutzer und Sitzungen zählst du so:

SELECT
  COUNT(DISTINCT user_pseudo_id) AS nutzer,
  COUNT(DISTINCT CONCAT(
    user_pseudo_id,
    CAST((SELECT value.int_value
          FROM UNNEST(event_params)
          WHERE key = 'ga_session_id') AS STRING)
  )) AS sitzungen
FROM `projekt.analytics_XXXXXX.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260101' AND '20260107'

Der Sitzungs-Trick: Weil es keine Session-Tabelle gibt, bildest du eine eindeutige Sitzung als Kombination aus user_pseudo_id und ga_session_id. Genau solche Muster machen den Reiz von BigQuery aus – du definierst selbst, was gezählt wird, statt dich auf die vordefinierten GA4-Metriken zu verlassen.

Schritt 4: Kosten verstehen und kontrollieren

BigQuery rechnet vor allem nach abgefragter Datenmenge ab, nicht nach Ergebnisgröße. Der Free Tier umfasst pro Monat rund 1 TiB verarbeitete Abfragedaten und 10 GiB Speicher. Für kleine bis mittlere Sites reicht das oft lange. Kosten entstehen erst darüber – und meist durch vermeidbare Fehler.

Die wichtigsten Kostenhebel:

Nie SELECT * über große Zeiträume. BigQuery liest die angesprochenen Spalten der gesamten gescannten Tabellen. Wähle nur die Spalten, die du brauchst.
Immer über _TABLE_SUFFIX (oder Partition) den Zeitraum begrenzen. Ohne Datumsfilter scannst du deine komplette Historie – der häufigste teure Anfängerfehler.
Zwischenergebnisse materialisieren. Wiederkehrende, aufwendige Auswertungen als Tabelle/View speichern, statt jedes Mal die Rohdaten neu zu scannen.
Streaming-Export bewusst einsetzen. Der Intraday-Export verursacht zusätzliche Kosten; nutze ihn nur, wenn du Echtzeit-Nähe wirklich brauchst.

Wer diese vier Punkte beachtet, bleibt in der Regel im günstigen Rahmen. Die Angst vor „unkalkulierbaren Cloud-Kosten" ist meist unbegründet – teuer wird es fast nur durch SELECT * ohne Datumsfilter.

Schritt 5: DSGVO und Datenaufbewahrung

Sobald du Rohdaten in die Cloud exportierst, ist Datenschutz Pflicht. Drei Punkte gehören geklärt: der Datenstandort (für DSGVO-Setups meist EU, siehe Schritt 1), die Rechtsgrundlage und Auftragsverarbeitung für die Verarbeitung in Google Cloud, und der Umgang mit der user_pseudo_id – sie ist pseudonym, aber datenschutzrechtlich relevant.

Ein Vorteil der Rohdaten: Du kannst in BigQuery selbst bestimmen, wie lange du Daten hältst und was du daraus ableitest – etwa alte Daten löschen oder aggregieren. Das passt zum Prinzip der Datensparsamkeit und ergänzt eine saubere First-Party-Datenstrategie, wie sie der Ratgeber zur First-Party-Datenstrategie ohne CDP beschreibt. Wichtig: Das ist keine Rechtsberatung – die konkrete Ausgestaltung gehört fachkundig geprüft.

Häufige Fehler – und wie du sie vermeidest

Fehler	Folge	Besser
`SELECT *` ohne Datumsfilter	hohe Kosten, langsame Abfragen	nur nötige Spalten, `_TABLE_SUFFIX` setzen
`UNNEST` vergessen	Fehler oder leere Parameter	`event_params` per Unterabfrage entpacken
Session als Standard-Feld erwartet	falsche Zahlen	Session aus `user_pseudo_id` + `ga_session_id` bauen
Intraday- und Tages-Tabelle mischen	Dubletten	bewusst eine Quelle wählen
Export spät aktiviert	fehlende Historie	so früh wie möglich anschalten

Diese fünf Punkte decken die meisten Frust-Momente ab. Besonders der Datumsfilter und das UNNEST-Muster sind die zwei Dinge, die den Unterschied zwischen „teuer und frustrierend" und „günstig und mächtig" machen.

Realistische Erwartung

Ehrlich: BigQuery ist ein Sprung in der Komplexität. Du brauchst SQL, ein Grundverständnis des Schemas und Disziplin bei den Kosten. Für eine kleine Broschüren-Website ohne besondere Analysefragen ist der Aufwand oft nicht gerechtfertigt – da reichen Standard-Berichte und Looker Studio (siehe Looker-Studio-Dashboards mit GA4).

Was du dafür gewinnst, ist beträchtlich: vollständige, unbeschnittene Daten, volle Freiheit in der Auswertung, die Möglichkeit, Sessions und Metriken selbst zu definieren, und eine Basis, um GA4 mit anderen Datenquellen zu verbinden. Für datengetriebene Teams ist BigQuery der Punkt, an dem GA4 vom begrenzten Report-Tool zur echten Datenquelle wird. Der Einstieg ist steiler – der Hebel danach umso größer.

Fazit

Der BigQuery-Export befreit dich von Sampling, Thresholding und Kardinalitätsgrenzen – zum Preis von etwas mehr Technik. Richte den Export früh ein (Datenstandort und Export-Typ bewusst wählen), verstehe das verschachtelte Schema und das UNNEST-Muster, baue Sessions selbst aus user_pseudo_id und ga_session_id, und halte die Kosten über Datumsfilter und Spaltenauswahl im Griff. Dann hast du die vollständige, unverfälschte Wahrheit deiner GA4-Daten – die Grundlage für Auswertungen, die in der Oberfläche schlicht nicht möglich sind. Wer den Einstieg oder komplexe Auswertungen nicht selbst stemmen will, findet dafür bei spezialisierten Analytics-Fachleuten Unterstützung.

Häufig gestellte Fragen

Das Aktivieren des Exports ist kostenlos, und die Daten sind unsampled. Kosten entstehen erst durch die Google-Cloud-Nutzung oberhalb des Free Tiers – rund 1 TiB verarbeitete Abfragedaten und 10 GiB Speicher pro Monat sind frei. Kleine bis mittlere Sites bleiben damit oft lange kostenlos. Teuer wird es fast nur durch vermeidbare Fehler wie SELECT * ohne Datumsfilter.

Weil GA4-Ereignisdaten verschachtelt sind: event_params ist ein REPEATED RECORD – ein Array aus Schlüssel-Wert-Paaren, nicht eine flache Spalte. Um einen einzelnen Parameter (z. B. die Seiten-URL) herauszuholen, entpackst du das Array mit einer UNNEST-Unterabfrage und filterst auf den passenden key. Dieses Muster ist der zentrale Mechanismus beim Arbeiten mit dem GA4-Export.

GA4 exportiert Ereignis-Rohdaten – eine Zeile pro Ereignis, keine fertige Session-Ebene. Die Session-ID (ga_session_id) steckt selbst in event_params. Eine eindeutige Sitzung bildest du, indem du user_pseudo_id mit ga_session_id kombinierst. Das wirkt zunächst umständlich, gibt dir aber die Freiheit, selbst zu definieren, was als Sitzung zählt – statt dich auf vordefinierte Metriken zu verlassen.

Nein. Der Export beginnt ab dem Zeitpunkt der Aktivierung; ältere Daten werden nicht nachgeliefert. Deshalb solltest du den Export so früh wie möglich anschalten – selbst wenn du BigQuery noch gar nicht aktiv nutzt. So sammelst du Historie, auf die du später zugreifen kannst. Wer zu spät aktiviert, hat schlicht keine früheren Rohdaten.

Beim Einrichten der Verknüpfung wählst du, wo BigQuery die Daten speichert. Für DSGVO-Setups ist in der Regel der EU-Standort die richtige Wahl. Triff diese Entscheidung bewusst, denn ein späterer Umzug ist aufwendig. Kläre parallel Rechtsgrundlage und Auftragsverarbeitung für die Verarbeitung in Google Cloud – das ist keine Rechtsberatung, sondern gehört im Einzelfall geprüft.

Quellen

Google (offiziell): BigQuery Export – GA4 (Analytics-Hilfe) · BigQuery Export schema
Digital Applied: GA4 BigQuery Export 2026: Marketing Analytics Reference
OWOX: UNNEST GA4 Event Parameters in BigQuery

Hinweis: Free-Tier-Grenzen und Cloud-Preise können sich ändern – vor dem Produktivbetrieb die aktuelle Google-Cloud-Preisübersicht prüfen. Kein Rechts- oder Steuerrat; Datenstandort, Auftragsverarbeitung und Aufbewahrung im Einzelfall datenschutzrechtlich klären.