Warum die meisten BigQuery-Projekte scheitern (und es fast nie an BigQuery liegt)

Das Muster: BigQuery wird zum Datengrab

Es läuft fast immer gleich ab. Jemand aktiviert den GA4-BigQuery-Export, die Rohdaten fließen, und für zwei Wochen fühlt sich das nach Fortschritt an. Endlich eigene Daten, endlich SQL, endlich keine Sampling-Grenzen mehr.

Dann passiert nichts mehr.

Die events_-Tabellen wachsen täglich. Niemand baut darüber eine saubere Schicht. Wer eine Zahl braucht, schreibt eine neue Query von Hand, kopiert sie aus einem alten Dashboard oder fragt die Person, die das letzte Mal eine ähnliche Frage hatte. Sechs Monate später gibt es vierzig halb-redundante Queries, drei Definitionen von "Conversion" und eine BigQuery-Rechnung, die niemand erklären kann.

Das ist kein Tooling-Problem. Das ist ein fehlender Plan, der sich als Tooling-Problem tarnt.

Fehler 1: Der Export ist kein Modell

Der GA4-Export ist roh. Bewusst roh. Eine Zeile pro Event, verschachtelte event_params als Arrays, user_properties als Structs, alles unnormalisiert. Google liefert das so, weil es maximal flexibel sein soll, nicht weil man darauf direkt reporten soll.

Viele Teams überspringen genau diesen Schritt. Sie reporten direkt auf die Rohtabelle. Jedes Dashboard, jede Ad-hoc-Query muss dann selbst die event_params auspacken, selbst die Session rekonstruieren, selbst entscheiden, was ein Purchase ist. Diese Logik liegt verstreut in dreißig Queries statt an einer Stelle.

-- Eine einzige Bestellung aus den rohen Events, alles muss ausgepackt werden
SELECT
  event_date,
  (SELECT value.string_value FROM UNNEST(event_params)
     WHERE key = 'transaction_id') AS transaction_id,
  (SELECT value.int_value FROM UNNEST(event_params)
     WHERE key = 'ga_session_id')  AS session_id,
  ecommerce.purchase_revenue       AS revenue
FROM `projekt.analytics_123456789.events_*`
WHERE event_name = 'purchase';

Diese Auspack-Logik gehört genau einmal ins Modell, nicht in jedes Dashboard.

Dasselbe gilt für Kennzahlen. COUNT(DISTINCT user_pseudo_id) ist nicht die GA4-Nutzerzahl, und Sessions zählt man über ga_session_id pro Nutzer, nicht über session_start. Wer das nicht im Modell festschreibt, bekommt Zahlen, die der GA4-Oberfläche widersprechen, und verliert die Diskussion im Meeting.

Die Modellierungsschicht ist nicht optional. Sie ist der Punkt, an dem aus Events Geschäftslogik wird:

• stg_events säubert und tippt die Rohdaten
• int_sessions rekonstruiert Sessions konsistent
• fct_orders ist die eine Wahrheit über Bestellungen
• dim_* hält Kanäle, Kampagnen, Produkte sauber getrennt

Genau das macht dbt, und deshalb ist es bei uns der Standard-Layer zwischen BigQuery und BI. Nicht aus Mode. Weil die Alternative ist, dass jede Definition vierzig Mal existiert und vierzig Mal leicht anders.

Fehler 2: SELECT * frisst das Budget

BigQuery rechnet im On-Demand-Modell nach gescannten Bytes ab, rund 6 $ pro Terabyte. Das klingt harmlos, bis jemand SELECT * über ein Jahr GA4-Events schreibt und die Query nichts davon weiß, dass nur drei Spalten und ein Monat gebraucht werden.

Ein Beispiel aus einem Setup, das ich 2024 übernommen habe: Die monatliche BigQuery-Rechnung war höher als die GA4-360-Lizenz, die man mit dem Wechsel auf die Free-Tier-Version eigentlich vermeiden wollte. Man hatte das teure Tool gegen ein vermeintlich günstiges getauscht und dann genauso viel ausgegeben. Punkt.

Die Ursachen sind fast immer dieselben:

• Keine Partitionierung nach event_date, also scannt jede Query die komplette Historie
• Kein Clustering, also keine Pruning-Vorteile bei Filtern
• Dashboards, die live auf die Rohtabelle gehen, statt auf ein materialisiertes, schlankes Modell
• SELECT * als Reflex, obwohl niemand 300 Spalten braucht

-- ❌ Full Scan: liest jedes Mal die komplette Event-Historie
SELECT * FROM `projekt.analytics_123456789.events_*`;

-- ✅ Smart Scan: nur der gebrauchte Zeitraum, nur die nötigen Spalten
SELECT event_date, event_name, user_pseudo_id
FROM `projekt.analytics_123456789.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260501' AND '20260531';

Dasselbe Ergebnis, ein Bruchteil der gescannten Bytes. Der _TABLE_SUFFIX-Filter ist bei den täglich geshardeten GA4-Tabellen das, was Partitionierung sonst leistet.

Partitionierung plus ein materialisiertes Modell senkt die gescannten Bytes oft um über 90 %. Das ist kein Optimierungs-Detail für Spezialisten. Das ist der Unterschied zwischen einer Rechnung, die man unterschreibt, und einer, die man verteidigen muss.

Fehler 3: Keine Tests, kein Vertrauen

Marketing-Daten werden seltener falsch als unbemerkt falsch. Ein Tag bricht, ein Parameter wird umbenannt, ein Join verdoppelt Zeilen. Ohne Tests merkt das niemand, bis ein Quartalsreport komisch aussieht und die Diskussion bei "stimmen die Zahlen überhaupt?" landet.

In klassischer Software ist ein Test Pflicht. In Daten-Pipelines wird er behandelt, als wäre er Kür. Dabei sind die nötigen Tests banal:

• Ist order_id eindeutig?
• Ist revenue nie negativ?
• Decken sich die Tageskonten zwischen Roh-Export und Modell?
• Taucht jeder erwartete Event-Typ noch auf, oder ist still etwas weggebrochen?

dbt-Tests fangen genau das ab, automatisiert, bei jedem Lauf. Der eigentliche Gewinn ist nicht technisch. Er ist sozial: Wenn die Pipeline grün ist, hört die Diskussion über die Glaubwürdigkeit der Zahlen auf und die Diskussion über die Entscheidung fängt an. Das ist der ganze Sinn der Übung.

Fehler 4: Erst das Dashboard, nie das Modell

Der teuerste Fehler ist kulturell. Die Erwartung lautet: in zwei Wochen steht das Dashboard. Also baut jemand schnell ein Dashboard direkt auf die Rohdaten, es sieht gut aus, alle sind zufrieden, und die Modellierungsschicht wird "später" gemacht.

Später kommt nie.

Das Dashboard wird zur Quelle der Wahrheit, obwohl die Logik darin steckt, unsichtbar, ungetestet, nicht versioniert. Will man die Definition von "aktiver Kunde" ändern, muss man sie in jedem Report einzeln suchen. Jede Änderung wird zur Schnitzeljagd. Genau hier entstehen die drei Teams mit drei Zahlen für denselben Umsatz, nicht aus Böswilligkeit, sondern weil die Logik nie an einen gemeinsamen Ort gezogen wurde.

Ein Dashboard ist die letzte Schicht, nicht die erste. Wer es zuerst baut, baut auf Sand.

Was ein funktionierendes Setup anders macht

Die guten Setups sehen langweilig aus, und das ist ein Kompliment. Sie haben eine klare Reihenfolge, und sie halten sie ein:

1. Roh-Export landet in einem eigenen Dataset. Unangetastet, als Quelle der Wahrheit für alles Weitere.
2. dbt modelliert in Schichten. Staging säubert, Intermediate rekonstruiert, Marts liefern Geschäftslogik. Jedes Modell hat einen Namen, einen Test und einen Owner.
3. Definitionen leben einmal. "Conversion", "aktiver Kunde", "attribuierter Umsatz", je genau einmal definiert, im Modell, nicht im Dashboard.
4. Partitioniert und geclustert. Reporting geht auf schlanke Marts, nicht auf die Rohtabelle.
5. BI ist die Anzeige, nicht die Logik. Power BI oder Data (Looker) Studio zeigt, was das Modell berechnet hat. Mehr nicht.

Dieselbe Architektur zahlt sich doppelt aus, sobald KI ins Spiel kommt. Ein Sprachmodell, das Fragen zu Ihren Marketing-Daten beantworten soll, ist nur so gut wie die Modelle darunter. Saubere, getestete, benannte Tabellen sind genau das, was ein LLM braucht, um nicht zu halluzinieren. Die unaufgeräumte Rohtabelle ist es nicht. Datenqualität ist keine Vorbereitung auf KI. Sie ist die Voraussetzung dafür.

BigQuery ist ein exzellentes Warehouse. Schnell, günstig im EU-Standort europe-west3, eng mit GA4 verzahnt. In fast jedem gescheiterten Projekt, das wir übernommen haben, war BigQuery der Teil, der funktionierte. Gescheitert ist die Schicht, die niemand gebaut hat.

Steht Ihr Warehouse, aber niemand traut den Zahlen? Ein Audit Sprint prüft Modellierung, Kosten und Tests und liefert in zwei Wochen einen priorisierten Plan, was zuerst geradegezogen werden muss.