Markus Baersch

Serverseitiges Tracking mit dem Google Tag Manager beschränkt sich derzeit i. d. R. auf Google Analytics Clients und Tags. Dieser Beitrag zeigt, wie man die typische Trackinglücke schließt, die auf den meisten Websites besteht, wenn auf First Party Tracking mit dem serverseitigen Google Tag Manager Container ("Google Tag Server") umgestellt werden soll. Dabei kommen die jeweiligen Templates von Simo Ahava zum Einsatz. Dies ist nicht die einzige - und im Sinne der Reduktion eingehender Datenströme ggf. nicht die beste - Option, aber sie erfüllt ihren Zweck und basiert auf Tags, die man vermutlich mittelfristig nicht selbst warten oder weiterentwickeln muss.

Ab hier folgt der "alte" Beitrag mit der Beschreibung des zum Video passenden Vorgangs:

Eine Vorbemerkung zur Datensammlung

Dieses Beispiel nutzt das clientseitige Tag von Simo*, um Daten auf der Website im Browser zu erheben und an den Tag Server zu senden. Wer mein Blog verfolgt weiß, dass ich ein Freund von möglichst reduzierter Datensammlung im Browser bin... und natürlich könnte man alternativ auf dem Datenstrom einer Datensammlung über Analytics-Trackingcodes oder eine eigene Data Collection setzen. Da aber ohnehin für den konkreten Anwendungsfall von Facebook i. d. R. ein Basis-Script ausgespielt werden muss, welches sich um die Cookies und die Identifizierung des Besuchers kümmert und das nur bei Consent ausgespielt werden darf, ist eine separate Datensammlung, wie sie im client-seitigen Tag Template für die Nutzung der FB Conversions API vorgesehen ist, sicher zu vertreten. Diese setzt allerdings "nur" dann ein Cookie, wenn es so definiert wurde und eine Facebook-Klick-Id beim Eintritt auf die Seite vorhanden ist.

Es sind also Anwendungsfälle denkbar, in denen man sich mit einer selbst gespeicherten fbclid, der Identifizierung über die Mailadresse oder andere Optionen der API stützen möchte / kann und dies dann auch im Rahmen einer eigenen Datensammlung. In diesem Beispiel soll uns aber das Cookie des Beispiel-Tags ausreichen - auch im Sinne einer möglichst geringen Komplexität des ohnehin aus mehreren Schritten bestehenden Vorgangs der Einrichtung.

*) Wichtig: Facebook hat alle GTM Templates (primär für den normalen clientseitgen Einsatz) im Februar 2021 von Simo Ahava offiziell übernommen. Zwischenzeitlich sind auch die SSGTM-Templates zu Facebook aus Simos Repository verschwunden. Der Nachbau des hier beschriebenen Vorgangs ist mit den derzeit von FB verfügbaren Templates nicht (mehr) möglich! Mehr dazu unten bei den ehemaligen Links zu den Vorlagen.

Hinweis: Den hier beschriebenen Vorgang zeigt auch das Video zur Einrichtung der Conversions API und Nutzung im Tag Manager bei Youtube.

Schritt 1:
Einrichten des FB Pixels und der Conversions API

Wenn es nicht bereits ein Pixel gibt, zunächst in den Unternehmenseinstellungen der Facebook Business Suite ("Weitere Tools - Unternehmenseinstellungen") im Bereich "Datenquellen - Pixel" ein Pixel anlegen. Hier muss sichergestellt werden, dass der Benutzer "Conversions API System User" Zugriff auf das Pixel hat - anderenfalls wird später eine Fehlermeldung im serverseitigen GTM zurückkommen, wenn Daten per API übergeben werden sollen.

Anschließend nach Auswahl des Pixels den Events Manager über den Button "Im Events Manager öffnen" aktivieren. Dort unter "Test-Events" die Test ID notieren. Diese wird später bei der Einrichtung im Tag Manager verwendet.

Danach unter "Einstellungen" im Bereich "Conversions API" die Pixel-ID notieren (kann per Klick in die Zwischenablage kopiert werden) und weiter unten im Bereich "Conversion API" einen API - Zugriffsschlüssel generieren.

Im Einrichtungsassistenten die Option "Code manuell installieren" wählen, danach Pixel auswählen und auf der nächsten Seite die Schaltfläche "Zugriffsschlüssel generieren" anklicken. Der nach kurzer Zeit generierte Schlüssel kann per Klick in die Zwischenablage kopiert werden. Diesen API Key ebenfalls notieren für die Einrichtung des Trackings via Tag Server.

Nach Abschluss der API Einrichtung den Assistenten schließen und ggf. in den Einstellungen für den Echtbetrieb weiter unten schon die Traffic-Berechtigungen für die eigene Website eintragen. Für den Testbetrieb ist das aber nicht erforderlich.

Schritt 2:
Templates von Github herunterladen

Solange die Templates noch nicht in der Template Gallery bereitstehen, können diese bei Github gefunden werden.

Update 03/2021: Die Templates von Simo sind nicht mehr verfügbar. Es gibt Ersatz, aber damit ist das Problem, wie die Daten aus dem Client zum Serverseitigen Tag Manager kommen, nicht gelöst. Die unten stehenden Links führen also zum akt. Stand der Templates von FB, die ähnlichen Zwecken dienen, aber den Nachbau des hier gezeigten Vorgangs nicht ermöglichen. Das Verschwinden der Vorlagen hat seinen Grund, denn das hier demonstrierte Vorgehen (allein) verzichtet weitestgehend auf eine clientseitige Implementierung des FB-Trackings und das ist nicht im Sinne des Anbieters. Der API-Einsatz soll stets ein clientseitiges Tracking begleiten; genau deshalb gibt es auch Event-IDs, die zur Deduplizierung dienen sollen. Daher wird es wohl eine andere, bevorzugte Lösung geben... oder man muss sich mit einem anderen Datenstrom zum serverseitigen Tag Manager bemühen und die FB API mit passenden Tags bedienen.

Wer dennoch einen Nachbau der hier gezeigten Vorgehensweise plant - sei es aus Neugier oder als Einstieg in eine selbst angepasste Implementierung -, kann meine existierenden Kopien der letzten Fassung von Simos Templates gern bei mir per E-Mail nach Lesen dieses "Disclaimers" anfordern.

(Ende des Updates)

Links zu den Vorlagen von "facebookincubator": Es werden insgesamt drei Templates angeboten (die aber nicht denen entsprechen, die hier im Beispiel eingesetzt werden; zur Nutzung siehe Update 02/2021 oben!):

• Client - Template für den serverseitigen Tag Manager zum Verarbeiten der Requests
• Tag - Template des serverseitigen Containers für die Weitergabe der Daten via Conversion API direkt an Facebook
• Template für den clientseitigen Einsatz im GTM, da darüber die Data Collection passiert (aber es nun im Fall dieser Templates nicht mehr leistet, da es die normale clientiseitige Tag-Vorlage aus der Gallery ist)

In allen Ordnern findet sich jeweils eine Datei template.tpl, die lokal gespeichert werden muss. Wer sonst mit Github nichts am Hut hat, klickt die Datei an, wählt dann "Raw" als Ansicht und speichert dann die Seite auf dem eigenen Rechner. Dabei idealerweise jeweils passende und unterscheidbare Namen für die Datei wählen und darauf achten, dass die Dateiendung .tpl nicht noch durch ein .txt ergänzt wird, denn das stört später beim Import der Templates.

Schritt 3:
Serverseitigen Tag Manager Container einrichten

Mit den gerade gespeicherten Vorlagendateien für den serverseitigen Tag Manager werden nun neue Templates im GTM Container angelegt. Wer noch keinen Container hat, findet hier eine Anleitung zur Einrichtung und generelle Informationen zum Arbeiten mit Tag und Client-Templates.

Unter "Vorlagen" im Container je eine neue Client- und eine Tag-Vorlage anlegen und im Bearbeitungsdialog nach Klick auf "Neu" über das Drei-Punkte-Menü oben rechts den Punkt "Importieren" auswählen, um das passende Template für Client und  Tag einzulesen. Passt alles, lassen sich die Vorlagen speichern.

Beim Facebook Tag von Simo ist nach akt. Stand die API-Version nicht als Feld definiert, sondern steht direkt im Code. Das mag sich (sehr wahrscheinlich) noch ändern. Solange das so ist, ist die Versionsnummer hier ggf. an die aktuell gültige API Version anzupassen. Hier steht derzeit (November 2020) noch "8.0", aktuell ist aber Version 9.0. Daher die Angabe "const apiVersion = '8.0';" entsprechend anpassen und die akt. Versionsnummer angeben.

Mit diesen Vorlagen kann nun ein Client im serverside GTM Container erzeugt werden - und ein passendes Tag. Beim Client sind dabei keine besonderen Einstellungen erforderlich. Er dient dazu, die auf der Website gesammelten und an den Tag Server gesendeten Daten entgegenzunehmen und für Tags verständlich weiterzugeben.

Nun ein Tag unter Verwendung der neuen Tag Vorlage anlegen. Dort den kopierten API Key und die Test-ID in die Einstellungen eintragen. Damit das Tag auslöst, zudem einen Trigger erzeugen, der auf den FB-Client "hört", z. B. über die Bedingung des bei der Anlage verwendeten Client-Namens. Der ganze Vorgang der Anlage von Clients und Tags ist unter dem o. a. Beitrag im Detail beschrieben. Alle anderen Einstellungen wie die Pixel-ID etc. lassen wir wie im Tag voreingestellt aus den Daten bestimmen, die der Client empfangen hat.

Schritt 4:
Einrichtung im clientseitigen Tag Manager

Damit der Client Daten bekommt, ist nun das dritte Template an der Reihe. Dieses wird im Tag Manager Container verwendet, der ganz normal auf der Website eingebunden ist. Also nicht der gerade bearbeitete serverseitige Container, sondern der clientseitige "normale" Container. In diesem mögen derzeit bereits Facebook-Tags über das Template von Simo oder als Benutzerdefiniertes HTML ausgespielt werden, die nach erfolgreichem Test dann gegen die serverseitige Variante ersetzt werden können. Für den Test wird aber zunächst parallel ein weiteres Tag implementiert. Damit dies geschehen kann, muss zunächst auch im clientseitigen Container ein neues Template installiert werden.

Dazu unter "Vorlagen" wieder via "Neu" und den Import des dritten im Schritt 2 gespeicherten Template eine neue Vorlage anlegen. Bevor diese gespeichert wird, ist zwingend eine Anpassung erforderlich, damit das Tracking funktioniert:

Unter "Berechtigungen" muss bei diesem Template die passende URL des Endpunktes des eigenen Tag Servers angegeben werden. Ist der serverseitige GTM Container z. B. unter tracking.meinedomain.de zu erreichen, hier diese Domain eintragen; einschließlich führendem "https://" und abschließendem "/".

Mit diesem Template nun ein Tag einrichten, das auf der Website bei allen Seitenaufrufen feuert. Dabei die Pixel ID eintragen und "PageView" als Standard-Typ wählen. In den Einstellungen des Tags wird weiter unten dann wieder der Endpunkt des eigenen Tag Servers eingetragen, an den die Daten gesendet werden sollen. Dieser muss der im Template bei den Berechtigungen angegebenen URL entsprechen.

Das neue Facebook Tag vom Typ "Facebook Pixel - Server-Side" kann man für den Testbetrieb auf "Alle Seiten" triggern, solange man es nur im Vorschaumodus selbst ausspielt. Bei einem Livebetrieb aber natürlich auf korrekte Einbindung gemäß Tracking-Consent achten, wenn ein Consent Manager im Einsatz ist!

Optional: E-Commerce

Ist ein Shop im Spiel, für den erweiterten Test oder Echtbetrieb ein weiteres Tag hinzufügen, das die E-Commerce-Datenschicht nutzt und entsprechend triggern, um E-Commerce-Events zu übertragen. Die Einstellungen entsprechen dem "normalen" Tag Template von Simo für den clientseitigen Einsatz, welches hier dann vermutlich schon im GTM verwendet wird.

Schritt 5:
Vorschau anwerfen und Testen

Um zu kontrollieren, ob alles korrekt funktioniert, nun den serverseitigen GTM in den Vorschaubetrieb versetzen. Danach ebenso mit dem clientseitigen GTM verfahren und über den dabei verwendeten Tag Assistant die Website aufrufen, auf der der clientseitige GTM eingebunden ist.

Bei Aufruf von Seiten auf der Test-Website sollte der Debugger des clientseitigen GTM nun das erfolgreiche und fehlerfreie Feuern des neuen Facebook-Tags anzeigen. Ist dem nicht so, wie oben angegeben die Domain prüfen, die als Endpunkt eingetragen wurde.

Passt alles, zeigt die Vorschau des serverseitigen GTM eingehende Requests. Diese werden vom FB Client verarbeitet und bei korrekt eingerichtetem Trigger wird das FB Tag gefeuert. Der Responsecode des Aufrufs aus dem Tag sollte "200" lauten. Bei einer 400 das Ergebnis des Requests prüfen. Hier findet sich i. d. R. eine Fehlermeldung, wenn z. B. die API Version veraltet ist, der Schlüssel nicht stimmt oder andere Probleme das Tracking verhindern.

Ist alles OK, zeigt der Events-Manager von Facebook die Test-Hits an.

Ist alles durchgetestet (ggf. inkl. E-Commerce Events), kann die Test-ID aus dem FB Tag im GTM entfernt und alles veröffentlicht werden, wenn der Echtbetrieb starten soll. In diesem Fall kann dann das bisherige clientseitige direkte Tracking aus dem Browser an Facebook pausiert bzw. aus dem clientseitigen GTM entfernt werden. Als Ersatz dienen in diesem Fall nun die Requests, die an den eigenen Tag Server gehen und von dort aus per Conversion API an Facebook geliefert werden.