Conversion-Tracking und die Issues im Client-Side Bereich

Hast du in den letzten Jahren bemerkt, dass sich deine Conversion-KPIs im Website-Tracking verändert haben? Fragst du dich öfter, ob deine getrackten Daten wirklich die Realität widerspiegeln? Kannst du deinen Return on Ad Spend (ROAS) nicht mehr steigern oder siehst du zu, wie er immer weiter sinkt? Dann könnte das daran liegen, dass du deine Conversion-Daten mit Client-Side-Tracking erhebst. Warum das in Zukunft keine gute Entscheidung mehr ist und welche Lösungsmöglichkeiten es gibt, erfährst du in diesem Artikel.

Wie funktioniert das Conversion-Tracking, nachdem ich das JavaScript in meine Website integriert habe?

Im Allgemeinen kennen wir Conversion-Tracking so: Man geht zu einer Plattform oder einem Service und möchte diesen mit Website-Daten versorgen. Dafür erhält man in der Regel ein JavaScript, das auf allen Seiten der Website eingebunden werden muss. Sobald eine Conversion stattfindet, fügt man zusätzlich ein Conversion-Label oder eine Conversion-ID hinzu, oft auch einen Conversion-Value, was im E-Commerce häufig einer Transaktion oder einem Kauf entspricht.

Grundsätzlich beginnt meine Reise auf einer Website, die mir Werbung anzeigt. Durch den Klick auf eine Anzeige passieren zwei Dinge:

Fall 1:

Der Ad-Service wird darüber informiert, dass ich auf eine Werbung geklickt habe. Mithilfe eines Third-Party-Cookies kann der Klick meinem Benutzerprofil zugeordnet werden (Third-Party-Tracking).

Fall 2:

Ich werde zur Zielwebsite weitergeleitet. Die Ziel-URL enthält in diesem Fall eine Referenz auf die zuvor angeklickte Werbung, die über URL-Parameter übermittelt wird. Jedes Werbenetzwerk verwendet hierfür eigene ‚Click Identifier‘, die eine Referenz auf die angeklickte Werbung enthalten. Google Ads nutzt beispielsweise den URL-Parameter ‚gclid. Zusätzlich werden weitere URL-Parameter hinzugefügt, um mehr Informationen über die angeklickte Werbung zu erhalten, wie z.B. utm_campaign, utm_source, utm_content usw. (First-Party-Tracking).“

Im Fall (2) sprechen wir von First-Party-Tracking, da die Tracking-Daten im Kontext der Website weiterverarbeitet werden müssen. Dafür haben wir unser JavaScript eingebaut. Dieses JavaScript durchsucht auf allen Seiten meiner Website die URL nach dem Click Identifier des Werbenetzwerks. Wenn dieser in der URL gefunden wird, wird er in einem Cookie für eine vordefinierte Zeitspanne gespeichert, meist zwischen 30 und 90 Tagen. Sobald nun eine Conversion auf der Website stattfindet, prüft das JavaScript, ob ein Cookie gesetzt wurde, das den Click Identifier der zuletzt angeklickten Werbung enthält. Anschließend generiert es einen HTTP-Request zum Werbenetzwerk mit dem gespeicherten Click Identifier. Auf diese Weise kann das Werbenetzwerk nachvollziehen, welche Werbung zu welcher Conversion geführt hat, indem es den Click Identifier mit der Conversion auf der Website verknüpft.

Im Fall (1) würde zusätzlich das Third-Party-Tracking versuchen, diese Zuordnung herzustellen. Falls nämlich kein Click Identifier auf der Website vorhanden ist und der Conversion-Stream an das Werbenetzwerk gesendet wird, versucht dieses nun mithilfe des Third-Party-Cookies eine Verbindung zwischen den historischen Aktivitäten des Nutzers und der Conversion herzustellen.

Dies beschreibt in Kürze, wie Conversion-Tracking im Allgemeinen funktioniert.

Die oben beschriebene Welt stellt eine Idealsituation dar und spiegelt keineswegs die Realität wider. Browser haben bereits vor einiger Zeit damit begonnen, Mechanismen zu entwickeln, die das Tracking von Webseiten erschweren sollen. Im Folgenden möchte ich anhand unseres skizzierten Beispiels die damit verbundenen Probleme näher beleuchten.

Third-Party-Cookies und ihr (absehbares) Ende

Eine Möglichkeit des Conversion-Trackings besteht im Setzen von Third-Party-Cookies, wodurch Daten in einem Third-Party-Kontext verknüpft werden können. Bekannte Browser wie Safari, Firefox und Brave blockieren Third-Party-Cookies jedoch standardmäßig seit dem Jahr 2017 (https://webkit.org/). Das bedeutet, dass Conversion-Tracking über Third-Party-Cookies in diesen Browsern nicht mehr möglich ist, was zu einer verminderten Datenqualität führt und die Nutzung von First-Party-Tracking erforderlich macht. Andere Browser wie Chrome und Edge (die auf der Chrome-Engine basieren) blockieren Third-Party-Cookies standardmäßig noch nicht. Google plante ursprünglich, Third-Party-Cookies ebenfalls ab Anfang 2025 standardmäßig zu deaktivieren. Kürzlich hat das Unternehmen jedoch einen Rückzieher gemacht und arbeitet nun an einer Opt-In-Lösung (https://privacysandbox.com/news/privacy-sandbox-update/). Diese Opt-In-Lösung ermöglicht es den Nutzern, sich weiterhin für Third-Party-Cookies zu entscheiden oder die Privacy Sandbox zu wechseln.

Ad-Blocker

Eine weitere Einschränkung im Bereich des Client-Side-Trackings sind Ad-Blocker. Diese sind entweder bereits im Browser integriert oder werden als Erweiterung nachinstalliert. Ad-Blocker basieren auf Blacklists, Whitelists und Regexes und blockieren dadurch bekannte Tracking-Skripte, um das Tracking zu verhindern. Das bedeutet, dass das JavaScript möglicherweise gar nicht erst das Tracking-Skript laden kann oder der Tracking-Stream zum Werbenetzwerk blockiert wird. Laut Statistik haben etwa 40% aller Nutzer einen Ad-Blocker installiert (https://de.statista.com/themen/3068/adblocking/).

Das bedeutet, dass in unseren Conversion-Tracking-Daten eine Ungenauigkeit von mindestens 40% enthalten ist.

ITP/ETP – Cookie Laufzeiten Limitierung

Von Third-Party-Cookies und Third-Party-Tracking haben wir bereits im Fall (1) gehört. Die nächste Einschränkung betrifft den allgemeinen Bereich der „Tracking Prevention“. Im Safari-Browser auf macOS nennt man diese „Intelligent Tracking Prevention“ (ITP), während sie im Mozilla Firefox als „Enhanced Tracking Prevention“ (ETP) bekannt ist. Diese Funktionen sind in den genannten Browsern standardmäßig aktiviert und blockieren Third-Party-Cookies, was unseren Fall (1) vollständig betrifft. Daher konzentrieren wir uns nun auf Fall (2), der mit Browser-eigenen Cookies auf der Zielwebsite arbeitet. Neben dem Blockieren bekannter Tracker zielen die Tracking-Preventions auch darauf ab, die Lebensdauer von gespeicherten Informationen in Cookies oder dem LocalStorage des Browsers zu begrenzen.

Dafür gelten im Allgemeinen folgende Regeln:

• Tracking Preventions reduzieren die Laufzeit von Cookies, die von Drittanbietern gesetzt werden, auf 7 Tage.
• Wenn in der URL spezielle URL-Parameter wie utm_source, click-ids usw. enthalten sind, reduzieren Tracking Preventions die Laufzeit von Cookies, die von Drittanbietern gesetzt werden, auf 24 Stunden.
• Tracking Preventions verkürzen die Laufzeit von Cookies, die von einer First-Party-Domain gesetzt werden, die über einen DNS-CNAME-Eintrag angelegt wurde (CNAME-Cloaking), auf 7 Tage.
• ITP reduziert die Laufzeit von Cookies, die von einer First-Party-Domain gesetzt werden, auf 7 Tage, wenn die IP-Adresse nicht zur Hälfte mit der IP-Adresse übereinstimmt, die den Webseiteninhalt lädt.

Was bedeutet das nun für unseren Fall (2) im Conversion-Tracking?

Zur Erinnerung: Wenn wir auf eine Werbung klicken, wird eine Click-ID an die Ziel-URL angehängt. Die Zielseite benötigt ein JavaScript, das die Click-ID aus der URL ausliest und in einem Cookie speichert, damit wir bei einer Conversion diese der Werbung zuordnen können. Hier kommt die Tracking Prevention mehrfach ins Spiel!

Erstens: Das JavaScript könnte von einem bekannten Tracker stammen und wird möglicherweise von der Tracking Prevention blockiert, sodass es gar nicht erst auf die Website geladen wird. Das bedeutet, dass wir kein Cookie setzen können und somit bei einer Conversion keine Informationen an das Werbenetzwerk übermittelt werden können.

Zweitens: Selbst wenn es uns gelingt, ein Cookie zu setzen, wird die Laufzeit des Cookies drastisch auf 24 Stunden reduziert, da in der URL eine Click-ID vorhanden ist. Das bedeutet, dass wir, wenn innerhalb von 24 Stunden keine Conversion auf der Seite erfolgt, diese nicht mehr dem Werbeklick zuordnen können.

Insgesamt führt dies zu einer schlechteren Datenqualität für unser Werbenetzwerk, was wiederum zu einer weniger effektiven Kampagnensteuerung führt.

Des Weiteren verursachen Tracking-Preventions ein weiteres großes Problem: Sie beeinträchtigen die User-Erkennung. Solange ein Nutzer nicht eingeloggt ist, werden User auf der Website über Cookies wiedererkannt. Wenn jedoch diese User-Cookies nach maximal 7 Tagen gelöscht werden, werden wiederkehrende Besucher für unser Tracking automatisch als neue Besucher erfasst. Dies kann dazu führen, dass Attribuierungen fehlerhaft sind, da wir nicht mehr die gesamte Customer Journey nachvollziehen können und somit nicht mehr genau wissen, welche Touchpoints auf der Reise eines Users letztlich zu einem Kauf geführt haben.

Das wiederum kann dazu führen, dass Budgets im Kampagnen-Bereich möglicherweise nicht mehr korrekt verteilt werden und der ROAS (Return on Ad Spend) nicht gesteigert werden kann, insbesondere bei Single-Session-Käufen.

Positiver Consent

Zuletzt ist das Thema Consent ein ebenfalls wichtiges Kriterium, wenn es um die Datenverfügbarkeit im Conversion-Tracking geht. Ohne eine ausdrückliche Zustimmung des Nutzers für den Vendor des Werbenetzwerks sollten keine Daten an das Werbenetzwerk übermittelt werden. Um dieses Problem zu umgehen, haben Anbieter wie Google den (Advanced) Consent Mode eingeführt (https://support.google.com/google-ads/answer/10000067?hl=en), der es ermöglicht, auch bei negativem Consent Daten zu tracken.

Es ist jedoch unbedingt ratsam, in diesem Zusammenhang die Rechtsabteilung zu konsultieren, um eine rechtlich abgesicherte Bestätigung zu erhalten, dass diese Vorgehensweise zulässig ist. Gerade im Client-Side-Tracking ist dieses Thema besonders heikel, da im HTTP-Stream häufig personenbezogene Daten enthalten sind, was die Einhaltung der Datenschutzvorschriften erschwert.

Fazit Conversion-Tracking

Anhand eines einfachen Beispiels im Conversion-Tracking sehen wir, wie schwierig es sein kann, eine gute Datenqualität und Datengenauigkeit zu erzielen. Auf einschlägigen Websites findet man die Information, dass nur noch etwa 30% der erfassten Daten tatsächlich aktivierbar sind. Der Rest geht aufgrund der oben genannten Restriktionen verloren. Das führt dazu, dass Attribuierungen fehlerhaft sind, zu viele Nutzer getrackt werden und einzelne Conversions nicht mehr korrekt einer Kampagne zugeordnet werden können.

Durch falsche Budgetverteilungen kann es zusätzlich dazu kommen, dass statt mehr Conversions eventuell weniger gemessen werden und der ROAS (Return on Ad Spend) dadurch einbricht. Die fehlenden Conversions fallen besonders dann auf, wenn man die Tracking-Daten mit dem Warenwirtschaftssystem vergleicht, das im E-Commerce-Bereich 100% der Transaktionen erfassen sollte. Erst durch diesen Vergleich wird einem das Ausmaß der bereits stark eingeschränkten Datengenauigkeit bewusst.

War es das mit dem Conversion-Tracking?

Natürlich nicht! 😉 Es gibt bereits eine Lösung auf dem Markt: Server-Side-Tracking. Server-Side-Tracking verlagert das Speichern des Click-ID-Parameters auf den Server und ist somit nicht von Tracking-Preventions betroffen. Bei einer Conversion wird die entsprechende Information von einem Server-Side-Tracking-Server an das Werbenetzwerk gesendet. Dadurch wird sichergestellt, dass Ad-Blocker den HTTP-Stream nicht blockieren können, da dieser von einem Server und nicht direkt von der Website an das Werbenetzwerk übermittelt wird. Das bedeutet, dass Server-Side-Tracking bereits eine Lösung bietet, um wieder zu einer besseren Datenqualität und Datengenauigkeit zu gelangen.