Inhaltsverzeichnis
Ihre Kampagnen scheinen schwach zu laufen, doch der Direktverkehr konvertiert erstaunlich gut? Wenn Zahlung, Buchung oder Anmeldung auf der Domain eines Dienstleisters stattfinden, liegt die Ursache oft genau dort: Die Besucherin wechselt die Domain, ihre Messkennung folgt ihr nicht, und der Verkauf wird dem falschen Kanal zugeordnet.
Kurz gesagt
Ein Cookie existiert nur für die Domain, die es gesetzt hat: Zwei getrennte Domains bedeuten zwei getrennte Besucher, ausser die Kennung wird mitgenommen.
Die domainübergreifende GA4-Konfiguration (Parameter _gl) und der Conversion Linker bilden die Basis, versagen aber ohne Linkklick: Weiterleitung, POST, Iframe, JavaScript-Button.
Server-Side-Tracking trägt kein Cookie über Domaingrenzen. Es verlängert die Lebensdauer der Kennungen auf jeder Ihrer Domains trotz der Grenzen von Safari.
Besucher über mehrere Domains zu verknüpfen, hat Folgen unter DSG und DSGVO: vor dem Go-live klären.
Dieser Beitrag richtet sich an Schweizer KMU, Webagenturen und Marketingagenturen, deren Conversion-Strecke über mehrere Domains führt. Das betrifft viele Websites in der Romandie und der Deutschschweiz: Hotellerie, Weiterbildung, Ticketing, Vereine, Arztpraxen und Shops, die die Zahlung auslagern.
Warum bricht die Messung bei zwei Domains zusammen?
Der Mechanismus ist einfach, und gerade deshalb bleibt er monatelang unbemerkt.
Ein Cookie gehört zu einer einzigen Domain
Läuft GA4 auf ihr-hotel.ch, schreibt es ein Cookie _ga mit einer Client-ID, das an ihr-hotel.ch gebunden ist. Klickt die Besucherin auf «Buchen» und landet auf buchung-anbieter.com, wendet der Browser eine Grundregel des Webs an: Eine Website liest keine Cookies einer anderen Website. Das Messskript der Zieldomain findet kein Cookie, legt ein neues an und gibt der Besucherin eine neue Identität.
Sie haben nichts kaputt gemacht und nichts falsch konfiguriert: Der Browser tut genau, was er soll.
Was GA4 dann anzeigt
Die Folge sehen Sie in den Akquisitionsberichten. Die erste Sitzung endet auf Ihrer Website ohne Conversion. Eine zweite Sitzung beginnt auf der Domain des Anbieters. Weil der Referrer Ihre eigene Website ist oder bei einer Weiterleitung verloren geht, wird diese zweite Sitzung als Direktverkehr eingestuft, oder sogar als «Referral» von Ihrer eigenen Domain.
Die Nutzerzahl wird mechanisch aufgebläht: eine Person, zwei Nutzer. Die Conversion-Rate des bezahlten Kanals bricht ein, jene des Direktverkehrs steigt steil an. Wenn Ihr Direktverkehr deutlich besser konvertiert als Ihre Kampagnen, liegt hier oft ein Teil der Erklärung.
Was Google Ads, Meta und LinkedIn sehen
Auf der Werbeseite wiegt das Problem schwerer, weil es die Gebotsoptimierung trifft. Ein Klick auf eine Google-Ads-Anzeige hängt eine Klick-ID (gclid, auf manchen iOS-Strecken wbraid und gbraid) an die URL der Zielseite. Diese Kennung muss auf dieser Domain gespeichert und bei der Conversion wieder gelesen werden.
Findet die Conversion auf einer Domain statt, die die Kennung nie gesehen hat, wird sie ohne Quelle gemeldet oder gar nicht. Das Smart Bidding lernt dann aus unvollständigen Daten und verschiebt Ihr Budget zu den falschen Zielgruppen.
Welche Strecken sind betroffen, und was muss wirklich korrigiert werden?
Die Frage lautet nicht «Habe ich mehrere Domains?», sondern «Verlässt meine Conversion-Strecke meine Domain vor dem Abschluss?». Die häufigsten Fälle in der Schweiz:
Hotellerie und Unterkünfte: Website auf .ch, Buchungsmaschine auf der Domain des Anbieters.
Ticketing, Events und Freizeit: Die Website präsentiert das Angebot, die Ticketing-Plattform kassiert.
E-Commerce mit gehosteter Zahlungsseite: Warenkorb auf Ihrer Domain, Karteneingabe beim Zahlungsanbieter, Rückkehr auf Ihre Bestätigungsseite.
Weiterbildung und Privatschulen: institutionelle Website auf der einen, Anmeldeportal oder LMS auf der anderen Seite.
Praxen und Kliniken: Terminbuchung über eine externe Plattform.
Mehrmarken- oder mehrsprachige Gruppen: eine .ch- und eine .fr- oder .de-Domain, zwischen denen Besucher wechseln.
B2B und Recruiting: Unternehmenswebsite und Bewerbungsportal oder Kundenbereich auf einer eigenen Domain.
Wichtig: Ein Hin- und Rückweg zählt doppelt. Bei einer Zahlung verlässt die Besucherin Ihre Domain und kehrt zurück. Jeder Übergang ist eine Gelegenheit, die Identität zu verlieren, und die Bestätigungsseite löst genau Ihr Kauf-Event aus.
Subdomain oder eigene Domain?
Bevor Sie einen Container öffnen, qualifizieren Sie die Situation. Nicht jeder Fall verlangt dieselbe Arbeit, und viele Teams beheben ein Problem, das sie gar nicht haben.
Gleiche Domain, Unterverzeichnisse (ihre-seite.ch/fr/ und ihre-seite.ch/de/): nichts zu tun, die Cookies werden geteilt.
Subdomains derselben Domain (www.ihre-seite.ch und shop.ihre-seite.ch): keine domainübergreifende Konfiguration nötig, sofern das Cookie auf der Stammdomain gesetzt wird. Das ist das Standardverhalten des Google-Tags und des Conversion Linkers. Eine fälschlich auf Subdomains angewandte domainübergreifende Konfiguration kann sogar Probleme schaffen.
Verschiedene Domains, gleiches Unternehmen (ihre-seite.ch und ihre-seite.fr): domainübergreifende Konfiguration nötig, Einwilligung durchdenken.
Domain eines Drittanbieters (Zahlung, Buchung, Ticketing): der schwierigste Fall, denn Sie kontrollieren weder den Code noch die Cookie-Richtlinie der Zieldomain. Die Lösungen hängen davon ab, was der Anbieter umzusetzen bereit ist.
Diese Einordnung bestimmt den Grossteil des Aufwands. Im Audit ist sie die erste Frage, noch bevor wir Google Tag Manager öffnen; sie steht auch in unserer Tracking-Audit-Checkliste mit 15 Punkten.
Parameter _gl und Conversion Linker: warum die native Verknüpfung nicht reicht
Die domainübergreifende Konfiguration in GA4
GA4 regelt die domainübergreifende Messung in der Oberfläche: Verwaltung, Datenstreams, Tag-Einstellungen konfigurieren, Domains konfigurieren. Laut der offiziellen Google-Dokumentation lassen sich dort bis zu 100 Bedingungen anlegen.
So funktioniert es: Wechselt eine Besucherin auf eine hinterlegte Domain, hängt das Tag einen Parameter _gl an die URL, der die GA4-Client-ID und die Google-Klick-IDs transportiert. Die Zieldomain liest den Parameter und legt die passenden Cookies neu an. Die Sitzung läuft weiter, die Nutzerin bleibt dieselbe.
Drei Bedingungen müssen erfüllt sein: Alle Domains nutzen dieselbe Mess-ID «G-», das Google-Tag ist auf jeder Seite jeder Domain vorhanden, und der Wechsel erfolgt über einen Linkklick oder ein Formular, das das Tag dekorieren kann.
Der Conversion Linker, das vergessene Tag
Der Conversion Linker ist ein eigenes Google-Tag-Manager-Tag, getrennt von GA4. Laut der Google-Tag-Manager-Dokumentation erkennt er Anzeigenklick-Informationen in der URL der Zielseite und speichert sie in First-Party-Cookies und im lokalen Speicher des Browsers (bei AMP-Seiten in der URL). Standardmässig nutzt er die höchstmögliche Domain-Ebene.
Fehlt dieses Tag auf der Domain, auf der die Conversion stattfindet, wird die von Ihrer Website mitgebrachte gclid nie gespeichert. Das ist das häufigste Versäumnis auf domainübergreifenden Strecken, auch bei Werbetreibenden mit grossen Google-Ads-Budgets.
Sechs Situationen, in denen die Link-Dekoration versagt
Der Parameter _gl wird nur angehängt, wenn das Tag die Navigation abfangen kann. In folgenden Fällen wird er nicht übergeben, und die Strecke reisst lautlos:
Serverseitige Weiterleitung: Ihre Website sendet eine 302-Weiterleitung zum Anbieter. Kein Linkklick, keine Dekoration.
Dynamisch erzeugtes POST-Formular: häufig bei Zahlungsstrecken, wo ein Skript das Formular aufbaut oder absendet.
JavaScript-Button: Ein Button, der nach einem asynchronen Schritt window.open aufruft oder window.location ändert, kann vor der Dekoration auslösen.
Iframe: Ein eingebettetes Buchungs-Widget ist eine Seite einer anderen Domain, in die der Parameter nicht per Klick gelangt.
Rückkehr vom Anbieter: Die Drittdomain schickt die Besucherin ohne Dekoration auf Ihre Bestätigungsseite zurück. Sie kommt als Unbekannte zurück, wenn ihr ursprüngliches Cookie abgelaufen oder gelöscht ist.
Keine Einwilligung zum Zeitpunkt des Klicks: Sind Analyse-Cookies auf der Ausgangsdomain abgelehnt, gibt es keine Kennung zu transportieren, und das ist auch richtig so.
Diese sechs Fälle erklären, warum eine «in der GA4-Oberfläche erledigte» Konfiguration eingerichtet wirkt, obwohl nichts durchkommt: Die Einstellung stimmt, die reale Strecke nicht.
Was verändert Server-Side-Tracking wirklich?
Hier ist Präzision nötig, denn das Thema wird oft überverkauft. Server-Side-Tracking lässt kein Cookie eine Domaingrenze überschreiten. Ein Tagging-Server auf data.ihre-seite.ch kann ein Cookie für ihre-seite.ch setzen, nicht für die Domain eines Anbieters. Keine Architektur umgeht diese Browserregel.
Was Server-Side löst: die Lebensdauer der Cookies
Der eigentliche Gewinn liegt woanders, und er zählt bei Strecken, die sich über Zeit ziehen, etwa bei einer Buchung oder einer B2B-Offerte.
Seit Februar 2019 begrenzt Safari persistente, per JavaScript erzeugte Cookies auf 7 Tage, wie Apple mit Intelligent Tracking Prevention 2.1 angekündigt hat. Die Grenze sinkt auf 24 Stunden, wenn die Besucherin von einer als Tracker eingestuften Domain mit dekorierter URL (Query-Parameter oder Fragment) kommt, so die WebKit-Dokumentation zur Tracking Prevention.
Das ist kontraintuitiv: Link-Dekoration fügt der URL gerade Parameter hinzu. Führt die Strecke über eine eingestufte Domain, kann der Mechanismus, der die Attribution retten soll, die Lebensdauer des neu angelegten Cookies verkürzen.
Ein Cookie, das der Server in der HTTP-Antwort setzt, von einer Subdomain, die Ihnen tatsächlich gehört, unterliegt nicht der Grenze für JavaScript-Cookies. Das ist der Kern des Server-Side-Gewinns. Mit einer wichtigen Einschränkung: Laut derselben WebKit-Dokumentation erkennt ITP CNAME-Cloaking und IP-Cloaking durch Dritte (eine Subdomain, die per CNAME oder IP-Adresse auf die Infrastruktur eines Dritten zeigt) und begrenzt dann auch diese Cookies auf 7 Tage. Klären Sie mit Ihrem sGTM-Hoster, wie Ihre Erfassungs-Subdomain angebunden ist.
FPID, FPLC und die Grenze von zwanzig Stunden
Google hat für Server-Side einen eigenen Mechanismus vorgesehen. Der Server-Container kann ein Cookie FPID als HttpOnly setzen, für JavaScript unzugänglich und damit robuster. Die Kehrseite: Ein Cookie, das JavaScript nicht lesen kann, eignet sich nicht zur Link-Dekoration.
Google hat deshalb ein zweites Cookie eingeführt, FPLC, abgeleitet vom FPID und per JavaScript lesbar, das als domainübergreifendes Verknüpfungstoken dient. Wie Simo Ahava dokumentiert hat, lebt dieses Token 20 Stunden, und die Server-Container beider Domains müssen zum selben Google-Tag-Manager-Konto gehören.
Konkret: Die domainübergreifende Verknüpfung per Server-Side funktioniert für eine durchgehende Strecke, nicht für eine Besucherin, die drei Tage später zurückkommt, um ihre Buchung abzuschliessen.
Was Server-Side löst, und was nicht
Löst: die Lebensdauer der Kennungen auf jeder Ihrer Domains und damit die Fähigkeit, eine späte Conversion dem ursprünglichen Klick zuzuordnen.
Löst: die Übermittlung der Conversions an die Plattformen per Server-API (Google Ads, Meta, LinkedIn, TikTok), auch wenn technische Einschränkungen des Browsers die Aufrufe blockieren.
Löst: die Anreicherung der Conversion mit Daten aus Ihrem Backoffice, was den Identitätsverlust zwischen Domains teilweise ausgleicht.
Löst nicht: das Teilen eines Cookies zwischen zwei getrennten Domains. Das bleibt unmöglich.
Löst nicht: ein fehlendes Tag auf der Domain des Anbieters. Wer dort nichts einsetzt, misst dort nichts.
Löst nicht: eine verweigerte Einwilligung. Server-Side respektiert die Wahl der Besucher: Eine Ablehnung bleibt eine Ablehnung.
Die drei Verknüpfungsschichten, der Reihe nach
Auf einer domainübergreifenden Strecke entsteht Robustheit durch das Übereinanderlegen von drei Schichten, nicht durch die Wahl einer einzigen.
Schicht 1, native Verknüpfung: domainübergreifende GA4-Konfiguration und Conversion Linker auf allen Domains der Strecke, auch auf jener des Anbieters. Das ist die Basis, und sie kostet keine Lizenzgebühren.
Schicht 2, expliziter Transport: Wo Schicht 1 nicht greift (Weiterleitung, POST, Iframe), transportieren Sie die nötigen Kennungen selbst in der URL oder in Formularfeldern und lesen sie bei der Ankunft aus. Diese Parameter sind Personendaten: Zweck, Information und Aufbewahrungsdauer müssen festgelegt sein.
Schicht 3, serverseitiger Abgleich: Die Conversion wird serverseitig anhand der Bestell- oder Buchungsreferenz rekonstruiert und per API an die Plattformen gesendet. Diese Schicht fängt auf, was die ersten beiden durchgelassen haben, und übersteht Browser-Änderungen am besten.
Merksatz: Die Schichten 1 und 2 retten die Sitzung, Schicht 3 rettet die Conversion. Alle drei speisen Ihre Gebotsstrategie, doch die dritte holt die Conversions zurück, die den anderen entgangen sind.
Tipp von A-Track
Gehört die Zieldomain einem Anbieter, bitten Sie nicht einfach darum, «das Tracking einzubauen». Schicken Sie eine präzise Anfrage: gleiche GA4-ID, Conversion Linker, zu hinterlegende Domains und Rückleitung auf Ihre Bestätigungsseite mit der Bestellreferenz. Das verkürzt den Austausch deutlich.
Einwilligung, DSG und DSGVO: was zu prüfen ist
Wer eine Besucherin über zwei Domains verknüpft, baut per Definition ein Profil, das über eine einzelne Website hinausgeht. Die rechtliche Einordnung verschiebt sich.
Erstens, Transparenz. Das Bundesgesetz über den Datenschutz verlangt Transparenz und Verhältnismässigkeit. Eine domainübergreifend geteilte Kennung muss in der Datenschutzerklärung jeder betroffenen Domain beschrieben sein, mit Angabe des Verantwortlichen. Für Cookies verlangt das Schweizer Recht (Art. 45c FMG) Information und ein Widerspruchsrecht; für Besucher aus der EU gilt die vorgängige Einwilligung (ePrivacy und DSGVO).
Zweitens, die Reichweite der Einwilligung. In der Regel deckt ein Banner auf ihre-seite.ch die Domain anbieter-domain.com nicht ab, ausser es besteht eine ausdrückliche vertragliche Regelung zwischen beiden Unternehmen. Oft sieht die Besucherin zwei Banner nacheinander und antwortet unterschiedlich. Ihre Umsetzung muss das berücksichtigen: Wird Analytics auf der zweiten Domain abgelehnt, darf dort keine Kennung neu angelegt werden. Google weist selbst darauf hin, dass Analytics für die domainübergreifende Verknüpfung per _gl eine Einwilligung braucht.
Drittens, ein nützliches Signal der Aufsicht. Die französische CNIL geht davon aus, dass ein Tracker zur Reichweitenmessung seine Befreiung von der Einwilligungspflicht verliert, sobald er eine globale Verfolgung des Surfverhaltens über verschiedene Websites erlaubt, etwa über eine gemeinsame Kennung. Anders gesagt: Genau der Mechanismus, der die Attribution repariert, macht auf EU-Seite die Einwilligung zur Pflicht. Das ist nicht direkt auf das Schweizer Recht übertragbar, betrifft aber jedes Schweizer Unternehmen, das die EU anspricht.
Schliesslich muss der Consent Mode auf allen Domains einheitlich sein. Unterschiedliche Standardwerte je Domain erzeugen Modellierungsabweichungen, die niemand erklären kann. Siehe unseren Leitfaden zu Google Consent Mode v2 und für den Gesamtrahmen unseren Leitfaden zu DSG und DSGVO.
Fazit: Ihre Strecke in dreissig Minuten prüfen
Für diese Prüfung brauchen Sie kein kostenpflichtiges Tool, nur einen Browser und Methode.
Zeichnen Sie die reale Strecke auf. Listen Sie jede Domain zwischen Einstiegs- und Bestätigungsseite der Reihe nach auf, samt Übergangsart: Link, Weiterleitung, Formular, Iframe.
Machen Sie einen Testkauf oder eine Testbuchung über eine Anzeige oder eine URL mit einem fiktiven gclid-Parameter, im privaten Fenster.
Prüfen Sie bei jedem Domainwechsel die URL. Ist der Parameter _gl vorhanden? Wenn nicht, versagt Schicht 1 an dieser Stelle.
Prüfen Sie die Cookies auf der Zieldomain. Ist der Wert von _ga identisch mit jenem der Ausgangsdomain? Gibt es ein Cookie _gcl_aw?
Prüfen Sie die Bestätigungsseite. Löst dort das Conversion-Event aus, und mit welcher Client-ID?
Vergleichen Sie drei Zahlen über dreissig Tage: Bestellungen im Backoffice, Conversions in GA4, Conversions in Google Ads. Eine grosse, anhaltende Abweichung auf einer domainübergreifenden Strecke hat selten eine andere Ursache.
Wiederholen Sie den Test in Safari auf einem iPhone und nochmals sieben Tage später. Erst dieser Test zeigt Probleme mit der Cookie-Lebensdauer, die in Chrome in einer einzigen Sitzung unsichtbar bleiben.
Scheitern die Schritte 3 und 4, haben Sie ein Verknüpfungsproblem. Gelingen sie, zeigt Schritt 6 aber eine Abweichung, suchen Sie bei der Persistenz oder der Einwilligung. In den meisten Fällen, die wir sehen, liegt das Problem nicht im Google Tag Manager, sondern in einem Schritt der Strecke, den niemand als Domainwechsel erkannt hatte.
Wie A-Track Sie unterstützen kann
Wir betreuen solche Strecken für Schweizer KMU und für Agenturen, die die Messung auslagern möchten: Audit, um festzustellen, wo Conversions verloren gehen, Umsetzung der drei Schichten und anschliessender Abgleich zwischen Backoffice und Plattformen. Unsere Dienstleistung Tracking & Compliance deckt die Umsetzung ab, unsere jährliche Wartung sorgt dafür, dass die Strecke beim nächsten Checkout-Redesign nicht bricht (siehe auch warum Server-Side-Tracking nach dem Go-live ausfällt).
Quellen
Google Analytics, domainübergreifende Messung einrichten, offizielle Dokumentation.
Google Tag Manager, Conversion-Linker-Tag, offizielle Dokumentation.
WebKit, Intelligent Tracking Prevention 2.1, Apple, 21. Februar 2019; WebKit, Tracking Prevention.
Simo Ahava, Cross-domain Tracking With Server-side FPID Cookie.
Luc Nugteren, Multi-domain tracking: 5 best practices, Stape, 16. September 2026.
Zerstört Ihre externe Zahlungsseite die Attribution?
A-Track verfolgt den Weg von Ihrer Website bis zum Zahlungs- oder Buchungsanbieter, prüft _gl, Conversion Linker und Einwilligung und behebt Brüche in der Attribution.
Vereinbaren Sie ein 30-minütiges Gespräch mit einem Experten.
