Google Ads Conversion-Tracking mit serverside Google Tag Manager

23. September 2021• Webtracking

Am 20. Juli 2021 veröffentlichte Google 2 neue Tags im Server-Container. Ein Tag für das Google Ads Conversion-Tracking und ein Tag für den Conversion Linker:

Die offizielle Dokumentation, wie Google Ads Conversion-Tracking im Google Tag Manager Server-Container aufgesetzt wird, ist hier auf der Google Developers-Seite zu finden. In diesem Artikel gebe ich eine Anleitung, wie man die neuen Tags einsetzt. Folgende Schritt sind notwendig:

GA4-Tag aktualisieren
Conversion Linker-Tag erstellen
Google Ads Conversion-Tracking-Tag erstellen
Testing und Funktionsweise

GA4-Tag aktualisieren

Das Google Ads Conversion-Tracking im Server-Container basiert auf den GA4-Datenstream vom Browser. Sprich: Grundvoraussetzung für das serverseitige Google Ads Conversion-Tracking ist schon ein bestehendes serverseitiges GA4-Setup. Im ersten Schritt müssen wir daher zu unseren Web-Container wechseln. Dort müssen wir das bestehende GA4-Tag, welches die Daten an den GTM-Server schickt, anpassen. Um die Daten an den eigenen Endpoint zu schicken, mussten wir bisher den Endpoint unter “Festzulegende Felder” als transport_url-Feld angeben. Jetzt gibt es aber die Funktion “An Servercontainer senden”. Das heißt, dass wir das transport_url-Feld entfernen müssen und stattdessen unseren Endpoint in das neue Feld einsetzen:

“An Servercontainer senden” macht 2 Sachen:

Es setzt zum einen das vorher schon existierende transport_url-Feld.
Das Feld “first_party_collection” wird auf “true” gesetzt. Damit weiß das GA4-Tag im Client, dass die Daten nicht an einen Third-Party-Endpoint gehen (also nicht direkt zum Google-Server wie bisher), sondern das es sich um einen eigenen – vom Website-Betreiber geführten – Endpoint handelt. Das führt dazu, dass das GA4-Protokoll auch sensible Informationen mit dem eigenen Server teilen kann. Wie das im Detail funktioniert, siehe unter “Testing und Funktionsweise”.

Conversion Linker-Tag erstellen

Im Server-Container brauchen wir nun ein Conversion Linker-Tag, welches auf allen page_view-Events feuert:

Was das Tag genau macht, schauen wir uns später an.

Google Ads Conversion-Tracking-Tag erstellen

Jetzt erstellen wir das Google Ads-Tag im Server-Container. Hier brauchst du die entsprechenden IDs und Labels aus dem Google Ads-Konto:

Als Trigger definiere ich in diesem Fall als Beispiel ein download-Event, welches natürlich vom clientseitigen GA4-Tag aus zum Server zunächst geschickt werden muss.

Testing und Funktionsweise

Nun kann das Setup getestet werden, bevor es Live geht. Schauen wir uns an wie es funktioniert. Vorschaumodus im Web- und Server-Container müssen dabei aktiviert werden.

Zunächst komme ich auf die Seite inkl. einem gclid-Parameter in der URL, um einen Anzeigen-Klick zu simulieren. Mein clientseitiger GA4-Tag schickt das page_view-Event zum GTM-Server. Dafür sorgt das Feld “An Servercontainer senden”. Ist in diesem Feld die URL zum eigenen Endpoint gesetzt, dann wird auch das Feld “first_party_collection” auf “true” gesetzt. Das bezweckt vielerlei Sachen:

Es teilt dem clientseitigen GA4-Tag mit, dass der Ziel-Server ein eigener Server ist. Dadurch können die Felder von user_data dort hingeschickt werden.
Gleichzeitig teilt aber “first_party_collection” den Server-Tags mit, dass keines der Daten aus dem user_data-Feld für das Bauen des Hits herangezogen werden darf.
Zusätzlich setzt es die Erlaubnis für eine 2-Weg-Kommunikation. Mittels XHR ist es dem Server gestattet Informationen zurück zum Browser zu schicken. Dies ist für die nachfolgenden Schritte wichtig, wie wir gleich sehen werden.

Kommt das page_view-Event im Server-Container an, reagieren 2 Tags und erzeugen 2 ausgehende Requests:

Ein Request geht direkt raus an Google Analytics 4
Der zweite Request kommt vom Conversion Linker

Der Conversion Linker schickt zuerst einen Request mit der aufgerufenen Seite an den Google Ads-Server:

Außerdem: Wenn in der URL der gclid-Parameter enthalten ist oder wenn im eingehenden Request die Cookies _gcl_aw und _gcl_dc vorhanden sind (das sind Google Ads First-Party-Cookies), dann setzt das Conversion Linker-Tag im Response ein Cookie namens “FPGCLAW”:

In diesem Cookie wird nochmal die Google Ads Klick-ID hinterlegt, nur eben als HTTP-Cookie und nicht als JavaScript-Cookie. Nun surfe ich weiter auf der Seite und löse die Google Ads Conversion aus. Dabei schickt das clientseitige GA4-Tag wieder den Hit an den Server-Container. Im Server-Container feuert dann das Google Ads Conversion-Tracking-Tag:

Danach passieren 2 Sachen. Zum einen geht der Conversion-Request vom GTM-Server direkt zum Google Ads-Server raus:

Damit gehen alle für die Conversion-Erfassung relevanten Parameter raus. Es passiert aber noch was. Schaut man im Preview Modus weiter runter auf der selben Seite, wo man den ausgehenden Request zum Google Ads-Server sieht, dann stellt man fest, dass man eine Antwort bekommen hat:

Hier fällt auf, dass dies vom Doubleclick-Server kommt. Hintergrund ist, dass Google Ads dem Doubleclick-Server mitteilen muss, welcher User-ID die Conversion zugeordnet werden muss. Damit Doubleclick dieses Stitching hinbekommt, muss es sein Third-Party-Cookie abholen, welches im Browser des Nutzers liegt. Aus diesem Grund schickt der GTM-Server den Request weiter bzw. zurück an den Browser. Im Request ist ein Befehl hinterlegt, der den clientseitigen GA4-Tag anweist, den Doubleclick-Request durchzuführen: