Wie Cookie-Syncing Werbe-IDs über Websites hinweg abgleicht

Was ist Cookie-Syncing?

Ad-Tech-Firmen nutzen Cookie-Syncing, um die ID, die eine Firma in Ihrem Browser hinterlegt, mit der ID abzugleichen, die eine zweite Firma für denselben Browser führt, damit beide ihre zwei Datensätze als eine Person behandeln können. Jede Firma setzt ihr eigenes Third-Party Cookie von ihrer eigenen Domain aus, und der Browser erlaubt einer Domain nicht, das Cookie einer anderen Domain zu lesen. Cookie-Syncing umgeht das, indem die ID in einer URL weitergereicht wird, statt das Cookie direkt zu lesen.

Google nennt den Grund in seinem Leitfaden für Authorized Buyers: "the security model of internet browsers restricts one from reading a cookie set by another domain." Der Cookie-Matching-Dienst von Google existiert, damit ein Bieter sein eigenes Cookie mit "a corresponding bidder-specific Google User ID" abgleichen kann, die Google als "an encrypted form of the doubleclick.net cookie" beschreibt. Die Branche nennt dasselbe auch Cookie-Matching, ID-Syncing oder User-Matching.

Wenn Sie eine Website betreiben, passiert Cookie-Syncing auf Ihren Seiten immer dann, wenn Sie ein Ad-Tag, ein Retargeting-Pixel oder einen Tag-Manager-Container laden, der eines davon nachlädt. Ihr eigenes Analytics sieht die abgeglichenen IDs nie. Die Werbefirmen schon.

Wie funktioniert Cookie-Syncing Schritt für Schritt?

Cookie-Syncing läuft über eine Kette von HTTP-Requests, die ein Pixel startet und ein Redirect abschließt, wobei die Nutzer-ID einer Firma in die URL geschrieben wird, der der Browser folgt. Googles Leitfaden zum Cookie-Matching dokumentiert den Ablauf für seine Real-Time-Bidding-Partner, und andere Werbenetzwerke nutzen dasselbe Muster:

1. Ein Match-Tag lädt. Eine Seite, die der Besucher öffnet, enthält ein Pixel-Tag eines Bieters, das den Browser zum Cookie Matching Service von Google schickt. Der Browser sendet Google mit diesem Request sein doubleclick.net-Cookie.
2. Google leitet weiter. Google antwortet mit einem HTTP-302-Redirect auf die Cookie-Matching-URL des Bieters und setzt die bieterspezifische Google User ID in einen Parameter google_gid.
3. Der Bieter liest beide IDs. Der Browser folgt dem Redirect zur Domain des Bieters, die ihr eigenes Cookie in den Request-Headern und Googles ID in der URL erhält.
4. Das Paar landet in einer Match-Tabelle. Der Bieter speichert die Zuordnung in seiner eigenen Match-Tabelle oder schickt Google seine eigene ID in einem Parameter google_hm, sodass Google die Tabelle führt.
5. Bid-Requests tragen den Abgleich. Spätere Bid-Requests für diesen Browser enthalten die abgeglichenen Daten des Bieters, sodass der Bieter weiß, dass die Impression zu einem Nutzer gehört, für den er ein Profil hat.

Google betreibt den Ablauf auch umgekehrt mit einem Parameter google_push: Dann platziert Google das Tag, und der Bieter leitet zurück zu Google, um den Abgleich abzuschließen. Der Besucher sieht davon nichts. Das Pixel ist ein 1x1-Bild oder ein unsichtbarer Request, derselbe Baustein, den der Leitfaden zu Spionagepixeln beschreibt.

Warum brauchen Ad-Tech-Firmen Cookie-Syncing?

Ad-Tech-Firmen brauchen Cookie-Syncing, weil jede von ihnen einen Browser nur an ihrem eigenen Cookie erkennt und sich Käufer und Verkäufer in einer Echtzeit-Auktion innerhalb von Millisekunden einig sein müssen, wer der Besucher ist. Angenommen, ein Datenhändler kennt einen Browser als a91f, eine Exchange kennt ihn als 7c2e und ein Bieter als 55d0. Ohne Match-Tabelle kann der Bieter nicht erkennen, dass die angebotene Impression zu der Person gehört, die gestern auf einer anderen Site einen Warenkorb verlassen hat.

Jeder Sync fügt eine weitere Firma hinzu, die eine ID für denselben Browser hält. Deshalb steht Cookie-Syncing im Zentrum des Cross-Site-Trackings, und deshalb nennt der Leitfaden dazu, wie Datenhändler personenbezogene Daten sammeln, es neben Pixeln und SDKs als Quelle für Daten über Online-Verhalten. Ein Sync-Tag auf einer Nachrichtenseite fächert sich zu jedem Partner auf, mit dem der Besitzer des Tags synchronisiert, und jeder davon kennt denselben Browser nun unter demselben Schlüssel.

Was haben Safari und Firefox gegen Cookie-Syncing unternommen?

Safari und Firefox haben Cookie-Syncing an der Basis zerstört, indem sie das Third-Party Cookie abschneiden, von dem jeder Schritt der Redirect-Kette abhängt. Der Abgleich funktioniert nur, wenn das eigene Cookie des Bieters mit dem weitergeleiteten Request ankommt, und beide Browser verhindern das standardmäßig.

WebKit nennt das Redirect-Muster "tracker collusion". Sobald eine Domain als Tracker klassifiziert ist, wird "a check is made to see which other domains have previously redirected to" sie, "and all of them get classified too." Eine klassifizierte Domain, mit der der Nutzer in den letzten 30 Tagen der Browsernutzung nicht als First Party interagiert hat, verliert alle ihre Website-Daten.

Mozilla beschreibt den Ansatz von Firefox einfacher: Jedes Cookie, das eine Website oder eingebettete Inhalte setzen, "is confined to the cookie jar assigned to only that website." Ein Bieter bekommt zwar weiterhin ein Cookie, aber auf jeder Site ein anderes, und das ist das Gegenteil dessen, was ein Sync braucht. Der Leitfaden zu partitionierten CHIPS-Cookies erklärt, wie Chrome Sites, die sich dafür entscheiden, dasselbe partitionierte Modell anbietet.

Funktioniert Cookie-Syncing in Chrome noch?

Cookie-Syncing funktioniert in Chrome weiterhin bei jedem Nutzer, der Third-Party Cookies nicht blockiert hat, weil Google sich entschieden hat, Third-Party Cookies als Nutzereinstellung beizubehalten. In einem Beitrag vom 22. April 2025 schrieb Anthony Chavez, der bei Google die Privacy Sandbox leitet, Chrome werde "maintain our current approach to offering users third-party cookie choice in Chrome, and will not be rolling out a new standalone prompt for third-party cookies." Nutzer wählen eine Option in den Chrome-Einstellungen unter Privacy and Security, und die Hilfeseite von Chrome sagt: "by default, third-party cookies are blocked in Incognito mode."

Danach hat Google den Großteil der Ersatztechnik eingestellt. Ein Update vom 17. Oktober 2025 listete die Privacy-Sandbox-APIs auf, die eingestellt werden, darunter Topics, Protected Audience, die Attribution Reporting API und Related Website Sets, und nannte als Grund "their low levels of adoption." CHIPS und FedCM bleiben.

Für Website-Betreiber heißt das: Jedes Werbe- oder Retargeting-Tag, das Sie in Chrome laden, kann weiterhin IDs mit seinen Partnern synchronisieren. Nur wenn Sie das Tag entfernen, hört es auf Ihren Seiten auf.

Wie können Website-Betreiber Cookie-Syncing auf ihren eigenen Seiten sehen?

Website-Betreiber sehen Cookie-Syncing, indem sie auf ihrer eigenen Seite das Netzwerk-Panel des Browsers öffnen und nach Redirect-Ketten zwischen Werbedomains suchen, die IDs im Query-String tragen. Laden Sie eine Seite mit Werbe- oder Retargeting-Tags in Chrome mit erlaubten Third-Party Cookies, öffnen Sie die DevTools, filtern Sie nach "Img" oder "Doc" und sortieren Sie nach Domain.

Anzeichen für einen Sync:

• Ein Request an eine Werbedomain, der den Status 302 mit einem Location-Header zurückgibt, der auf eine andere Werbedomain zeigt.
• Query-Parameter mit Namen wie uid, gid, buyeruid, partner_uid oder google_gid, die einen langen Zufallswert enthalten.
• Ein 1x1-GIF oder eine leere Antwort am Ende der Kette.
• Dieselbe Kette feuert bei jedem Seitenaufruf, nicht einmal pro Besuch.

Wiederholen Sie die Prüfung dann in Safari. Der Privacy Report von Safari listet die bekannten Tracker auf, die er daran gehindert hat, ein Profil des Besuchers anzulegen, und der Leitfaden zum Safari Privacy Report erklärt, wie Sie ihn lesen. Der Unterschied zwischen den beiden Browsern zeigt Ihnen, wie viele Partner Ihre Tags mitbringen.

Warum braucht First-Party-Analytics kein Cookie-Syncing?

First-Party-Analytics braucht kein Cookie-Syncing, weil es nur Besuche auf der Site zählt, auf der es installiert ist, und es deshalb keine zweite Firma gibt, deren ID es abgleichen müsste. Ein Seitenaufruf, ein Referrer, ein Ziel und ein Kauf gehören alle zu einer Website. Das Analytics-Tool muss auf dieser Site eine Sitzung von einer anderen unterscheiden, nicht denselben Browser auf einem Rezeptblog und in einem Schuhshop wiedererkennen.

Flowsery ist für genau diese engere Aufgabe gebaut. Das Tracking-Skript von Flowsery läuft cookieless mit einem täglich rotierenden Besucher-Hash und erhebt keine personenbezogenen Daten, und im Cookieless-Modus rotieren die Besucher-IDs täglich, sodass Flowsery einen anonymen Besucher nicht über Tage oder Geräte hinweg verknüpft. Flowsery sagt, dass es Analytics-Daten nie verkauft oder weitergibt und keine Browser-Fingerprints erhebt. Für angemeldete Nutzer hängt der Aufruf identify() von Flowsery die Nutzer-ID an, die Sie bereits haben, und die Umsatzattribution ordnet eine Zahlung über Stripe, Paddle, Polar, Lemon Squeezy oder Shopify der Sitzung zu, die konvertiert hat. Keiner der beiden Schritte verwendet die ID eines Werbepartners. Die Seite zur cookielosen Tracking-Lösung zeigt, wie Sitzungen stattdessen mit gesalzenen Hashes gruppiert werden.

Häufig gestellte Fragen

Ist Cookie-Syncing dasselbe wie Cookie-Matching?

Ja. Die Dokumentation von Google für Authorized Buyers nennt es Cookie-Matching, und die Branche spricht auch von ID-Syncing und User-Matching. Alle vier Namen beschreiben denselben Redirect-basierten Austausch von IDs zwischen zwei Ad-Tech-Domains.

Braucht Cookie-Syncing Third-Party Cookies?

Ja, der klassische Redirect-Ablauf braucht das Third-Party Cookie des Bieters, das mit dem weitergeleiteten Request ankommen muss. Safari blockiert alle Third-Party Cookies und Firefox partitioniert sie pro Site, sodass der Bieter entweder gar kein Cookie oder nur ein Site-spezifisches bekommt. Chrome sendet Third-Party Cookies weiterhin für Nutzer, die sie nicht blockiert haben.

Kann ich Cookie-Syncing auf meiner Website stoppen?

Sie stoppen Cookie-Syncing auf Ihren eigenen Seiten, indem Sie die Werbe-, Retargeting- und Datenhändler-Tags entfernen, die es auslösen. Ein Consent-Banner, das diese Tags blockiert, bis ein Besucher zustimmt, stoppt die Syncs ebenfalls für Besucher, die ablehnen. Ihr Analytics-Tool hat keine Einstellung, die Syncing für Tags abschaltet, die es nicht kontrolliert.

Gelten Daten aus Cookie-Syncing als personenbezogene Daten nach der DSGVO?

Eine synchronisierte ID ist eine Online-Kennung, die einen Browser über Sites hinweg herausgreift, und damit ein personenbezogenes Datum nach der DSGVO. In der EU braucht das Setzen und Auslesen der zugrunde liegenden Cookies eine Einwilligung nach den ePrivacy-Regeln. Die Weitergabe an Partner braucht außerdem für jeden Empfänger eine Rechtsgrundlage.

Hat Chrome Third-Party Cookies blockiert?

Nein. Googles Beitrag vom 22. April 2025 sagt, dass Chrome die Wahl bei Third-Party Cookies weiterhin in den Einstellungen anbietet und keinen eigenständigen Prompt einführt. Chrome blockiert Third-Party Cookies standardmäßig nur im Inkognito-Modus.

Synchronisiert Flowsery Cookies mit Werbenetzwerken?

Nein. Flowsery misst den Traffic Ihrer eigenen Site, sagt, dass es Analytics-Daten nie verkauft oder weitergibt, und sein Cookieless-Modus nutzt einen täglich rotierenden Besucher-Hash ohne personenbezogene Daten. Flowsery hat keine IDs von Werbepartnern, die es abgleichen könnte.

Was ist eine Match-Tabelle beim Cookie-Syncing?

Eine Match-Tabelle ist die Liste, in der ein Ad-Tech-Unternehmen speichert, welche seiner eigenen User-IDs zu welcher Partner-ID gehört. Der Bidder baut sie nach dem Redirect auf, wenn er das eigene Cookie und die Partner-ID in derselben Anfrage gesehen hat. Im Ablauf von Google kann der Bidder seine ID auch in einem google_hm-Parameter zurückschicken, sodass Google die Tabelle hostet.

Wie prüfe ich, ob meine Website Cookie-Syncing nutzt?

Öffnen Sie die DevTools in Chrome mit erlaubten Third-Party Cookies, laden Sie eine Seite mit Werbe- oder Retargeting-Tags und filtern Sie nach "Img" oder "Doc". Achten Sie auf eine 302-Antwort, deren Location-Header auf eine andere Werbedomain zeigt, und auf Parameter wie uid, gid oder google_gid mit einem langen Zufallswert. Ein 1x1-GIF am Ende der Kette ist ein weiteres Anzeichen für einen Sync.

Blockiert Safari Cookie-Syncing?

Safari blockiert das Cookie, von dem der Sync abhängt. ITP von WebKit blockiert alle Third-Party Cookies ohne Ausnahmen, sodass der Redirect den Bidder ohne dessen Cookie erreicht und es nichts zu matchen gibt. Safari klassifiziert außerdem Domains, die zwischen Trackern weiterleiten, und zieht damit jede Domain der Kette in die Klassifizierung.

Funktioniert Cookie-Syncing im Inkognito-Modus?

Laut Chrome-Hilfe sind Third-Party Cookies im Inkognito-Modus standardmäßig blockiert. Das Cookie des Bidders kommt dann nicht mit der weitergeleiteten Anfrage an, und der klassische Sync hat nichts zu matchen, solange der Nutzer diese Einstellung nicht ändert.