Drittanbieter-Cookies können durch Browsereinschränkungen, Nutzereinstellungen, Entwickler-Flags oder Unternehmensrichtlinien blockiert werden.
Sie müssen dafür sorgen, dass Ihre Website oder Ihr Dienst allen Nutzern eine hervorragende Erfahrung bietet, unabhängig davon, ob Drittanbieter-Cookies verfügbar sind.
Auf dieser Seite finden Sie Informationen zu häufigen Nutzeraktionen, die betroffen sein können, wenn Drittanbieter-Cookies blockiert werden.
Häufige Kaufprozesse
Viele Zahlungs- und Shopping-Abläufe sind auf Drittanbieter-Cookies angewiesen. In der folgenden Tabelle sind einige Nutzeraktionen aufgeführt, die betroffen sein können, wenn Drittanbieter-Cookies deaktiviert sind. Außerdem werden alternative APIs vorgeschlagen, die Entwickler verwenden können, um Probleme zu vermeiden. Diese Liste ist möglicherweise unvollständig und kann aktualisiert werden, sobald weitere Privacy Sandbox-Lösungen verfügbar sind.
Zahlungsbezogene Abläufe testen
Am besten testen Sie, ob Ihre Nutzerabläufe von Einschränkungen für Drittanbieter-Cookies betroffen sind, indem Sie sie mit aktiviertem Testflag für Drittanbieter-Cookies durchlaufen.
Damit Ihre Website wie erwartet funktioniert, testen Sie den folgenden Ablauf mit eingeschränkten Drittanbieter-Cookies:
- Websiteübergreifende Kaufabwicklung: Testen Sie die Zahlungsabläufe, die auf einem Drittanbieter für Zahlungen basieren, z. B. Mit <example-provider> bezahlen. Achten Sie darauf, dass:
- Die Weiterleitung erfolgt.
- Das Zahlungsportal wird korrekt geladen.
- Der Zahlungsvorgang kann ohne Fehler abgeschlossen werden.
- Der Nutzer wird wie erwartet zu Ihrer Website zurückgeleitet.
- Zahlungsdashboards: Testen Sie, ob die Transaktions-Dashboard-Widgets wie erwartet funktionieren, wenn Drittanbieter-Cookies eingeschränkt sind. Prüfen Sie, ob der Nutzer Folgendes tun kann:
- Rufen Sie das Dashboard auf.
- Alle Zahlungen werden wie erwartet angezeigt.
- Sie können fehlerfrei zwischen den verschiedenen Abschnitten des Dashboards wechseln, z.B. zwischen dem Transaktionsverlauf und den Zahlungsdetails.
- Zahlungsmethoden verwalten: Testen Sie, ob die Widgets zur Verwaltung von Zahlungsmethoden wie erwartet funktionieren. Wenn Drittanbieter-Cookies blockiert sind, testen Sie Folgendes:
- Das Hinzufügen oder Löschen einer Zahlungsmethode funktioniert wie erwartet.
- Die Zahlung mit zuvor gespeicherten Zahlungsmethoden ist davon nicht betroffen.
- Betrugserkennung: Vergleichen Sie, wie Ihre Lösung zur Betrugserkennung mit und ohne Drittanbieter-Cookies funktioniert.
- Sind zusätzliche Schritte erforderlich, wenn Drittanbieter-Cookies blockiert werden, was zu zusätzlichem Aufwand für die Nutzer führt?
- Kann es weiterhin verdächtige Muster erkennen, wenn Drittanbieter-Cookies im Browser blockiert werden?
- Personalisierte Schaltfläche für die Kasse: Testen Sie, ob Zahlungsschaltflächen korrekt gerendert werden, wenn Drittanbieter-Cookies eingeschränkt sind.
- Kann der Nutzer Käufe abschließen, auch wenn auf der personalisierten Schaltfläche nicht seine bevorzugte Methode angezeigt wird?
Websiteübergreifende Zahlungsabwicklung
Einige Zahlungsanbieter verwenden möglicherweise Drittanbieter-Cookies, damit Nutzer auf ihr Konto auf mehreren Händlerwebsites zugreifen können, ohne sich noch einmal authentifizieren zu müssen. Diese Nutzerinteraktion kann für Nutzer, die ohne Drittanbieter-Cookies surfen, beeinträchtigt sein.
Eingebettete Zahlungsformulare
Betrachten Sie die folgenden Domains:
payment-provider.examplebietet Zahlungsdienste für Händlerwebsites an und speichert Zahlungs- und Sitzungsdaten von Nutzern.merchant.exampleist eine Website, auf der ein vonpayment-provider.examplebereitgestelltes Bezahlformular eingebettet ist.
Ein Nutzer hat sich gerade bei payment-provider.example angemeldet (z. B. beim Abschließen des Bezahlvorgangs auf einer anderen Website). Der Nutzer startet den Bezahlvorgang auf merchant.example.
Wenn Drittanbieter-Cookies verfügbar sind, hat das auf merchant.example eingebettete payment-provider.example-Kassenformular im Kontext der obersten Ebene Zugriff auf sein eigenes Sitzungscookie auf oberster Ebene, das auf payment-provider.example festgelegt ist.
Wenn Drittanbieter-Cookies jedoch blockiert werden, kann das eingebettete Element nicht auf seine eigenen Top-Level-Cookies zugreifen.
Anpassbare Lösung mit FedCM
payment-provider.example sollte die Implementierung von FedCM als Identitätsanbieter in Betracht ziehen. Diese Vorgehensweise kann in folgenden Fällen sinnvoll sein:
payment-provider.exampleist auf nicht verwandten Websites von Drittanbietern eingebettet.payment-provider.exampleist auf mehr als fünf ähnlichen Websites eingebettet.
Der Hauptvorteil von FedCM besteht darin, dass die Benutzeroberfläche Nutzern mehr Kontext für ihre Entscheidungen bieten kann. Mit der Einwilligung des Nutzers ermöglicht FedCM den Austausch von benutzerdefinierten Daten zwischen der vertrauenden Partei (merchant.example) und dem Identitätsanbieter (payment-provider.example). Die vertrauende Partei kann einen oder mehrere Identitätsanbieter unterstützen und die FedCM-Benutzeroberfläche wird nur unter bestimmten Bedingungen angezeigt.
Je nach Bedarf können Entwickler zwischen dem passiven Modus wählen, in dem die FedCM-Aufforderung automatisch angezeigt wird, wenn der Nutzer beim Identitätsanbieter angemeldet ist, oder dem aktiven Modus, in dem der Anmeldevorgang nach einer Aktion des Nutzers ausgelöst wird, z. B. durch Klicken auf eine Schaltfläche zum Bezahlen.
FedCM dient auch als Vertrauenssignal für die Storage Access API (SAA). Dadurch kann das eingebettete Element auf seine nicht partitionierten Cookies der obersten Ebene zugreifen, nachdem der Nutzer zugestimmt hat, sich beim Anbieter des eingebetteten Elements anzumelden, ohne dass eine zusätzliche Nutzeraufforderung erforderlich ist.
Lösung mit Fokus auf Speicherzugriff
Eine weitere API, die Sie in Betracht ziehen sollten, ist die Storage Access API (SAA).
Über SAA wird der Nutzer aufgefordert, dem payment-provider.example-Einbettungscode den Zugriff auf seine eigenen Cookies der obersten Ebene zu erlauben. Wenn der Nutzer den Zugriff genehmigt, kann das Formular wie bei verfügbaren Drittanbieter-Cookies gerendert werden.
Wie bei FedCM muss der Nutzer die Anfrage auf jeder neuen Website genehmigen, auf der payment-provider.example eingebettet ist. SAA-Demo
Wenn der Standard-SAA-Prompt nicht Ihren Anforderungen entspricht, können Sie FedCM implementieren, um die Nutzerfreundlichkeit zu verbessern.
Nutzerfreundlichkeit auf einer kleinen Anzahl verwandter Websites verbessern
Wenn sowohl die Händlerwebsite als auch der Zahlungsanbieter zum selben Unternehmen gehören, können Sie die API für Gruppen ähnlicher Websites verwenden, um Beziehungen zwischen Domains zu deklarieren. Das kann dazu beitragen, die Reibung für Nutzer zu verringern. Wenn sich insurance.example und payment-portal-insurance.example beispielsweise in derselben RWS befinden, erhält payment-portal-insurance.example automatisch Zugriff auf seine eigenen Top-Level-Cookies, wenn innerhalb des payment-portal-insurance.example-Embeds Speicherzugriff angefordert wird.
Andere experimentelle Lösungen
Eine weitere experimentelle API, die in diesem Szenario hilfreich sein könnte, ist Partitioned Popins. Die API befindet sich derzeit in der aktiven Entwicklungsphase.
Bei Partitioned Popins kann der Nutzer aufgefordert werden, seine Anmeldedaten einzugeben, um sich in einem Pop-in, das von merchant.example geöffnet wurde, in payment-provider.example anzumelden. Der Speicher wird nach dem Opener merchant.example partitioniert. In diesem Fall hat die payment-provider.example-Einbettung Zugriff auf die im Pop-in festgelegten Speicherwerte. Bei dieser Lösung muss sich der Nutzer auf jeder Website beim Zahlungsdienstleister anmelden.
Zahlungslink-Checkouts
Einige Zahlungsanbieter bieten einen Dienst an, mit dem ein Zahlungslink generiert wird, über den eine benutzerdefinierte Zahlungsseite für die Website eines Händlers aufgerufen werden kann. Ein Zahlungslinkdienst und ein Nutzerportal für den Zahlungsanbieter werden häufig auf verschiedenen Domains implementiert, z. B. payment-provider.example und payment-link.example.
Mit payment-link.example wird ein von payment-provider.example bereitgestelltes Abrechnungsformular eingebettet. Dies ist eine Variante des Musters eingebettetes Abrechnungsformular.
FedCM,
SAA
und
RWS
sind ebenfalls gute Optionen für diesen Fall.
Zahlungs-Dashboards
Einige Anwendungen zeigen ihren Nutzern Transaktions-Dashboards auf mehreren Websites an, die eine zentrale Ansicht ihrer Finanzaktivitäten bieten. Dazu muss das Dashboard auf nutzerspezifische Daten in mehreren Domains zugreifen.
Betrachten Sie die folgenden Domains:
earnings.examplebietet ein Auszahlungs-Dashboard, das in verschiedene Webanwendungen eingebettet werden kann. In diesem Dienst werden Daten zu Nutzerumsätzen und Sitzungsinformationen gespeichert.catsitting.exampleunddogsitting.examplesind separate Websites, auf denen jeweils dasearnings.example-Dashboard eingebettet ist.
Ein Nutzer meldet sich in seinem earnings.example-Konto an. Wenn sie catsitting.example oder dogsitting.example aufrufen, können sie ihre Einnahmen sehen. Das eingebettete earnings.example-Dashboard basiert auf Top-Level-Cookies und zeigt die personalisierten Einnahmeninformationen des Nutzers an.
Wie in den anderen Beispielen hat das earnings.example-Einbettungselement keinen Zugriff auf seine Cookies der obersten Ebene, wenn Drittanbieter-Cookies deaktiviert sind.
Eigene Dashboards
Wenn alle drei Domains derselben Partei gehören, sollten Sie SAA zusammen mit RWS verwenden.
Mit SAA kann earnings.example mit Einwilligung des Nutzers auf sein Cookie der obersten Ebene zugreifen. Wenn diese Partei die earnings.example auf höchstens vier Domains verwendet, kann die Nutzerfreundlichkeit verbessert werden, indem Beziehungen zwischen ihnen mit RWS deklariert werden.
Wenn dieselbe Partei das Widget in mehr als fünf Domains einbettet, kann sie keine Beziehungen zwischen allen Einbettungswebsites und der Domain des Widgets deklarieren, da RWS nur bis zu sechs Websites in einem Set unterstützt – eine primäre und fünf zugehörige Websites.
Verteilung von skalierten Dashboards
In den folgenden Fällen sind SAA und RWS möglicherweise nicht die optimale Lösung:
- Sie stellen eine Dashboard-Lösung für Drittanbieterwebsites bereit.
- Sie haben mehr als fünf Websites, auf denen Ihr Dashboard-Widget eingebettet ist.
In diesem Fall sollte earnings.example erwägen, FedCM als Identitätsanbieter zu implementieren. Das bedeutet, dass sich der Nutzer mit einem von earnings.example verwalteten Konto bei dogsitting.example anmelden muss.
FedCM bietet eine anpassbare Benutzeroberfläche, mit der dem Nutzer deutlich mitgeteilt werden kann, welche Informationen weitergegeben werden. Mit FedCM kann dogsitting.example earnings.example anfordern, benutzerdefinierte Berechtigungen freizugeben, z. B. für den Zugriff auf Transaktionsdaten.
FedCM dient auch als Vertrauenssignal für die Storage Access API. Das earnings.example-Einbettungselement erhält ohne zusätzliche Nutzeraufforderung beim SAA-API-Aufruf Speicherzugriff auf seine eigenen Top-Level-Cookies.
Website-spezifische Dashboard-Einstellungen
Wenn die Daten nicht auf mehreren Websites geteilt werden müssen, sollten Sie in Erwägung ziehen, Ihre Cookies mit CHIPS zu partitionieren. CHIPS können nützlich sein, um standortspezifische Einstellungen zu speichern, z. B. das Dashboard-Layout oder Filter.
Zahlungsmethoden verwalten
Ein weiterer häufiger Ablauf ist, dass Nutzer ihre Zahlungsmethoden in einem eingebetteten Element ansehen und bearbeiten, ohne die Hostwebsite zu verlassen.
Betrachten Sie den folgenden Ablauf:
payments.examplebietet ein Tool zur Zahlungsverwaltung, das in Websites eingebettet werden kann. In diesem Dienst werden Zahlungsdaten und Sitzungsinformationen von Nutzern gespeichert.shop.exampleist eine Website, auf der das Toolpayments.exampleeingebettet ist. So können Nutzer bevorzugte Zahlungsmethoden, die mit ihremshop.example-Konto verknüpft sind, ansehen, bearbeiten oder auswählen.
Zahlungsdienstleister, die die Verwaltung von Zahlungsmethoden implementieren, sollten auch in Erwägung ziehen, mit FedCM ein Identitätsanbieter zu werden. Mit FedCM kann sich der Nutzer mit dem vom Identitätsanbieter (payments.example) verwalteten Konto beim Relying Party (shop.example) anmelden.
Mit der Einwilligung des Nutzers ermöglicht FedCM den Austausch benutzerdefinierter Daten zwischen der vertrauenden Partei und dem Identitätsanbieter. Der Hauptvorteil von FedCM besteht darin, dass die Benutzeroberfläche Nutzern mehr Kontext für ihre Entscheidungen bieten kann. Es dient auch als Vertrauenssignal für die Storage Access API, über die das eingebettete Element auf seine Cookies der obersten Ebene zugreifen kann.
Wenn Drittanbieter-Cookies deaktiviert sind, hat die payments.example-Einbettung keinen Zugriff auf die Cookies der obersten Ebene. In diesem Fall kann SAA durch Anfordern des Speicherzugriffs für einen ordnungsgemäßen Betrieb sorgen.
Manchmal müssen die im Einbettungscode festgelegten Informationen nicht auf anderen Websites geteilt werden. payments.example muss möglicherweise nur unterschiedliche Nutzereinstellungen für jede einzelne Einbettungswebsite speichern. In diesem Fall sollten Sie Cookies mit CHIPS partitionieren. Mit CHIPS ist der in payments.example auf shop.example eingebettete Cookie nicht für payments.example auf another-shop.example eingebettet zugänglich.
Eine weitere experimentelle API, die möglicherweise in diesem Nutzerfluss verwendet werden kann, ist Partitioned Popins.
Wenn sich der Nutzer in einem von shop.example geöffneten Pop-in in payments.example anmeldet, wird der Speicher nach dem Öffner partitioniert und das payments.example-Embed hat Zugriff auf die im Pop-in festgelegten Speicherwerte. Bei dieser Methode müssen Nutzer jedoch auf jeder Website Anmeldedaten eingeben, um sich beim Zahlungsanbieter anzumelden.
Betrugserkennung
Risikoanalysesysteme können die in Cookies gespeicherten Daten analysieren, um Muster zu erkennen, die von der Norm abweichen. Wenn ein Nutzer beispielsweise plötzlich seine Versandadresse ändert und mehrere große Käufe über ein neues Gerät tätigt, kann der potenzielle Betrugsrisiko-Score erhöht werden. Cookies zur Betrugserkennung sind in der Regel Drittanbieter-Cookies, die auf den Händlerwebsites von Zahlungsanbietern oder Widgets von Diensten zur Betrugsprävention gesetzt werden.
Einschränkungen für Drittanbieter-Cookies sollten die Systeme zur Betrugserkennung nicht beeinträchtigen, können aber zu zusätzlichen Problemen für Nutzer führen. Wenn das System aufgrund blockierter Cookies nicht sicher bestätigen kann, dass ein Nutzer legitim ist, sind möglicherweise zusätzliche Prüfungen erforderlich, z. B. die Identitätsüberprüfung.
Wenn Sie die Betrugserkennung unterstützen möchten, wenn Drittanbieter-Cookies blockiert werden, sollten Sie die Private State Tokens (PST) API in Ihre Lösung zur Betrugserkennung einbinden. Mit PST kann sich ein Zahlungsanbieter als Token-Aussteller registrieren und Nutzern Tokens gewähren, die nicht auf Drittanbieter-Cookies basieren. Diese Tokens können dann auf Händlerwebsites eingelöst werden, um zu prüfen, ob der Nutzer vertrauenswürdig ist. Weitere Informationen zur Implementierung finden Sie in der Entwicklerdokumentation zu PST.
Im Rahmen der Privacy Sandbox werden auch andere APIs zur Betrugsbekämpfung getestet.
Personalisierte Schaltfläche „Zur Kasse“
Auf Händlerwebsites eingebettete Zahlungs-Schaltflächen (z. B. Mit <bevorzugte Zahlungsmethode> bezahlen) basieren häufig auf websiteübergreifenden Informationen, die vom Zahlungsanbieter festgelegt werden. So können Nutzer mit ihrer bevorzugten Zahlungsmethode bezahlen. Wenn Drittanbieter-Cookies im Browser des Nutzers blockiert werden, kann sich das auf das Rendern personalisierter Zahlungsaufschaltflächen auswirken.
SAA kann zwar den Zugriff auf den Speicher ermöglichen, die erforderliche Aufforderung führt jedoch möglicherweise nicht zu einer optimalen Nutzererfahrung.
Wir arbeiten an einer potenziellen Lösung, die speziell auf diesen Anwendungsfall zugeschnitten ist: Fenced Frames mit lokalem, nicht partitioniertem Datenzugriff. Die API befindet sich derzeit in der aktiven Entwicklungsphase und Sie können ihre Zukunft mitgestalten. Probieren Sie es selbst aus und geben Sie Feedback.
Hilfe und Feedback
Wenn Sie Fragen oder Feedback zu den in diesem Leitfaden beschriebenen Nutzerpfaden oder APIs haben, können Sie uns Ihr Feedback mitteilen.