Browser- und Server-Events, Deduplizierung über event_id und der Umgang mit Einwilligungen
Wer Werbung bei Meta oder TikTok schaltet, braucht verlässliche Conversion-Daten, denn die Plattformen steuern ihre Auslieferung darüber. Ein Pixel im Browser allein liefert diese Daten immer häufiger unvollständig, etwa weil Einwilligungen fehlen, Browser Skripte blockieren oder Kunden den Kauf auf einem anderen Gerät abschließen. Die Antwort ist eine Kombination aus Browser-Events und Server-Events, die sauber dedupliziert werden. Dieser Artikel zeigt, wie das in einem Magento-2-Shop aufgebaut wird, wie die Einwilligung dazu passt und woran Sie Fehler erkennen.
Inhaltsverzeichnis
- 1. Browser-Events und Server-Events im Vergleich
- 2. Deduplizierung über event_id
- 3. Einwilligung und Rechtsrahmen: DSGVO, TDDDG und Praxis
- 4. Aufbau in Magento 2: Meta Pixel plus Conversions API
- 5. TikTok Pixel und Events API
- 6. Hashing von Kundendaten für bessere Zuordnung
- 7. Event-Match-Qualität und Testwerkzeuge der Plattformen
- 8. Typische Fehlerbilder und ihre Ursachen
- 9. Attribution grob eingeordnet: Warum die Zahlen nie identisch sind
- 10. Zusammenfassung
- 11. FAQ
1. Browser-Events und Server-Events im Vergleich
Ein Pixel läuft im Browser des Besuchers und meldet Ereignisse wie Seitenaufruf, Warenkorb oder Kauf direkt an die Plattform. Es ist schnell eingerichtet und liefert viel Kontext, hängt aber von Browser, Einwilligung und Netzwerk ab. Die Conversions API von Meta und die Events API von TikTok funktionieren dagegen serverseitig: Ihr Shop sendet das Ereignis selbst an die Plattform, unabhängig vom Browser des Kunden.
Keiner der beiden Wege ersetzt den anderen sinnvoll. Der Browser liefert Informationen wie Klick-Kennungen und Seitenkontext, der Server liefert Zuverlässigkeit bei bestätigten Bestellungen. Empfohlen wird deshalb meist eine Kombination, bei der dasselbe Ereignis über beide Wege kommt und die Plattform es anhand einer gemeinsamen Kennung als ein einziges erkennt.
2. Deduplizierung über event_id
Wenn derselbe Kauf einmal vom Pixel und einmal vom Server gemeldet wird, würde er ohne Gegenmaßnahme doppelt zählen. Die Plattformen lösen das über eine event_id: Beide Meldungen tragen denselben Ereignisnamen und dieselbe event_id, und die Plattform behält nur eine davon. Entscheidend ist, dass die Kennung im Shop erzeugt und an beide Wege weitergegeben wird.
Für einen Kauf eignet sich eine stabile Kennung, die aus der Bestellung abgeleitet wird, etwa die Bestellnummer mit Präfix. Bei Ereignissen ohne Bestellbezug wie dem Aufruf einer Produktseite erzeugen Sie eine zufällige Kennung pro Ereignis und reichen sie von der Seite zum Server weiter. Prüfen Sie in den Testwerkzeugen, ob die Plattform die beiden Meldungen tatsächlich zusammenführt.
Nach der Einrichtung lohnt ein Blick auf einen Zeitraum von einigen Tagen: Liegt die Zahl der als dedupliziert gekennzeichneten Ereignisse nahe an der Zahl der Käufe, funktioniert die Zusammenführung. Bleibt sie auffällig niedrig, stimmt vermutlich die Kennung auf einem der beiden Wege nicht.
// Browser-Seite: Pixel-Event mit gemeinsamer Kennung (Beispielwerte)
fbq('track', 'Purchase',
{ value: 100.00, currency: 'EUR' },
{ eventID: 'order-100000123' }
);
// Die Conversions API erhält serverseitig dasselbe Ereignis mit
// event_name "Purchase" und event_id "order-100000123".
3. Einwilligung und Rechtsrahmen: DSGVO, TDDDG und Praxis
Für Werbe-Pixel ist in der Regel eine Einwilligung des Besuchers nötig, und zwar bevor das Skript geladen wird. Das ergibt sich im Kern aus der DSGVO und aus den Regeln zum Zugriff auf Endgeräte, die in Deutschland früher im TTDSG und heute im TDDDG stehen. Wie Sie Ihren Shop konkret bewerten, hängt vom Einzelfall ab. Dieser Text ist keine Rechtsberatung, ziehen Sie dafür Ihre Datenschutzberatung hinzu. Technische Bausteine finden Sie bei unseren Tracking-Extensions.
Wichtig für die Praxis: Die serverseitige Übertragung ist kein Freibrief. Auch wenn der Browser nichts lädt, werden personenbezogene Daten an eine Plattform gesendet, wofür eine Rechtsgrundlage und eine Einwilligung vorliegen müssen. Senden Sie Server-Events daher nur für Besucher, die zugestimmt haben, und geben Sie den Zustimmungsstatus bereits beim Bestellvorgang an den Server weiter.
4. Aufbau in Magento 2: Meta Pixel plus Conversions API
Der Aufbau folgt einem klaren Ablauf. Das Pixel wird nach der Einwilligung geladen und sendet PageView, ViewContent, AddToCart, InitiateCheckout und Purchase. Parallel löst der Shop für wichtige Ereignisse einen serverseitigen Aufruf aus, etwa beim Abschluss der Bestellung nach einem Magento-Event, und übergibt dabei dieselbe event_id. Der Zugriffstoken für die API gehört in die Konfiguration, nicht in den Quellcode.
Behandeln Sie den Server-Aufruf wie jede Schnittstelle: mit Zeitlimit, Fehlerprotokoll und Wiederholung bei vorübergehenden Fehlern, damit ein Ausfall der Plattform den Checkout nicht verlangsamt. Am besten läuft er asynchron, zum Beispiel über eine Warteschlange. So bleibt die Bestellabwicklung unabhängig, was auch aus Sicht von Performance-Optimierung und Stabilität sinnvoll ist.
5. TikTok Pixel und Events API
TikTok folgt einem ähnlichen Muster: Ein Pixel im Browser sendet Ereignisse wie ViewContent, AddToCart oder CompletePayment, und die Events API ergänzt sie serverseitig. Auch dort dient eine event_id dazu, doppelte Meldungen zusammenzuführen. Die Ereignisnamen unterscheiden sich von denen bei Meta, daher lohnt eine Zuordnungstabelle im Messkonzept, damit niemand Namen verwechselt.
Gehen Sie bei TikTok nach denselben Regeln vor wie bei Meta: Skript erst nach Einwilligung, Server-Events nur für zugestimmte Besucher, Zugangsdaten in der Konfiguration. Prüfen Sie die Dokumentation der Plattform auf aktuelle Parameter, da sich Details ändern können. Wenn Sie beide Plattformen betreiben, empfiehlt es sich, die Ereignis-Erzeugung im Shop einmal zu bauen und pro Plattform nur die Übersetzung zu pflegen.
6. Hashing von Kundendaten für bessere Zuordnung
Damit die Plattform ein Ereignis einem Nutzer zuordnen kann, erwarten die APIs optionale Kundendaten wie E-Mail-Adresse, Telefonnummer oder Name. Diese Werte werden nicht im Klartext gesendet, sondern vorher normalisiert, also kleingeschrieben und von Leerzeichen befreit, und dann mit SHA-256 gehasht. Der Hash ist eine Schutzmaßnahme, ändert aber nichts daran, dass es sich weiterhin um personenbezogene Daten handelt.
Verarbeiten Sie diese Daten deshalb nur, wenn eine Einwilligung vorliegt, und übertragen Sie nur Felder, die Sie wirklich brauchen. Eine saubere Normalisierung ist entscheidend, denn schon ein Leerzeichen am Ende erzeugt einen anderen Hash, der sich keinem Nutzer zuordnen lässt. Das folgende Beispiel zeigt die Normalisierung und den Hash einer E-Mail-Adresse in PHP.
<?php
declare(strict_types=1);
/**
* Normalizes and hashes an email address for use as hashed user data.
*
* @param string $email Raw customer email address
* @return string SHA-256 hash of the trimmed, lowercased address
*/
function hashEmail(string $email): string
{
return hash('sha256', mb_strtolower(trim($email)));
}
7. Event-Match-Qualität und Testwerkzeuge der Plattformen
Meta zeigt im Events Manager eine Einschätzung, wie gut sich Ereignisse Nutzern zuordnen lassen, die sogenannte Event-Match-Qualität. Je mehr passende, korrekt gehashte Kundenparameter ein Ereignis enthält, desto besser fällt sie in der Regel aus. Betrachten Sie sie als Hinweis zur Verbesserung, nicht als Selbstzweck, und senden Sie nie mehr Daten, als Ihre Einwilligung abdeckt.
Beide Plattformen bieten Testwerkzeuge, mit denen Sie Browser- und Server-Ereignisse live ansehen können, bevor Kampagnen darauf aufbauen. Nutzen Sie sie für eine vollständige Testbestellung und prüfen Sie, ob Ereignisname, Wert, Währung und event_id auf beiden Wegen übereinstimmen und die Plattform sie als dedupliziert ausweist. Dokumentieren Sie das Ergebnis, damit spätere Änderungen verglichen werden können.
8. Typische Fehlerbilder und ihre Ursachen
Das häufigste Fehlerbild sind doppelte Conversions, weil die event_id fehlt oder auf beiden Wegen unterschiedlich ist. Ebenso verbreitet sind Ereignisse ohne Währung oder mit Wert null, wodurch Optimierungen ins Leere laufen. Auch ein Pixel, das vor der Einwilligung feuert, ist ein Fehler, den Sie im Netzwerkprotokoll erkennen. Zugangsdaten im Quellcode oder in öffentlich erreichbaren Dateien betreffen die Sicherheit Ihres Shops.
Ein weiteres Muster sind Server-Events, die ohne Zustimmung gesendet werden, weil der Status nicht bis in den Hintergrundprozess gelangt. Prüfen Sie auch zeitliche Abweichungen: Wird ein Ereignis mit stark verspäteter Zeit gesendet, kann die Plattform es ablehnen oder falsch zuordnen. Ein Monitoring auf Fehlerantworten der Schnittstellen zeigt solche Probleme früh, bevor sie in den Kampagnenzahlen sichtbar werden.
Bei Mehrsprachigkeit und mehreren Store-Views kommt hinzu, dass jede Ansicht dasselbe Pixel mit derselben Kennung nutzen oder bewusst getrennte Konten verwenden kann. Legen Sie das früh fest, sonst landen Käufe verschiedener Märkte in einem Datensatz, den später niemand mehr sauber trennen kann.
9. Attribution grob eingeordnet: Warum die Zahlen nie identisch sind
Die Plattformen rechnen Käufe nach eigenen Attributionsregeln zu und zählen oft auch Abschlüsse nach einem Anzeigenkontakt ohne Klick. GA4 bewertet anders, und der Shop kennt nur die tatsächlichen Bestellungen. Vergleichen Sie daher Trends statt Einzelzahlen und legen Sie fest, welche Quelle für welche Entscheidung maßgeblich ist, etwa der Shop für den Umsatz und die Plattform für die Kampagnensteuerung.
Server-Events verbessern die Datengrundlage, beheben aber keine Messlücke vollständig. Planen Sie Aufwand und Nutzen realistisch und holen Sie sich bei größeren Vorhaben ein Angebot ein, zum Beispiel über unsere Preise. Starten Sie mit dem Kauf-Ereignis, prüfen Sie es gründlich und erweitern Sie dann schrittweise auf Warenkorb und Produktansicht.
| Aspekt | Browser-Pixel | Server-Events (API) | Hinweis |
|---|---|---|---|
| Ausführung | Im Browser des Besuchers | Auf dem Server des Shops | Beide Wege kombinieren und deduplizieren |
| Abhängigkeit | Einwilligung, Browser, Blocker | Server-Anbindung, Zustimmungsstatus | Server-Events nur mit Zustimmung senden |
| Kennung | eventID im Pixel-Aufruf | event_id im API-Aufruf | Auf beiden Wegen identisch erzeugen |
| Kundendaten | Teils automatisch aus dem Browser | Normalisiert und mit SHA-256 gehasht | Nur Felder senden, die Sie wirklich brauchen |
Mironsoft
Magento-Entwicklung, Modul-Beratung und Systemarchitektur
Magento-Projekt, das eine zweite Meinung oder erfahrene Umsetzung braucht?
Wir entwickeln individuelle Magento-Module, beraten bei Architekturentscheidungen und übernehmen komplexe Umsetzungen, von der Service-Contract-Planung bis zum produktionsreifen Deployment.
Architektur-Beratung
Modul- und Systemarchitektur vor der Umsetzung fundiert durchdenken lassen.
Custom-Modul-Entwicklung
Individuelle Magento-Module nach Best Practices sauber umsetzen.
Code-Review & Audit
Bestehende Module auf Performance, Sicherheit und Wartbarkeit prüfen lassen.
10. Zusammenfassung
Facebook Pixel, Conversions API und TikTok: Das Wichtigste auf einen Blick
Kernidee
Browser-Pixel und Server-Events ergänzen sich und werden über eine gemeinsame event_id zu einem einzigen Ereignis zusammengeführt.
Wichtigster Schutz
Skripte laden und Server-Events senden nur, wenn eine Einwilligung vorliegt und der Status bis zum Server gelangt.
Größtes Risiko
Fehlende oder unterschiedliche event_id, ungeprüfte Daten und Pixel vor der Zustimmung verfälschen Zahlen und gefährden die Rechtskonformität.
Erfolgskriterium
Die Testwerkzeuge beider Plattformen zeigen jedes Kauf-Ereignis genau einmal, mit korrektem Wert, Währung und Zuordnung.