Serverseitiges Google Ads Conversiontracking

In der sich ständig bewegenden Diskussion um Tracking, Cookies und das ganze andere Zeug kommt eine Frage ganz besonders oft auf: Wie kann ich meine Conversions vor der Tracking- und Consent-Lücke retten? Dieser Post hat seit 2017 laufend andere Methoden aufgezählt und dann wieder verworfen, wie man auf alternativen Wegen mit Conversions umgehen kann, um diese in das Ads System zu spielen. Seit der DSGVO war dies zunächst vor allem rechtlich fraglich. Seit Google aber zur Verarbeitung von Conversions und Signalen zur Zielgruppenbildung auf explizite Kommunikation von Consent Mode ("Zustimmungsmodus") Signalen wie ad_storage & Co. angewiesen ist, sind alle Wege aus zwei Perspektiven zu betrachten: Messung von Conversions mit Zustimmung und ggf. das Senden zusätzlicher Conversions als Modellierungssignal, wenn keine Zustimmung bestand. Über Sinn und Unsinn von Modellierung und Advanced Consent Mode soll es hier nicht primär gehen, sondern die aktuell möglichen Methoden im Fokus behalten.

Warum die Frage so drängend ist

Während bei vielen Websitebetreibern die Bereitschaft zum Verzicht auf Tracking angesichts des kräftigen Gegenwinds steigt, bleibt die Messung von Erfolg von Werbekampagnen ein Punkt, an dem für viele der Spaß aufhört. Kein Wunder, denn viele Werbesysteme - auch natürlich Google Ads - leben von der Messung von Erfolg “über den Klick hinaus”. Das ist nichts Neues und ist für eine wirtschaftlich sinnvolle Kampagnengestaltung und -steuerung unerlässlich.

Speziell bei Google Ads sind zudem viele der automatischen Gebotsoptionen und “Smarte” Kampagnen auf Erfolgsmessung zur optimalen Steuerung angewiesen. Daher mag auch niemand darauf verzichten.

Optionen für Conversions in Google Ads

Zur Messung im Kontext einer Website (jenseits von Anrufen und Apps) können generell drei Wege verwendet werden:

• Google Ads Conversiontrackingcode implementieren
• Import von Conversions aus Google Analytics
• Import aus anderen Systemen als "Offline Conversions"

Während bei den “anderen Systemen” auch Salesforce und Drittanbieter-Tools als Quellen bereitstehen, die über eine Verbindung ähnlich wie im Fall von Analytics “automatisch” importiert werden können, sind es vor allem importierte Conversions, die anhand der Google Click IDs (gclid, wbraid, gbraid) und / oder personenidentifizierbaren Daten wie Mailadressen & Co. mit den Daten der Kampagnen verknüpft werden können.

Die Google Ads Hilfe spricht von Offline-Conversion-Tracking. Für ein Tracking ohne Cookies etc. wäre das natürlich die naheliegende Lösung. Jedenfalls auf den ersten Blick. Aber der Reihe nach...

Google Ads Conversion Tracking Code verwenden?

Die einfachste “Idee” zur Reduktion von Tracking ist der Ausbau von Google Analytics und ausschließliche Verwendung des Google Ads eigenen Codes. Nur auf den wesentlichen Conversionseiten. Also eben keine globale Implementierung auf allen Seiten, keine Daten für Remarketinglisten etc., aber zumindest doch ein Tracking von Bestellabschluss-Seiten und Bestätigungsseiten von Kontaktformularen etc. Das reduziert tatsächlich das Tracking - und theoretisch sogar die Gefahr, beim Messen erwischt zu werden, denn man muss es dann auf eine der Conversionseiten schaffen, um es zu bemerken oder Seiten wirklich mit einer Klick ID aufrufen, um diese in einem Cookie wiederzufinden -, aber am eigentlichen Problem ändert es wenig. Immer noch sind Google Trackingcodes und Cookies im Spiel - mit allen Problemen, die Regulierung, Browser und Trackingblocker mit sich bringen. Am Ende des Tages ist der Unterschied zwischen Google Ads Tracking und Google Analytics aus Implementierungssicht also nur gering - selbst der Trackingcode nutzt eine gemeinsame Bibliothek und Syntax. Vermutlich also aus keiner Perspektive die beste Lösung… wer aber eigentlich Analytics nur nutzt, um damit Conversions in Ads zu erfassen und sonst keinen Nutzen daraus zieht, kann so wenigstens die Angriffsfläche verringern und ist auch “datensparsamer” als vorher. Immerhin. Allgemein lohnt es sich durchaus, Google Ads mit eigenen Tags auf einer Website zu verbauen, selbst wenn auch Google Analytics im Spiel ist. Im Sinne der Maximierung der Signale für das Ads-Konto ist eine von der korrekten Attribution in GA (die durchaus scheitern kann!) unabhängige, separate Messung sinnvoll. Welches Signal wirklich in die Steuerung von Kampagnen einfließt, ist durch die Verwendung als primäre oder sekundäre Zählmethode gezielt steuerbar.

Ads API direkt beim Auftreten einer Conversion nutzen?

Alternativ ist auch eine serverseitige Messung denkbar, die auf der Google Ads API aufsetzt. Das erfordert aber eine Menge initialen Aufwand, nur um eine einzige Funktion zu nutzen und so den "Offline Import" direkt dann anzustoßen, wenn die Conversion passiert. Zum Unglück muss diese Anbindung auch durch die regelmäßigen Updates der API gebracht werden (=regelmäßiger Aufwand). Zum Glück existieren dazu fertige Lösungen verschiedener sGTM-Anbieter in Form eines Tag-Templates für den serverseitigen Tag Manager.

Die Click ID für Offline-Conversions “merken”

Ungeachtet des irreführenden Namens kann aber auch die Option des Offline-Conversion-Trackings dazu dienen, Website Conversions zu erfassen. Dazu muss allerdings “irgendwo” die Google Click ID, die als Parameter “gclid” (und / oder gbraid / wbraid) an der Zieladresse einer Anzeige hängt, wenn das Auto-Tagging in Ads aktiviert ist, beim Eintritt in die Seite gespeichert werden, so dass sie noch verfügbar ist, wenn das Conversionereignis (Kauf, Anfrage, Anmeldung etc.) auftritt. Jedenfalls dann, wenn der Browser diese nicht schon wieder entfernt hat, bevor die Seite aufgerufen wurde, denn genau das passiert vermehrt durch steigende Strenge von Trackingschutzmaßnahmen.

Eher selten kann man für seine Werbung auf eine Landingpage zurückgreifen, die wirklich nur aus einer “Einseitenanwendung” (SPA) besteht und wo auch am Ende eines Bestellprozesses oder einer erfolgten Anfrage immer noch die Parameter in der URL vorhanden sind. Daher muss man sich die ID beim Eintritt in die Website merken, um sie später weitergeben zu können. Diese Speicherung muss aber “irgendwo” geschehen. Betrachtet man das aus Sicht der zu erwartenden Regulierung durch ePrivacy, wird also ein Cookie oder eine Ablage im Browserspeicher davon abhängen, wie “funktional notwendig” eine solche Speicherung ist. Meint: ohne Zustimmung ist da im Browser nichts zu machen. Reicht es hingegen, die ID nur für die Dauer einer Sitzung zu erkennen, gibt es auch andere Optionen. Wie zum Beispiel das serverseitige Speichern der ID in der Sitzung als Sessionvariable, so dass sie solange auf Conversionseiten genutzt werden kann, bis die Session beendet wird. Die Nutzbarkeit einer solchen Lösung hängt nicht zuletzt davon ab, wie wahrscheinlich es ist, dass ein Besucher direkt nach dem Anzeigenklick eine Conversion auslöst. Es ist also mehr oder weniger das gleiche Problem, dass man beim Tracking generell mit der Frage der Identität und deren Lebensdauer hat… denn eine Klick ID ist ja nichts anderes als Identität, mit deren Hilfe der Klick auf eine Anzeige und eine erfolgte Conversion zusammengeführt werden sollen.

Für den folgenden Fall nehmen wir an, dass eine Verwaltung der ID für die Dauer der Session ausreicht - statt der Session ein Cookie zu verwenden, ist vom Prinzip sehr ähnlich und selbst eine im Browserspeicher abgelegte ID wäre auf ähnliche Weise zu handhaben, wenn sie auf der Conversionseite dann ausgelesen und mit “verarbeitet” wird (dazu später mehr im Abschnitt zur Verarbeitung).

Beispiel: Click ID in Sitzung “merken”

Unterstellen wir ein System, in dem PHP genutzt wird und ohnehin bereits eine Session existiert. Idealerweise mit einem sicheren und nur serverseitig zugänglichen Cookie. An der Stelle, an der die Session gestartet wird, kann mit anderthalb Zeilen Code dafür gesorgt werden, dass eine in der URL enthaltene Click ID in der Session gespeichert wird.

$gclid = $_GET['gclid'];
if (isset($gclid) && $gclid !== "") $_SESSION['gclid'] = $gclid;

Ab sofort kann diese gespeicherte ID auch auf Folgeseiten, die nach dem Eintritt über die Landingpage auch auf allen weiteren Seiten der Sitzung genutzt werden. Hier statt einer Sitzungsvariablen ein Cookie zu nutzen, ist ebenso codearm zu bewerkstelligen - und natürlich auch ohne PHP, sondern direkt per JavaScript im Browser. Der Vorteil eines Cookies wäre, dass auch spätere Sitzungen noch Conversions auslösen können… aber damit hat man wieder alle typischen “Cookie-Probleme” zu verwalten und behandeln.

Verarbeitung der ID

Erreicht der Besucher nun eine “Conversionseite” wie z. B. die Bestätigungsseite eines Anfrageformulars, passiert i. d. R. etwas. Die Anfrage wird per Mail an den Betreiber gesendet oder in einer Datenbank gespeichert. Ein Kauf wird in einem Shop gespeichert; eine Newsletteranmeldung von einem Newslettersystem in einer Empfängerliste vermerkt.

Die erste Herausforderung ist nun also, die gespeicherten IDs aus der Session auszulesen und zusammen mit den Spuren der Conversion in den eigenen Systemen zu versenken. Das kann je nach CMS bzw. Shopsystem - oder gar einem externen Newsletteranbieter - eine ganze Menge an Aufwand bedeuten, aber meistens kann ein Formular um Felder erweitert werden, so dass diese IDs es in das eigene Backend schaffen. Allerdings ist nicht jedes System auf die Implementierung weiterer Datenfelder, deren Wert auch noch aus der serverseitigen Session ausgelesen werden muss, gut eingerichtet; idealerweise sogar updatesicher. Insofern muss man bei Erwägung dieser Option genau prüfen, welcher Aufwand für Einbau und Pflege einer solchen Lösung entsteht. Ein Beispiel für die Übertragung in einem Formular zeigt Google selbst in der Hilfe zur Nutzung von Offline-Conversions. Ist diese Hürde genommen, kommt der zweite Teil: Die Weitergabe der Conversiondaten an Google Ads.

"Enhanced Conversions"

Fehlen diese IDs (weil der Browser sie gefressen hat oder keine Weitergabe in das CRM möglich ist), bleiben leider nur noch personenidentifizierbare Daten wie Mailadressen, Namen, Telefonnummern als Ersatz übrig, die man dann (idealerweise als Hash und nicht im Klartext) mit Zielsystemen teilen kann. Das muss nicht Google Ads sein; Microsoft Ads und Meta sowie andere Plattformen bieten i. d. R. ähnliche Wege an. Die Idee dahinter ist, dass bei einem Klick auf eine Anzeige bei angemeldeten Besuchern Daten wie Mailadressen bekannt sind. Bringt eine Conversion nun einen Hash einer Mailadresse mit, die bei Google bekannt und mit einem ausgehenden Klick auf eine Anzeige verknüpft ist, kann so auch ohne Klick IDs eine Brücke zwischen Interaktion mit Anzeigen und Erfolg geschlagen werden: Die Conversion ist messbar. Das klappt aber natürlich deutlich weniger zuverlässig wie die Zuordnung anhand einer Klick ID, denn weder kennt man bei jeder Art von Conversion eine Mailadresse, noch ist garantiert, dass eine gesendete Mailadresse auch bei Google bekannt und mit einem Klick verknüpft ist. Inkognito Browser, unterschiedliche Google Accounts und Mailadressen - reichlich Punkte, an denen eine solche Verbindung scheitern kann.

Offline Conversions importieren

Hat man die erforderlichen Daten zum Zeitpunkt einer Conversion nebst der ID(s) als Minimalausstattung zur Hand, indem man die Daten aus seinen eigenen Backendsystemen exportiert, sind diese in einem passenden Format über die Google Ads Oberfläche manuell einzulesen. Auch eine Bezeichnung der Conversionaktion (passend zum angelegten Importschema bei verschiedenen Conversions), ein Wert und eine Währung können angegeben werden, was vor allem für Transaktionen in einem Shop und daraus resultierende Kampagnensteuerung anhand des Conversion-Wertes wichtig ist.

Komplexere Lösungen umgehen den manuellen Schritt und übergeben regelmäßig erfasste Conversions über die API direkt an Google Ads.

Wenn keine Zustimmung besteht

Ist keine Zustimmung vorhanden, kann man - wenngleich umstritten - lt. Auffassung von Google dennoch sinnvoll Daten senden. Eine Conversion per Tag im Browser im "erweiterten Zustimmungsmodus" verzichtet auf Cookies, sendet aber alles andere dennoch. Die wichtige Klick ID, welche es eben bei sauberer Implementierung nicht in ein Cookie geschafft hat, ist im Fall einer SPA ggf. immer noch in der URL. Oder sie wurde von einem "Conversion Linker" von einer zur anderen Seite immer als URL Parameter weitergetragen. Die Consent Mode Parameter, die das Conversion Tag beim Aussenden der Conversion an Google mitbringt, dokumentiert die fehlende Zustimmung und degradiert den Request zu einem Signal zur Modellierung, mittels der die Lücke in der Messung der Conversions durch fehlende Zustimmung geschlossen werden soll.

Und da auch ohne Cookies und in diesem "Advanced Consent Mode" immer noch die Gefahr besteht, dass der Request gar nicht erst aus dem Browser gelangt oder das zum Tracking erforderliche gtag.js vom Browser blockiert wurde, gibt es auch den Mischbetrieb von Conversions aus dem Browser und via Import, der ebenso dazu geeignet ist, Modellierungssignale zu senden. Wobei man dann spätestens bei Verwendung von Mailadressen etc. zur Messung von "Enhanced Conversions" in Ads (siehe oben) wieder das Thema Datenschutz besonders zu beachten hat.

Ist das nun die beste Lösung?

Damit landet ein Minimum an erforderlichen Informationen im Google Ads System, ohne dass dabei Google Trackingcodes oder deren Tracking-Cookies im Spiel sind. Aus der Falle des “domainübergreifenden und profilbildenden” Trackings sollte man damit entkommen sein. Aber ist das die einzige Lösung, um dieses Ziel zu erreichen? Muss man wirklich den ganzen Aufwand betreiben, um vor allem die in eigenen Systemen gespeicherten Conversiondaten mit einer Google Click ID anzureichern - und vor allem dann auch an Google Ads zu übertragen; sei es durch manuellen oder maschinellen Import? Die kurze Antwort ist: Ja. Es gab und gibt Wege, wie man dies auch durch synthetische Requests vom Server aus nachbilden kann. Oder man arbeitet mit synthetischen Usern, wie es im Fall von JENTIS passiert, um damit die Modellierung in das eigene Tool zu ziehen und so zu versuchen, die Lücke zu schließen, wenn keine Zustimmung besteht.

Ich selbst hatte hier in diesem Post viele Jahre ebenso alternative Wege vorgestellt, wie man eine Conversion in Ads bekommt und hatte sogar eine zeitlang Erfolg mit aus Logfiles ausgelesenen Conversions. Spätestens mit dem Consent Mode und der Pflicht, diese Parameter aktiv mit Conversions bei Google anzuliefern, sind aber alle Mittel wie ein genereller Export aller Conversions aus Matomo oder anderen Systemen (die nach wie vor existieren) keine wirkliche Lösung, wenn hier nicht wenigstens auch die Dokumentation der Consent Lage stimmig ist und nicht einfach nur Zustimmung "dazu gelogen" wird. Das ist technisch möglich, aber moralisch verwerflich und rechtlich angreifbar. Daher endet dieser Beitrag mit dem Hinweis, sich nicht auf Versprechen einzulassen, die zu gut klingen, um wahr zu sein. Optionen zum Einsenden von Conversions existieren in ausreichender Zahl. Advanced Consent Mode "ermöglicht" sogar (auf fragliche Weise) das Senden von Daten ohne Zustimmung. Das muss ausreichen - alle anderen Basteleien sollten jenseits dessen liegen, was man vor sich selbst und dem Gesetzgeber im Zweifelsfall verantworten kann. So sehr man sich nach einem "Recht auf Werbeerfolgskontrolle" sehnt, wo Geld für Traffic ausgegeben wird: der rechtliche Rahmen ist zwar nicht schwarzweiß, aber lässt kaum Spielraum, wenn es um Werbesysteme und Aktivierung geht. Zustimmung (nicht erschwindelt, sondern erworben) ist nach wie vor der beste Weg, um auf der sicheren Seite zu sein. Denn der Knackpunkt bleiben die Klick IDs, ohne die eine Verbindung von Klick zu Conversion nur schwer möglich ist.