Einrichten des serverseitigen Trackings von Facebook mit der Facebook Conversions API

Das Hauptmerkmal des Conversions API Gateway ist seine Umgebung. Jede Instanz des Conversions API Gateway benötigt einen Cloud-Server, um alle Kommunikationsprozesse zwischen dem Meta Pixel und der Conversions API zu verwalten. Weitere Informationen finden Sie in der Meta-Dokumentation zur Funktionsweise des Conversions API Gateway.

Sobald das Meta Pixel mit der Conversions API Gateway-Umgebung verbunden ist, verwendet es Webereignisse, um Daten vom Server zu verfolgen. Daher ist es vor der Implementierung des Conversions API Gateway unerlässlich, sicherzustellen, dass die Webereignisse zu 100 % korrekt sind und alle erforderlichen Benutzer- und Produktinformationen enthalten.

Mit Stape ist die Einrichtung und das Hosting des Conversions API Gateway einfacher denn je. Erstellen Sie einfach ein Stape-Konto und richten Sie das Conversions API Gateway innerhalb von Stape ein. Verbinden Sie dann die erforderlichen Meta-Pixel mit der Conversions API Gateway-Umgebung.

Vorteile:

1. Niedriger Preis. Das Hosting von Conversions API Gateway durch Stape kostet 10 $/Monat pro Pixel oder 100 $/Monat für 100 Pixel. Wir bieten auch eine kostenlose 7-Tage-Testversion an.

Darüber hinaus ist das Conversions API Gateway die einfachste Möglichkeit, die Conversions API zu implementieren, wodurch Sie im Vergleich zu einer manuellen Implementierung Hunderte oder sogar Tausende von Dollar sparen können.

2. Einfache Einrichtung. Sie müssen keine Entwickler oder Tracking-Spezialisten beauftragen, um das Conversions API Gateway einzurichten. Der Einrichtungsprozess ist unkompliziert und dauert selbst für Personen ohne technische Kenntnisse weniger als eine Minute.

3. Keine Wartung. Updates für das Conversions API Gateway werden automatisch installiert. Sie müssen keine Zeit für die manuelle Aktualisierung von Einstellungen oder Servern aufwenden. Selbst wenn Sie ein neues Ereignis hinzufügen, müssen Sie nur das richtige Web-Tracking einrichten, und das Conversions API Gateway beginnt automatisch mit der Verfolgung von Ereignissen vom Server aus.

Nachteile:

1. Neu. Das Conversions API Gateway ist neu, und Meta wird wahrscheinlich neue Funktionen und Updates für die bestehenden Funktionen einführen. Daher ist es sinnvoll, sich auf Änderungen an den Funktionen vorzubereiten.

2. Keine Unterstützung für andere Plattformen. Wenn Sie die Vorteile des serverseitigen Trackings voll ausschöpfen möchten, ist der Server Google Tag Manager (sGTM) möglicherweise die bessere Lösung. Sie benötigen weiterhin eine Instanz von Google Tag Manager, um Server Google Analytics (GA), Google Ads usw. zu verwalten. 

Stape bietet Hosting für das Conversions API Gateway zu einem Preis von 10 US-Dollar pro Pixel pro Monat oder 100 US-Dollar für 100 Pixel pro Monat an. Darüber hinaus erhalten alle Nutzer eine kostenlose 7-Tage-Testversion.

Um das Conversions API Gateway mit Stape einzurichten, müssen Sie lediglich Folgendes tun:

Sobald Sie den Conversions API Gateway-Container auf Stape erstellt haben, richten wir einen Amazon Web Services Cloud Formation Stack basierend auf den Meta-Anforderungen ein und verwalten alle Updates.

Eine Schritt-für-Schritt-Anleitung finden Sie in unserem Beitrag zum Einrichten des Meta Conversions API Gateway.

Der erste Schritt beim Testen des serverseitigen Trackings von Facebook ist derselbe wie bei Google Analytics. Sie müssen sicherstellen, dass Ereignisse bei den richtigen Triggern ausgelöst werden. Öffnen Sie das GTM-Debugging-Tool, navigieren Sie durch die Seiten Ihrer Website und führen Sie die Ereignisse aus, die Sie testen möchten. Wenn Sie dies getan haben, gehen Sie zur Registerkarte „Tag Manager Debugger“ und überprüfen Sie die Ergebnisse.

Stellen Sie zunächst sicher, dass das FB-Basis-Pixel bei einer Seitenaufruf ausgelöst wird. Wenn der Tag-Status „Fail“ lautet, überprüfen Sie die ausgehenden Anfragen, die den Grund für das Scheitern des Tags angeben sollten.

Wenn Sie unser serverseitiges FB-Tracking-Tag verwenden, haben Sie zwei Möglichkeiten, FB-Ereignisse zu senden: 

Öffnen Sie den Events Manager in Ihrem Facebook Business Manager und klicken Sie auf „Events testen”. Sie sehen einen Test-Event-Code, den Sie zu Ihrem Facebook-Tag in Google Tag Manager hinzufügen sollten. Mit diesem Code können Sie Facebook-Server-Events in Echtzeit testen.

Nachdem Sie die Test-ID hinzugefügt haben, öffnen Sie Ihre Website und führen Sie Aktionen aus, die Ihre FB-Ereignisse auslösen. Kehren Sie dann zum Facebook-Testtool zurück und überprüfen Sie die angezeigten Ereignisse. In der Spalte „Received From“ sollte „Server“ angezeigt werden. Sie können auf das Ereignis klicken, um die aufgezeichneten Parameter anzuzeigen. 

Beachten Sie, dass das Chrome-Plugin „Facebook Pixel Helper“, mit dem Sie Facebook-Browser-Ereignisse überprüft haben, für die Conversions-API nicht funktioniert. Deshalb müssen Sie alles im Testtool überprüfen.

Der dritte Schritt ähnelt dem zuvor beschriebenen, weist jedoch einige Unterschiede auf. Um das Ablaufdatum der Facebook-Cookies zu überprüfen, müssen Sie diese zunächst generieren. Öffnen Sie dazu Ihre Website und fügen Sie fbclid hinzu.

Öffnen Sie anschließend die Entwicklertools, gehen Sie zu „Storage“ und klicken Sie auf „Cookies“. Überprüfen Sie, ob _fbc und _fbp verlängert wurden.

Das Events Testing Tool von Facebook ist eine leistungsstarke Ressource, mit der Sie Probleme mit Ihren Facebook-Pixeln oder Server-Events debuggen und beheben können. Wenn Fehler vorliegen, werden diese zur genaueren Überprüfung auf der Registerkarte „Diagnostics“ in der Symbolleiste angezeigt.

Rot markierte Fehler erfordern in der Regel sofortige Aufmerksamkeit und sollten umgehend behoben werden. Gelbe Fehler sind nicht kritische Warnungen, die Sie überwachen und irgendwann beheben sollten.

Facebook ermöglicht es Ihnen, Probleme als behoben zu markieren oder zu ignorieren. Wenn Sie einen Fehler als behoben markieren und er erneut auftritt, zeigt Facebook ihn nach drei Tagen erneut an. Ignorierte Probleme hingegen werden in den Bereich „Ignoriert“ verschoben und bleiben dort.

Wenn Sie Probleme mit Ihrem Facebook-Tracking beheben, empfehlen wir Ihnen, diese als gelöst zu markieren. Auf diese Weise teilen Sie Facebook mit, dass die Probleme behoben wurden, und die Plattform benachrichtigt Sie, wenn diese Probleme erneut auftreten.

Sie können alle Domains sehen, die Daten an Ihr Facebook-Pixel senden. Wenn Facebook Traffic von einer neuen Subdomain oder Domain erkennt, erhalten Sie eine Warnung. Mit dieser Funktion können Sie Domains auf die Whitelist oder Blacklist setzen, um Traffic von Ihren Testseiten oder technischen URLs zu blockieren.

Höchstwahrscheinlich werden Sie auch Datenverkehr von gtm-msr.appspot.com sehen. Dies kann passieren, wenn Sie einen Debugging-/Publish-Container ausführen oder wenn Benutzer Ihre Website mit deaktiviertem JavaScript besuchen (einige Bots).

Um Domänen-Zulassungs- oder Sperrlisten zu erstellen, öffnen Sie das Ereignis-Tool im Business Manager → klicken Sie auf „Einstellungen“ → scrollen Sie nach unten zu „Traffic-Berechtigungen“.

Dies ist nach unserer Erfahrung der zweithäufigste Facebook-CAPI-Fehler. Dieser Fehler weist darauf hin, dass Sie einige Deduplizierungsschlüssel für Ihre Serverereignisse nicht senden. Facebook verwendet folgende Deduplizierungsschlüssel: Ereignisname, Ereignis-ID, _fbp und externe ID.

Unserer Erfahrung nach wird dieser Fehler in 80 % der Fälle durch fehlende Ereignis-ID-Parameter verursacht. Überprüfen Sie, ob Sie eine Ereignis-ID sowohl für das Facebook-Pixel als auch für die Facebook-Conversions-API senden. Diese Ereignis-ID sollte für Browser- und Serverereignisse identisch sein, damit Facebook denselben Ereignisnamen und dieselbe Ereignis-ID für die Deduplizierung erkennen kann.

Senden Sie beispielsweise für PageView-Ereignisse die gleiche Ereignis-ID und den gleichen Ereignisnamen sowohl vom Facebook-Pixel als auch von der Facebook-CAPI.

Um die Ereignis-ID zu testen, öffnen Sie das Facebook-Ereignistesttool. Wenn alles korrekt ist, sollte Ihre Ausgabe ähnlich wie im folgenden Screenshot aussehen. So zeigt Facebook die aufgezeichneten PageView-Ereignisse sowohl vom Browser als auch vom Server an, die dieselbe Ereignis-ID hatten, was darauf hinweist, dass Browser-Ereignisse verarbeitet und Server-Ereignisse dedupliziert wurden.

Es kann jedoch vorkommen, dass Browser- und Serverereignisse zufällig ausgelöst werden. Überprüfen Sie in diesem Fall die Facebook-Ereignis-ID; diese sind wahrscheinlich nicht identisch. Sie können unsere benutzerdefinierte Variable für den Web-Container verwenden, um die Facebook-Ereignis-ID zu konfigurieren. Weitere Informationen zur Deduplizierung von Facebook-Ereignissen finden Sie im obigen Abschnitt.

Manchmal kann dieser Fehler auftreten, wenn Sie die Facebook-Test-ID nicht entfernt und die Facebook-CAPI-Tags in der Produktionsumgebung veröffentlicht haben. Wir empfehlen, die Test-ID als Lookup-Tabellenvariable einzurichten, die nur funktioniert, wenn der Debug-Modus aktiviert ist, um dieses Problem zu beheben.

Hier weist Facebook Sie darauf hin, dass die vom Server gesendeten Werte nicht eindeutig sind oder falsch formatiert sind. Möglicherweise senden Sie beispielsweise eine Benutzer-IP, die sowohl Symbole als auch Zahlen enthält, oder Sie haben die falsche Variable ausgewählt, z. B. die Telefonnummer im E-Mail-Feld.

Um das Problem zu identifizieren, öffnen Sie den Vorschaumodus des Google Tag Manager-Servers und des Web-Containers (wenn Sie GTM zum Einrichten der Facebook Conversions API verwendet haben). Sie sollten sehen, welche Benutzerparameter an Facebook gesendet wurden und ob sie korrekt formatiert waren. Testen Sie das Ereignis, klicken Sie im Debug-Modus auf das Tag und überprüfen Sie die Werte.

Dieser Fehler kann auch darauf hinweisen, dass Sie vergessen haben, einen Parameter einzufügen, oder dass dieser falsch formatiert ist.

Beispielsweise gab es einen Kunden, der das Land und die Stadt des Benutzers anhand seiner IP-Adresse senden wollte. Facebook erwartete jedoch die tatsächlichen Adressdaten des Benutzers, die auf der Website eingegeben wurden, und nicht die automatisch aus der IP extrahierten Daten. Diese Konfiguration führte zu einem Fehler wegen ungültiger Schlüsselparameter.

Dieser Fehler bezieht sich in der Regel auf Browser-Ereignisse und weist darauf hin, dass Facebook Benutzerdaten in der URL erkannt hat. Einige CMS und Tools, wie Calendly oder PayPal, senden nach der Registrierung oder dem Kauf Benutzerdaten in der URL.

Dieser Fehler ist schwer zu beheben und erfordert die Aufmerksamkeit Ihrer Entwickler. Sie sollten die URL-Abfrageparameter verbessern und alle Benutzerinformationen aus der URL entfernen. Alternativ können Sie die Anweisungen zum Entfernen personenbezogener Daten (PII) befolgen und versuchen, das Problem innerhalb von GTM zu beheben. Eine weitere Option ist die Umstellung auf ausschließlich serverseitiges Facebook-Tracking. Auf diese Weise können Sie die URL vor dem Senden an Facebook ändern. 

Für jedes Server-Ereignis, das Sie an Facebook senden, wird ein Ereignisübereinstimmungsqualitätswert generiert. Dieser Wert hängt von der Menge der Benutzerdaten ab, die Sie an Facebook senden.

Wenn Sie eine benutzerdefinierte Subdomain für Ihren Tagging-Server verwenden, werden nur die Benutzer-IP, die Browser-ID, _fbp und _fbc an das CAPI von Facebook gesendet. Wenn Sie nur diese Benutzerparameter senden, ergibt sich ein Übereinstimmungsqualitätswert von etwa 4 von 10.

Um einen hohen Qualitätswert zu erreichen, ist es entscheidend, so viele Parameter wie möglich zu senden. Facebook verwendet diese Daten, um die Nutzer Ihrer Website mit denen in seiner Datenbank abzugleichen. Bevor Sie fortfahren, stellen Sie jedoch sicher, dass das Senden von Nutzerdaten an Facebook mit den Datenschutzrichtlinien Ihrer Website und den einschlägigen Vorschriften übereinstimmt. Technisch gesehen ist das Senden von mehr Parametern vorteilhaft, da es zu genaueren Zielgruppen- und Conversion-Daten führt, den Algorithmen von Facebook spezifische Informationen über Ihre Nutzer liefert und die Kampagnenleistung verbessert.

Wie können Sie den Event-Match-Qualitätsfaktor erhöhen? Die Antwort ist einfach: Senden Sie mehr Nutzerdaten. Die Umsetzung kann jedoch komplex sein. Überprüfen Sie zunächst, ob die Datenschicht auf Ihrer Website implementiert ist und ob sie alle Nutzerdaten enthält. Wenn sich Nutzer beispielsweise auf Ihrer Website anmelden können, überprüfen Sie, ob die Nutzerdaten bei der Anmeldung an die Datenschicht gesendet werden.

Wenn der Data Layer nicht implementiert ist, beauftragen Sie Ihre Entwickler mit der Einrichtung.

Stellen Sie als Nächstes sicher, dass Sie alle Nutzerparameter vom Web an den Server-Container übergeben.

Darüber hinaus kann eine neue Funktion des Data Tag dazu beitragen, die Übereinstimmungsqualität zu verbessern. Wir haben die Möglichkeit hinzugefügt, Nutzerdaten zu speichern. Wenn ein Nutzer beispielsweise ein Kontaktformular auf der Website ausfüllt, können Sie den Data Tag verwenden, um die Nutzerdaten im lokalen Speicher abzulegen und auf anderen Seiten zu verwenden.

Bei der Verfolgung von Facebook-Ereignissen sowohl über den Browser als auch über den Server verlangt Facebook eine eindeutige Ereignis-ID für jedes Ereignis. Für abgeglichene Ereignisse muss der Name des Facebook-Pixel-Ereignisses genau mit dem Namen des Server-Ereignisses übereinstimmen. Dasselbe gilt für die Ereignis-ID: Ereignisse aus dem Facebook-Pixel sollten ebenfalls mit den Facebook-Server-Ereignissen übereinstimmen. In diesem Prozess findet die Deduplizierung statt.

Dieser Fehler tritt auf, wenn Sie dieselbe Ereignis-ID für mehrere Ereignisse senden. Wenn ein Benutzer beispielsweise auf der Produktseite landet, sollten zwei Ereignisse ausgelöst werden: PageView und ViewContent. Sie müssen für jedes Ereignis eine eindeutige Ereignis-ID senden. Die FB-Ereignisse und Ereignis-IDs sollten wie folgt aussehen:

Auch wenn diese Ereignisse auf derselben Seite ausgelöst werden und möglicherweise denselben Trigger in Google Tag Manager für den Web- und Server-Container verwenden, sollte für jedes Ereignis eine eindeutige Ereignis-ID gesendet werden.

In diesem Szenario tritt der Fehler „Gleiche Ereignis-ID für viele Ereignisinstanzen empfangen” auf:

In diesem Beispiel senden wir die eventID 69 sowohl für PageView- als auch ViewContent-Ereignisse. Aber Facebook erwartet eine eindeutige eventID für diese beiden Ereignisse.

Lösung: fügen Sie die Facebook-Test-ID hinzu, öffnen Sie den Vorschaumodus für die Web- und Server-Container und testen Sie die Einrichtung. Sobald Sie festgestellt haben, wann dieser Fehler auftritt, können wir weitere Schritte zur Behebung des Problems unternehmen.

Wir haben eine benutzerdefinierte Variable erstellt, die eine eindeutige Ereignis-ID generiert, und empfehlen, diese für die Einrichtung der Facebook-Ereignis-Deduplizierung zu verwenden. Sie können den Ereignisnamen zu dieser Variable hinzufügen, um sicherzustellen, dass die Ereignis-ID eindeutig ist. In diesem Fall bleibt die Ereignis-ID auch dann eindeutig, wenn Ihre Ereignisse denselben Auslöser verwenden, da sie aus event_name_eventID besteht. Weitere Informationen zur Facebook-Ereignis-Deduplizierung finden Sie im obigen Abschnitt.

Um die Migration Ihres Web-Facebook-GTM-Tags zum serverseitigen Container zu vereinfachen, haben wir alle vom GA-Client empfangenen Daten dem Facebook-Ereignis zugeordnet, ohne dass Sie zusätzliche Einstellungen vornehmen müssen. Dies unterstützt auch die Zuordnung von GA Enhanced E-Commerce-Ereignissen, und natürlich kann das Tag alle an Facebook gesendeten Ereignisparameter überschreiben.

Wenn das Tag beispielsweise erkennt, dass es sich bei dem Ereignistyp um einen Kauf handelt, ermitteln wir die Produktliste, die Währung und den Wert.

In den folgenden Abschnitten beschreiben wir, wie genau die Daten in jeder Parametergruppe zugeordnet werden.

Nur wenige Parameter fallen unter die Kategorie „Server-Ereignisdaten“. Weitere Informationen finden Sie in der Dokumentation von Facebook zu den verfügbaren Ereignisparametern.

Zu den standardmäßig festgelegten Parametern gehören:

Mit der Option „Benutzerdaten-Tag“ können Sie alle Benutzerdaten, die an Facebook gesendet werden, überschreiben oder hinzufügen. Weitere Informationen dazu, welche Daten Sie dem Aufruf hinzufügen können, finden Sie in der Dokumentation von Facebook zu Benutzerdatenparametern. Wenn in der Dokumentation angegeben ist, dass der Parameter gehasht werden muss, müssen Sie ihn mit SHA256 hashen, da der Hit sonst nicht an Facebook gesendet wird.

Sie können auch alle anderen Parameter überschreiben oder eigene Parameter hinzufügen, indem Sie den Abschnitt „Benutzerdefinierte Daten” in den Tag-Einstellungen verwenden. Weitere Informationen zu den Datenparametern, die Sie einfügen können, finden Sie in der Dokumentation zu Standardparametern.

Wenn die Parameterelemente für den erweiterten E-Commerce vorhanden sind, setzen Sie den content_type auf product. Die GA-Produktparameter item_name und item_category werden jeweils Facebook content_name und content_category zugeordnet.

Das Tag versucht auch, andere Produktparameter zu ermitteln, darunter: 

Wenn der Ereignistyp „Kauf“ lautet, die Währung jedoch nicht zugeordnet werden kann, wird USD als Standardwert verwendet, da Facebook keine Kaufereignisse ohne Währungsparameter akzeptiert.