{"id":10123,"date":"2026-09-27T13:29:00","date_gmt":"2026-09-27T11:29:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=10123"},"modified":"2026-10-26T11:41:34","modified_gmt":"2026-10-26T10:41:34","slug":"tutorial-ga4-daten-nach-bigquery-exportieren-und-die-erste-sql-abfrage-schreiben","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/digital-analytics-de\/tutorials-de\/tutorial-ga4-daten-nach-bigquery-exportieren-und-die-erste-sql-abfrage-schreiben\/","title":{"rendered":"Tutorial: GA4-Daten nach BigQuery exportieren und die erste SQL-Abfrage schreiben"},"content":{"rendered":"

BigQuery stellt exportierte GA4-Events f\u00fcr eigene SQL-Auswertungen bereit: Verkn\u00fcpfungen mit Gesch\u00e4ftsdaten, ausdr\u00fccklich definierte Kennzahlen und beobachtete Seitenabfolgen. Auch GA4 bietet Pfad- und Trichterexplorationen. SQL erweitert die Kontrolle \u00fcber Berechnung und Ausgabe.<\/p>\n

Die Anleitung beginnt mit dem t\u00e4glichen Export, pr\u00fcft den Eingang von Events und gruppiert anschlie\u00dfend beobachtete Webseitenaufrufe nach Sitzungskennungen. Die Beispiele beschreiben den ausgew\u00e4hlten Export, keine garantiert vollst\u00e4ndigen Besuche.<\/p>\n

\"Exportumfang,
Exportumfang, verf\u00fcgbare Kennungen und Sortiergrenzen bestimmen die Aussage eines rekonstruierten Pfads.<\/figcaption><\/figure>\n

1. T\u00e4glichen Export einrichten<\/h2>\n

Die Verkn\u00fcpfung entsteht unter Verwaltung \u2192 Produktverkn\u00fcpfungen \u2192 BigQuery-Verkn\u00fcpfungen<\/strong>. In GA4 sind mindestens Bearbeitungsrechte auf Property-Ebene erforderlich. Das Cloud-Projekt ben\u00f6tigt die dokumentierten IAM- und Dienstberechtigungen. Die Rolle Owner enth\u00e4lt diese Rechte; eine passende engere Rollenkombination kann ebenfalls ausreichen. Die BigQuery-API muss aktiviert sein.<\/p>\n

Die Einrichtung umfasst Cloud-Projekt, Speicherort, Streams und ausgeschlossene Events. F\u00fcr Standard-Properties stehen Daily und Streaming unabh\u00e4ngig voneinander bereit; geeignete Analytics-360-Properties bieten zus\u00e4tzlich Fresh Daily. Daily erzeugt events_YYYYMMDD<\/code>, Streaming vorl\u00e4ufige events_intraday_YYYYMMDD<\/code>-Tabellen mit m\u00f6glichen L\u00fccken. F\u00fcr abgeschlossene Tage eignet sich der t\u00e4gliche Export besser; versp\u00e4tete Events k\u00f6nnen j\u00fcngere Tagestabellen allerdings noch ver\u00e4ndern.<\/p>\n

Die Verkn\u00fcpfung holt fr\u00fchere Property-Daten nicht nach. Erste Daten treffen normalerweise innerhalb von 24 Stunden ein; eine bestimmte t\u00e4gliche Lieferzeit ist nicht garantiert. F\u00fcr Standard-Properties gilt ein t\u00e4gliches Limit von einer Million exportierten Events. Eine \u00dcberschreitung kann den t\u00e4glichen Export aussetzen. Ausgeschlossene Streams oder Events senken das Volumen, ver\u00e4ndern aber auch die Grundlage der Auswertung.<\/p>\n

Ein t\u00e4glicher Export bedeutet keine kostenlose Cloud-Nutzung: Speicherung und Abfragen k\u00f6nnen Kosten verursachen, Streaming zus\u00e4tzlich \u00dcbertragungskosten. Vor der ersten Abfrage zeigen Editor-Sch\u00e4tzung oder Dry Run die erwartete Verarbeitung. Ein Dry Run pr\u00fcft die Abfrage, ohne diese auszuf\u00fchren. maximum bytes billed<\/code> begrenzt bei bedarfsabh\u00e4ngiger Abrechnung die abrechenbaren Bytes je Abfrage. Die folgenden Beispiele verwenden einen bewusst begrenzten Zeitraum.<\/p>\n

2. Unterschiede zu GA4-Berichten verstehen<\/h2>\n

Der Event-Export arbeitet ohne Stichprobe und fasst viele unterschiedliche Dimensionswerte nicht in einer (other)<\/code>-Zeile zusammen. GA4-Berichte und Explorationen k\u00f6nnen unterschiedliche Ausgangstabellen verwenden; Stichproben, Aggregationsgrenzen oder Datenschutzschwellen sind m\u00f6glich. Schwellenwerte betreffen beispielsweise demografische Angaben und Suchanfragen. Aktive Google-Signale erkl\u00e4ren nicht pauschal jede fehlende Zeile.<\/p>\n

BigQuery reproduziert weder die Verhaltens- und Schl\u00fcsselereignismodellierung noch die datengetriebene Attribution aus GA4. Trotzdem fehlen nicht s\u00e4mtliche Attributionsfelder: Das aktuelle Schema enth\u00e4lt unter anderem beobachtete Last-Click-Sitzungsquellen, soweit verf\u00fcgbar. Bei Abweichungen sind Kennzahl, Zeitraum, Property-Zeitzone, Identit\u00e4tsverfahren, Exportfilter und Datenstand abzugleichen. Eine Differenz ist weder automatisch ein Fehler noch automatisch unbedenklich.<\/p>\n

3. Das verschachtelte Schema lesen<\/h2>\n

Jede exportierte Zeile steht f\u00fcr ein Event. Direkte Spalten sind unter anderem event_name<\/code>, event_date<\/code>, event_timestamp<\/code> und user_pseudo_id<\/code>. Zus\u00e4tzliche Werte wie ga_session_id<\/code> und page_location<\/code> liegen in event_params<\/code>, einer Liste von Namen und zugeh\u00f6rigen Werten innerhalb der Eventzeile. UNNEST<\/code> macht diese Records zug\u00e4nglich; eine skalare Unterabfrage liest genau einen Wert f\u00fcr den gesuchten Namen.<\/p>\n

event_date<\/code> folgt der eingestellten Berichtszeitzone. event_timestamp<\/code> wird in UTC-Mikrosekunden angegeben; mehrere gemeinsam \u00fcbertragene Events k\u00f6nnen denselben Zeitstempel tragen. Batch-Felder erg\u00e4nzen Reihenfolgeinformationen. Eine Pseudo-ID bezeichnet eine App-Instanz oder einen Browserkontext, keine verifizierte Person. Fehlende und wechselnde Kennungen begrenzen die Rekonstruktion. Die Abfrage gruppiert nach den getrennten Feldern stream_id<\/code>, Pseudo-ID und Sitzungs-ID.<\/p>\n

4. Eingang exportierter Events pr\u00fcfen<\/h2>\n

Projektkennung, Property-Dataset und Datumswerte sind Platzhalter f\u00fcr tats\u00e4chlich vorhandene Tagestabellen. Die Abfragen verwenden GoogleSQL.<\/p>\n

SQL<\/span>