Customer-Journey-Tracking über Kanäle hinweg

Worum es geht

Eine Customer Journey ist die Abfolge aller Berührungspunkte, die ein Mensch mit deinen Marketing-Kanälen hat, bis er kauft. Jemand sieht eine Anzeige, klickt sie Tage später nicht weiter an, stolpert über einen Preisvergleich, liest eine Bewertung und sucht am Ende gezielt nach deinem Shop. Aus deiner Sicht ist das eine Bestellung. Aus Mess-Sicht ist es eine Kette aus mehreren Stationen, von denen jede einen Anteil am Abschluss hatte.

Customer-Journey-Tracking ist die technische Aufgabe, diese Kette so zu erfassen, dass sich ihre einzelnen Glieder derselben Person zuordnen lassen. Ohne diese Erfassung gibt es keine Attribution. Ein Attributionsmodell verteilt Umsatz auf Touchpoints, aber nur auf die, die es kennt. Fehlt ein Touchpoint in den Daten, kann ihm kein Modell einen Beitrag zuschreiben, egal wie ausgefeilt es rechnet. Die Reihenfolge ist deshalb klar: erst die Journey sauber erfassen, dann attribuieren.

Genau hier scheitern viele Setups, ohne dass es im Reporting auffällt. Eine Plattform zeigt brav ihre Zahlen, aber sie sieht nur den Ausschnitt der Journey, der durch ihren eigenen Kanal lief. Was davor und danach über andere Kanäle passierte, bleibt unsichtbar. Erst eine kanalübergreifende Erfassung macht die ganze Kette sichtbar und damit den Unterschied zwischen Last-Click und Multi-Touch überhaupt messbar.

Zurück zum Überblick: Multi-Touch Attribution, der vollständige Leitfaden.

Was ein Touchpoint ist und wie er markiert wird

Ein Touchpoint ist ein einzelner, erfassbarer Kontakt zwischen Nutzer und Kanal, der zu einem Besuch auf deiner Seite führt. Der Klick auf eine Meta-Anzeige ist ein Touchpoint, der Besuch über einen Affiliate-Gutschein ist einer, die Marken-Suche am Ende ist einer. Damit aus einem Besuch ein attribuierbarer Touchpoint wird, muss beim Eintreffen klar sein, woher er kam. Diese Herkunft trägt der Besuch in der URL mit sich, und dafür gibt es zwei Mechanismen.

Click-IDs für bezahlte Klicks

Bei Klicks auf bezahlte Anzeigen hängt die Plattform automatisch eine Click-ID an die Ziel-URL. Google nutzt gclid, Meta nutzt fbclid, Microsoft msclkid, und auch andere Netzwerke haben ihr eigenes Pendant. Diese ID identifiziert den konkreten Klick und lässt sich später wieder mit der Plattform abgleichen, um Kampagne, Anzeigengruppe und teils Keyword aufzulösen. Die Click-ID ist damit die präziseste Form der Touchpoint-Markierung, weil sie nicht von Hand gesetzt wird, sondern von der Plattform selbst stammt.

UTM-Parameter für alles andere

Wo keine Plattform automatisch markiert, etwa bei Newslettern, organischen Posts, Kooperationen oder Affiliate-Links, übernehmen UTM-Parameter die Herkunft. Sie hängen als lesbare Felder an der URL und benennen Quelle, Medium und Kampagne, also etwa utm_source, utm_medium und utm_campaign. Der Vorteil ist, dass du sie selbst vergibst und damit volle Kontrolle über die Benennung hast. Der Nachteil ist genau derselbe: Werden sie uneinheitlich oder gar nicht gesetzt, landet der Touchpoint in der falschen Schublade oder fällt durch. Eine konsistente UTM-Konvention über alle Kanäle ist deshalb die Grundlage jeder belastbaren Journey-Erfassung.

Beim ersten Seitenaufruf liest das Tracking diese Marker aus der URL aus und legt sie zusammen mit Zeitstempel und Visitor-ID ab. Aus dem rohen Besuch wird so ein Datenpunkt, der weiß, von welchem Kanal er kam und zu welchem Nutzer er gehört. Diese beiden Informationen sind das Minimum, das ein Attributionsmodell später braucht.

Im Glossar: Touchpoint, Click-ID, UTM-Parameter, Customer Journey.

Technische Erfassung über Kanäle

Einzelne Touchpoints zu markieren reicht nicht. Die eigentliche Leistung des Journey-Trackings ist, mehrere Besuche derselben Person über Tage und Kanäle hinweg als eine zusammenhängende Kette zu erkennen. Dafür braucht es drei Bausteine, die zusammenspielen.

• First-Party-Cookie: Beim ersten Besuch wird unter deiner eigenen Domain ein Cookie gesetzt, das eine Kennung speichert. Weil es First-Party ist, also von deiner Domain stammt und nicht quer über fremde Domains liest, akzeptieren Browser es deutlich länger als ein Third-Party-Cookie. Es ist der Anker, an dem die Journey über mehrere Besuche hängt.
• Visitor-ID-Persistenz: In dem Cookie steckt eine Visitor-ID, eine zufällige Kennung, die denselben Browser über mehrere Sessions wiedererkennt. Kommt der Nutzer nach drei Tagen erneut, liest das Tracking dieselbe ID und hängt den neuen Touchpoint an die bestehende Journey an, statt eine zweite, getrennte Journey zu beginnen. Die Persistenz dieser ID entscheidet darüber, wie lang eine Journey überhaupt zusammengehalten werden kann.
• Click-ID-Propagation: Die beim Klick empfangene Click-ID muss nicht nur erfasst, sondern bis zur Conversion durchgereicht werden. Beim Kauf wird sie zusammen mit dem Bestellwert wieder an die Plattform zurückgespielt, klassisch über die Conversion-API. So schließt sich der Kreis: Die Plattform erfährt, dass aus genau diesem Klick ein Umsatz wurde, und der Touchpoint bekommt seinen Beitrag zugeordnet.

Zusammen ergeben diese drei Bausteine eine Journey, die nicht an der Grenze eines einzelnen Besuchs oder eines einzelnen Kanals endet. Der erste Kontakt über eine Anzeige, der zweite über einen Vergleich und die abschließende Bestellung tragen alle dieselbe Visitor-ID und lassen sich dadurch als eine Kette lesen. Genau diese Kette ist es, die ein Multi-Touch-Modell anschließend bewertet.

Wichtig ist, dass die Erfassung kanalübergreifend an einer Stelle zusammenläuft. Wenn jede Plattform nur ihre eigenen Touchpoints in ihrem eigenen Konto sammelt, hast du am Ende mehrere Teil-Journeys, die einander überlappen und doppelt zählen. Eine zentrale Schicht, die alle Touchpoints einer Visitor-ID zusammenführt und Dubletten bereinigt, ist die Voraussetzung dafür, dass die Journey sauber und ohne Doppelzählung steht.

Die zentrale Schicht in der Praxis: Multi-Channel Attribution. Im Glossar: Cross-Channel-Attribution, Conversion-API.

Wo Journeys abreißen

In der Theorie hält die Visitor-ID die Journey beliebig lange zusammen. In der Praxis reißen Journeys regelmäßig ab, und an drei Stellen besonders zuverlässig. Wer Journey-Tracking baut, sollte diese Bruchstellen kennen, weil sie bestimmen, wie viel von der echten Journey überhaupt im Datensatz ankommt.

ITP und iOS-Restriktionen

Safari kürzt mit seiner Intelligent Tracking Prevention die Lebensdauer client-seitig gesetzter Cookies drastisch, in vielen Fällen auf wenige Tage. Auf dem iPhone wirkt das zusätzlich über die systemweite Tracking-Prevention. Die Folge: Eine Visitor-ID, die per JavaScript im Browser gesetzt wurde, kann nach kurzer Zeit verloren sein. Kommt der Nutzer danach erneut, gilt er als neu, und seine vorherigen Touchpoints fallen aus der Journey heraus. Gerade lange Journeys, die sich über eine Woche oder mehr ziehen, verlieren so ihren Anfang.

Fehlender Consent

Ohne Einwilligung darf ein großer Teil der Touchpoints gar nicht erst erfasst werden. Lehnt ein Nutzer ab oder reagiert er nicht auf das Consent-Banner, fehlen seine Berührungspunkte im Tracking vollständig. Besonders trifft das die frühen, awareness-nahen Touchpoints, weil Nutzer früh in der Journey seltener bereits eingewilligt haben. Das schneidet ausgerechnet den Anfang der Kette ab, also den Teil, den Multi-Touch eigentlich sichtbar machen soll.

Cross-Device

Die Visitor-ID hängt am Browser, nicht am Menschen. Sieht jemand die Anzeige abends am Handy und kauft zwei Tage später am Desktop, sind das aus Sicht des Trackings zwei verschiedene Geräte mit zwei verschiedenen IDs. Ohne ein verbindendes Element, etwa einen Login, der auf beiden Geräten genutzt wird, lassen sich die beiden Hälften der Journey nicht zuverlässig zusammenführen. Der Geräte-Wechsel zerschneidet die Kette genau in der Mitte.

Diese drei Bruchstellen wirken nicht einzeln, sondern addieren sich. Eine reale Journey, die über mehrere Tage, mehrere Kanäle und zwei Geräte läuft und teils ohne Consent stattfindet, kommt im Tracking oft nur als Fragment an. Das ist kein Grund, Journey-Tracking aufzugeben, sondern der Grund, es robust zu bauen.

Die Browser-Restriktionen im Detail: iOS-Tracking-Restriktionen. Das Consent-Fundament: DSGVO-konformes Tracking.

Was die Daten zeigen

Dass Journeys mehrstufig sind und im Tracking Löcher haben, ist keine Behauptung, sondern zeigt sich in den Daten. In unseren Website-Audits sehen wir bei den geprüften Shops drei Muster immer wieder, und sie hängen direkt mit allem zusammen, was in den vorherigen Abschnitten beschrieben wurde.

Erstens: Im Schnitt liegen mehrere Touchpoints zwischen erstem Kontakt und Bestellung. Der einstufige Kauf, bei dem jemand klickt und sofort kauft, ist die Ausnahme, nicht die Regel. Schon das genügt, um Last-Click als alleinige Steuerungsgröße zu disqualifizieren, denn ein Modell, das nur den letzten Schritt zählt, ignoriert die Mehrheit der Stationen.

Zweitens: Die Mehrheit der Bestellungen ist Mehr-Channel. Sie entstehen über mehr als einen Kanal, nicht über einen einzigen. Klar über der Hälfte der Bestellungen berührt unterwegs mehrere Kanäle, was bedeutet, dass die kanalübergreifende Erfassung aus dem dritten Abschnitt kein Nice-to-have ist, sondern den Normalfall abbildet. Wer nur kanalweise misst, sieht für die Mehrheit seiner Bestellungen nur einen Ausschnitt.

Drittens, und das ist die unangenehme Kehrseite: Ein erheblicher Teil der Bestellungen, oft über ein Drittel, bleibt ohne sauber erkannten Channel. Das sind die Journeys, die an den Bruchstellen aus dem vierten Abschnitt zerfallen sind, durch ITP, fehlenden Consent oder den Geräte-Wechsel. Diese Bestellungen lassen sich keinem Touchpoint zuordnen, weil die Daten dahinter schlicht fehlen. Genau diese Lücke ist der Hebel: Je besser die Journey-Erfassung, desto kleiner der unzuordenbare Anteil und desto belastbarer jede Attribution darüber.

Die drei Muster ergeben zusammen ein klares Bild. Journeys sind lang und kanalübergreifend, und ein großer Teil von ihnen geht im Tracking teilweise verloren. Beide Befunde zeigen in dieselbe Richtung: Die Qualität deiner Attribution beginnt nicht beim Modell, sondern bei der Erfassung der Journey.

Den unzuordenbaren Anteil im eigenen Shop messen: kostenloses Website-Audit. Was Last-Click an diesen Journeys verzerrt: Last-Click vs. Multi-Touch.

Server-Side als Stabilisator

Die meisten Bruchstellen aus dem vierten Abschnitt entstehen client-seitig, also im Browser. Genau dort setzt Server-Side-Tracking an. Statt die Visitor-ID und die Touchpoint-Daten allein per JavaScript im Browser zu verarbeiten, läuft die Erfassung über deinen eigenen Server. Das ändert nichts daran, welche Daten du erfassen darfst, aber es ändert, wie lange und wie zuverlässig die erlaubten Daten überleben.

Der wichtigste Effekt betrifft die Visitor-ID-Persistenz. Ein Cookie, das vom Server gesetzt wird, fällt nicht unter dieselben aggressiven Kürzungen, die Browser auf client-seitig per JavaScript gesetzte Cookies anwenden. Die Visitor-ID hält dadurch länger, und damit halten auch die Journeys länger, die an ihr hängen. Gerade die langen, mehrstufigen Journeys, die client-seitig ihren Anfang verlieren, bleiben serverseitig eher vollständig.

Der zweite Effekt betrifft die Click-ID-Propagation. Wird die Click-ID serverseitig gespeichert und beim Kauf über die Conversion-API direkt vom Server an die Plattform zurückgespielt, ist dieser Weg robuster als ein reiner Browser-Pixel, der durch Adblocker, Skript-Fehler oder vorzeitiges Schließen des Tabs ausfallen kann. Mehr Conversions erreichen die Plattform, und mehr Touchpoints bekommen ihren Beitrag zugeordnet.

Zu betonen ist, was Server-Side nicht ist. Es ist kein Trick, um Consent zu umgehen, und es erfasst keine Daten, für die keine Einwilligung vorliegt. Es stabilisiert ausschließlich die Erfassung der Daten, die du ohnehin erheben darfst, indem es sie den client-seitigen Restriktionen entzieht. In Kombination mit sauberem Consent und Consent Mode v2 ist es der Baustein, der die Journey-Erfassung von lückenhaft zu belastbar bringt.

Server-Side im Produkt: Server-Side Tracking in DataFirst Track. Die technische Umsetzung: Server-Side GTM erklärt. Im Glossar: Server-Side Tracking.