Drittanbieter-Cookies werden vielfältig eingesetzt, spielen aber auch eine wichtige Rolle beim websiteübergreifenden Tracking. Chrome hat ab dem 1. Quartal 2024 für 1% der Nutzer Drittanbieter-Cookies eingeschränkt, um Tests zu ermöglichen. Ab Anfang 2025 sollen Drittanbieter-Cookies für 100% der Nutzer eingestellt werden, vorbehaltlich aller verbleibenden wettbewerbsrechtlichen Bedenken der Competition and Markets Authority (CMA) des Vereinigten Königreichs.
Auf dieser Seite finden Sie Informationen zu datenschutzfreundlichen Lösungen für eingebettete Szenarien, in denen bisher Drittanbieter-Cookies verwendet wurden, sowie Strategien, mit deren Hilfe Sie die für Ihre Anforderungen am besten geeignete Lösung auswählen können.
Eingebettete Dienste oder Einbettungen umfassen Inhalte Dritter (z. B. Videos, Karten), interaktive Komponenten (z. B. Chat, Kommentarsysteme oder Zahlungsdienste), Anmeldedienste und mehr.
Der Großteil der Umstellung von Drittanbieter-Cookies muss von Einbettungsentwicklern erledigt werden, nicht von Websites, die Einbettungen hosten. In diesem Leitfaden werden hauptsächlich Lösungen für Entwickler behandelt, die eingebettete Dienste erstellen.
Wenn Ihre Website auf einer Einbettung basiert, die Drittanbieter-Cookies verwendet, sollten Sie Ihre Einbettungspfade prüfen und testen und sich an die Einbettungsanbieter wenden, wenn Sie einen Fehler feststellen.
Nutzerpfade im Zusammenhang mit eingebetteten Inhalten prüfen und testen
Um festzustellen, ob Ihre Einbettungen von der Einstellung von Drittanbieter-Cookies betroffen sind, testen Sie am besten die Nutzerflüsse von eingebetteten Drittanbieter-Cookies und achten dabei darauf, dass das entsprechende Flag aktiviert ist.
Teste nach dem Einschränken von Drittanbieter-Cookies die folgenden gängigen Einbettungsszenarien:
- Chat-Widgets:Können Sie eine Chatsitzung starten? Können Sie die Seite aktualisieren, ohne die Sitzung zu verlieren? Kannst du zu anderen Seiten wechseln und deine Sitzung fortsetzen?
- Eingebettete Inhalte:Kannst du dir Videoinhalte oder andere eingebettete Inhalte ansehen? Werden Nutzereinstellungen wie Sprache oder Untertitel beibehalten? Werden Anzeigen wie erwartet angezeigt – beispielsweise nicht als Premium-Abonnent?
- Anmeldung:Funktioniert die Anmeldung – einschließlich der Einmalanmeldung (SSO) – für Einbettungen, die sie unterstützen? Werden sie durch Aktualisieren der Seite und Navigation zu Seiten beibehalten, die dieselben Einbettungen verwenden?
- Kommentar-Widgets:Kann ich Kommentare hinterlassen, positiv bewerten und positiv bewerten?
- Lösungen für eingebettete Zahlungen:Kannst du Zahlungen erfolgreich abwickeln?
In den nächsten Abschnitten finden Sie genauere Informationen dazu, wie diese Abläufe betroffen sein können.
Gängige Anwendungsfälle
Es gibt eine Reihe von APIs, die für Einbettungen verwendet werden können, die bisher auf Drittanbieter-Cookies basieren. In der folgenden Tabelle sind einige gängige Workflows und die empfohlenen APIs zur Verwendung als allgemeine Zusammenfassung aufgeführt. In den folgenden Abschnitten wird die Begründung für diese Empfehlungen erläutert.
| Anwendungsfall | Empfohlene API für die Verwendung von Drittanbieter-Cookies |
|---|---|
| Chat-Widget | CHIPS |
| Eingebettete Karten | CHIPS |
| Sandbox-Domains für nicht vertrauenswürdige Nutzerinhalte (z. B. googleusercontent.com und githubusercontent.com), deren Status nach Publisher aufgeschlüsselt werden muss |
CHIPS |
| Eingebettete Anzeigen, die auf den Status pro Publisher beschränkt sind | CHIPS |
| Über einen Identitätsanbieter anmelden | FedCM |
| Eingebettete Inhalte werden an unterschiedlichen, aber ähnlichen Ursprüngen gehostet. | Storage Access API mit Gruppen ähnlicher Websites |
| Einbettung von Inhalten mit anmeldungsabhängigen Einstellungen (z. B. Videoinhalte ohne Werbung oder Einstellungen für Sprache/Untertitel) |
Storage Access API |
| Kommentar-Widget für soziale Medien mit Anmeldung | Storage Access API |
API für eingebettete Anwendungsfälle von Drittanbietern auswählen
In diesem Abschnitt wird die Auswahl einer geeigneten alternativen API beschrieben und die empfohlenen APIs erläutert.
Das folgende Flussdiagramm hilft Ihnen bei der Auswahl der verfügbaren Optionen:
Das Flussdiagramm stellt drei Hauptfragen, die wir uns genauer ansehen und warum in jedem Fall eine bestimmte API empfohlen wird.
1. Sind die Cookies für die eingebettete Website spezifisch?
Viele Einbettungen von Drittanbietern werden unabhängig auf Websites ohne Bezug verwendet. Chat-Widgets für den Kundensupport erfordern beispielsweise häufig Cookies, aber diese Cookies müssen nicht zwischen zwei völlig verschiedenen Organisationen ausgetauscht werden, die beide dieselbe Chat-Widget-Lösung verwenden. In vielen Fällen würde das Teilen von Cookies sogar gar nicht erst zugelassen werden.
Wenn Sie auf anderen Websites den Einbettungsdienst eines Drittanbieters anbieten und dieser auf Cookies basiert, prüfen Sie, ob diese Cookies spezifisch für den Dienst auf der Website sind, auf der er eingebettet ist. Werden sie jemals von Instanzen deiner Einbettung auf anderen Websites geteilt?
Wenn die Cookies nicht freigegeben werden müssen, ist die Partitionierung der Cookies mithilfe von CHIPS die einfachste Option. Diese API verknüpft Drittanbieter-Cookies mit der Website der obersten Ebene, anstatt sie für alle Websites freizugeben, die dieselbe Einbettung von Drittanbieter-Websites verwenden. CHIPS ist einfach zu implementieren, da den vorhandenen Cookies nur ein zusätzliches Partitioned-Attribut hinzugefügt werden muss. Dadurch können die eingebetteten Dienste weiterhin den Status speichern, aber gemeinsam genutzter websiteübergreifender Speicher entfernt werden, der websiteübergreifendes Tracking zulässt.
Websites sollten außerdem prüfen, ob Cookies aus den richtigen Gründen verwendet werden. Cookies sollten nur verwendet werden, wenn sie gesetzt sind oder zusammen mit HTTP-Anfragen gesendet werden müssen. Falls dies nicht der Fall ist und Cookies nur als praktische Speicheroption verwendet werden, sollten Sie stattdessen die verschiedenen Speicher-APIs in Betracht ziehen. So bleiben Daten lokal, wenn sie nicht gesendet werden müssen. Die Speicher-APIs sind in allen gängigen Browsern bereits partitioniert, ähnlich wie CHIPS die Cookies partitioniert.
2. Sind die Cookies für einen externen Identitätsanbieter?
Eine gängige Verwendung von Drittanbieter-Cookies in Einbettungen ist die Bereitstellung von Anmeldefunktionen, die von einem Drittanbieter wie Über Google anmelden verwaltet werden. Partitionierte Cookies sind in diesem Fall keine Option.
Federated Credential Management (FedCM) ist eine spezielle API speziell für diesen Anwendungsfall und funktioniert ohne Drittanbieter-Cookies. Wenn FedCM vom Identitätsanbieter unterstützt wird, sind Drittanbieter-Cookies möglicherweise nicht mehr erforderlich.
Weitere Informationen dazu, wie sich die Auswirkungen der Einstellung von Drittanbieter-Cookies auf die Workflows zur Anmeldung beheben lassen, finden Sie im Leitfaden zur Identitätsbestätigung.
3. Werden die Cookies bei einer kleinen Anzahl ähnlicher Websites eingesetzt?
Wenn keine der vorherigen Optionen als Ersatz für Cookies geeignet ist, müssen Sie den Zugriff auf Drittanbieter-Cookies für die Einbettung wieder aktivieren. Diese Funktion kann für bestimmte, kontrollierte Anwendungsfälle mit der Storage Access API aktiviert werden. Diese API aktiviert den uneingeschränkten Zugriff auf Drittanbieter-Cookies (je nach Kontrolle) und stellt somit die leistungsstärkste Option dar. Daher wird empfohlen, sie zu vermeiden, wenn eine restriktivere Alternative ausreicht.
Für die Verwendung der Storage Access API gelten einige Anforderungen:
- Der Nutzer muss zuvor die Website des eingebetteten Inhalts auf oberster Ebene besucht haben. Wenn Sie beispielsweise ein Kommentarsystem einbetten, muss der Nutzer auch die Website dieses Kommentarsystems besuchen.
- Der Nutzer muss mit der Einbettung interagieren, bevor Cookies geteilt werden können. Daher ist es unter Umständen nicht möglich, den kompletten eingebetteten Inhalt vor der Nutzerinteraktion zu laden.
- Unter Umständen muss der Nutzer das Teilen von Cookies über ein Browser-Pop-up genehmigen, insbesondere beim ersten Aufruf und in regelmäßigen Abständen danach.
- Auf der Einbettungswebsite müssen möglicherweise auch zusätzliche Sandbox-Attribute festgelegt werden.
Durch diese Einschränkungen wird sichergestellt, dass Drittanbieter-Cookies nur dann wirksam wieder aktiviert werden können, wenn Nutzer und Website dies erwarten. In bestimmten Szenarien können die Nutzeraktionen jedoch übersprungen werden. Wenn der Nutzer beispielsweise erst kürzlich den Zugriff genehmigt hat, ist es möglicherweise nicht erforderlich, ihn für einen bestimmten Zeitraum, der vom Browser definiert wird, erneut aufzurufen.
Ein weiteres Szenario, in dem der Nutzer dies wahrscheinlich erwartet, sind ähnliche Websites. Beispielsweise verwenden einige Organisationen eine Reihe verschiedener Ursprünge, die vom Browser als websiteübergreifend betrachtet werden, sodass die Verwendung von Cookies als Drittanbieter behandelt wird. Beispiele hierfür sind Marken mit länderspezifischen Websites (z. B. example.com und example.co.uk) oder markenspezifische Websites (z. B. example.car und example.house).
Falls es nur wenige ähnliche Websites gibt, können Sie Gruppen ähnlicher Websites verwenden. Websites werden an Chrome gesendet, damit Chrome erkennt, dass sie zusammenhängen. Dies ermöglicht den nutzerfreundlicheren Zugriff auf die Storage Access API mit weniger Aufforderungen durch die Nutzer.
Bei Websites ohne Bezug, die eigentlich Drittanbieter sind, und für die ein vollständiger Zugriff auf Drittanbieter-Cookies erforderlich ist, weil die alternativen APIs nicht ausreichen, unterliegt die Verwendung der Storage Access API vollständigen Anforderungen und Aufforderungen.
Vergleich der verschiedenen APIs
Jede der Lösungen hat leicht unterschiedliche Eigenschaften und Einschränkungen, die sie zu einer besseren Wahl für bestimmte Anwendungsfälle machen. In der folgenden Tabelle sind die wichtigsten Unterschiede zusammengefasst:
| CHIPS | Partitionierter Speicher | FedCM | Storage Access API mit verwandten WebSite-Gruppen | Storage Access API | |
|---|---|---|---|---|---|
| Der Nutzer muss nicht zuvor auf die eingebettete Partei als Website der obersten Ebene zugegriffen haben. | |||||
| Erfordert keine Aufforderung durch den Nutzer zur Genehmigung des Zugriffs | |||||
| Nutzer müssen nicht mit eingebetteten Inhalten interagieren | (Dies gilt auch für eingebettete Websites mit Zugriff auf oberster Ebene.) |
||||
| Implementierungsaufwand | Sehr niedrig | Niedrig | Hoch | Mittel | Mittel |
| Können verwendet werden, um Cookies für mehrere Websites bzw. Ursprünge der obersten Ebene zu nutzen | (Angebot wird derzeit geprüft.) |
||||
| Verfügbar in anderen Browsern als Chromium | (Falls zurück zur Storage Access API.) |
Browserübergreifende Anwendungsfälle
Wie in der letzten Zeile der Tabelle erwähnt, ist die Browserkompatibilität einer der wichtigsten Faktoren bei der Entscheidung für eine Lösung. Einige der APIs (CHIPS, FedCM, Related WebSite Sets) sind nur in Chromium-Browsern verfügbar. Die einzigen derzeit zwei browserübergreifenden Lösungen sind partitionierte Storage-APIs (wenn keine Cookies erforderlich sind) oder die Storage Access API (wenn Cookies erforderlich sind).
Wie bereits erwähnt, unterliegt die Storage Access API jedoch einer Reihe von Einschränkungen, die sich auf die Nutzererfahrung Ihrer Website auswirken können. Das Chrome-Team hat weitere APIs hinzugefügt, die auf bestimmte Anwendungsfälle zugeschnitten sind und ähnliche Funktionen bieten wie Drittanbieter-Cookies. Daher wird empfohlen, die besten Optionen zu berücksichtigen und als progressive Verbesserungen zu betrachten, mit einem Fallback auf die Storage Access API für Browser, die keine Unterstützung bieten.
Da Cookies aus verschiedenen Gründen (z. B. Browsereinstellungen oder Erweiterungen) blockiert werden können, reicht die Funktionserkennung der API-Unterstützung unter Umständen nicht aus. Stattdessen sollten Sie testen, ob die erwarteten Cookies vorhanden sind, und, falls nicht, auf den Storage Access API-Workflow zugreifen, um Zugriff auf Drittanbieter-Cookies anzufordern.
Jetzt handeln!
Wenn die Einbettung von Inhalten durch Drittanbieter ohne den Einsatz von Drittanbieter-Cookies nicht mehr funktioniert, gibt es mehrere Lösungen, die mögliche Auswirkungen beheben können, wie in diesem Video beschrieben. Der richtige Zeitpunkt, Ihren Dienst zu prüfen und sich auf die Einstellung von Drittanbieter-Cookies vorzubereiten, ist jetzt.
Für alle, die Probleme mit ihren Einbettungen haben, während in Chrome die Entfernung von Drittanbieter-Cookies getestet wird, gibt es eine Reihe von kurzfristigen Optionen für die Unterstützung bei der Migration zu Alternativen, die in diesem Beitrag beschrieben werden. Weitere Informationen finden Sie in der Dokumentation zur Bewahrung kritischer Nutzerfreundlichkeit.
Wenn Sie Fragen zu Anwendungsfällen für Einbettungen von Drittanbietern haben, die in diesem Leitfaden nicht behandelt werden, können Sie in unserem Entwickler-Support-Repository ein neues Problem mithilfe des Tags „Einstellung von Drittanbieter-Cookies“ melden.