E-Commerce-Attribution: Live API vs. BigQuery - warum die Zahlen abweichen
Im GA4 Auditor gibt es zwei Wege, die Quellen einer Bestellung zu analysieren:
über die Live-API (sessionDefaultChannelGroup) oder über den
BigQuery-Export (session_traffic_source_last_click.cross_channel_campaign.default_channel_group).
Für dieselbe Bestellung sieht man oft unterschiedliche Kanäle - das ist kein
Bug, sondern systemisch. Dieser Artikel erklärt warum.
Zwei Reports, zwei Datenstände
| Report | Datenquelle | Wann sinnvoll? |
|---|---|---|
| Live-Channel-Distribution | GA4 Data API (aggregiert) | Tages-Monitoring, Google-Ads-Sicht, schneller Health-Check |
| Order-Attribution / Google-Ads-Attribution | BigQuery (event-level) | Tracking-Debugging, Audit historischer Daten, Root-Cause |
Die Live-API liefert vor-aggregierte Reporting-Daten mit Googles Standard-Channel-Grouping. Der BigQuery-Export liefert dieselben Felder, aber aus den Rohdaten und deterministisch für einen abgeschlossenen Tag.
Das 72-Stunden-Fenster
GA4 hält die Attribution nach einem Event noch bis zu 72 Stunden offen. Googles ML modelliert in dieser Zeit Conversions für Cookie-blockierte Nutzer und Cross-Device-Journeys nach. Das hat zwei Effekte, die der Auditor sichtbar macht:
- Live-API zeigt aktuelle, modellierte Attribution - die sich aber bis zu 3 Tage später noch ändert.
- BigQuery-Daily-Export spiegelt den finalisierten Stand wider (24-48h nach Tagesende stabil).
Wer also montags die Live-API-Zahlen einer Kampagne vom Sonntag mit dem BigQuery-Export von Sonntag vergleicht, sieht zwangsläufig Unterschiede.
Wo „Direct" nicht gleich „Direct" ist
Die Live-API fasst auffälliges Verhalten oft pauschal unter (Direct) /
(unassigned) zusammen. Der Auditor zerlegt das im BigQuery-Report in
deutlich feinere Klassen - der entsprechende SQL-Block aus
app/queries/checks/google_ads_attribution.sql
zeigt das Prinzip:
CASE
-- gclid vorhanden UND korrekt als Paid Search/Cross-network klassifiziert
WHEN gclid IS NOT NULL AND gclid != ''
AND (
LOWER(session_default_channel) IN ('paid search', 'cross-network')
OR (LOWER(session_source) = 'google'
AND LOWER(session_medium) IN ('cpc', 'ppc', 'paidsearch'))
)
THEN 'attributed_paid_search'
-- gclid vorhanden, ABER als Organic/Direct klassifiziert (Bug-Fall)
WHEN gclid IS NOT NULL AND gclid != ''
THEN 'gclid_misclassified'
-- Direct ohne gclid: möglicherweise Tracking-Lücke
WHEN LOWER(session_default_channel) = 'direct'
THEN 'direct_no_gclid'
ELSE 'other'
END AS attribution_status
Das Feld attribution_status rollt der Auditor in der Dashboard-Section
Google Ads Attribution auf, sodass der bekannte GA4-Bug
„gclid da, aber als Organic gezählt" überhaupt sichtbar wird - in der
Live-API würde diese Session schlicht als Organic Search durchlaufen.
Daily vs. Intraday im BigQuery-Export
Der BigQuery-Export schreibt sowohl events_intraday_YYYYMMDD (laufend) als
auch events_YYYYMMDD (final, ein bis zwei Tage später). Der Auditor
bevorzugt automatisch die finalisierte Tabelle, sobald sie verfügbar ist -
das wirkt nach außen wie „die Zahlen ändern sich noch", ist aber gewollt:
Intraday-Daten sind Schätzwerte, Daily-Export ist Wahrheit.
Welcher Report wann?
- Live-API-Channel-Distribution für: Tages-Monitoring, Google-Ads-Sicht mit Conversion-Modeling, schnelle Plausibilitätsprüfung.
- BigQuery-Order-Attribution für: Tracking-Bug-Diagnose, historische Vergleiche, Audit-Berichte, alles Detailgenaue.
Im Dashboard sind beide Sichten parallel verfügbar - create_acquisition_section
für die Live-Sicht, create_order_attribution_section und
create_google_ads_attribution_section für die BigQuery-Sicht. Die
Hilfeseite Attribution & Akquisitions-Qualität
fasst die wichtigsten Diagnose-Pfade zusammen.
Fazit
Abweichungen zwischen Live-API und BigQuery sind keine Tracking-Fehler, sondern Folge unterschiedlicher Datenstände und Klassifikations-Granularität. Wer Attribution ernsthaft auditieren will, braucht beide Sichten: Die Live-API zeigt, dass etwas nicht stimmt - BigQuery zeigt, was genau.