Kurzfassung: Eine aktive CAPI-Verbindung beweist noch keine korrekte Kaufmessung. Prüfen Sie doppelte Browser-/Server-Ereignisse, Einwilligung, Datenfelder, Infrastruktur, Plugin-Logik, Monitoring und den vollständigen Kaufweg. Gleichen Sie bestätigte Bestellungen ab, bevor Sie Budgets ändern.
Server-side Tracking verlagert einen Teil der Ereignisverarbeitung in eine Serverumgebung. Das kann die Übertragung besser kontrollierbar machen, schafft aber keine Rechtsgrundlage für zusätzliche Datenerhebung. Maßgeblich sind Geschäft, Kunden und Datenflüsse, nicht die Sprache des Teams.
1. Derselbe Kauf kommt zweimal an
Pixel und Conversions API können zwei Kopien eines Kaufs übertragen. Das offizielle Meta SDK verbindet identische Ereignisse anhand von event_name und event_id.
Erzeugen Sie die ID einmal für das Geschäftseignis und verwenden Sie sie im Browser, auf dem Server und bei Übertragungswiederholungen weiter. Ein von jedem Sender neu erzeugter Zeitstempel verhindert diese Zuordnung. Unterschiedliche Ereignisse brauchen unterschiedliche IDs; personenbezogene Informationen gehören nicht in die Kennung. Das Neuladen der Bestätigungsseite darf keinen neuen Kauf erzeugen.
Rechenbeispiel: €4.000 Ausgaben bei 100 tatsächlichen Käufen ergeben €40 pro Kauf. Würde ein Bericht fälschlich 200 zählen, zeigte er €20. Das Beispiel setzt eine Doppelzählung im betreffenden Bericht voraus; empfangene Ereignisse sind nicht automatisch zugerechnete Werbekonversionen. Prüfen Sie auch Betrag, Währung und Zahlungsstatus. Deduplication allein bestätigt diese Angaben nicht.
2. Hosting wird ohne Datenflusskarte gewählt
Ein EU-Server ist eine Infrastrukturentscheidung, kein Nachweis für die Zulässigkeit aller Empfänger, Protokolle und Übermittlungen. Ebenso ist Hosting außerhalb der EU nicht grundsätzlich verboten. Erfassen Sie Quellen, Empfänger, Rollen, Zugriffe, Aufbewahrung und Löschung. Internationale Übermittlungen benötigen eine gesonderte rechtliche Bewertung. Die Hinweise der EU-Kommission erläutern Schutzinstrumente, zertifizieren aber keine konkrete Installation.
Bei Google Cloud Run liegt europe-west1 in Belgien, europe-west3 in Frankfurt; auch Stape bietet EU-Hosting. Vergleichen Sie die tatsächliche Verarbeitungskette, Betriebskosten und gemessene Latenz. Prüfen Sie bei einem Umzug Domain, Requests, Container-Konfiguration und Rückfallmöglichkeit. Eine universelle Umzugsdauer oder feste transatlantische Verzögerung gibt es nicht. Nutzen Sie Googles Cloud-Run-Anleitung.
3. Die Einwilligung endet im Browser
Ein Banner kann Marketing-Tags im Browser sperren, während das Backend dieselben Kundendaten sendet. Prüfen Sie Ablehnung, Zustimmung, Teilentscheidungen, Widerruf und Neuladen entlang der ganzen Kette, einschließlich gespeicherter Einstellungen und ausgehender Server-Requests.
Googles serverseitige Consent-Anleitung betrifft Google-Signale und dafür ausgelegte Google-Tags. Eigene Meta- oder TikTok-Integrationen benötigen passende Weiterleitungsregeln. Ein Feld namens consent_state löst das nicht allgemein. Auch cookieless bedeutet nicht automatisch anonym oder zulässig. Unterscheiden Sie notwendige Verarbeitung und optionale Werbung nach den anwendbaren Regeln, etwa den Cookie-Hinweisen der österreichischen DSB.
4. Matching-Felder werden ohne Zweck gesammelt
Dokumentieren Sie Quelle, Zweck und Verarbeitungsgrundlage jedes Feldes. Prüfen Sie Platzhalter, Telefon-/Länderformate sowie irrelevante oder sensible Angaben, bevor Sie weitere Identifikatoren für Event Match Quality hinzufügen.
Das Meta SDK behandelt normalisierte und gehashte Felder wie E-Mail und Telefon anders als IP-Adresse, User Agent, fbc und fbp. Letztere werden nicht auf dieselbe Weise gehasht. Folgen Sie der jeweiligen Spezifikation; alles kleinschreiben und hashen ist keine korrekte Regel. Hashing macht personenbezogene Daten nicht anonym. EMQ ist ein Diagnosewert, keine allgemeine Bestehensgrenze und kein versprochener CPM-Rabatt.
5. Ein Plugin gilt als fertiges System
Eine Standardintegration kann zu einem Standardshop passen. Shopifys Einstellungen Enhanced und Maximum verwenden bereits CAPI zusammen mit Pixel. Eigene Entwicklung sollte eine festgestellte Lücke schließen, statt ein funktionierendes Plugin grundsätzlich zu ersetzen.
Prüfen Sie bezahlte und unbezahlte Bestellungen, Stornierungen, Erstattungen, Währung, Consent und wiederholte Seitenaufrufe. Entfernen Sie veraltete doppelte Pixel-Installationen kontrolliert. Nach CMS-, Checkout-, CMP- oder Plugin-Updates wiederholen Sie die Szenarien und halten Version, Verantwortlichen und Rollback fest. Das Integrationssymbol bestätigt keine Geschäftslogik.
6. Nach dem Start fehlt das Monitoring
Lehrszenario: Ein Theme-Update verändert die Bestätigungsseite, danach fehlen Kaufereignisse. Eine frühere erfolgreiche Startprüfung erkennt diesen späteren Fehler nicht. Überwachen Sie Übertragungsfehler, Verzögerungen, fehlende IDs, Währung/Betrag und Abweichungen von bestätigten Shop- oder CRM-Bestellungen. Berücksichtigen Sie Saison und unterschiedliche Attributionsfenster.
Definieren Sie Warnungen anhand Ihrer eigenen stabilen Historie. Ein wöchentlicher Abgleich ist eine sinnvolle Arbeitsroutine, ergänzt durch Prüfungen nach Änderungen. EMQ kann zusätzliche Hinweise geben, soweit verfügbar. Prüfen Sie API-Felder und Berechtigungen, bevor Sie einen automatischen EMQ-Export versprechen. Weder ein Score von sieben noch 20% weniger Ereignisse sind universelle Alarmgrenzen.
7. Geprüft wird nur der Endpoint
Ein angenommener API-Request beweist weniger als ein vollständiger Kaufweg. Beginnen Sie lokal oder in einer Testumgebung; Plattform-Testereignisse oder produktive Bestellungen brauchen die entsprechende Freigabe. Server-Container Preview, Meta Test Events und GA4 DebugView/Realtime beantworten unterschiedliche Diagnosefragen.
Prüfen Sie auf Desktop und Mobilgerät alle sieben Wege:
- Ein neuer Besucher lehnt optionale Cookies ab.
- Er stimmt ihnen zu.
- Er ändert seine Entscheidung.
- Eine Bestellung wird bezahlt.
- Die Zahlung scheitert oder die Bestellung wird storniert/erstattet.
- Die Bestätigungsseite wird neu geladen.
- Derselbe Besucher kehrt über einen anderen Kanal zurück.
Vergleichen Sie Oberfläche, Requests, Serverprotokolle, Plattformempfang und bestätigte Verkäufe. Ein grünes Testereignis ist weder rechtliche Freigabe noch Attributionsnachweis.
Sieben Fehler im Überblick
| Fehler | Folge und erste Prüfung |
|---|---|
| Unterschiedliche Ereignisnamen/IDs | Überhöhte Zählung; einen Kauf bei beiden Sendern verfolgen |
| Keine Datenflusskarte | Unklare Empfänger/Fristen; alle Ziele erfassen |
| Consent nur im Browser | Entscheidung nicht umgesetzt; alle Zustände bis zum Server testen |
| Unnötige Matching-Felder | Übermäßige Erhebung/falsche Formate; jedes Feld prüfen |
| Ungeprüfte Plugin-Logik | Falscher Kaufstatus; Zahlung, Erstattung und Neuladen testen |
| Kein Monitoring | Unbemerkte Änderungen; Umfang, Werte, IDs und Verzögerung abgleichen |
| Nur Endpoint geprüft | Unvollständiger Kaufweg; sieben Szenarien auf beiden Geräten durchgehen |
In welcher Reihenfolge korrigieren?
Beheben Sie zuerst doppelte und falsche Käufe. Prüfen Sie anschließend Einwilligung und zulässige Datenflüsse, dann Matching-Felder, Monitoring und Berichte. Mehr Kontext bieten der Server-side-Tracking-Leitfaden und die CPA-Analyse.
Häufig gestellte Fragen
Welchen Fehler sollten wir zuerst untersuchen?
Beginnen Sie mit Abweichungen bei bestätigten Käufen: Dubletten, falscher Zahlungsstatus, Betrag oder Währung. Eine belastbare allgemeine Häufigkeitsrangfolge liegt hier nicht vor.
Wie finden wir Fehler in einer bestehenden Integration?
Verfolgen Sie eine freigegebene Testbestellung durch Browser, Server, Plattform und Shop. Wiederholen Sie Consent- und Fehlerszenarien, dann vergleichen Sie größere Summen mit gleichen Zeiträumen und Definitionen.
Kann Server-side Tracking eine Ablehnung umgehen?
Nein. Ein anderer technischer Weg schafft keine Verarbeitungsgrundlage. Die anwendbare Einwilligung oder andere zulässige Grundlage muss entlang der gesamten Kette gelten.
Welcher Event-Match-Quality-Wert ist gut?
Kein universeller Wert beweist Erfolg. Korrekte Ereignisse, zulässige Felder und der Abgleich mit bestätigten Ergebnissen sind wichtiger als ein durch unnötige Erhebung erhöhter Diagnosewert.
Reichen Ereignisse im Events Manager aus?
Nein. Gleichen Sie Deduplication, Consent, Zahlungsstatus, Betrag und Währung mit bestätigten Shop- oder CRM-Daten ab, auch nach Updates.
Reicht ein Shopify- oder WooCommerce-Plugin?
Manchmal. Prüfen Sie Zahlung, Erstattungen, Consent, Währung und Dubletten. Eine Standardintegration kann geeignet sein; eigene Entwicklung braucht einen konkreten Anlass.
Wie oft sollten wir CAPI nach dem Start prüfen?
Nach Änderungen an Checkout, CMP, GTM, Domain oder Plugin sowie durch regelmäßigen Abgleich. Wöchentlich ist eine praktische Routine; Warnschwellen folgen Ihrer eigenen Historie.
Wie lange dauern die Korrekturen?
Ein einzelner Konfigurationsfehler kann schnell behoben sein. Fehlende Geschäftslogik, Infrastrukturwechsel und Consent-Integration benötigen Analyse und erneute Prüfung. Grenzen Sie den Auftrag ein, bevor Sie Dauer oder finanziellen Nutzen schätzen.
Wenn Shop, CRM und Werbeberichte unterschiedliche Verkäufe zeigen, beschreiben Sie die Systeme und Ihre Definition eines bestätigten Verkaufs. Wir bestimmen die benötigten Ereignisse und Zugriffe für eine abgegrenzte Prüfung. Abweichung beschreiben.
