Freigegebener Speicher – Übersicht

Unbegrenzten, websiteübergreifenden Schreibzugriff auf den Speicher mit datenschutzfreundlichem Lesezugriff zulassen.

Implementierungsstatus

In diesem Dokument wird ein Vorschlag für nicht partitionierten, websiteübergreifenden Speicher beschrieben: die Shared Storage API.

  • Die Shared Storage API ist jetzt allgemein verfügbar.
  • Es ist eine Live-Demo verfügbar und Tests sind verfügbar:
    • Das Ausgabe-Gatter für die URL-Auswahl ist für lokale Tests ab Chrome M105 verfügbar.
    • Das Ausgabe-Gatter für die private Aggregation ist für lokale Tests ab Chrome M107 verfügbar.
    • Die Messung mit der Private Aggregation API ist jetzt allgemein verfügbar.
  • Chrome-Plattformstatus
Vorschlag Status
Berichte auf Ereignisebene für die Inhaltsauswahl (selectURL()) Verfügbar bis mindestens 2026
Budgetierung pro Website
Erläuterung		 Verfügbar in M119
Schreiben aus Antwortheadern zulassen
Erläuterung
GitHub-Problem		 Verfügbar in M124. Kann in M119-M123 manuell aktiviert werden
Zeitlimit für Beiträge zur privaten Aggregation
Erläuterung		 Verfügbar in M119
Debugging-Worklets mit Entwicklertools
Abschnitt		 Verfügbar in M120
Aktualisieren des Speicherlimits für freigegebenen Speicher auf 5 MB
Erläuterung		 Verfügbar in M124

Wozu brauchen wir diese API?

Um websiteübergreifendes Nutzer-Tracking zu verhindern, partitionieren Browser alle Arten von Speicher (Cookies, localStorage, Caches usw.). Es gibt jedoch eine Reihe legitimer Anwendungsfälle, die auf nicht partitioniertem Speicher basieren, was ohne die Hilfe neuer Web-APIs unmöglich wäre. Beispielsweise möchte ein Ersteller von Inhalten die Reichweite über verschiedene Websites hinweg messen, ohne Website-übergreifende Kennungen zu verwenden.

Mit der Shared Storage API können Websites nicht partitionierte websiteübergreifende Daten speichern und darauf zugreifen. Diese Daten müssen in einer sicheren Umgebung gelesen werden, um Datenlecks zu verhindern.

Sie können Daten im freigegebenen Speicher auf zwei Arten verwenden:

Zielgruppe

Es gibt viele verschiedene Arten von Unternehmen, die von der Shared Storage API profitieren können. Beispiel:

  • AdTech-Unternehmen können die Kampagnenreichweite messen, Frequency Capping festlegen und die Creatives rotieren, für die derzeit Drittanbieter-Cookies verwendet werden.
  • Zahlungsdienstleister können feststellen, ob es sich bei einem Nutzer um Bestandskund*innen handelt, und den Bezahlvorgang entsprechend anpassen.
  • Unternehmen für Websicherheit können benutzerdefinierte Logik entwickeln, um verdächtiges oder gefährliches Verhalten zu melden.

Suchen Sie in Ihrem Unternehmen nach websiteübergreifenden Speicherlösungen, die noch nicht angegangen werden? Anwendungsfall teilen

Anwendungsfälle

Die Shared Storage API ist auf viele Anwendungsfälle ausgelegt und ersetzt mehrere vorhandene Verwendungen von Drittanbieter-Cookies. Dazu zählen:

Anwendungsfall Beschreibung Ausgabegatter
Creative-Rotation Sie können Daten wie die Creative-ID, die Anzahl der Aufrufe und die Nutzerinteraktion speichern, um festzustellen, welche Creative-Nutzer auf verschiedenen Websites zu sehen sind. So können Sie ein Gleichgewicht zwischen den Aufrufen finden und eine Übersättigung bestimmter Inhalte vermeiden, um negative Nutzererfahrungen zu vermeiden. URL-Auswahl
A/B-Tests durchführen Sie können einen Nutzer einer Testgruppe zuweisen und diese Gruppe dann im freigegebenen Speicher für den websiteübergreifenden Zugriff speichern. URL-Auswahl
Nutzererfahrung für bekannte Kunden anpassen Sie können benutzerdefinierte Inhalte und Calls-to-Action basierend auf dem Registrierungsstatus eines Nutzers oder anderen Nutzerstatus teilen. URL-Auswahl
Maßnahmen gegen Missbrauch Unternehmen zur Bekämpfung von Missbrauch, Betrug und Websicherheit verwenden häufig proprietäre Techniken, um böswillige Nutzer zu erkennen – sowohl von automatisierten Bots als auch von echten Menschen, die versuchen, Schaden anzurichten. Hier können viele verschiedene Strategien getestet werden. Sie können beispielsweise das Ausgabe-Gatter für die URL-Auswahl verwenden, um eine Vertrauenswürdigkeitsbewertung des Nutzers zu codieren, oder das Ausgabe-Gatter „Private Aggregation“ verwenden, um Datasets zur Anomalieerkennung zu erstellen. URL-Auswahl, Private Aggregation API
Unique Reach messen Viele Produzenten und Werbetreibende von Inhalten möchten oft wissen, wie viele einzelne Nutzer ihre Inhalte gesehen haben. Mit dem freigegebenen Speicher können Sie Berichte dazu erstellen, wann ein Nutzer Ihre Anzeige, Ihr eingebettetes Video und Ihre Publikation zum ersten Mal gesehen hat. Außerdem lässt sich damit die doppelte Zählung desselben Nutzers auf einer anderen Website verhindern. So erhalten Sie einen aggregierten, ungenauen Bericht über die ungefähre Unique Reach. Private Aggregation API
Demografische Merkmale von Nutzern messen Produzenten von Inhalten möchten oft die demografischen Merkmale ihrer Zuschauer verstehen. Sie können den freigegebenen Speicher verwenden, um demografische Daten zu Nutzern in einem Kontext zu erfassen, in dem sie verfügbar sind, z. B. auf Ihrer Website mit selbst erhobenen Daten. Mithilfe von zusammengefassten Berichten können Sie diese Daten über viele andere Websites hinweg erfassen, zum Beispiel über eingebettete Inhalte. Private Aggregation API
Reichweite der Häufigkeit in K+ messen Dies wird manchmal als „effektive Häufigkeit“ bezeichnet. Es gibt oft eine Mindestanzahl von Aufrufen, bevor ein Nutzer bestimmte Inhalte erkennt oder sich an diese erinnert (oft im Zusammenhang mit Anzeigenaufrufen). Sie können den freigegebenen Speicher verwenden, um Berichte zu einzelnen Nutzern zu erstellen, die einen Inhalt mindestens K-mal gesehen haben. Private Aggregation API

Mit dem Vorschlag soll eine allgemeine API erstellt werden, die viele mögliche zukünftige Anwendungsfälle unterstützt. Dies ermöglicht weitere Experimente und Änderungen, um mit der Webumgebung zu wachsen.

Wie funktioniert freigegebener Speicher?

Mit freigegebenem Speicher können Sie fundierte Entscheidungen basierend auf websiteübergreifenden Daten treffen, ohne Nutzerinformationen wie den Browserverlauf oder andere personenbezogene Daten an eine eingebettete Website weiterzugeben oder Daten an Ihre eigenen Server zu exfiltrieren.

Sie können jederzeit in den freigegebenen Speicher schreiben, wie bei anderen JavaScript-Speicher-APIs wie „localStorage“ oder „indexedDB“. Im Gegensatz zu den anderen Storage-APIs können Sie die Werte für den freigegebenen Speicher nur in einer sicheren Umgebung lesen, die als Shared Storage-Worklet bezeichnet wird.

In Worklets fügen Sie Ihre Geschäftslogik hinzu. Innerhalb des Worklets dürfen Sie einen Wert aus dem freigegebenen Speicher lesen und verarbeiten. Sie können den genauen Wert jedoch nicht direkt an den Worklet-Aufrufer zurückgeben. Um nützliche Informationen aus dem Worklet zu extrahieren, gibt es eine Reihe von "Gatter". Es sind zwei Gates verfügbar, in Zukunft werden aber möglicherweise weitere hinzugefügt.

Die verfügbaren Ausgabegatter der Shared Storage API sind:

  • Websiteübergreifende URL-Auswahl: Sie können ein Worklet-Script ausführen, um anhand der gespeicherten Daten eine URL aus einer bereitgestellten Liste auszuwählen und den Inhalt dann in einem Fenced Frame zu rendern.
  • Verrauschte Aggregation mit der Private Aggregation API: Sie können ein Worklet ausführen, um websiteübergreifende Daten über die Private Aggregation API zu senden und einen zusammenfassenden Bericht zurückzugeben.

Shared Storage API testen

Die Shared Storage API für das Ausgabe-Gate der URL-Auswahl und das Ausgabe-Gatter für die private Aggregation stehen zum Testen zur Verfügung. Die Inhaltsauswahl kann in Chrome Canary/Dev/Beta M105+ und der Private Aggregation API getestet werden. Die Private Aggregation API ist für Tests in Chrome M107+ Canary und Dev verfügbar. Zum Testen der API aktivieren Sie das Test-Flag Privacy Sandbox Ads APIs unter chrome://flags/#privacy-sandbox-ads-apis.

Aktivieren Sie den Privacy Sandbox Ads APIs-Test, um diese APIs zu verwenden.

Demo verwenden

Eine Demo ist verfügbar und Sie können den Code auf GitHub überprüfen.

Diese Demo wurde aus der Perspektive eines Werbetreibenden, einer Anzeigentechnologie, eines Content-Distributors oder eines anderen Drittanbieterdienstes erstellt, der Informationen auf den Websites verschiedener Publisher speichern möchte. In der Demo wird der Code desselben Drittanbieters für jeden Anwendungsfall sowohl auf der Website von Publisher A als auch auf der Website von Publisher B ausgeführt. Rufe die Seiten des Publishers auf, um zu sehen, wie die Daten in einem websiteübergreifenden Kontext geteilt werden.

Die Demo enthält Anwendungsfälle für die Inhaltsauswahl und die private Aggregation.

In der Demo zur Inhaltsauswahl sind folgende Anwendungsfälle verfügbar: Anzeigen-Creatives rotieren, Nutzung für bekannte Kunden anpassen und A/B-Tests ausführen.

In der Demo für die private Aggregation können Sie sich Vorschauen der einzelnen Elemente Unique Reach messen und Reichweite der Häufigkeit in K+ ansehen. Ermitteln Sie die demografischen Merkmale Ihrer Nutzer.

Mit den Entwicklertools Fehler in Worklets für freigegebenen Speicher beheben

Um die Worklets des freigegebenen Speichers zu überprüfen, die auf der Seite gestartet wurden, auf der Sie sich befinden, können Sie den Tab „Quellen“ im Steuerfeld „Entwicklertools“ aufrufen und den Haltepunkt „Shared Storage Worklet / Script First Statement“ hinzufügen. Dieser Haltepunkt pausiert die anfängliche Modulskriptausführung oder kurzlebige Worklets beim Start.

Debugging eines Worklets für freigegebenen Speicher durch Hinzufügen eines Listeners auf Ereignisebene
Einem freigegebenen Speicher-Worklet kann ein Haltepunkt hinzugefügt werden.

Außerdem werden auf der Seite chrome://inspect/#shared-storage-worklets alle aktiven Worklets im freigegebenen Speicher von allen Seiten angezeigt.

Reagieren und Feedback geben

Das Angebot für den freigegebenen Speicher wird derzeit diskutiert und kann sich in Zukunft ändern. Wenn Sie diese API testen und Feedback haben, freuen wir uns darauf, von Ihnen zu hören.