Conversions serverseitig erfassen – Ein rundum Blick
Management Summary
Mit dem Wegfall von 3rd Party Cookies wandert das Tracking immer weiter in Richtung Server-Side. Doch welche Hürden lauern und was bringt das Ganze überhaupt?
Das Wort Pixel dürfte jedem Marketer und Entwickler bekannt sein. Dahinter steckt aber mehr als ein transparentes 1x1px Bild, welches im Webbrowser auf Webseiten irgendwo versteckt geladen wird, um im Hintergrund Daten über den Besuch auf einer Webseite zu speichern. Zugleich setzt auch fast jedes Pixel gerne noch ein oder mehrere Cookies – jetzt nur noch auf First Party Ebene, siehe dazu die Post Cookie Ära.
Wie funktioniert das traditionelle Tracking?
Wird eine Webseite aufgerufen, können im Quellcode der Seite JavaScript Pixel verbaut sein, welche ein Bild oder ein iFrame von einer externen Domain laden. Dabei bekommt dieses Pixel Informationen mitgesendet, wie zB eindeutige Client IDs, die in Cookies gespeichert werden und weitere Merkmale der Nutzer.
Der Aufruf des Pixels richtet sich an den Tracking Anbieter direkt. Also schickt der Browser diese Informationen beim Pixel Aufruf direkt an die Server von z.B. Google Analytics.
Traditionelles Tracking, Quelle: e-dialog
Wie zu sehen ist, wird hier ein Umweg gefahren:
- User ruft eine Webseite auf
- Die Webseite liefert den HTML Code mit JavaScript Pixeln zurück
- Der JavaScript Code muss im Browser ausgeführt werden und es muss eine URL für den Pixelaufruf generiert werden
- Diese URL wird im Browser aufgerufen und die Daten werden beim Tracking Anbieter gespeichert
- Im Browser des Users können 1st Party Cookies von dem JavaScript Code gesetzt werden
Der Server, der die Webseite liefert, könnte ja die Pixel selbst laden – also ganz ohne Browser! Alle der genannten Punkte könnten auch im Hintergrund während oder nach dem Seitenladen vom Server anstelle vom Browser erledigt werden.
Alternatives Tracking, Quelle: e-dialog
Wieso haben wir überhaupt Pixel auf der Seite, wenn der eigentliche initiale Aufruf an den Server einer Webseite schon genügen würde, um alle Informationen abzugreifen, die fürs Marketing benötigt werden?
Wieso können wir nicht einfach “nur” serverseitig tracken?
Es begann mit JavaScript…
Das Tracking via JavaScript ist historisch entstanden. Aus Webentwickler-Sicht spielen dabei diese Faktoren eine wichtige Rolle:
- Limitierte Web Entwickler Ressourcen bei Webseitenbetreibern
– zum Beispiel, weil die Konzentration aufs Kerngeschäft wichtiger ist oder
– kein entsprechendes Know How da ist, um ein anderes Tracking zu implementieren - Fehlender Zugriff auf den eigenen Server
– also technische Limitierung
– wenn zum Beispiel ein simples Webhosting Paket verwendet wird, wo keine eigenen Programme ausgeführt werden können
Wenn wir noch weiter zurückgehen, gab es da noch die Logfiles. Die Analyse von Server-Logfiles gestaltete sich aber sehr uneffizient. Diese Daten eignen sich außerdem für automatische Werbekampagnen gar nicht. So entstanden die ersten Tracking Pixel via JavaScript. Ein reines serverseitiges Tracking wäre in der Anfangszeit des Internets nur schwer umsetzbar gewesen.
Der Grund für die Implementierung von Pixeln via JavaScript hat sich von Anfang an schlicht und einfach etabliert, weil der Aufwand mit JavaScript am geringsten ist.
Aktuell ist es nach wie vor so, dass die größten Tracking- und Marketing Pixel Anbieter, wie Google Analytics 4, Meta (Facebook Pixel) und etliche Andere ihre Pixel standardmäßig als JavaScript Snippet für das Frontend anbieten (also zum Ausführen im Browser).
Dieser Umstand ist mit den oben genannten Punkten erklärbar und zusätzlich dadurch, dass diese Art von Einbau global gesehen am einfachsten ist.
JavaScript Pixel haben diese gravierenden Nachteile
- Der Browser kann das Pixel teilweise unterdrücken, manipulieren (die Daten ändern) und gar nicht ausspielen (ganz blockieren). Ein Paradebeispiel für das Blockieren von Tracking Pixeln ist die Safari ITP (Intelligent Tracking Prevention). Auch Firefox (Mozilla) blockiert das Tracking, wenn zum Beispiel Seiten mittels Inkognito Fenster angesteuert werden.
- Ein weiterer Nachteil des clientseitigen JavaScript-Trackings ist, dass alles was getrackt wird, über den Browser nachvollziehbar ist.
- Und bei fehlendem Consent (Cookie Einwilligung) erhalten wir im schlimmsten Fall wenig bis gar keine Daten, was mit serverseitigem Tracking Abhilfe schaffen kann. Das Konforme Tracking laut User Consent sollte hier aber trotzdem eingehalten werden. Mit serverseitigem Tracking kann jedoch viel genauer gesteuert werden, was erfasst wird. Somit ist die DSGVO Konformität leichter gegeben.
- Eine große Anzahl an Tracking Pixeln auf der Webseite verlangsamt das Laden der Seite und kann zu mehr Absprüngen und zu weniger Conversions führen. (Insbesondere auf Mobilgeräten.)
Ein Vorteil von JavaScript Tracking war jedoch, dass ganz einfach 3rd Party Cookies gesetzt und ausgelesen werden konnten und somit ein globales Audience Tracking umgesetzt werden konnte. Das ist nun nicht mehr der Fall und das JavaScript Tracking wird jetzt schon wegen dem Wegfall von 3rd Party Cookies durch das serverseitige Tracking ergänzt, oder in Zukunft sogar gänzlich ersetzt.
- Aus diesem Grund sind nun die zahlreichen Conversions APIs (Facebook & andere soziale Netzwerke mit Ad Managern) entstanden.
- Google Pixel können serverseitig getrackt werden.
Statt also Pixel auf der Webseite zu laden und die Webseite zu verlangsamen, könnten die gleichen Abläufe beim oder nach dem eigentlichen Laden der Webseite im Hintergrund (am Server) stattfinden. Hierfür existieren heutzutage schon mehrere Optionen.
Der serverseitige Google Tag Manager
Wenn etwas nicht im Browser des Benutzers stattfindet, sondern eine Kommunikation zwischen zwei Servern direkt stattfindet, ist die Rede von einer serverseitigen Interaktion. Seit geraumer Zeit bietet Google neben seinem clientseitigen (standardmäßigen) JavaScript Tag Manager für Webseiten einen serverseitigen Tag Manager (sGTM) an, welcher auch Marketing Tools mit Daten in einer serverseitigen Kommunikation anreichern kann.
Für das Instandsetzen eines sGTM’s bedarf es eines Hostings, zum Beispiel in der Google Cloud. Der sGTM ist ein Programm (Docker Image), welches auf einem Server ausgeführt werden muss.
Die Abläufe, die im sGTM stattfinden, sind über den Browser und dessen Entwicklerkonsole nicht nachvollziehbar, da die Abläufe nur am Server stattfinden. Zumindest in der Theorie.
Die von Google vorgeschlagene Vorgehensweise ist nämlich, dass die Tracking Pixel mittels JavaScript im Client GTM wie bisher aufgesetzt werden, diese Pixel aber an den sGTM gesendet werden, anstatt an die Tracking Tools direkt.
Der Aufruf eines zum Beispiel GA4 Pixels findet dann nicht mehr unter https://region1.google-analytics.com/ statt, sondern am sGTM, der zum Beispiel unter https://sst.e-dialog.group aufgesetzt wurde.
Server Side GTM kann ganz gewöhnlich Pixel ausspielen, Quelle: Google
Der sGTM hat dann die Möglichkeit, diesen einen Pixel Aufruf an Google Analytics 4 weiterzuleiten.
Und das ist noch nicht alles.
Exakt den gleichen Aufruf kann der sGTM auch gleich mit-verwenden, um zum Beispiel ein Facebook Pixel, Floodlight Tags und andere Marketing Pixel über den Website Besuch zu informieren. Dabei können Daten beliebig manipuliert, angereichert und angepasst werden. Auch eine Überprüfung, ob der Consent für andere Tools gegeben wurde, ist möglich.
Also gibt es schon allein bei der Verwendung des sGTM’s in dieser Konfiguration den Vorteil, dass ein Pixel für mehrere Tools eingesetzt werden kann.
Empfohlene Implementierungsvariante, Quelle: e-dialog
Wird der GA4 Aufruf jedoch vom Browser blockiert, bringt der sGTM hier auch nichts.
Das ist die empfohlene, einfache Implementierungsvariante. Ein weiterer Schritt wäre, ein komplett serverseitiges Tracking ohne ein einziges clientseitiges Pixel auf der Webseite zu implementieren. Dies setzt jedoch die zwei Punkte voraus: (1) Entwickler-Kapazitäten, (2) Zugriff auf den Server.
Wie könnte ein pures, serverseitiges Tracking aussehen?
Beim Seitenaufruf, müsste es ein Programm im Hintergrund geben, welches exakt die gleichen Abläufe durchführt, die das JavaScript Pixel auf der Website tätigt. Am Beispiel von Google Analytics wird die Analytics JS Bibliothek zuerst im Browser geladen und es wird ein sogenannter Measurement Protocol Aufruf generiert. Dieser Aufruf enthält alle benötigten Tracking Informationen, die Google Analytics benötigt.
Nicht auf alle Informationen kann serverseitig zugegriffen werden. Ein Beispiel ist die Bildschirmauflösung. Also müsste es ein paar kleine JavaScript Funktionen geben, die diese Informationen beim Webseitenbesuch an den Webserver zurückliefern können.
Ganz entscheidend beim Tracking ist noch der Schlüssel, mit dem der/die BenutzerIn der Webseite identifiziert werden kann. Hier müssten eigene IDs in Cookies gesetzt werden. Fallen Cookies aus, müsste localStorage oder eine andere Methode für die Überbrückung entwickelt werden, sodass das serverseitige Tracking den/die BenutzerIn wiedererkennen kann.
Wurde alles zusammengetragen, so kann der vom Server generierte Tracking Aufruf zum Beispiel direkt an die Server von Google Analytics oder beispielsweise an den sGTM geschickt werden und von dort aus weiterverarbeitet werden. Bei einem Seitenaufruf wird der/die BenutzerIn nun nicht mehr über ein Pixel getrackt – der Weg über den Webbrowser wird nun umgangen und die Daten werden sofort ans Tracking Tool geschickt.
Auf dem beschriebenen Weg kann das Tracking niemals durch einen Tracking Blocker oder durch sonstige Interferenzen gestört werden. Der einzige Fall, in dem ein Seitenaufruf nicht getrackt werden könnte, wäre ein Serverausfall seitens des Tracking Tool Anbieters.
Serverseitiges Tracking, Quelle: e-dialog
Um konform zu bleiben, müsste die Beachtung der Einwilligung zur Datenerfassung trotzdem serverseitig umgesetzt werden. Hier bekommt der Entwickler dann aber die volle Kontrolle über den Datenfluss und kann steuern, was genau übergeben werden soll.
Ginge das auch mit Facebook & Co?
Das größte Problem bei einer puren serverseitigen Tracking-Umsetzung ist der Nachbau der Abläufe, die in JavaScript Bibliotheken stattfinden. Bei Meta, also beim Facebook Pixel, sieht es etwas komplizierter aus.
Hier werden verschiedene Cookies (__fbp, __fbc) erstellt und bei jedem Facebook Ereignis weiterverwendet. Diese Cookies können auch mit einigen Zeilen Code selbst generiert und dann an den sGTM geschickt werden. Damit wäre es möglich, die Facebook Conversions API rein serverseitig zu bespielen. Das betrifft aber nur die Conversions API und nicht das JavaScript Facebook Pixel.
Facebook verlangt jedoch, dass das Facebook JavaScript Pixel (fbq) auf der Seite ausgespielt wird und möchte zusätzlich noch über die Conversions API (cAPI) bespielt werden. Diese Variante würde ich als hybrid bezeichnen, da hier sowohl Daten vom Client (Browser) als auch Daten vom Server (zB sGTM) an Facebook geschickt werden. Um nicht doppelt zu zählen, müssen Ereignisse und Conversions dann dedupliziert werden.
Eine reine serverseitige Lösung ist bei Facebook also nicht möglich, außer bei der Nutzung der Offline Conversions.
Conversions API’s und Offline Conversions
Die Conversions API von Facebook und von anderen Anbietern bietet auch den Import von Offline Conversions an. Der Upload von Offline Conversions erlaubt es, Interaktionen (Ereignisse & Conversions) von Nutzern außerhalb der Website zu analysieren. Dabei muss es aber einen Schlüssel geben. Im Fall der Conversions API’s bei Facebook oder TikTok muss der Schlüssel die mit SHA256 gehashte E-Mail Adresse sein, oder die Telefonnummer des/der NutzerIn.
Das Tracking findet dann gänzlich ohne JavaScript statt und die Daten müssen von einem Server an die Conversions API hochgeladen werden.
Was sind Offline Conversions?
Ein Möglicher Use-Case fürs Offline Conversion Tracking ist ein Vertragsabschluss, der online als Lead generiert wurde, jedoch erst verzögert in einem Geschäftslokal unterzeichnet wurde. Nach dem Vertragsabschluss müsste dann die Offline Conversion mit dem Schlüssel (SHA256 E-Mail Adresse) hochgeladen werden.
Werden Offline Conversions an zb Meta geschickt, kann herausgefunden werden, wie viele Kunden Werbeanzeigen im Meta-Werbenetzwerk vor der eigentlichen Conversions angeklickt oder sogar gesehen haben. Das bietet einen erstaunlichen Einblick in die Offline Welt.
Wenn die Integration über die Offline Conversions Conversions API zu komplex ist, bietet Facebook beispielsweise auch einen CSV Import an.
Weitere Tracking Optionen mit dem sGTM
Ist ein sGTM in Ihrem Unternehmen in Planung oder sogar schon im Einsatz, dann können serverseitige Conversions an folgende Netzwerke geschickt werden:
- Facebook Conversions API (Meta)
- X Conversions API (vorher Twitter Conversions API)
- LinkedIn Conversions API
- TikTok Conversions API
- Pinterest Conversions API
- Snapchat Conversions API
- AWIN Server to Server (S2S) conversion tracking
- Bing offline conversions (Microsoft ads)
Der große Vorteil bei der Nutzung von Conversions API’s ist, dass das Werbebudget viel effizienter verwendet wird, da die Audiences durch das erweiterte serverseitige Tracking präziser werden.
Werden noch die Schnittstellen für den Offline Conversion Upload der Conversions API’s verwendet, kann ermittelt werden, wie viele Offline Conversions mit dem Werbebudget erfolgt sind, was dann einen ganzheitlichen Überblick verschaffen kann.
Wie geht Google mit serverseitigen Conversions um?
Wie im vorherigen Abschnitt in der Liste zu sehen ist, hat Google keine Conversions API. Die Conversions API’s der vielen Anbieter charakterisieren sich durch die hybride Implementierungsvariante. Es muss also ein JavaScript Pixel auf der Seite feuern und auch ein serverseitiger Request an die Conversions API gehen. Dabei müssen sowohl das Webseitenpixel als auch die Conversions API eine “event_id” übergeben, damit die Aufrufe miteinander assoziiert und dedupliziert werden können.
Bei Google Pixeln ist das anders. Hier muss nur die serverseitige Integration vorhanden sein. Wird zum Beispiel ein Google Ads Pixel über den sGTM ausgespielt, so muss im Client GTM dasselbe Pixel nicht noch einmal konfiguriert werden. Das gleiche betrifft die DoubleClick Floodlights. Es muss lediglich das “Signal” an den sGTM geschickt werden, dass die Conversion getrackt werden soll.
Wenn die Pixel von Google im sGTM genauer analysiert werden, kann jedoch festgestellt werden, dass Google hier auch clientseitig weitere Pixel ausspielt, obwohl diese nur serverseitig sein sollten.
Fazit:
Ein reines serverseitiges Conversion Tracking ist aktuell schwer umzusetzen. Der Vorteil von serverseitigem Tracking ist die erhöhte Datenqualität. Mit Google Analytics könnte ein reines Server zu Server Setup umgesetzt werden. Es ist jedoch mit mehr Aufwand verbunden, als der traditionelle JavaScript Pixel-Einbau. Aber schon die Nutzung des Server-Side Google Tag Managers in Kombination mit dem Client Side Pixel bringt sehr viele Vorteile mit sich.
