Eine Journey, mehrere Domains. Ohne Verknüpfung klaut der Payment-Anbieter den Sale.
Kampagnen-Klick auf deiner Shop-Domain, Bezahlung auf der Domain des Payment-Anbieters, zurück auf die Danke-Seite. Weil ein Cookie nur für eine Domain gilt, startet bei jedem Wechsel eine neue Session, und Last-Klick verbucht den Kauf als Self-Referral auf den Payment-Anbieter oder auf Direct. Wir tragen einen First-Party-Schlüssel über deine eigenen Domains, schließen fremde Referrer aus, consent-first, sodass die Journey eine bleibt und die echte Quelle den Sale behält.
Verknüpfen heißt einen First-Party-Schlüssel über deine Domains tragen, nicht Referrer raten.
Ein stabiler journey_key wird beim Domain-Wechsel als Linker mitgegeben und server-seitig aufgelöst. DataFirst hält die Journey über die Domain-Grenze zusammen und schließt den Payment-Anbieter als Quelle aus, deterministisch, ohne Fingerprinting.
Domains festlegen
Die eigenen Domains als vertrauenswürdig bestimmen: Shop, Landingpage, Länder-Domains. Der externe Checkout oder Payment-Anbieter kommt auf die Referral-Exclusion, nicht in die Verknüpfung.
Schlüssel über die Grenze tragen
Der journey_key geht beim Domain-Wechsel als Linker in die URL und wird server-seitig gegen die Session aufgelöst. Nur First-Party über deine Domains, kein probabilistisches Referrer-Raten.
Ausschließen und Dry-Run
Payment- und Checkout-Domains werden als Quelle ausgeschlossen, die echte Kampagne behält den Sale. Der Dry-Run zeigt, wie die Domain-Sprünge zu einer Journey werden, bevor das live einfließt.
Einen Linker zu setzen klingt simpel. Sauber wird das Setup erst an den Stellen, an denen die meisten Cross-Domain-Ansätze entweder abreißen oder die falsche Quelle belohnen.
- First-Party-Schlüssel statt Referrer-Raten
- Wir tragen einen eindeutigen Schlüssel über die Domains, die du selbst besitzt. Aus dem Referrer eine Journey zu schätzen ist ungenau und verwechselt fremde Einstiege mit echten Übergängen. Wir stitchen nur konfigurierte, vertrauenswürdige Domains.
- Payment-Domain ausschließen, nicht gutschreiben
- Der externe Checkout ist keine Traffic-Quelle, sondern eine Zwischenstation. Über eine Referral-Exclusion zählt er nicht als Herkunft, sodass die Kampagne, die den Kauf ausgelöst hat, ihre Zuordnung behält statt sie an den Payment-Anbieter zu verlieren.
- Server-Side hält den Schlüssel über die Grenze
- Ein reiner Client-Linker scheitert an Redirects, verlorenen Query-Parametern oder Browser-Schutzmechanismen. Server-seitig geführt bleibt der Schlüssel stabil und trägt die Journey auch dann über die Domain-Grenze, wenn der URL-Parameter unterwegs verloren geht.
- Eine Journey, eine Quelle
- Die gestitchte Journey ersetzt drei isolierte Domain-Sessions durch einen durchgehenden Pfad. Der Kauf wird einmal gezählt, und die echte Einstiegsquelle behält den Sale, statt dass Direct oder der Payment-Anbieter ihn kassiert.
- Consent-first, kein Schlüssel ohne Rechtsgrundlage
- Trägt der Schlüssel Personenbezug, läuft die domainübergreifende Verknüpfung erst nach gültiger Einwilligung und gegen dein Consent-Management. Server-seitig verknüpfen heißt nicht einwilligungsfrei verknüpfen.
Im Glossar: Attributionsmodell, Deduplizierung, First-Party-Data.
"journey_key": "sha256:7b3e…a1", "hops": [ { "domain": "shop.de", "event": "campaign_click", "utm": "google/cpc" }, { "domain": "checkout.pay.com", "event": "payment", "linked": true }, { "domain": "shop.de", "event": "purchase", "value": "189.00" } ], "referral_exclusions": [ "checkout.pay.com" ], "resolved": { "journeys": 1, "source_kept": "google/cpc" }
Drei Domain-Sprünge, eine Journey, eine Quelle.
Die drei Hops teilen denselben journey_key, also dieselbe Journey. DataFirst führt sie zusammen, schließt die Payment-Domain als Quelle aus und behält die Kampagne, die den Klick ausgelöst hat. Ohne diese Auflösung wäre checkout.pay.com deine Traffic-Quelle und die echte Kampagne stünde mit null da.
3 hops → 1 journey · source google/cpcSelf-Referral belohnt den Payment-Anbieter und kürzt die Kampagne.
Meldest du jeden Domain-Wechsel als neuen Einstieg, gibt Last-Klick den Umsatz der Domain, von der der Kunde zuletzt kam, also dem Payment-Anbieter oder Direct. Die Kampagne, die die Reise mit dem Klick gestartet hat, steht mit null in den Zahlen und wirkt wie verbranntes Budget. Domainübergreifend gestitcht behält die echte Quelle den Sale, die Payment-Domain wird ausgeschlossen, und du steuerst dein Budget auf den echten Auslöser. Die Balken unten zeigen die Quell-Zuordnung schematisch.
Schematische Darstellung der Zuordnung, kein gemessener Wert.
Häufige Fragen zum Cross-Domain-Tracking
Was ist Cross-Domain-Tracking?
Cross-Domain-Tracking hält eine Customer Journey zusammen, auch wenn sie über mehrere Domains läuft. Typisch ist der externe Checkout: Jemand klickt eine Kampagne auf deiner Shop-Domain, wird zum Bezahlen auf die Domain des Payment-Anbieters geleitet und kommt danach auf deine Danke-Seite zurück. Weil ein First-Party-Cookie immer nur für eine Domain gilt, startet bei jedem Domain-Wechsel eine neue Session. Ohne Verknüpfung sieht die Rückkehr aus wie ein fremder Direktbesuch. Cross-Domain-Tracking erkennt, dass es dieselbe Journey war, und behält die ursprüngliche Quelle.
Warum taucht mein Payment-Anbieter als Traffic-Quelle auf?
Das ist der klassische Self-Referral. Wenn der Kunde von deiner Domain auf die Domain des Payment-Anbieters wechselt und danach zurückkommt, trägt der Browser den Payment-Anbieter als Referrer ein. Last-Klick verbucht den Sale dann auf diese Domain statt auf die Kampagne, die den Kauf ausgelöst hat. In den Zahlen wirkt der Payment-Anbieter wie eine starke Traffic-Quelle, und die echte Kampagne steht mit null da. Sauber gelöst wird das über eine Referral-Exclusion für die Payment-Domain plus einen First-Party-Schlüssel, der die Session über die Domain-Grenze zusammenhält.
Wie funktioniert Cross-Domain-Tracking DSGVO-konform?
Deterministisch über einen First-Party-Schlüssel, den du selbst zwischen deinen eigenen Domains überträgst, nicht über Fingerprinting. Der Schlüssel wird beim Domain-Wechsel als Linker in der URL mitgegeben und server-seitig gegen die Session-Identität aufgelöst, sodass die Journey vor und nach dem Sprung als eine erkannt wird. Verknüpft werden nur die Domains, die du konfigurierst und besitzt. Enthält der Schlüssel Personenbezug, läuft die Verknüpfung erst nach gültiger Einwilligung und gegen dein Consent-Management.
Welche Domains werden miteinander verknüpft?
Nur die, die du explizit als vertrauenswürdig konfigurierst. Das sind in der Regel deine eigenen Domains: die Shop-Domain, eine separate Landingpage- oder Aktions-Domain, ein Blog auf einer anderen Domain oder mehrere Länder-Domains derselben Marke. Der Payment- oder Checkout-Anbieter wird nicht als Quelle gutgeschrieben, sondern über eine Referral-Exclusion ausgeschlossen, damit er die Zuordnung nicht kapert. Domains, die du nicht konfigurierst, werden nicht zusammengeführt, und das ist korrekt so, nicht geraten.
Brauche ich dafür GA4 oder einen bestimmten Linker?
Nein, das Prinzip ist unabhängig vom Tool. GA4 bringt einen eigenen Cross-Domain-Linker und eine Liste zur Referral-Exclusion mit, die wir sauber konfigurieren. Darunter trägt der server-seitige First-Party-Schlüssel die Journey aber verlässlicher über die Domain-Grenze als ein reiner Client-Linker, der an Redirects, fehlenden Query-Parametern oder Browser-Schutzmechanismen scheitern kann. Wir richten beides so ein, dass es zusammenspielt, statt sich zu widersprechen.
Was kostet die Einrichtung von Cross-Domain-Tracking?
Das hängt von deinem Setup ab: wie viele Domains beteiligt sind, ob ein externer Checkout oder Payment-Anbieter im Spiel ist, ob eine separate Landingpage- oder Länder-Domain dazukommt, ob ein Server-Side-Container schon steht und wie das Consent-Management eingebunden ist. Einen pauschalen Festpreis auf einer Marketing-Seite zu nennen wäre unredlich, weil ein Ein-Domain-Shop und ein Setup mit externem Checkout und mehreren Länder-Domains nicht vergleichbar sind. Im Erstgespräch schauen wir auf deinen konkreten Stand und nennen dir einen belastbaren Aufwand.