Tracking trotz Consent-Verlust

Der Tracking-Verlust hängt stark vom Setup ab — die Frage ist nicht ob du verlierst, sondern wie viel.

Klassisches Browser-Tracking ohne Server-Side: 30–50 % Daten-Verlust ist heute Standard. Bei iOS-lastigen Zielgruppen (Premium, Health, Beauty) eher Richtung 50 %, bei Android-lastigen B2B-Zielgruppen Richtung 30 %.

Mit Server-Side-Setup & CAPI: Match-Rate steigt auf 70–90 % — abhängig von der Datenqualität (gehashte Email, gehashtes Telefon, Click-ID, IP).

Mit eigenem Data-Lake: 95 %+ Daten-Erhalt, weil du nicht auf Plattform-Reports angewiesen bist, sondern eigene Rohdaten auswertest.

Was „normal" ist, sagt nichts darüber aus, was möglich ist. 30–50 % Verlust ist häufig — heißt aber nicht, dass du das akzeptieren musst.

Es gibt drei zentrale Kennzahlen — und alle drei lassen sich konkret prüfen.

1. Event Match-Rate (EMQ in Meta): Im Meta Events Manager sichtbar. Werte unter 6.0 (von 10) sind kritisch, 7.0–8.5 ist gut, 9.0+ ist sehr gut. Niedrige EMQ heißt: Meta kann deine Events keinen Nutzer-Profilen zuordnen — die Optimierung leidet.

2. Server-Side vs. Browser-Diskrepanz: Vergleiche im Tag Manager Container die Anzahl Server-Side-Events vs. Browser-Pixel. Bei sauberem Setup sollte Server-Side 15–30 % mehr Events als Browser sehen — sonst geht der Vorteil von Server-Side verloren.

3. Plattform-Report vs. echte Verkäufe: Der ehrlichste Test — vergleiche Conversions im Meta- oder Google-Report mit den tatsächlichen Bestellungen aus dem Shop-Backend. Diskrepanz unter 10 % ist sehr gut, 10–20 % ist normal, mehr als 20 % bedeutet kaputtes Tracking.

Was diese Werte über deinen Stack aussagen: alle drei Kennzahlen müssen gleichzeitig im grünen Bereich sein.

Eine der häufigsten Fragen — und eine der am häufigsten falsch verstandenen. Die kurze Antwort: du brauchst beides, parallel.

Pixel (Browser-Tracking) sieht alles, was im Browser passiert (UTM-Parameter, Click-IDs, Referrer), wird aber durch ITP, Adblocker und Consent-Verweigerung stark eingeschränkt.

CAPI (Conversions API) sendet Conversions Server-zu-Server, unabhängig vom Browser. Wird nicht durch ITP oder Adblocker blockiert. Braucht reichere Daten (gehashte Email, Telefon, IP, User-Agent) für gutes Matching.

Mit Event-Deduplication erkennt Meta automatisch, ob ein Event vom Pixel und CAPI kam — und zählt es nur einmal. Du bekommst die Vorteile beider Welten: Browser-Klickdaten + Server-Side-Robustheit.

Faustregel: Pixel allein ist heute nicht mehr ausreichend. CAPI allein verliert Click-Attribution. Beide zusammen mit sauberer Deduplication ist der Standard.

Server-Side ist nicht automatisch GDPR-konform, aber es ist die bessere Grundlage für GDPR-Konformität als reines Browser-Tracking.

• Was Server-Side erlaubt: Pseudonymisierung auf dem Server (Email/Telefon/IP hashen), selektive Daten-Weitergabe pro Plattform, Audit-Logs für alle Daten-Transfers, Kontrolle über Sub-Prozessoren
• Was Server-Side nicht löst: Einwilligungspflicht (User-Consent bleibt nötig), US-Daten-Transfer (Schrems-II-Risiko bleibt), Cookie-Banner-Pflicht bei First-Party-Cookies
• Was du brauchst: Consent Management Platform (Cookiebot, Usercentrics), Datenschutzerklärung mit Hinweis auf Server-Side-Tracking, ggf. DPIA, Vertragslagen mit Sub-Prozessoren — setze ich standardmäßig mit auf.

BigQuery ist die strategische Frage hinter Server-Side-Tracking — und es lohnt sich häufiger als gedacht.

Was BigQuery monatlich kostet: Bei Mid-Sized-Setups (1–5 Mio. Events/Monat) typisch 30–100 € Storage + Query-Kosten. Skaliert linear mit Volumen.

Faustregel: Wenn du Tracking ernst meinst und Daten als langfristiges Asset siehst, ist BigQuery (oder ein Pendant wie Snowflake) die einmalige Investition, die du irgendwann eh machen musst. Je früher, desto billiger.

• Wann BigQuery Sinn macht: mehr als 100k Pageviews/Monat (GA4-Sampling sonst kritisch), mehrere Datenquellen zum Verbinden, eigene Attribution-Modelle, Compliance-Anforderungen für eigene Rohdaten
• Wann es überdimensioniert ist: kleine Sites mit klarem Funnel und einem Channel, keine SQL/dbt-Ressourcen im Team, reines Performance-Reporting reicht

Ja — und ist dann oft besonders wertvoll. Server-Side-Setup heißt nicht automatisch gutes Setup — viele Implementierungen lassen 30–50 % der Daten weiterhin liegen, ohne dass es jemand merkt.

Was du bekommst: Match-Rate-Check, Event-Deduplication-Verifikation, Reconciliation Pixel ↔ CAPI ↔ tatsächliche Verkäufe. Plus Action-Plan mit konkreten Optimierungs-Hebeln.

Typische Findings bei bestehenden Setups: falsch konfigurierte Trigger im sGTM-Container, fehlende User-Properties bei CAPI, ungenutzte Optimierungs-Felder, nicht aktivierter Enhanced Conversion-Modus.

Wie die Zusammenarbeit läuft: ich kläre die technischen Befunde direkt mit deinem Dev-Team oder externer Agentur. Kein Anbieter-Wechsel nötig.