Was ist der GA4-Export nach BigQuery

Zuerst gehört geklärt, was über diese Verknüpfung reist. Exportiert werden weder die Berichte von Analytics noch deren fertig berechnete Kennzahlen. Exportiert werden die Ereignisse so, wie sie erfasst wurden, eines je Zeile, mit ihren Parametern verschachtelt in derselben Zeile. Die Rate der Schlüsselereignisse, die Sitzung mit Interaktion oder der aktive Nutzer kommen nicht als Zahl an: Sie kommen als Rohstoff, aus dem du sie bei Bedarf neu berechnest.

Der Datensatz, der in BigQuery entsteht, trägt die Kennung der Property im Namen und enthält eine Tabelle je Tag. Jede Zeile bringt den Ereignisnamen, den Zeitstempel in Mikrosekunden, die pseudonyme Kennung des Browsers oder der Installation, die Ereignisparameter, die Nutzereigenschaften, die Artikel des Onlinehandels und die Daten zur Traffic-Quelle.

Diese verschachtelte Struktur ist der praktische Unterschied zu einem Berichtsexport in eine Tabellenkalkulation. Sie zwingt zu SQL mit Entschachtelung und erlaubt im Gegenzug Fragen, die die Oberfläche nicht zulässt, weil dort jeder Bericht die Gruppierung der Daten bereits für dich entschieden hat.

Die Verknüpfung wird in der Verwaltung der Property eingerichtet und verlangt Bearbeitungsrechte in Analytics sowie Inhaberrechte am Google-Cloud-Projekt. Es gibt zwei Modi, die sich gleichzeitig aktivieren lassen. Der tägliche Stapelexport schickt einmal am Tag alle Ereignisse des Vortages, ohne Stichprobe, üblicherweise am frühen Nachmittag in der Zeitzone der Property. Der laufende Export schickt die Ereignisse des aktuellen Tages binnen weniger Minuten, als Dienst nach bestem Bemühen und ohne Vollständigkeitsgarantie. 360-Properties haben zusätzlich eine schnellere Tagesvariante.

Jeder Modus schreibt in eigene Tabellen. Der tägliche erzeugt Tabellen mit dem Datumssuffix, der laufende erzeugt Intraday-Tabellen, die am Ende des Tages gelöscht werden, sobald die Tagestabelle vollständig ist. Die Intraday-Tabellen enthalten einige Felder nicht, darunter die Traffic-Quelle. Zudem aktualisiert Analytics die Tagestabelle noch bis zu drei Tage nach dem Ereignis, um Daten aufzunehmen, die verspätet von Geräten ohne Verbindung eintreffen.

Ein Limit entscheidet über viele Projekte. Eine Standard-Property erlaubt im Stapelexport bis zu eine Million Ereignisse pro Tag; wird das überschritten, pausiert der tägliche Export, und die vorherigen Tage werden nicht neu verarbeitet. Der laufende Export kennt diese Grenze nicht. Die Kosten stellt nicht Analytics: Sie stellt BigQuery für Speicher und für die Verarbeitung jeder Abfrage, mit einem monatlichen Freikontingent, und der laufende Export wird zusätzlich nach gesendetem Datenvolumen abgerechnet. Ein Export in die Testumgebung von BigQuery ist ebenfalls kostenlos möglich, mit den Einschränkungen dieser Umgebung.

SELECT
  event_date,
  event_name,
  COUNT(*) AS event_count
FROM
  `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
WHERE
  event_name IN ('page_view', 'session_start', 'purchase')
  AND _TABLE_SUFFIX BETWEEN '20201201' AND '20201202'
GROUP BY 1, 2;

Der Export löst vier Dinge, die die Oberfläche nicht löst. Das erste ist die Aggregation: Berichte zeigen bereits verdichtete Werte und fassen, wenn eine Dimension zu viele verschiedene Werte hat, den Rest unter einer Zeile namens (other) zusammen. In BigQuery liegt dieser Rest weiterhin vor, Zeile für Zeile. Das zweite ist die Attribution: Wer ein eigenes Modell, ein eigenes Zeitfenster oder eine eigene Sitzungsdefinition will, braucht die ursprünglichen Ereignisse und keine fertig attribuierte Kennzahl.

Das dritte ist die Verknüpfung. Die Bestellnummer, die im Kaufereignis mitreist, lässt sich mit der Bestelltabelle des Warenwirtschaftssystems zusammenführen, und dann geht das Gespräch nicht mehr um Transaktionen, sondern um bezahlte Bestellungen, Retouren und Marge. Das vierte ist die Aufbewahrung: Die Rohdaten bleiben in deinem Projekt, mit deiner Aufbewahrungsregel, nicht mit der der Oberfläche.

Ebenso gehört gesagt, was er nicht kann. Er bringt keine Daten aus der Zeit vor der Verknüpfung, und ein rückwirkendes Auffüllen gibt es nicht. Er bildet auch die modellierten Kennzahlen der Oberfläche nicht nach, weshalb eine Zahl aus BigQuery und eine aus Analytics abweichen können, ohne dass eine davon falsch ist. Und er ersetzt die tägliche Beobachtung nicht: Für einen schnellen Blick auf den Verlauf bleibt die Oberfläche der günstigste Weg.

• Aktiviere den Export schon beim Anlegen der Property, auch wenn du ihn noch nicht abfragst, denn Daten vor der Verknüpfung sind nicht nachholbar.
• Aktiviere täglichen und laufenden Export gemeinsam, wenn du den aktuellen Tag brauchst, und nutze jede Tabelle für das, wofür sie taugt.
• Behalte bei einer Standard-Property das tägliche Ereignisvolumen im Blick und reduziere überflüssige Ereignisse, bevor du an die Grenze des Stapelexports stößt.
• Filtere immer über das Tabellensuffix oder die Datumspartition, damit nicht bei jeder Abfrage ganze Jahre gescannt werden.
• Frage die letzten drei Tage erneut ab, bevor du eine Zahl als endgültig ausgibst, denn die Tagestabellen nehmen weiterhin verspätete Ereignisse auf.
• Lege die Abfragen in einem versionierten Repository ab und dokumentiere, welche Kennzahldefinition jede einzelne umsetzt.

• Erwarten, dass die Verknüpfung den Verlauf vor ihrer Aktivierung mitbringt, und es erst merken, wenn der Wert gebraucht wird.
• Eine Zahl aus BigQuery ungeprüft mit der aus der Oberfläche vergleichen und das einen Fehler nennen, obwohl die Abweichung aus Modellierung, Attribution oder Sitzungsdefinition stammt.
• Die Warnmail zum Limit ignorieren und Wochen später feststellen, dass der tägliche Export pausiert und diese Tage verloren sind.
• Intraday-Tabellen wie endgültige behandeln, obwohl sie zum Tagesende gelöscht werden und nicht alle Felder enthalten.
• Abfragen ohne Datumsfilter über den gesamten Datensatz starten und die Verarbeitungskosten am Monatsende entdecken.