Start » Blog » Serverside Tracking
07.12.2019
Serverseitiges Google Ads Conversiontracking
In der laufenden Diskussion um Tracking, Cookies und das ganze andere Zeug bin ich in den letzten Tagen mehrfach an der Frage vorbeigekommen, ob und wie man auch ohne Cookies und Google Trackingcodes etc. Conversions in Ads “zählen” kann. Dieser Beitrag versucht sich an einer Antwort.
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 Analytics
- Import aus anderen Systemen
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 ID (gclid) 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 zwar tatsächlich das Tracking - und die Gefahr, beim Messen erwischt zu werden, denn man muss es dann auf eine der Conversionseiten schaffen, um es zu bemerken -, 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.
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. Zum Unglück muss diese Anbindung auch durch die regelmäßigen Updates der API gebracht werden (=regelmäßiger Aufwand). Dafür gibt es aber zum Glück eine einfachere Lösung... weiter unten.
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” 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.
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. Und vermutlich ist auch die Lebensdauer einer solchen Angabe dabei ausschlaggebend. Will man “auf unbestimmte Zeit” in einem Schlüssel im localStorage liegen lassen, so dass auch Monate später noch bei Erreichen eines Conversionpunktes auf der Website eine Übergabe der gclid zu Trackingzwecken möglich ist? Machbar ist das zweifelsfrei.
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 die gclid 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 gespeicherte ID 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. Denn nicht jedes System ist 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.
Offline Conversions importieren
Hat man die erforderlichen Daten zum Zeitpunkt einer Conversion nebst der ID 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 einlesen. 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.
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? Außerdem hat man nun gclid-Felder in seiner Shop-Datenbank oder als Datenfelder gemeinsam mit den persönlichen Daten in der externen Datenbank des Newsletteranbieters. Und das wollte man eigentlich gar nicht, sondern hat es nur zum Conversiontracking implementiert.
Aktualisierung 09-2020: Direktes serverseitiges Tracking ohne Google Analytics
der folgende Abschnitt ist nur noch aus sentimentalen Gründen im Blogpost vorhanden und das Verfahren funktioniert auch nach wie vor. Allerdings ist es viel einfacher und technisch ebenso umsetzbar, eine Conversion direkt an Google Ads zu senden, ohne einen Umweg über ein Google Analytics Profil zu machen. Unterhalb des hier erhaltenen Absatzes geht es weiter mit dem direkten serverseitigen Tracking von Ads Conversions.
Ein Ausweg könnte der dritte der drei oben genannten Wege bieten: Der Import aus Google Analytics. Aber wie soll das gehen, wenn man doch kein Analytics Tracking mehr betreiben wollte / sollte? Wie so oft lautet die Antwort hier: Nutzung des Google Analytics Measurement Protocols.
Minimalprofil in Google Analytics
Wenn man eine Analytics Property nutzen will, um die Trackinganforderungen für Google Ads zu erfüllen, ohne den ganzen Aufwand der Speicherung und Verarbeitung der gclid zu betreiben, muss man vor allem auf zwei Dinge setzen:
- Ein eigenes Profil, das ausschließlich der Vermessung der Conversionevents als Auslöser des zu importierenden Ziels dient
- serverseitiges Tracking für dieses Profil - beschränkt auf die Conversionevents
Der Ansatz basiert auf der Prämisse, ähnlich wie bei Nutzung von Offline Conversions zwar die gclid zu verarbeiten (in Analytics), aber darauf zu verzichten, Google etwas in die Hand zu geben, das domainübergreifendes Tracking, Anreicherung von Werbefunktionen, Profilbildung und all die anderen bösen Dinge erlaubt. Analytics soll hierbei “maximal dumm” bleiben und nur die Daten speichern, die für die Rückmeldung eines Conversionerfolgs erforderlich sind.
Mimimierung der Hits
Bei den Trackinghits, die hierbei an Analytics gesendet werden, muss dabei neben der für den Zweck unvermeidbaren Id nichts weiter vorhanden sein, was der Identifizierung des Besuchers dienen könnte. Durch die Nutzung des Measurement Protocols sind dabei Dinge wie der Browser, die IP des Besuchers oder andere Dinge, die üblicherweise zur Bildung von Fingerprints o. Ä. herangezogen werden, aus der Rechnung genommen. Eine Client-ID brauchen wir auch nicht - alle Hits können problemlos mit einer beliebigen Zufallszahl bei jedem Hit anders belegt werden. Eine Konstante ist deshalb nicht ideal, weil wir ein Ziel einrichten wollen und bei gleichlautenden Client-IDs die Möglichkeit besteht, dass zeitlich nah beieinander liegende Conversionereignisse dann der gleichen Sitzung zugeordnet werden. Da ein Ziel aber nur einmal in einer Sitzung erreicht werden kann, ist eine Konstante kontraproduktiv. Im unten stehenden Beispiel wird daher einfach die gclid genutzt.
Da ggf. auch Conversionwerte übergeben werden sollen, bieten sich Events als Hit-Typ an, denn diese können einen Wert haben, der als Zielwert auch über den Import aus Analytics an Ads übergeben werden kann. Ein zusätzlicher Seitenaufruf ist nicht erforderlich. Wir nutzen zur zur Weitergabe der gclid die URL, die wir mit dem Event übergeben. Da nur Conversions gezählt werden sollen, werden keine anderen Daten wie Referrer o. Ä. gebraucht.
Ein Hit zum Tracking einer Conversion als Event braucht demnach nur sehr wenig:
- Eine vom normalen Tracking unabhängige Property als Ziel des Hits
- eine die gclid oder eine andere Konstante bzzw. Zufallszahl für die Client ID
- ein eindeutiges Event zur Einrichtung eines Ziels
- ein optionaler Eventwert als Zielwert
- eine beliebige konstante URL als Ort des Events, in der die gclid (hier im Beispiel 1234567890) übergeben werden kann
Ein Beispiel eines solchen Aufrufs über das Measurement Protocol kann also so aussehen:
https://www.google-analytics.com/collect?v=1&dh=www.beispiel.de&dp=%2Fconversion%2F%3Fgclid%3D1234567890&t=event&tid=UA-xxxxxx-1&cid=666&ec=Conversion&ea=Anfrage&ev=0&ni=0&aip=1
Als “virtuelle” URL wird hierbei stets die Seite /conversion/ übergeben, welche als Parameter die Click ID (hier im Beispiel “1234567890”) enthält. Die Tracking-ID muss zur entsprechenden Property passen. Die Client ID wurde konstant mit “666” belegt. Ein solcher Hit reicht aus, um in GA ein Event zu vermessen, für das ein Ziel angelegt werden kann, wenn dieser in der Lage ist, eine Sitzung zu öffnen. Dafür sorgt der Parameter “ni” für “non interaction” mit dem Wert 0, so dass das Event als Interaktion gilt. Das in der Sitzung erreichte Ziel wird in Ads importiert; die Click-ID sorgt für die Verknüpfung.
GCLID als Tracking-Parameter übergeben
Optional kann die GCLID auch aus der URL fern bleiben. Schließlich ist sie so immer noch in Analytics sichtbar. Soll das verhindert werden, kann die ID als Parameter gclid=1234567890 auch dem Tracking-Hit mitgegeben werden. Die Verbindung zum Ads-Klick ist auch auf diese Weise möglich.
Nochmal: Je nachdem, wie “dauerhaft” man die gclid (Session vs. Cookie) gespeichert hat, kann damit für die Dauer einer Sitzung oder darüber hinaus eine Conversion eines Ads Besuchers mit Click-ID erkannt und an Ads gemeldet werden, ohne den ganzen Zauber bei der Speicherung und Verarbeitung im Rahmen des Offline-Imports zu veranstalten.
Einrichtung in Analytics
Es genügt eine “nackte” Property ohne große Konfiguration, die mit dem Ads Konto verbunden wird. Um die Wahrscheinlichkeit zu verringern, dass Analytics die Hits für nicht valide hält und ausfiltert, sollte lediglich in der Datenansicht die Option zum Ausschluss bekannter Bots und Spider deaktiviert werden.
Mit der verwendeten URL bzw. über das Conversion-Event wird dann in dieser GA-Property ein Ziel eingerichtet, das als Conversion in das verbundene Ads Konto importiert werden kann. Das war es auch schon.
Hit serverseitig versenden
Um eine Convesion an Analytics zu senden, ist der Aufruf einer URL wie oben beschrieben erforderlich. Eine einfache Funktion in PHP kann so aussehen:
function send_conversion($t_ua, $t_ea, $t_vl) {
$gclid = $_SESSION['gclid'];
if (isset($gclid) && $gclid !== "") {
$cid = $gclid;
$dl = urlencode('https://'.$_SERVER['SERVER_NAME']."/conversion/?gclid=".$gclid);
$t_ea = urlencode($t_ea);
$event_url = "https://www.google-analytics.com/collect?v=1&dl=$dl".
"&t=event&tid=$t_ua&cid=$cid&ec=Conversion&ea=$t_ea&ev=$t_vl&ni=0&aip=1";
$ch = cURL_init();
curl_setopt($ch, CURLOPT_URL, $event_url);
cURL_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
cURL_setopt($ch, CURLOPT_FRESH_CONNECT, true);
cURL_setopt($ch, CURLOPT_TIMEOUT_MS, 50);
curl_exec($ch);
cURL_close($ch);
return true;
} else return false;
}
Der Funktion wird als erster Parameter die Property-Id übergeben, an die der Hit bzw. die Hits gesendet werden soll. Eine Event-Aktion zur Unterscheidung mehrerer Conversions (z. B. Kontakt vs. Anfrage vs. Kauf) kann als zweiter Parameter angegeben oder auch leer bleiben - ein valider Event-Hit kommt auch mit der konstanten Angabe “Conversion” als Eventkategorie aus. Der dritte Parameter übergibt einen optionalen Wert - vermutlich also vor allem bei einem Kauf sinnvoll.
Erreicht ein Besucher eine Conversionseite, kann durch Aufruf dieser Funktion ein Hit an das “Minimalanalytics” gesendet werden, wenn es eine in der Session gespeicherte Click ID gibt. Vor dem Event wird zudem ein Seitenaufruf gesendet, um die Verbindung zwischen der Sitzung und dem Klick herzustellen und die Übergabe an Ads zu ermöglichen. Anderenfalls ist eine Messung nicht erforderlich und es passiert gar nichts.
In einer Bestätigungsseite eines Kontaktformulars würde also ein einfaches
send_conversion("UA-123456-1", "Anfrage", 0);
ausreichen, wenn die Funktion an dieser Stelle bekannt ist und genutzt werden kann. Ebenso kann auf einer Bestellbestätigungsseite eine Messung inkl. Warenkorbwert ausgelost werden:
send_conversion("UA-123456-1", "Kauf", 499.99);
Serverseitiges Senden von Google Ads Conversions
Nach dem oben beschriebenen Verfahren kann ein Hit auch direkt an Google Ads versendet werden. Dazu wird statt des Endpunkts von Google Analytics direkt mit dem gleichen Endpunkt kommuniziert, der auch beim clientseitigen Einsatz des Google Ads Conversion Tracking Codes genutzt wird. Die GCLID des Klicks wird dabei als Parameter gclaw übergeben. Zusammen mit Conversion-ID, Conversion-Label und einen optionalen Wert wird daraus eine Conversion in Ads, die auf den Klick zurückzuführen ist. Ohne weitere Cookies, ohne Möglichkeit zum Remarketing und über den Messpunkt der Conversion hinaus absolut "unnütz" für Google. Also genauso, wie wir es haben wollten.
Ersetzt man also im obigen Beispiel für Analytics die URL und sorgt zudem noch dafür, dass der Aufruf einigen Weiterleitungen folgt, ist das Absetzen einer Conversion mit der ID 12345 und dem Label ABCDE sowie dem Wert von 10.00 sogar noch einfacher, als im Analytics-Fall. Denn außer den genannten Eigenschaften der Conversion aus der Einrichtung in Google Ads brauchen wir nur noch die gespeicherte GCLID <gclid> und können damit serverseitig die folgende URL aufrufen:
https://www.googleadservices.com/pagead/conversion/12345/?value=10.0&label=ABCDE&guid=ON&gclaw=<gclid>&script=0
Das Verfahren bleibt gleich - also z. B. ein Aufruf via CURL, der direkt aus dem System erfolgt oder (wie im folgenden Abschnitt beschrieben) aus dem Browser getriggert wird. Mehr als ein Conversionwert wird dabei nicht als Parameter anfallen. Erfreulich unkomplex, oder?
Ich habe diese Methode - und ebenso den Weg über Google Analytics - in einem Video zur Demonstration in einem WordPress Plugin umgesetzt, so dass man sich den Ablauf vom Eintritt auf der Landingpage bis zur Conversion im Beispiel ansehen kann. Zudem finden sich weitere Infos im Folgebeitrag zum serverseitigen Conversiontracking.
Auslösen der Messung im Browser
Nicht immer ist ein konkreter Seitenaufruf auf dem eigenen Server im Spiel, wenn eine Conversion stattfindet. AJAX-Formulare, Klicks auf Links und jede Menge anderer Aktionen sind denkbar, bei denen eine Messung einer Conversion erfolgen soll. Als Lösung kann man dazu wie beim serverseitigen Web-Tracking auf einen clientseitigen Aufruf eines “Loggers” zurückgreifen, der die o. a. Funktion ausführt. Wird also wie im Beitrag zu serverseitigem Tracking beschrieben eine Hybridlösung implementiert, kann diese statt für alle Trackinghits nun gezielt für Conversionereignisse genutzt werden, welche zur mit dem Ads Konto verbundenen “Minimalproperty” gelangen sollen.
Vor- und Nachteile
Echte Nachteile serverseitiger Optionen ggü. “klassischem” Tracking von Conversions via Analytics oder dem Ads Trackingcode gibt es nur dann, wenn die Speicherung der gclid die Sitzung nicht überdauert, so dass Conversions aus nachfolgenden Sitzungen nicht mehr erfasst werden. Mit der Speicherung in einem Cookie oder an anderer Stelle kann dem aber begegnet werden.
Aspekte wie der Wegfall von Nutzbarkeit zum Remarketing oder fehlende Angaben zu gesehenen oder gekauften Produkten etc., die in einer detaillierten Implementierung des Ads Codes oder Analytics zur Verfügung stehen, sind hingegen im Hinblick auf die Reduktion auf das Vermessen von Kampagnenerfolg nicht als Nachteil, sondern als Vorteil einzustufen. Denn genau diese Dinge gehören zu den “ungewünschten” Eigenschaften, die hiermit oder dem Offline-Conversion-Import behandelt werden sollen.
Mit dem hier beschriebenen (sehr eingeschränkten) Einsatz von Analytics oder serverseitiger Auslösung der Ads Conversion sind folgende typische bekannte oder befürchtete Verwendungen durch Google oder andere Drittparteien, die durch Scripts oder Zugriff auf Cookies auf der Website “aktiv” sind, nicht mehr möglich:
- Besucher-Profilbildung, Kategorisierung von Interessen, Erhebung demografischer Daten über den Besucher der Website etc.
- Ausspielen personalisierter Werbung basierend auf diesen Profilen
- Attribution des Besuchs durch Drittanbieter (jenseits Google Ads via gclid, was ja Zweck der Übung ganzen ist)
- Auslesen einer Identität und Zusammenführen der (in Analytics) gesammelten Daten mit anderen Systemen
- Cookie-Synching durch Werbeplattformanbieter
Es kommt hinzu, dass die Wahrscheinlichkeit steigt, mehr Conversions als vorher zu erfassen. Denn die steigenden Probleme durch Trackingblocker und aktive Maßnahmen der Browserhersteller greifen in diesem Szenario nicht… Oder genauer: Wenn man nicht mit einer Sessionvariable, sondern einem Cookie für längere Attributionszeitfenster arbeitet, dann sollte es serverseitig gesetzt werden, um nicht mit ITP zu kollidieren. Gleiches gilt für die potentiellen Probleme mit localStorage in modernen Browsern wie Safari und Edge.
In Summe gibt es also kaum Argumente gegen eine solche Lösung, solange man nur die Anforderung erfüllen muss, Conversions in Google Ads zu messen - ohne die Nebenwirkungen von “normalem” Einsatz von Google Analytics oder Ads Tracking hinsichtlich Datenschutz, Cookies & Co.
Ist das nun eine konkrete Empfehlung?
Nein. Denn - zumindest mir - ist unklar, ob man mit einer solchen Property wirklich “aus dem Consent- und Datenschutz-Schneider” ist. Allein der Vorteil, dass diese Messung wie im Fall serverseitigen Analyticstrackings nicht erkennbar ist (selbst bei einer Hybridlösung bleibt die Funktion des eigenen Loggers ja eine Blackbox), bedeutet keine Konformität mit den Anforderungen einer kommenden ePrivacy oder den bestehenden Vorstellungen von Datenschützern. Speziell die technisch undifferenzierten Vorbehalte gegen jede Lösung, die irgendwie mit Google Analytics zu tun hat, sind damit vermutlich nicht behandelt.
Da die Messung aber tatsächlich auf das beschränkt ist, was zur Erfolgsmessung in Ads benötigt wird und der darüber hinaus bestehende Nutzen (also jenseits von Ads) faktisch gleich Null ist, ist das vermutlich die derzeit beste Lösung. Es passiert nicht mehr oder weniger wie beim Offline-Conversion-Import - nur mit i. d. R. deutlich weniger Aufwand.
So erscheint die Minimalisierung zumindest nicht mehr oder weniger kritisch als diese Form der Rückmeldung von Conversions. Der Knackpunkt bleibt die gclid, ohne die eine Verbindung von Klick zu Conversion nicht möglich ist. Jedenfalls ohne Zauberei. Wenn wir also davon ausgehen, dass die Werbeerfolgskontrolle irgendwie stattfinden muss und hoffentlich auch darf, ist der bequemere Weg über Analytics einer Speicherung in den eigenen Backendsystemen zum Zweck des Exports an Ads keinesfalls unterlegen. Meint: Wer die Speicherung der gclid und deren Imports in Ads rechtfertigen kann, sollte es auch mit dieser Variante schaffen. Das muss reichen - für den Moment zumindest. In der aktuellen Situation sollte eine Umsetzung aber zumindest nicht “schädlicher” sein, als consentfreies Ausspielen von Google Ads Remarketing- und Conversiontracking-Tags - ganz im Gegenteil.
gib einen aus