Markus Baersch

Analytics · Beratung · Lösungen

Start » Blog » Serverside Tracking

17.09.2020

Im Dezember 2019 habe ich hier einen Beitrag über Alternativen zum Einsatz von clientseitigen Tags zur Erfassung von Conversions veröffentlicht. Darin ging es ausschließlich um Google Ads und die vorgestellte Methode machte einen Umweg über eine separate Google Analytics Property. Der Post hat Fragen beantwortet, aber auch neue aufgeworfen. Einige dieser Fragen beantwortet dieser Folgebeitrag.

  1. Wie kann man serverseitig Conversions für Google Ads messen, ohne Analytics verwenden zu müssen?
  2. Funktioniert der Weg auch für andere Systeme wie z. B. Bing Ads (Spoiler: Ja)?
  3. Brauche ich unbedingt Cookies, um die Click-IDs zu speichern?

Google Ads Tracking ohne Umweg

Während der Arbeit an einem zu Demozwecken dienenden WordPress-Plugin, das anhand einer realen Website das Prinzip aus dem o. g. Beitrag zeigen sollte, bin ich (nicht zum ersten Mal) an der Frage hängen geblieben, ob man die erforderlichen Aufrufe statt an Analytics nicht direkt an Google Ads senden kann, um dort direkt als Conversion verarbeitet zu werden. Schlussendlich macht auch ein clientseitiger Trackingcode nichts anderes (naja... zumindest wenn er wirklich nur der Erfolgskontrolle dienen soll). "Ein Pixel abrufen" bedeutet, einen Request an einen Tracking-Dienst zu senden. Warum also nicht den entsprechenden Hit direkt vom Server senden?

Hier kommt das "Identitätsproblem" ins Spiel. Während der clientseitige Request eines Conversionpixels Cookies aus dem Browser im Gepäck hat, die auf der anderen Seite erlauben, das Signal zuzuordnen, brauchen wir am Server eine Alternative. Entweder Cookie-Werte im Header des serverseitigen Request selbst setzen oder einen Parameter suchen, über den das Identifizierungsmerkmal weitergegeben werden kann.

Schaut man den Hits (ja, es sind mehr als nur einer) des clientseitigen Google Ads Conversiontracking-Codes auf die Finger Parameter, zeigt sich ein Weg, um die GCLID (Google-Click-Id) weiterzugeben, welche die Brücke zwischen dem erfolgten Anzeigenklick und der gemeldeten Conversion erlaubt: Der Parameter gclaw enthält genau diese Id. Neben vielen weiteren Parametern, die die Aufrufe des normalen Trackingcodes mit zahlreichen Informationen anreichern.

Die meisten sind aber für den angedachten Zweck der möglichst minimierten Werbeerfolgskontrolle nicht erforderlich. Als guter Ansatzpunkt zur Minimierung erweist sich eine alte Fassung des Google Adwords Conversion Trackings. Dieser enthielt eine erfreulich überschaubare URL für ein Image-Tag, das als Fallback bei streikendem JavaScript dient. Diese URL nutzte den gleichen Endpunkt wie heutige auf GTAG.JS basierende Trackingcodes von Google Ads - nur eben mit viel weniger Parametern. Das sah dort so aus:

https://www.googleadservices.com/pagead/conversion/<conversion_id>/?value=<conversion_value>&currency_code=EUR&label=em><conversion_label>&guid=ON&script=0

Hier stecken die Id und das Label aus der Einrichtung der Conversion in Google Ads und ein optionaler Wert. Für eine in Ads erzeugte Conversion mit der Id 123456789, dem Label abcdEFghijKlmNOp, und einem Wert von 10,-- Euro wie folgt aus:

https://www.googleadservices.com/pagead/conversion/123456789/?value=10&currency_code=EUR&label=abcdEFghijKlmNOp&gclaw=aaaaa11111bbbbb22222&guid=ON&script=0

 Dabei hängen wir die GCLID aaaaa11111bbbbb22222, für die wir die Conversion auslösen wollen, mittels des gclaw-Parameters an. Sie kommt wie schon im Ursprungsbeitrag angesprochen entweder aus der Session oder einem Cookie, in dem sie beim Eintritt auf der Landingpage der Anzeige gespeichert wurde. Der Versand geschieht wie zuvor direkt von Server zu Server. Im folgenden Video wird das Tracking für Google Ads demonstriert; sowohl mit dem Umweg über Google Analytics als auch auf direktem Weg.

Video zum serverseitigen Ads Conversion-Tracking

Verfahren auf andere Systeme anwenden

Tracking von Conversions funktioniert in vielem Systemen im Prinzip gleich. Entweder werden auf jeder Seite ständig Daten versendet und im System dann anhand von Regeln in Conversions umgewandelt (oder die sendenden Browser anhand ihrer Cookies in Zielgruppen eingeteilt) oder es gibt Hits, die nur im "Conversionfall" versendet werden. Der hier beschriebene Weg für Google Ads basiert auf dem zweiten Modell. Bei Webanalyse und dort eingerichteten Zielen ist es hingegen der erste Weg.

Jenseits des Google-Universums sind ähnliche, ebenfalls auf Click-Ids basierende Tracking-Mechanismen im Einsatz. Die Endpunkte unterscheiden sich, die Request Methoden (POST oder GET) ggf. auch. Ebenso ist die Platzierung von Informationen und deren Umfang sehr unterschiedlich; Parameter heißen anders... aber im Kern könnte man auch andere Systeme über (ggf. sparsame) serverseitige Hits mit Daten versorgen, die durch eine Referenz zu einer Id als Conversion verarbeitet werden können. Diese Referenzen bestehen aus ggf. in einem Cookie eines clientseitig ausgespielten Basiscodes gespeichertem Wert oder einer auf anderem Weg konservierten Click-Id.

Facebook Ads

Bekannt ist das Konzept einer Click Id nicht nur von Google (gclid, dclid). Auch Facebook nutzt eine Click-Id (fbclid, wer kennt sie nicht ;)) und bietet bei der zum Zweck der serverseitigen Anbindung vorhandenen Facebook Conversion API neben anderen Optionen auch diese als Mittel zur Zuordnung der Conversions an. Hat man von FB gesetzte Cookies oder Click-Ids, ist alles, was man im Client an Messpunkten und Events auslösen kann, auch über den Server zu regeln. Wenn man eine ID hat. Möglicherweise kann man auch bei FB auf die API verzichten und mit einfachen serverseitigen Aufrufen inkl. fbclid als Parameter das Ziel einer Conversionmessung erreichen... ich habe es ehrlich gesagt nicht erprobt. Bei Bing aber schon:

Bing Ads / Microsoft Advertising

Anders als Facebook ist man bei Bing Ads (ich behalte den alten Namen hier einfach bei) deutlich sparsamer mit dokumentierten Alternativen zum clientseitigen Tracking. Eine offizielle API gibt es nicht. Wege, die auch ohne Trackingcode funktionieren, sind vorhanden, können aber nur im App-Kontext genutzt werden und hängen von Endpunkten bestimmter Anbieter ab. Alte Trackingcodes wiederum haben andere Endpunkte bedient, die inzwischen verstorben sind (Ehrlich. Ich habe es versucht ;)).

Trotzdem macht der clientseitige UET-Code nicht viel anders als der Trackingcode von Google Ads. Und so lässt sich auch hier a) eine reduzierte URL finden, die serverseitig aufgerufen werden kann und b) ein Weg nutzen, die Click-Id, welche im Parameter msclkid steckt, in diesem Aufruf zu übergeben.

Das lässt sich nutzen, um sowohl Seitenaufrufe als auch Events an Bing Ads zu übertragen. Der Einfachheit halber - und weil es weniger Informationen erfordert - beschränkt sich dieses Beispiel auf Abschlussziele, welche auf einem Event basieren. Denn schließlich sollen wie bei Google Ads nur gezielt bei Auftreten einer Conversion entsprechende Hits versendet werden.

Bei der Anlage eines Abschlussziels, das zum unten stehenden Hit passt, muss ein Eventziel angelegt werden.

Eventabschluss-Ziel

In den Einstellungen zum Erreichen des Ziels kann ein beliebiges Merkmal verwendet werden - oder auch eine Kombination. Der unten gezeigte Aufruf übergibt "conversion" sowohl als Kategorie, Aktion und Label. Auch ein Event-Wert kann angegeben werden, ist aber irrelevant. Um Conversion-Werte zu übertragen, wird ein anderes Feld verwendet. Als sinnvolles Gegenstück im Abschlussziel kann dazu weiter unten ein variabler Abschlusswert konfiguriert werden.

Eventabschluss-Ziel Einstellungen

Der dazu passende Hit sieht wie folgt aus, wenn ein Zielwert von 10,-- Euro übergeben werden soll und die Id des dazu passend angelegten UET Codes 123456789 lautet (als msclkid nehmen wir wie bei der Google Click Id oben den Beispielwert =aaaaa11111bbbbb22222 an):

https://bat.bing.com/action/0?ti=123456789&Ver=2&vids=0&ec=conversion&el=conversion&gv=10&gc=EUR&ea=conversion&en=Y&evt=custom&msclkid=aaaaa11111bbbbb22222

Wird dieser Hit - analog zum Google Ads Beispiel und mit einer ebenso wie die gclid hierfür gespeicherten msclkid - serverseitig abgesendet, sieht man einige Stunden später das erreichte Ziel in Bing Ads. Auf ähnliche Weise sind bei Bedarf Seitenziele zu erreichen. Wer das lieber mag, verwendet den Parameter gv weiterhin für den optionalen Wert des Ziels, ersetzt die Event-Parameter ec, el, ea gegen den mit der vollständigen URL der gewünschten Seite (URL codiert) gefüllten Parameter gv und ändert den Wert für evt von custom auf pageLoad.

Events liefern aber alle Freiheiten, die man auch für ein granulareres Tracking benötigt. Neben dem Wert sind beliebige Kombinationen von Eventkategorie, -aktion und -label nutzbar, um mehr als ein Abschlussziel zu füttern. So sind mit gleichen Mitteln Conversions ebenso gut in Bing Ads wie auch in Google Ads ohne clientseitigen Trackingcode zu erfassen.

Andere (Werbe-) Systeme

Ich bin sicher, dass auch andere Systeme existieren, die eine Identifizierung erlauben, die auf eine bestimmte Aktion wie einen Klick auf ein Werbemittel zurückzuführen sind und mit deren Hilfe man ein serverseitiges Tracking nach diesem Vorbild aufbauen kann. Ich kenne nur keine. Hinweise hierzu sind daher jederzeit willkommen - einfach eine Mail senden!

Brauchen wir immer Cookies?

Gerade diese Frage impliziert den Wunsch nach "völlig unsichtbarem" Tracking. Bevor ich mich an eine technische Antwort wage, erfolgt ein Verweis auf meinen Beitrag zu den Herausforderungen beim Tracking; speziell den Abschnitt "(Technisch) nutzbare Identitätsquellen". Wenngleich diese im Licht von erteilter oder verweigerter Zustimmung betrachtet wurden, gilt die Kernaussage auch hier: Ohne Identifizierungsmerkmal können Hits nicht zugeordnet oder zusammengefasst werden.

Bei der Analytics bedeutet dies, dass aufeinanderfolgende Hits, wie sie durch Browsen auf einer Website entstehen, ohne eine gemeinsame Id (Client-Id, Session-Id, was auch immer) nicht sinnvoll zu Sitzungen gebündelt werden können. Jeder Hit ein neuer User und eine neue Session.

Für die Webanalyse existieren Auswege. Kurzzeit- oder Session-Cookies zum Beispiel. Während diese im Browser immer noch zu sehen sind, ist spätestens bei serverseitigem Fingerprinting nichts mehr von einer für das Tracking genutzten Identität im Client zu bemerken. Fingerprints haben aber je nach Generierung ihre Tücken. Basieren sie auf der IP und dem User-Agent, ist die Auflösung relativ genau, solange die IP nicht gewechselt wird. Dafür umfasst sie aber schon in dieser Fassung ggf. auch andere Besucher, die von der gleichen IP stammen und den gleichen User Agent übertragen. Nicht unmöglich, wenngleich nicht die Regel. Wir die IP anonymisiert (also gekürzt), steigt das Risiko der "Verwechslung" und Zusammenlegung mehrerer Clients zu einer Id. Spätestens wenn der User Agent nicht im Spiel ist, ist der Fingerprint auch noch Cross-Device. Überhaupt teilt er ggf. die Lebensdauer mit der IP-Adresse, wenn nicht entsprechende Maßnahmen getroffen werden, solange nicht Browser verwendet werden, die ihren User Agent zufällig ändern. Das gibt es - von Haus aus oder per Plugin. Genau aus diesem Grund.

Cookielose Analytics-Tools, die sich (zumindest nach eigener Aussage) ohne Consent nutzen lassen, arbeiten zudem i. d. R. mit einem Fingerprint, der regelmäßig wechselt; oft jeden Tag. Damit ist ein Besucher heute noch - während seiner Sitzung - wiedererkennbar, so dass seine Hits zu einer Sitzung zusammengefasst werden können. Eine zweite Sitzung am gleichen Tag würde auch dem gleichen User zugeordnet. Einen Tag später aber entsteht aus gleicher IP und unverändertem User Agent bei der Hash-Erstellung im Fingerprint durch ein täglich wechselndes "Salt" eine neue Id.

Das ist zwar mit entsprechenden Ungenauigkeiten versehen, erlaubt aber dennoch vieles, was Webanalyse ausmacht. Mit den entsprechenden Unschärfen, die IP-Wechsel und sich ggf. ändernde User Agent Informationen des gleichen Browsers mit sich bringen. Nur nicht die Attribution von Erfolg in Form von Zielen oder Transaktionen auf mehrere Kanäle. Allein die Quelle der Sitzung, in der Ziele erreicht werden, ist hierdurch nachvollziehbar; längerfristige Betrachtungen sind so - gewollt - nicht mehr möglich.

Zurück zum Conversion-Tracking. Hilft das hier? Denn auch bei serverseitiger Speicherung der Ids statt im Client brauchen wir ja nach wie vor einen Schlüssel, mit dem man diese Informationen wieder hervorkramen kann, wenn eine Conversion stattfindet.

Serverseitige Speicherung von Click-Ids

Im Fall einer Speicherung in der Session passiert streng genommen genau das: Der Speicherort der Click-Id ist nicht mehr ein Cookie, sondern der Session-State auf dem Server. Der Schlüssel zum Wiederauffinden ist die Session-Id. Diese steht zwar i. d. R. in einem Cookie, aber der dort gespeicherte Wert ist eben nicht die Click-Id des Werbesystems, sondern die der Session. Um cookielos zu arbeiten, muss man nur den Server so konfigurieren, dass kein Session-Cookie erforderlich ist. Fertig. Geil, oder? Nein... leider nicht: an jeder URL, die nun aufgerufen wird, hängt nun eine Session Id. Der Albtraum aller Suchmaschinenoptimierer und auch ansonsten ein unschöner Gruß aus den Neunzigern. Also doch keine Lösung. Die Verbindung zwischen einer irgendwo auf dem Server gespeicherten Click-Id und den Requests, die von einem bestimmten Browser den Server erreichen, muss auf anderem Weg hergestellt werden.

Die theoretische Idee, auf die man nun verfallen mag, ist die serverseitige deduplizierte Speicherung aller Click-Ids aus den unterschiedlichen Systemen, zusammen mit einem Datum und einem serverseitig erstellten Fingerprint. Erreicht ein Besucher nun ein Ziel und ist sein Fingerprint seitdem unverändert, kann man aus seiner Datenbank ggf. vorhandene Click-Ids hervorkramen und serverseitig die Conversions an Google Ads, Bing Ads, Facebook und wen auch immer melden. Keine Cookies im Spiel. Ziel also erreicht? Technisch vermutlich schon. Solange die ganzen damit einhergehenden Probleme gelöst werden, die die Datenmenge, zuverlässige Speicherung. Serverlast und Performance stellen werden, wenn man mehr als ein paar Besucher über Werbesysteme einkauft.

Über Cron Jobs ließen sich diese Daten regelmäßig von Altlasten befreien. Schließlich sollen sich Conversionfenster auch irgendwann schließen. Aber damit sowas funktioniert, müssen leider die Fingerprints relativ genau sein und mindestens so lange leben, wie das Conversionfenster geöffnet sein soll. Das ist etwas ganz anderes, als eine kurzlebige ID zu schaffen, um damit zumindest die Webanalyse am Leben zu erhalten. Dennoch sind solche Konstrukte kein reines Wolkenschloss, sondern ganz sicher in der einen oder anderen Spielart in realen Unternehmen im Einsatz. Beispielsweise zur Bedienung der Facebook Conversion API.

Während dabei die Speicherung einer Click-Id in der Session oder einem kurzlebigen Cookie (wie im Urprungsbeitrag beschrieben) vermutlich unkritisch ist oder sich im Fall eines länger lebenden Cookies auch an Consent binden oder mit entsprechender Argumentation vielleicht sogar als "erforderlich" erklären lässt, sieht das bei einem langlebigen Fingerprint ganz anders aus. Wie schon bei der Webanalyse beschrieben steht und fällt die Fähigkeit zur Attribution mit der Langlebigkeit der Id. Meint: Wer serverseitig Conversions auslösen will, hat sich immer noch im Kontext von Consent zu bewegen oder sollte alles, was er ansonsten dennoch tun will, mit seinem Anwalt, seinem Datenschutzbeauftragten und seinem Gewissen vereinbaren können.

Und so lautet die kurze Antwort auf die Frage nach Conversiontracking ohne Cookies: Technisch ja, wenngleich mit Aufwand verbunden. Aus jeder anderen Perspektive betrachtet ist die Frage weder in diesem Blogpost noch von mir zu beantworten. Wie bei allen anderen Dingen, die Privacy betreffen. Ich hoffe, die Antwort hilft trotzdem weiter. Mir auf jeden Fall, denn die Frage wird mir häufiger gestellt und nun habe ich etwas, worauf ich verweisen kann 😉

Was jetzt? Nutzen oder doch nicht?

Das ist die Frage. Unkritisch wäre es auf jeden Fall, ein Cookie zur Speicherung der Ids zu nutzen, wenn Zustimmung dazu besteht. Oder wenn die ggf. zum Offline Import ohnehin schon bestehenden Mittel zur Speicherung von Click-Ids eingesetzt werden können. Ohne Zustimmung eine kurzzeitige Speicherung im Client vorzunehmen, mag auch in Ordnung sein - ich muss das nicht beurteilen. Ohne Consent eine "heimliche" Speicherung auf dem Server umzusetzen und mit langfristigen Fingerprints zu arbeiten, verspricht aber auf jeden Fall Datenschutzärger im Diesseits und die ewige Hölle im Jenseits. Gar keine Conversions zu messen hingegen könnte das unternehmerische Aus bedeuten. Irgendwo dazwischen liegt also die individuelle Antwort für jeden Unternehmer. Die Position mag vom Impact abhängig sein, den fehlende Messungen haben können. Um die Lücke zu minimieren, kann man auf jeden Fall gut im Rahmen von Zustimmung von clientseitigem Tracking auf ein serverseitiges Tracking umstellen. Damit reduziert man zumindest den wachsenden Einfluss von ITP und anderen Trackingschutzmaßnahmen. Denn ein Szenario ist ebenso realistisch wie ärgerlich: Eine Website ringt Besuchern die Zustimmung zur Werbeerfolgskontrolle ab, aber der Browser stellt sich (wenn auch in guter Absicht) dabei in den Weg. Zumindest dem Problem ist mit serverseitigem Conversiontracking wirkungsvoll zu begegnen.

Hat Dir der Beitrag geholfen?

Dann freue ich mich, wenn Du ihn mit anderen teilst! Wenn Du magst, gib einen aus ;)

© 2001 - 2024 Markus Baersch