Sauber messen trotz iOS und Consent: CAPI und Server-Side erklärt

Warum stimmen meine Zahlen nicht mehr?

Kurze Antwort: Ein wachsender Teil der Käufe erreicht den Werbekanal nicht mehr, weil der Browser das Tracking blockiert. Schätzungen zufolge fehlen bei reinem Pixel-Tracking heute 30–50 % der Conversions. Die Ursachen sind Safaris Intelligent Tracking Prevention, iOS App Tracking Transparency (Nutzer, die „Nicht tracken" wählen) und Ad-Blocker.

Wichtig, weil es viele noch falsch im Kopf haben: Das große „Cookie-Sterben" in Chrome ist abgesagt. Google hat die geplante Abschaffung der Third-Party-Cookies 2024 zurückgezogen und im April 2025 endgültig bestätigt; im Oktober 2025 wurden zudem die meisten Privacy-Sandbox-Techniken eingestellt. Third-Party-Cookies sind in Chrome also weiter standardmäßig an. Das eigentliche Problem sitzt nicht in Chrome, sondern bei Safari, iOS und Ad-Blockern — und das löst man nicht mit Warten, sondern mit serverseitiger Messung.

Was ist die Conversions API (CAPI)?

Die Conversions API schickt Ereignisse wie einen Kauf direkt von deinem Server an Meta — Server zu Server, ohne den Umweg über den Browser des Nutzers. Andere Plattformen haben ihr Gegenstück: Google Ads nennt es Enhanced Conversions (genau genommen eine Anreicherung des bestehenden Google-Tags mit gehashten First-Party-Daten, kein reiner Server-zu-Server-Stream wie Metas CAPI), TikTok die Events API. Der Punkt ist derselbe: Auch wenn der Browser das Tracking blockiert, kommt das Ereignis über den Server trotzdem an.

Pixel oder CAPI — was denn nun?

Beides. Die richtige Frage ist nicht „Pixel oder CAPI", sondern wie du sie parallel betreibst:

• Pixel liefert Browser-Signale — Cookie-IDs (fbp/fbc), User-Agent, Klick-Kontext.
• CAPI liefert das Signal vom Server, wenn der Pixel blockiert wird.
• Deduplizierung über event_id: Beide Events tragen dieselbe ID, damit Meta erkennt, dass es ein Kauf ist — und ihn nur einmal zählt.

Genau hier passiert der häufigste Fehler: Ist die Deduplizierung nicht sauber konfiguriert — unterschiedliche oder fehlende event_id —, zählt Meta denselben Kauf doppelt, oder das zusätzliche Server-Signal bringt gar nichts. Richtig gemacht, holt die Kombination grob 20–30 % der verlorenen Daten zurück und verbessert die Attribution spürbar.

Was ist Event Match Quality — und warum entscheidet sie?

Der am meisten unterschätzte Hebel. Damit Meta ein Server-Event einem Menschen zuordnen kann, schickst du Match-Keys mit — gehasht, also nicht im Klartext: E-Mail, Telefonnummer, die Cookie-IDs fbp/fbc, IP, Name. Je mehr und je bessere Keys, desto höher die Event Match Quality (EMQ), eine Skala bis 10. Metas grober Benchmark liegt bei rund 6; 8+ ist stark und für Käufe ein ambitioniertes, aber realistisches Ziel. Der Unterschied ist nicht kosmetisch: Höhere EMQ heißt bessere Zuordnung, bessere Optimierung, sauberere Zahlen. Viele Konten dümpeln bei 5–6 und lassen damit Performance liegen.

Wo kommt Server-Side (sGTM) ins Spiel?

Server-Side Tagging — meist ein Google-Tag-Manager-Container auf deiner eigenen Subdomain — ist das saubere Fundament darunter. Statt dass jedes Tool sein Skript im Browser lädt, laufen die Ereignisse über deinen Server und werden von dort an Meta, Google und TikTok verteilt. Zwei handfeste Vorteile: Du setzt First-Party-Cookies serverseitig, die länger halten — clientseitig (per JavaScript) gesetzte Cookies kappt Safari nach rund sieben Tagen; serverseitig auf einer echten First-Party-Domain gesetzte halten deutlich länger (bis zu rund 400 Tage), solange die Domain nicht als Tracker eingestuft wird —, und du hast einen kontrollierten Datenfluss statt eines Wildwuchses an Browser-Skripten. Pflicht ist sGTM nicht, aber es ist die robusteste Basis für alles oben.

Und der Datenschutz? Consent Mode und Einwilligung

Klar und wichtig: Server-Side ist kein Weg um die Einwilligung herum. Es verlagert nur, wo Daten verarbeitet werden — die Einwilligungspflicht bleibt. Im EWR brauchst du weiterhin eine gültige Einwilligung, bevor du zu Werbezwecken misst.

Google Consent Mode v2 ist dafür seit März 2024 für EWR-Werbetreibende mit Google-Diensten Pflicht. Er überträgt vier Signale — ad_storage, analytics_storage, ad_user_data, ad_personalization — und steuert, was vor und nach der Einwilligung passiert. „Basic" blockiert die Tags bis zur Zustimmung; „Advanced" lädt sie mit auf „denied" gesetzten Defaults und sendet vorher nur anonyme, cookielose Pings.

Seit dem 15. Juni 2026 hängt außerdem die Weitergabe von Analytics-Daten an Google Ads allein am Consent-Signal: ad_storage entscheidet, ob Google Ads überhaupt Cookies und IDs erfassen darf, ad_user_data, ob gehashte First-Party-Daten (etwa für Enhanced Conversions) übergeben werden dürfen. Das frühere Sicherheitsnetz über „Google Signals" fällt damit weg — sauberes Consent-Signaling ist jetzt noch wichtiger.

Auch dein Server-Container muss den Consent-Status respektieren. Kurz: Sauber messen heißt auch rechtssicher messen. (Das ist keine Rechtsberatung — die konkrete Umsetzung gehört mit deinem Datenschutzbeauftragten abgestimmt.)

Womit fange ich an?

Realistische Reihenfolge, nicht alles auf einmal:

• 1. Pixel + CAPI parallel mit sauberer event_id-Deduplizierung.
• 2. Event Match Quality hochziehen — gehashte E-Mail und Telefonnummer mitsenden, fbp/fbc zuverlässig erfassen. Der schnellste Gewinn.
• 3. Consent Mode v2 + CMP sauber aufsetzen, serverseitig respektieren.
• 4. Server-Side (sGTM) als Fundament, wenn Volumen und Anspruch es rechtfertigen.

Und dann der eigentliche Zweck: Wenn die Messung steht, kannst du den Zahlen wieder trauen — und auf das steuern, was zählt. Dazu passt Deckungsbeitrag statt ROAS und warum ich mir mein Reporting selbst gebaut habe.