Known customers

The Shared Storage API is a Privacy Sandbox proposal for general purpose, cross-site storage, which supports many possible use cases. One example is identifying known customers, which is available to test in Chrome 104.0.5086.0 and later.

You can store whether the user has registered on your site into Shared Storage, then render a seperate element based on whether the user's stored status (is the user a "known" customer).

# Try setting known customers

To experiment with identifying known customers in Shared Storage, confirm you're using Chrome 104.0.5086.0 or later. Then enable the Privacy Sandbox Ads APIs experiment flag at chrome://flags/#privacy-sandbox-ads-apis.

You can also enable Shared Storage with the --enable-features=PrivacySandboxAdsAPIsOverride,OverridePrivacySandboxSettingsLocalTesting,SharedStorageAPI,FencedFrames flag in the command line.

# Experiment with code samples

You may want to render a different element based on whether the user was seen on a different site. For example, a payment provider may want to render a "Register" or "Buy now" button based on whether the user has registered at the payment provider's site. Shared storage can be used to set the user's status and customize their user experience based on that status.

In this example:

• known-customer.js is embedded in a frame. This script sets the options for which button should be displayed on a site, “Register” or “Buy now.”
• known-customer-worklet.js is the shared storage worklet that determines if the user is known. If the user is known, the information is returned. If the user is unknown, that information is returned to display the “Register” button and the user is marked as known for the future.

known-customer.js

// The first URL for the "register" button is rendered for unknown users.
const BUTTON_URLS = [
  { url: `https://${advertiserUrl}/ads/register-button.html` },
  { url: `https://${advertiserUrl}/ads/buy-now-button.html` },
];

async function injectButton() {
  // Load the worklet module
  await window.sharedStorage.worklet.addModule('known-customer-worklet.js');

  // Set the initial status to unknown ('0' is unknown and '1' is known)
  window.sharedStorage.set('known-customer', 0, {
    ignoreIfPresent: true,
  });

  // Run the URL selection operation to choose the button based on the user status
  const opaqueURL = await window.sharedStorage.selectURL('known-customer', BUTTON_URLS);

  // Render the opaque URL into a fenced frame
  document.getElementById('button-slot').src = opaqueURL;
}

injectButton();

known-customer-worklet.js

class SelectURLOperation {
  async run(urls) {
    const knownCustomer = await this.sharedStorage.get('known-customer');

    // '0' is unknown and '1' is known
    return parseInt(knownCustomer);
  }
}

register('known-customer', SelectURLOperation);

# Other use cases

Explore other Shared Storage use cases and code samples:

# Generate reports with Private Aggregation

• Unique reach measurement: Many content producers and advertisers often want to know how many unique people saw their content. You can use Shared Storage to report on the first time a user saw your ad, embedded video, publication, and prevent duplicative counting of that same user on a different site, giving you an aggregated noisy report of your approximate unique reach.
• Demographics measurement: Content producers often want to understand the demographics of their audience. You can use Shared Storage to record user demographic data in a context where you have it, such as your first-party site, and use aggregated reporting to report on it across many other sites, such as embedded content.
• K+ frequency measurement: Sometimes described as "effective frequency," there is often a minimum number views before a user will recognize or recall certain content (often in the context of advertisement views). You can use Shared Storage to build reports of unique users that have seen a piece of content at least K number of times.

# URL selection

• Frequency control: run a worklet script to select a URL from a provided list, based on the stored data, and then render that URL in a fenced frame. This has many possible uses, such as selecting new content when a frequency cap is reached.
• A/B testing: You can assign a user to an experiment group, then store that group in Shared Storage to be accessed cross-site.
• Creative rotation: You can store the creative rotation mode, and other metadata, to rotate the creatives across different sites.
• Known customer for payment provider: You can store whether the user has registered on your site into shared storage, then render a different element based on that stored status.

These are only some of the possible use cases for Shared Storage. We'll continue to add examples as we receive feedback and discover new use cases.

# Engage and share feedback

The Shared Storage proposal is under active discussion and subject to change in the future. If you try this API and have feedback, we'd love to hear it.

• GitHub: Read the proposal, raise questions and participate in discussion.
• Shared Storage API announcements: Join or view past announcements on our mailing list
• Developer support: Ask questions and join discussions on the Privacy Sandbox Developer Support repo.