The industry has been keeping a keen eye on the development of Google Privacy Sandbox. Recently, the “First-Party Sets” API (since renamed to “Related Website Sets”) was brought out of its Origin Trial and shipped to Chrome v115. Related Website Sets is now enabled for 10% of Chrome users and will be enabled by default for 100% of Chrome users soon. It will be ramped up to 35%, then 60%, and finally 99% by Chrome v117. Google has also confirmed that the deprecation of 3rd party cookies will start from 1st January 2024, with it disabled for 1% of the global Chrome user base, with Google progressing from there as they see fit.

AdFixus was recently invited to attend a session alongside local industry leaders at the Google offices in Sydney led by their privacy team and Related Website Sets product team. In this article, we explore the Privacy Sandbox APIs, the Related Website Sets API, and perspectives on what these forthcoming changes mean for the industry and how organisations should look to respond to this.

What is Google Privacy Sandbox?

Privacy Sandbox is an initiative led by Google to create a set of technologies across Chrome and Android in response to the industry-wide deprecation of 3rd party cookies and similar invasive technologies.

Google has developed and tested a number of proposed technology solutions over the last few years in collaboration with the industry (including AdTech/MarTech vendors, Chromium, W3C TAG, industry bodies and test partners). A full list of the proposed APIs can be found at the bottom of this page.

What is the Related Website Sets API?

The Related Website Sets (“RWS”) API is a web-only Privacy Sandbox API developed so that: “browsers are allowed limited access to third-party cookies across multiple sites by allowing companies to declare relationships among their owned sites”.

In the simplest terms: In a world where Chrome 3rd Party Cookies are fully deprecated, it will not be possible for sites with different domains to allow cross-site cookie access. The Related Website Sets API provides a solution to this by allowing these different domain name sites to declare a relationship with each other for the purpose of allowing cross-site cookie access.

RWS allows for three use-case “categories” where a company owning different domains are allowed to define a valid “relationship”:

1. Country Code Top-Level Domains (ccTLD) – unlimited.
2. Service Domains - unlimited.
3. Associated Domains – maximum of 5 (may be revised in the future).

A company named “Brand X” may be able to define the following relationships for their owned domains:

‍

Key takeaways

1. RWS does not support webviews or Android. It is for regular websites only.
2. The focus of RWS is on “non-ads use cases” it is intended to minimise impact on regular “cross-site” cookie usage such as login authentication domains.
3. “Associated Domains” are limited to a maximum of “5” domains which may be revisited as RWS becomes enabled for 100% of Chrome users.
4. Organisations will need to adhere to a formal submission process to declare their “set submissions” in order to gain approval .
5. Once an RWS submission has been approved it will act in an “auto-grant” basis for Chrome users on valid websites enabling cross-site cookies. This means that users will not be provided with a prompt requiring consent or notification – it is automatically running behind the scenes.
6. At the time of writing, RWS is a Chrome-only solution. It is not supported or in roadmap for other major browsers (Safari, Mozilla, etc.).

The AdFixus view

Challenges in the approach are immediately apparent, such as:

1. RWS is intended to support non-Ads use-cases.
2. RWS is limited to Chrome users. Organisations seeking to enable use-cases (ads and non-ads) impacted by 3PC deprecation will still need to develop non RWS solutions to support users across all browsers.
3. RWS is limited to only 5 associated domains – organisations requiring support for more than 5 domains will not be able to do so with RWS and will still need to develop a more comprehensive approach.
4. This is just one of sixteen other Privacy Sandbox APIs. Careful consideration is required in evaluating the effort required to fully adopt Privacy Sandbox solutions for all relevant post 3PC deprecation use-cases.
5. RWS cannot be used outside of a brands owned sites – alternative solutions will be needed to engage in data sharing initiatives.

As such, organisations should not seek to adopt RWS as a “silver bullet” solution to 3rd party cookie deprecation and usage for advertising, measurement, and user identification.

It is important to note that RWS and Privacy Sandbox APIs are ultimately still a “Google approach to solving part of the 3PC deprecation and privacy” imperative. It is not one that is a “privacy-legislation” based approach to operating in a privacy-first internet without 3rd party cookies.

AdFixus customers are adopting the Related Websites API by first evaluating a comprehensive strategy that supports their entire customer ecosystem. The AdFixus solution is a critical piece of infrastructure for our customers to execute a 1st party strategy that is:

1. Supported by all browsers .
2. Implemented without limitation on all owned domains.
3. Owned fully without external 3rd party ownership.
4. Comprehensive beyond cross-site cookie use-cases.
5. Aligned to evolving privacy-legislation and browser privacy protocols.
6. Durable across enterprises into the wider data sharing ecosystem.

Conclusion

The Related Websites API is narrowly scoped to solve a limited range of use-cases impacted by the deprecation of 3rd party cookies. Google Privacy Sandbox does introduce a number of APIs which together cover the broader scope of use-cases that organisations are seeking to resolve. However, this is still a Google-only solution and does not encompass the entire web (approximately 30-50% of your traffic). Major browsers have not yet agreed to a set of solutions which will be uniformly supported posing significant risk to reliance on any one set of solutions.

Whilst there is value in testing new solutions such as RWS -

It is important to not rely solely upon these and instead to adopt a comprehensive approach. Organisations should seek to employ solutions that are future-proofed against ongoing privacy changes, supported across all browsers, and can be fully owned and activated by themselves.

‍

Appendix

The table below summarises all the proposed Google Privacy Sandbox APIs – covering a range of use-cases not limited to only advertising use-cases. Read more here.