Nutzer über mehrere Domains und Subdomains tracken, ohne die Attribution zu verlieren

Wenn ein einzelner Nutzer von deiner Unternehmensseite über ein Login-Portal in eine Produkt-App auf unterschiedlichen Domains wechselt, macht das übliche Analytics-Setup unbemerkt aus dieser einen Person drei getrennte Besucher – und die ursprüngliche Kampagne, die ihn gebracht hat, verliert die Conversion. Domainübergreifendes Tracking ist die Praxis, einen Nutzer über diese Grenzen hinweg als eine durchgängige Journey zu behalten – mit First-Party-Cookies, einer Referral-Ausschlussliste und einem Linker, der die Identität von Domain zu Domain trägt. Die praktische Schlussfolgerung: Es ist machbar, aber nur, wenn du alle drei Mechanismen bewusst konfigurierst und laufend prüfst, denn ein Setup, das an Tag eins korrekt aussieht, kann mit der nächsten Website-Änderung still zusammenbrechen.

Warum Sessions und Attribution an Domain-Grenzen abbrechen

Größere Organisationen leben selten auf einer einzigen Domain. Eine typische Journey startet vielleicht auf der Corporate-Marketing-Seite, wechselt in ein separates Login-Portal, läuft weiter in eine Produkt-Web-App auf eigener Domain und führt gelegentlich über eine Kampagnen-Microsite, die für einen bestimmten Launch eingekauft wurde. Jede davon ist oft eine eigene registrierbare Domain, teils im Besitz unterschiedlicher interner Teams oder Dienstleister.

Das Problem ist strukturell und kein Fehler in einem einzelnen Tool. Die Analytics-Identität steckt in einem Browser-Cookie, und Cookies gelten nur für die Domain, die sie gesetzt hat. Ein Cookie, das auf corporate.com geschrieben wurde, kann auf product-app.com nicht gelesen werden – der Browser behandelt sie als unabhängige Origins. Überschreitet der Nutzer also diese Grenze, findet die Analytics-Bibliothek auf der neuen Domain keinen bestehenden Identifier, erzeugt einen frischen und startet eine neue Session.

In diesem Moment brechen zwei Dinge. Erstens die Session-Kontinuität: Aus einer Person werden zwei Besucher, was deine Nutzerzahl aufbläht und das durchschnittliche Engagement pro Nutzer halbiert. Zweitens, und schädlicher, die Attribution. Die neue Domain sieht als Referrer deine vorherige Domain, sodass der Besuch diesem internen Referral gutgeschrieben wird statt der bezahlten Kampagne, der organischen Suche oder der E-Mail, die den Nutzer ursprünglich gebracht hat. Die Conversion, die in der Produkt-App passiert, wird deiner eigenen Website zugerechnet und nicht dem Kanal, der sie verdient hat.

Cookies, Referral-Ausschluss und Linker: wie sie sich wirklich verhalten

Zuverlässiges domainübergreifendes Tracking ruht auf drei Mechanismen. Zu verstehen, was jeder davon tatsächlich tut – und was nicht –, unterscheidet ein Setup, das hält, von einem, das funktionieren scheint und still Daten verliert.

First-Party-Cookies und ihr Domain-Scope

Ein First-Party-Cookie ist eines, das von der aktuell besuchten Domain gesetzt wird – im Gegensatz zu einem Third-Party-Cookie, das eine externe, in die Seite eingebettete Domain setzt. First-Party-Cookies sind die tragfähige Grundlage für Analytics, weil Browser Third-Party-Cookies zunehmend einschränken und die Lebensdauer per Skript gesetzter Cookies verkürzen; Safaris Intelligent Tracking Prevention und Chromes sich wandelnde Cookie-Richtlinien sind hier die relevanten Randbedingungen. Die wichtige Einschränkung für unseren Zweck ist der Scope: Ein First-Party-Cookie gehört zu genau einer registrierbaren Domain und kann nicht mit einer anderen Domain geteilt werden – egal, wem beide gehören.

• Was das in der Praxis bedeutet: der Identifier ist überall auf einer Domain und ihren Subdomains verfügbar, endet aber schlagartig am Rand dieser Domain.
• Warum das wichtig ist: du kannst nicht einfach ein Cookie setzen und erwarten, dass es dem Nutzer über Domains hinweg folgt – der Wert muss aktiv mitgetragen werden.

Die Referral-Ausschlussliste

Eine Referral-Ausschlussliste sagt deinem Analytics, Traffic aus bestimmten Domains nicht als neue Quelle zu behandeln. Ohne sie erfasst das Tool, wenn ein Nutzer von corporate.com auf product-app.com landet, corporate.com als Referrer und startet typischerweise eine neue Session, die diesem Referral zugerechnet wird. Trägst du alle deine eigenen Domains in die Referral-Ausschlussliste ein, verhinderst du das: Interne Übergänge setzen die Kampagnenquelle nicht mehr zurück, und der ursprüngliche Akquisekanal bleibt erhalten. In Google Analytics wird das in den Datenerfassungs-Einstellungen der Property konfiguriert; wirf einen Blick in die Analytics-Dokumentation zum Verwalten von domainübergreifender Messung und Referral-Ausschlüssen.

Der Linker-Parameter

Der Linker ist der Mechanismus, der die Identität physisch über die Grenze bewegt. Klickt ein Nutzer auf einen Link von einer deiner Domains zu einer anderen, hängt der Linker den aktuellen Identifier (und Session-Informationen) als Parameter an die Ziel-URL an. Die empfangende Domain liest diesen Parameter und übernimmt den Identifier, statt einen neuen zu erzeugen – so wird derselbe Nutzer als eine durchgängige Journey erkannt. Deshalb siehst du beim Wechsel zwischen den Seiten einer Organisation manchmal einen langen Parameter wie einen Linker-Wert an URLs angehängt – dieser String ist die Identität, die übergeben wird.

Linker haben reale Schwachstellen, die man benennen sollte: Sie funktionieren nur bei Links, die die Analytics-Bibliothek dekorieren kann. Hart codierte Links, serverseitige Redirects und nach dem Laden der Seite erzeugte Links können den Parameter entfernen. Ein Redirect, der Query-Strings verwirft, kappt die Übergabe still, selbst wenn alles korrekt konfiguriert ist.

Subdomain-Tracking vs. domainübergreifendes Tracking

Diese beiden Probleme werden häufig vermischt, unterscheiden sich aber tatsächlich im Schwierigkeitsgrad – und sie gleich zu behandeln, ist eine verbreitete Quelle vergeudeter Mühe.

• Subdomain-Tracking deckt Bewegung innerhalb einer registrierbaren Domain ab – etwa von www.example.com zu shop.example.com zu app.example.com. Weil diese dieselbe übergeordnete Domain teilen, ist ein auf .example.com gescoptes Cookie über alle hinweg lesbar. In den meisten modernen Setups funktioniert das ohne Linker; die Identität bleibt einfach bestehen. Das Entscheidende ist, das Cookie auf Ebene der übergeordneten Domain zu setzen statt auf einem einzelnen Host.
• Domainübergreifendes Tracking deckt Bewegung zwischen getrennten registrierbaren Domains ab – example.com zu example-app.com zu example-login.io. Diese teilen unter keiner Konfiguration Cookies, deshalb musst du eine Referral-Ausschlussliste mit einem aktiven Linker kombinieren. Das ist der schwierigere Fall und der, in dem die Attribution am häufigsten leckt.

Ein nützlicher Test: Teilen zwei Hostnamen dieselbe registrierbare Domain (der Teil, den du tatsächlich registriert hast, plus sein Public Suffix), ist es ein Subdomain-Fall. Tun sie das nicht, ist es ein domainübergreifender Fall und braucht den vollen Mechanismus. Login-Portale, Checkout-Anbieter und Produkt-Apps auf eigenen Domains sind fast immer domainübergreifend, auch wenn sie wie Teil derselben Marke aussehen.

Checkliste für Einrichtung und Prüfung

Die Einrichtung selbst ist eine endliche Liste von Schritten. Die Disziplin liegt darin, jeden Übergang an einer echten Journey zu prüfen und nach jeder Änderung an deinen Seiten erneut zu kontrollieren.

Schritte zur Einrichtung

1. Inventarisiere jede Domain und Subdomain in der Journey. Liste alle registrierbaren Domains und Hosts auf, die ein Nutzer durchlaufen kann, inklusive Login-Portalen, Checkout, Help-Centern und Kampagnen-Microsites. Du kannst nicht konfigurieren, was du nicht erfasst hast.
2. Gruppiere sie in domainübergreifende und Subdomain-Beziehungen. Entscheide für jedes Paar, ob ein gemeinsames Cookie sie bereits überspannt (Subdomain) oder ob ein Linker nötig ist (domainübergreifend).
3. Scope First-Party-Cookies auf Ebene der übergeordneten Domain, damit Subdomain-Bewegung automatisch abgedeckt ist.
4. Trage jede einzelne deiner eigenen Domains in die Referral-Ausschlussliste ein, damit interne Übergänge die Traffic-Quelle nicht zurücksetzen.
5. Aktiviere den Linker für alle domainübergreifenden Übergänge und liste die Ziel-Domains, die den Identifier empfangen sollen, explizit auf.
6. Prüfe Redirects und ausgehende Links. Stelle sicher, dass Redirects Query-Parameter erhalten und dass Links zwischen Domains solche sind, die die Analytics-Bibliothek zum Klickzeitpunkt dekorieren kann.
7. Berücksichtige Consent. Blockiert ein Consent-Banner die Analytics-Bibliothek bis zur Zustimmung, feuert der Linker beim ersten Klick möglicherweise nicht. Entscheide, wie das mit deinem Consent-Design zusammenspielt, und dokumentiere es.

Schritte zur Prüfung

1. Geh jeden Übergang selbst durch. Wechsle als echter Nutzer von Domain A zu Domain B und prüfe die Ziel-URL auf den Linker-Parameter. Fehlt er, ist die Übergabe an diesem Link gescheitert.
2. Bestätige, dass der Identifier bestehen bleibt. Prüfe, dass der Nutzer- oder Client-Identifier auf Domain B mit dem von Domain A übereinstimmt und nicht frisch erzeugt wurde.
3. Bestätige, dass Session und Quelle nicht zurückgesetzt werden. Die ursprüngliche Kampagnenquelle sollte nach dem Sprung noch angehängt sein, und du solltest keinen Ausschlag von internem Referral-Traffic sehen.
4. Prüfe die Rück- und Mehrsprung-Pfade. Journeys sind selten linear. Teste A zu B zu C und B zurück zu A, denn ein in eine Richtung konfigurierter Linker ist womöglich in der anderen nicht konfiguriert.
5. Prüfe nach jeder Website-Änderung erneut. Neue Microsites, Redesigns, geänderte Redirects und Consent-Updates sind die üblichen Ursachen für Regressionen. Behandle domainübergreifendes Tracking als etwas, das man überwacht, nicht einmal einrichtet.

Wie datataste dabei hilft, einen Nutzer als eine Journey zu behalten

Domainübergreifendes Tracking ist ein Konfigurationsproblem mit einem angehängten Monitoring-Problem. Die Konfiguration erledigst du einmal; beim Monitoring verlieren die meisten Teams an Boden, denn ein Linker, der nach einem Redesign nicht mehr feuert, erzeugt keinen Fehler – nur ein langsames Attributionsleck. Genau diesen Teil adressiert datataste.

• Kontinuierliches Data-Quality-Monitoring. datataste überwacht deine Tracking-Datenqualität laufend und macht Probleme wie kaputte oder fehlende Events sichtbar, statt still falsche Zahlen zu melden. In einer Multi-Domain-Landschaft heißt das: Ein kaputter Übergang oder ein plötzlich fehlendes Conversion-Event kann als markiertes Problem auftauchen, statt erst Monate später bei einem Attributions-Review entdeckt zu werden.
• Automatische Event-Erkennung. datataste erkennt aussagekräftige Website-Events automatisch – Klicks, Formularabsendungen, Conversions – mithilfe eines Replay-basierten Event-Mappers, ohne dass du für jedes Element manuell Tags einrichten musst. Über mehrere Domains und Teams hinweg reduziert das die Zahl der Stellen, an denen ein handgebautes Tag auf einer neuen Seite vergessen oder falsch konfiguriert werden kann.
• Server-seitige, First-Party-Erfassung. datataste unterstützt Server-side Tracking auf First-Party-Basis, mit optionaler Weiterleitung von Events an GA4 und Meta vom Server aus. Die First-Party-Erfassung passt zu den oben beschriebenen Cookie-Scope-Realitäten, und die serverseitige Weiterleitung gibt dir einen konsistenten Erfassungspunkt, während du Daten weiterhin an die Ziele sendest, die deine Teams bereits nutzen.

Zur Klarheit über den Umfang: Diese Funktionen helfen dir, Brüche zu erkennen und zu diagnostizieren und den manuellen Tagging-Aufwand über ein Multi-Domain-Setup hinweg zu reduzieren. Sie nehmen dir nicht die Notwendigkeit, deine domainübergreifende Konfiguration bewusst zu gestalten – die Referral-Ausschlüsse, die Linker-Abdeckung und das Cookie-Scoping müssen für deine konkrete Landschaft weiterhin korrekt eingerichtet sein. Mehr dazu findest du auf der Features-Seite und in der Dokumentation.

Fazit

Domainübergreifendes Tracking scheitert standardmäßig leise, weil Cookies an Domain-Grenzen enden und Analytics jede Domain als Neuanfang behandelt. Einen Nutzer als eine Journey zu behalten, ist nicht exotisch – es ist die disziplinierte Kombination aus First-Party-Cookies, die auf die übergeordnete Domain gescopt sind, einer vollständigen Referral-Ausschlussliste und einem Linker, der wirklich jeden domainübergreifenden Link erreicht, geprüft an echten Journeys und erneut kontrolliert, sobald sich die Seiten ändern. Eine Multi-Domain-Analyse, der du vertraust, entsteht, wenn du dies als fortlaufende Qualitätspraxis behandelst statt als einmaligen Schalter. Weil diese Mechanismen Cookies, Consent und personenbezogene Daten berühren, zieh eine Datenschutzexpertin oder einen Datenschutzexperten hinzu, wenn du gestaltest, wie Identität über deine Domains getragen wird.

Häufige Fragen

Brauche ich für Subdomains einen Linker?

Meist nicht. Teilen zwei Hosts dieselbe registrierbare Domain, ist ein auf die übergeordnete Domain gescoptes First-Party-Cookie über alle hinweg lesbar, sodass die Identität ohne Linker bestehen bleibt. Ein Linker ist bei getrennten registrierbaren Domains nötig, die niemals Cookies teilen.

Warum zeigt meine Produkt-App meine eigene Website als Traffic-Quelle?

Das ist das klassische Symptom eines fehlenden Referral-Ausschlusses. Wechselt ein Nutzer von deiner Marketing-Seite in deine App auf einer anderen Domain, erfasst die App deine Seite als Referrer und startet eine neue, diesem Referral zugerechnete Session. Alle deine eigenen Domains in die Referral-Ausschlussliste einzutragen – zusammen mit einem funktionierenden Linker, der den Identifier trägt – löst das.

Macht Server-side Tracking die domainübergreifende Konfiguration überflüssig?

Nein. Die Erfassung auf den Server zu verlagern ändert, wo Events verarbeitet werden, aber der Browser speichert die Identität weiterhin in domaingebundenen Cookies, und die Identität muss weiterhin über Domain-Grenzen getragen werden. Du brauchst weiterhin Referral-Ausschlüsse und einen Linker; die serverseitige Erfassung ergänzt sie, ersetzt sie aber nicht.

Was bricht ein funktionierendes domainübergreifendes Setup am häufigsten?

Redirects, die Query-Parameter entfernen, nach der Konfiguration hinzugefügte Links, die die Analytics-Bibliothek nicht dekoriert, neue Kampagnen-Microsites, die nie in die Referral-Ausschlussliste aufgenommen wurden, Consent-Banner, die die Analytics-Bibliothek beim ersten Klick verzögern, und Browser-Änderungen beim Umgang mit Cookies. Deshalb zählt die laufende Prüfung mehr als die anfängliche Einrichtung.