Drei verschiedene Verluste
Content-Blocker (uBlock Origin, AdGuard, Brave Shields, DNS-basierte Blocker) gleichen Request-Hostnamen und Skript-URLs mit öffentlichen Listen ab. connect.facebook.net, googletagmanager.com und analytics.google.com stehen auf diesen Listen; die eigene Subdomain der Seite nicht. Die Blockade passiert, bevor Code läuft — nichts auf der Seite kann dir sagen, dass sie passiert ist. Der Besucher taucht schlicht nicht auf.
Tracking-Schutz des Browsers (Safari ITP, Firefox ETP, Brave) blockiert keine Requests an First-Party-Hosts; er begrenzt Zustand: Drittanbieter-Cookies werden partitioniert oder blockiert, skriptgesetzte Cookies laufen nach 7 Tagen ab, und Cookies über einen CNAME auf eine Drittanbieter-Adresse werden ebenfalls begrenzt. Der Besucher taucht auf, aber öfter als neuer Besucher, als es der Realität entspricht.
Consent-Verweigerung ist der Besucher, der Nein sagt. Technisch ist nichts kaputt; die Daten dürfen nicht erhoben werden. Ein Setup, das diesen Verlust „zurückholt“, ist keine Messung, sondern ein Verstoß.
Wie groß jeder Verlust ist
Das hängt vom Publikum ab. Technische und jüngere Zielgruppen in Deutschland zeigen Content-Blocker-Raten deutlich über dem globalen Durchschnitt; der Safari-Anteil treibt ITP-Effekte; Consent-Raten hängen vom CMP-Design und dem Vertrauen in die Site ab. Statt Branchendurchschnitte zu zitieren, miss deine eigenen: Vergleiche die angenommenen Seitenaufrufe des Collectors (Events-Seite, nach Quelle) mit der Seitenaufrufzahl, die das Anbieter-Tag für denselben Zeitraum meldet — die Lücke ist dein Content-Blocker-Verlust auf dem Host dieses Anbieters. Die Consent-Seite liefert den Verweigerungsanteil direkt, und das Verhältnis wiederkehrender Besucher je Browser in deinem Analytics zeigt den ITP-Effekt.
Was ein First-Party-Server-Setup zurückholt
- Eingewilligte Events, die listenbasierte Blocker blockieren. Das SDK lädt von deiner Subdomain und sendet an deinen Collector; Blocker matchen das nicht. Das eingewilligte Event erreicht deinen Collector und von dort die Server-APIs der Anbieter. Die Match-Qualität hängt davon ab, welche Kennungen der Consent erlaubt hat.
- Serverseitige Zustellung dessen, was der Browser nicht senden konnte. Vom Shop oder Server bestätigte Käufe und Leads werden zugestellt, auch wenn das Anbieter-Pixel nie geladen wurde.
- Anbieterausfälle und vorübergehende Fehler. Der Worker wiederholt; der Browser hat das nie getan.
Was sich nicht ändert: Die anonyme ID wird vom SDK unter Analytics- oder Marketing-Consent geschrieben, und Safari begrenzt skriptgeschriebenen Speicher weiterhin auf sieben Tage. Die Erkennung wiederkehrender Safari-Besucher darüber hinaus bleibt begrenzt; Track umgeht das nicht.
Was es nicht zurückholen darf
- Verweigerten Consent. Keine Click-IDs, keine Kennungen, keine Marketing-Destinationen. Der Router setzt das je Event durch; es ist keine Konfiguration, die man abschalten kann.
- Blockierte Anbieter-Pixel als solche. Blockiert der Besucher
fbevents.js, bleibt die Browser-Seite von Meta blockiert. Der Server-Weg erhält das eingewilligte Event — das ist das Design — aber er injiziert das Pixel nicht über einen anderen Weg. - Fingerprinting als Ersatz für Kennungen. Nicht implementiert, nicht konfigurierbar. Unbekannt bleibt unbekannt.
„Event Match Quality“ der Anbieter ehrlich lesen
Anbieter bewerten, wie viele Kennungen jedes Server-Event trägt. Nach dem Wechsel auf serverseitig steigt der Wert oft, weil die gehashte E-Mail aus dem Bestellsystem nun enthalten ist. Das ist eine echte Verbesserung für eingewilligte Käufe. Es ist kein Beleg dafür, dass mehr Menschen getrackt werden; die Consent-Seite zeigt denselben Verweigerungsanteil wie zuvor.
Praktische Schritte
- Collector und SDK auf eine First-Party-Subdomain legen (siehe den Leitfaden zur First-Party-Domain).
- Käufe und Leads vom Server mit derselben Event-ID wie der Browser senden.
- Zählwerte je Browser auf der Datenqualitätsseite vergleichen; die Lücke sollte bei Chrome mit Blockern und bei Firefox schrumpfen, die Erkennung wiederkehrender Besucher auf Safari besser werden.
- Die Consent-Rate in Ruhe lassen — oder mit einem klareren Banner verbessern, nie mit Technik.