Drittanbieter-Cookies werden vielfältig eingesetzt, sind aber auch ein wichtiger Erfolgsfaktor für websiteübergreifendes Tracking.
Chrome bietet Nutzern eine neue Nutzererfahrung mit Drittanbieter-Cookies. Sie müssen Ihre Website für Nutzer vorbereiten, die ohne Drittanbieter-Cookies im Internet surfen.
Auf dieser Seite finden Sie Informationen zu datenschutzfreundlichen Lösungen für eingebettete Szenarien, in denen bisher Drittanbieter-Cookies verwendet wurden, sowie Strategien, mit denen Sie die für Ihre Anforderungen am besten geeignete Lösung auswählen können.
Eingebettete Dienste oder Einbettungen umfassen Inhalte von Drittanbietern (wie Videos, Karten), interaktive Komponenten (wie Chat, Kommentarsysteme oder Zahlungsdienste), Anmeldedienste und mehr.
Die meisten Schritte zur Umstellung von Drittanbieter-Cookies müssen von den Entwicklern von eingebetteten Inhalten übernommen werden, nicht von Websites, die eingebettete Inhalte hosten. In diesem Leitfaden werden in erster Linie Lösungen für Entwickler erläutert, die eingebettete Dienste erstellen.
Wenn deine Website auf einer Einbettung basiert, die Drittanbieter-Cookies verwendet, solltest du deine mit eingebetteten Inhalten zusammenhängenden Prozesse prüfen und testen. Wenn du Probleme feststellst, wende dich an die Anbieter von Einbettungen.
Einbettungsbezogene Nutzerpfade prüfen und testen
Ob deine Einbettungen von Drittanbieter-Cookies betroffen sind, kannst du am besten feststellen, indem du die Aufrufabfolge von Drittanbieter-Einbettungen testest, indem du das Kennzeichen für das Testen von Drittanbieter-Cookies aktiviert lässt.
Nachdem du die Nutzung von Drittanbieter-Cookies eingeschränkt hast, solltest du folgende gängige Szenarien für die Einbettung testen:
- Chat-Widgets:Können Sie eine Chatsitzung starten? Können Sie die Seite aktualisieren, ohne die Sitzung zu verlieren? Können Sie andere Seiten aufrufen und die Sitzung beibehalten?
- Eingebettete Inhalte:Kannst du Videos oder andere eingebettete Inhalte ansehen? Werden die Einstellungen der Nutzer wie Sprache oder Untertitel beibehalten? Werden Anzeigen zur erwarteten Zeit eingeblendet, zum Beispiel wenn sie nicht als Premium-Abonnent angezeigt werden?
- Anmeldung:Funktionieren Anmeldungen – einschließlich Anmeldungen bei der Einmalanmeldung (SSO) – für Einbettungen, die sie unterstützen? Werden sie durch Seitenaktualisierungen und Navigation zu Seiten beibehalten, die dieselben Einbettungen verwenden?
- Kommentar-Widgets:Kannst du Kommentare hinterlassen, mit „Mag ich“ bewerten und positiv bewerten?
- Eingebettete Zahlungslösungen:Können Zahlungen erfolgreich ausgeführt werden?
In den nächsten Abschnitten finden Sie genauere Informationen dazu, wie sich diese Abläufe auswirken können.
Gängige Anwendungsfälle
Es gibt eine Reihe von APIs, die für Einbettungen verwendet werden können, für die bisher Drittanbieter-Cookies verwendet wurden. In der folgenden Tabelle sind einige gängige Workflows und die empfohlenen APIs aufgeführt, die als allgemeine Zusammenfassung verwendet werden können. In den folgenden Abschnitten werden die Gründe für diese Empfehlungen erläutert.
| Anwendungsfall | Empfohlene API für die Verwendung von Drittanbieter-Cookies |
|---|---|
| Chat-Widget | CHIPS |
| Karteneinbettungen | CHIPS |
| Sandbox-Domains für nicht vertrauenswürdige Nutzerinhalte wie googleusercontent.com und githubusercontent.com, deren Status vom Publisher festgelegt werden muss |
CHIPS |
| Eingebettete Anzeigen, deren Status auf Ebene des Publishers beschränkt werden muss | CHIPS |
| Über einen Identitätsanbieter anmelden | FedCM |
| Einbettungen, die von unterschiedlichen, aber verwandten Ursprüngen gehostet werden | Storage Access API mit Gruppen ähnlicher Websites |
| Eingebettete Inhalte mit anmeldebasierten Einstellungen (z. B. Videoinhalte ohne Werbung oder Sprach-/Untertiteleinstellungen) |
Storage Access API |
| Kommentar-Widget für soziale Medien erfordert Anmeldung | Storage Access API |
API für eingebettete Anwendungsfälle von Drittanbietern auswählen
In diesem Abschnitt erfahren Sie, wie Sie eine geeignete alternative API auswählen und welche APIs empfohlen werden.
Das folgende Flussdiagramm hilft bei der Auswahl der verfügbaren Optionen:
<ph type="x-smartling-placeholder">
<ph type="x-smartling-placeholder">Das Flussdiagramm stellt drei Hauptfragen, die wir uns genauer ansehen werden und warum eine bestimmte API jeweils empfohlen wird.
1. Sind die Cookies für die einbettende Website spezifisch?
Viele Einbettungen von Drittanbietern werden unabhängig auf Websites ohne Bezug verwendet. Chat-Widgets für den Kundensupport benötigen beispielsweise häufig Cookies, damit sie funktionieren. Sie müssen diese Cookies jedoch nicht mit zwei völlig verschiedenen Organisationen teilen, die beide zufällig dieselbe Chat-Widget-Lösung verwenden. Tatsächlich wäre in vielen dieser Fälle sogar die Vorliebe, die Freigabe von Cookies nicht zuzulassen.
Wenn du auf anderen Websites einen Einbettungsdienst eines Drittanbieters anbietest und dieser auf Cookies nutzt, solltest du prüfen, ob diese Cookies für den jeweiligen Dienst der Website spezifisch sind, auf der es eingebettet ist. Werden sie jemals von Instanzen deiner eingebetteten Inhalte auf anderen Websites geteilt?
Wenn die Cookies nicht gemeinsam genutzt werden müssen, ist das Partitionieren von Cookies mithilfe von CHIPS die einfachste Option. Diese API verknüpft Drittanbieter-Cookies mit der Top-Level-Website, anstatt sie für alle Websites freizugeben, die dieselbe Drittanbieter-Einbettung verwenden. CHIPS ist einfach zu implementieren, da den vorhandenen Cookies nur ein zusätzliches Partitioned-Attribut hinzugefügt werden muss. Dadurch kann der Status weiterhin von den eingebetteten Diensten gespeichert werden, allerdings wird der freigegebene websiteübergreifende Speicher entfernt, der websiteübergreifendes Tracking ermöglichen würde.
Websites sollten auch prüfen, ob Cookies aus den richtigen Gründen verwendet werden. Cookies sollten nur verwendet werden, wenn sie festgelegt wurden oder mit HTTP-Anfragen gesendet werden müssen. Wenn 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-Cookies partitionieren.
2. Sind die Cookies für einen externen Identitätsanbieter gedacht?
Drittanbieter-Cookies in Einbettungen werden häufig verwendet, um Log-in-Funktionen bereitzustellen, die von einem Drittanbieter für die Anmeldung verwaltet werden, z. B. Über Google anmelden. Partitionierte Cookies kommen in diesem Fall nicht infrage.
Federated Credential Management (FedCM) ist eine spezielle API für diesen Anwendungsfall und funktioniert ohne Drittanbieter-Cookies. Wenn FedCM vom Identitätsanbieter unterstützt wird, sind dadurch möglicherweise keine Drittanbieter-Cookies mehr erforderlich.
Weitere Informationen dazu, wie Sie die Auswirkungen von Drittanbieter-Cookies auf die Anmeldeworkflows beheben, finden Sie im Leitfaden zur Identitätsbestätigung.
3. Werden die Cookies bei einer kleinen Anzahl verwandter Websites verwendet?
Wenn keine der vorherigen Optionen als Ersatz für Cookies geeignet ist, musst du den Zugriff auf Drittanbieter-Cookies für die Einbettung wieder aktivieren. Diese Option kann in bestimmten, kontrollierten Anwendungsfällen mit der Storage Access API aktiviert werden. Diese API aktiviert den vollständigen Zugriff auf Drittanbieter-Cookies (je nach Kontrolle) wieder und ist somit die leistungsstärkste Option. Daher empfehlen wir, diese Option zu vermeiden, wenn eine restriktivere Alternative ausreichen würde.
Für die Verwendung der Storage Access API gelten bestimmte Voraussetzungen:
- Der Nutzer muss die Website der Einbettung zuvor auf der obersten Ebene besucht haben. Wenn der Nutzer beispielsweise ein Kommentarsystem einbettet, muss der Nutzer auch die Website dieses Systems besuchen.
- Der Nutzer muss mit der Einbettung interagieren, bevor Cookies geteilt werden können. Das bedeutet, dass der vollständige eingebettete Inhalt vor der Nutzerinteraktion möglicherweise nicht geladen werden kann.
- Unter Umständen muss der Nutzer der Freigabe von Cookies über ein Pop-up-Fenster des Browsers zustimmen, insbesondere bei der ersten Instanz und danach in regelmäßigen Abständen.
- Möglicherweise müssen für die Website, auf der die Website eingebettet wird, auch zusätzliche Sandbox-Attribute festgelegt werden.
Diese Einschränkungen sorgen dafür, dass Drittanbieter-Cookies nur dann wieder aktiviert werden können, wenn der Nutzer und die Website dies erwarten. In bestimmten Fällen werden die Nutzeraktionen jedoch übersprungen. Wenn der Nutzer beispielsweise erst kürzlich den Zugriff genehmigt hat, ist es möglicherweise nicht erforderlich, ihn für einen bestimmten Zeitraum (wie vom Browser definiert) erneut anzufordern.
Ein weiteres Szenario, bei dem der Nutzer dies wahrscheinlich erwartet, sind ähnliche Websites. Einige Organisationen verwenden beispielsweise unterschiedliche Ursprünge, die vom Browser als websiteübergreifend betrachtet werden. Daher wird die Verwendung von Cookies hier als Drittanbieter behandelt. Beispiele hierfür sind Marken mit länderspezifischen Websites (z. B. example.com und example.co.uk) oder markenspezifischen 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 weiß, dass sie zusammenhängen. So ist der Zugriff auf die Storage Access API benutzerfreundlicher und mit weniger Aufforderungen von Nutzern.
Bei Websites ohne Bezug auf Drittanbieter, für die ein uneingeschränkter Zugriff auf Drittanbieter-Cookies erforderlich ist, weil die alternativen APIs nicht ausreichen, unterliegt die Verwendung der Storage Access API den vollständigen Anforderungen und Aufforderungen.
Vergleich der verschiedenen APIs
Jede der Lösungen hat geringfügig unterschiedliche Eigenschaften und Einschränkungen, die sie zu einer besseren Wahl für bestimmte Anwendungsfälle machen. In der folgenden Tabelle werden die wichtigsten Unterschiede zusammengefasst:
| CHIPS | Partitionierter Speicher | FedCM | Storage Access API mit zugehörigen Website-Gruppen | Storage Access API | |
|---|---|---|---|---|---|
| Der Nutzer muss nicht zuvor auf die eingebettete Partei als Website der obersten Ebene zugegriffen haben. | |||||
| Keine Nutzeraufforderung zum Genehmigen des Zugriffs erforderlich | |||||
| Der Nutzer muss nicht mit der Einbettung interagieren | (Kann auch für eingebettete Websites mit Zugriff auf oberster Ebene zutreffen) |
||||
| Implementierungsaufwand | Sehr niedrig | Niedrig | Hoch | Mittel | Mittel |
| Können verwendet werden, um Cookies für mehrere Websites/Ursprünge auf oberster Ebene freizugeben | (Angebot wird geprüft.) |
||||
| Verfügbar in anderen Browsern als Chromium | (Zurück zur Storage Access API) |
Browserübergreifende Anwendungsfälle
Wie in der letzten Tabellenzeile 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 beiden browserübergreifenden Lösungen sind derzeit partitionierte Speicher-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 auf Ihrer Website auswirken können. Das Chrome-Team hat an weiteren APIs gearbeitet, die auf bestimmte Anwendungsfälle zugeschnitten sind und eine ähnliche Nutzererfahrung bieten wie Drittanbieter-Cookies. Daher wird empfohlen, die besten Optionen zu erwägen und diese als schrittweise Verbesserungen zu betrachten, mit einem Fallback auf die Storage Access API für nicht unterstützte Browser.
Da Cookies aus verschiedenen Gründen blockiert werden können (z. B. Browsereinstellungen oder Erweiterungen), reicht die Funktionserkennung der API-Unterstützung möglicherweise nicht aus. Stattdessen sollten Sie testen, ob die erwarteten Cookies vorhanden sind. Falls nicht, greifen Sie auf den Storage Access API-Workflow zurück, um Zugriff auf Drittanbieter-Cookies anzufordern.
Jetzt handeln!
Wenn Ihre Drittanbieter-Einbettung ohne die Verwendung von Drittanbieter-Cookies nicht mehr funktioniert, gibt es mehrere Lösungen, mit denen sich mögliche Auswirkungen beheben lassen, wie in diesem Gespräch beschrieben. Jetzt ist es an der Zeit, Ihren Dienst auf Drittanbieter-Cookies zu prüfen. Es ist jetzt.
Für diejenigen, die aktuell Probleme mit ihren Einbettungen haben, während Chrome die Entfernung von Drittanbieter-Cookies testet, gibt es eine Reihe von kurzfristigen Möglichkeiten zur Unterstützung bei der Migration zu Alternativen, die in diesem Beitrag beschrieben werden. Weitere Informationen finden Sie in der Dokumentation zur Beibehaltung kritischer Nutzerfreundlichkeit.
Wenn Sie Fragen zu Anwendungsfällen für eingebettete Drittanbieter-Cookies haben, die in diesem Leitfaden nicht behandelt werden, können Sie über die Einstellung „Einstellung von Drittanbieter-Cookies“ ein neues Problem melden. in unserem Repository für den Entwicklersupport.