Google has planned to phase out third-party cookies by this year, specifically on Google Chrome. In the process, Google is introducing a new series of application programming interfaces (APIs) for web browsers. These APIs, along with the Google Privacy Sandbox, will still allow advertisers to continue publishing ads and reaching potential customers.
If you want to learn more about Google Privacy Sandbox and the Android Privacy Sandbox that’s soon to come, the following is a guide to the Privacy Sandbox and what implications it has for advertisers and publishers.
What is Google’s Privacy Sandbox?
One of the biggest topics in the marketing world has been Google’s decision to drop third-party cookies, which have been integral for advertisers to help target their audiences. The reason for this is an increasing move toward maintaining privacy for consumers. At the same time, many publishers worry about how they’ll be able to continue launching effective advertising campaigns without these formerly integral third-party cookies.
The main reason Google has begun to transition away from third-party cookies is the worry about how malicious parties may attempt to misuse user data that these cookies collect. People have also increasingly demanded more privacy online, which is another critical reason behind the elimination of third-party cookies.
To help compensate for the absence of third-party cookies, Google plans to launch its own set of tools to make use of first-party user data to assist advertisers and publishers. Part of this plan involved the introduction of Google Privacy Sandbox, which is soon to extend to Android devices.
The Reason for the Privacy Sandbox
A growing number of users are making the switch to browsers that don’t allow for the collection of third-party cookies. Although Chrome is to remove third-party cookies, Google has delayed their removal until 2023. Meanwhile, browsers like Firefox and Safari have already started to remove support for third-party cookies.
Google continues to push the move away from third-party cookies, but it still needs to maintain its advertising business to maintain its browser market share. Subsequently, the company has developed the Privacy Sandbox to allow users to remain anonymous while giving advertisers to continue targeting users based on their behavior through certain browser APIs.
The goal is to protect users while serving advertisers using workarounds to compensate for the elimination of third-party cookies. Ultimately, users will also benefit from increased control and transparency.
What the Privacy Sandbox Entails
The Google Privacy Sandbox aims to enforce change by introducing several core browser APIs, which will effectively take the place of cookies. Using these APIs, advertisers will still be able to collect useful data about attribution and conversion. This means that advertisers will still benefit from actionable insights while preserving the anonymity of users. Specifically, advertisers can look at signals in lieu of cookies to better understand how users interact with their websites.
The following are the main APIs included in the Google Privacy Sandbox.
Aggregated Reporting API
This API enables the collection of data pertaining to campaign performance without tracking users. It will include views, impressions, reach, and other metrics consolidated within a single report. It will allow browsers to store data, which advertisers can then use their own systems to analyze.
Conversion Measurement API
This API will also allow for campaign tracking without cookies. Specifically, it would allow for conversion and click tracking for ads. The browser will send this information to advertisers in a limited format to maintain privacy for users.
Trust Token API
This is an API intended to help combat fraud, spam, and denial of service (DoS) attacks. It would do so by enabling publishers to authenticate real users without tracking technology, which means it would serve as an alternative to a user authentication system like CAPTCHA. This API would work by classifying users as either trusted or untrusted via their browser ID. The ID wouldn’t allow for the tracking of individual users, but it would place them into each group to help determine whether they’re real or fake users.
Google originally released a Chrome extension in 2020 that was based on the Trust Token API. This extension would show the number of ads loaded on a page, along with the information used to display them and which advertisers show up on the page. In turn, users can gain a better understanding of the context of each ad.
Turtledove API
The Turtledove API would enable advertisers to develop both targeted and retargeted advertising. It’s to be put into effect with The First Locally-Executed Decision Over Groups Experiment (FLEDGE). The API would enable ad networks to add users to certain segment groups within a browser-based on certain actions they perform. For instance, advertisers can target audiences with ads based on interest groups to encourage people to purchase items in an abandoned shopping cart.
The Topics API
Like Turtledove API, the Topics API allows advertisers to target users based on interests. This API looks at users’ recent browser activity, along with site categorization. Advertisers can use certain categories to target relevant ads to people who visit their site.
WEB ID
This API would help preserve and expand identity federation on the internet, protecting users’ privacy and preventing potential abuse by allowing for anonymous login.
What Google’s Privacy Sandbox Means for Advertisers and Publishers
Google has made it clear that it’s willing to work with both advertisers and Chrome users to ensure everyone benefits from the Privacy Sandbox. This means that publishers can provide feedback for each API.
Eventually, each of the proposed APIs is likely to become an open web standard. Google likely hopes that other browsers will also embrace them, including Safari and Firefox. If the APIs become standardized, this could indicate that advertisers will be able to gain a clearer view of users on Chrome and other browsers. Additionally, publishers will have the ability to monetize sites while getting around the lack of third-party cookies.
Due to the fact that the Google Privacy Sandbox is still in development, it’s not entirely clear exactly how it will affect advertisers. Some advertisers, publishers, and ad tech vendors worry about what will be available to them with the Privacy Sandbox, particularly since Google has teams that are dedicated to advertising who might have more access to data. However, it appears that advertisers and publishers alike will still be able to benefit from the ability to target audiences without relying on third-party cookies.
The Introduction of the Android Privacy Sandbox
As of February 16 of this year, Google announced that it’s planning on expanding its Privacy Sandbox by making it available on Android. The reason for this is to protect the privacy of mobile users in addition to other internet users.
With so many apps available on app stores like Google Play, mobile apps are increasingly integral in people’s lives. However, mobile marketing and digital advertising have needed to change to respect users’ privacy on Android and other mobile devices. In an effort to help preserve the privacy of users, Google has begun a new multi-year initiative to integrate the Privacy Sandbox on Android to introduce new private advertising solutions. These solutions will eliminate cross-app identifiers and other sensitive data to protect users while still enabling advertisers and publishers to connect with audiences.
Making Up for Other Approaches
Google Privacy Sandbox on Android is intended to enhance users’ privacy while giving both businesses and developers the tools they need to succeed with mobile advertising efforts. Other platforms have tried different approaches to improve privacy, but this entailed restricting critical technologies that advertisers and developers need. Google believes such approaches are harmful to both users and the advertisers trying to reach them.
In the meantime, Google plans to continue supporting current ads platform features for a minimum of two years before implementing new changes that advertisers and users can expect.
Design Proposal Overviews
To achieve the main goal of the Privacy Sandbox on Android, the solution will introduce two core solutions, including an SDK Runtime and a variety of privacy-protecting APIs that are similar to those seen with the conventional Google Privacy Sandbox. The following is a breakdown of each of these integrations and what they aim to achieve.
SDK Runtime
The Android platform maintains boundaries for execution and security through the concept of app sandboxing. Apps often include third-party code via SDKs, including analytics and ads SDKs. In turn, app developers can benefit from data from subject matter experts’ efforts to scale campaigns more easily while focusing on app differentiation.
Android SDKs are executed in the sandbox of the host app, much like other operating systems. These SDKs also have the same permissions and privileges that the host app has, along with access to the storage and memory of the host app. This allows SDKs and apps to integrate with each other, but it also enables the collection and sharing of sensitive user data. At the same time, app developers may be unaware of precisely how the SDK functions and the types of data it collects, which can make it difficult for developers to maintain accountability for data collection and sharing processes in adherence to data privacy guidelines.
To help mitigate the potential issues of existing Android SDKs, Android will introduce a new platform capability with Android 13 that enables third-party SDKs to operate in the SDK Runtime, which is a dedicated runtime environment. This will help define permissions and data access rights for Android SDKs and provide a modified execution environment.
The Goals of the SDK Runtime
Specifically, the goals of the new SDK Runtime include:
- Reduction of undisclosed tracking of app usage by third-party SDKs through the restriction of unique and persistent user identifiers from SDK access.
- Reduction of undisclosed access to user data and sharing of it by third-party SDKs via a well-defined API, process isolation, and data access control.
- Assistance for app developers to more reliably account for their apps’ data access and sharing practices.
- Allow for faster SDK update distribution to apps by mitigating the burden on developers and users alike.
- Minimizing undue impact to SDK and app developers.
- Helping SDK developers avoid tampering by external SDKs by limiting reflection and JNI code, along with other unsafe language constructs.
- Helping ads SDKs identify and address ad fraud and invalid traffic via complete control over the remote views displaying media.
The Execution of SDKs in an Isolated Process
The new SDK Runtime would allow certain SDKs to operate in a separate process for apps, allowing for bi-directional communication between the SDK Runtime and its corresponding app.
Distribution Models That Establish Trust
Separating the SDK from the app would also allow for separate SDK and app distribution. To make sure the correct SDKs are installed in the SDK Runtime of an app, the new proposal needs a trusted installation and distribution mechanism. Having this mechanism in place would help protect both users and developers from the loading of invalid SDKs. Simultaneously, app stores can reduce the burden of SDK distribution from developers.
SDKs won’t need to be statically linked and packaged collectively with apps prior to uploading to app stores. Instead, SDK developers would be able to upload their own SDK versions to app stores and isolate them from the app. Developers can also indicate their SDK dependencies according to version and build. Once users download the app, the installation process would then use the SDK dependencies specified by the app and download them through the app store.
Alterations to the Way Developers Build, Run, and Distribute SDKs and Apps
The new proposal will also implement certain changes in various categories, including:
- Permissions, storage, and memory for access
- Languages, lifecycle, runtime changes, and media rendering for execution
- Building, debugging, and testing in development
- SDK-to-SDK and app-to-SDK in communications
- The method of distributing, updating, and rolling back across device, SDK, and app versions
Topics API
The Topics API would allow for interest-based advertising on Android devices. This helps push personalized ads that are relevant to users’ interests in an effort to engage them more than generic ads. The Topics API would use topics signals to learn about users’ interests and share them with advertisers, allowing for interest-based advertising while maintaining user privacy.
The process would specifically involve providing callers with coarse-grained advertising topics according to a user’s app usage. The topics could work in conjunction with contextual information pertaining to the app to push more relevant ads to individual users.
FLEDGE
Advertisers often want to serve ads to people who are most likely to be interested in their offerings based on how users interacted with the advertiser’s app. For instance, a developer of an eCommerce app may want to use ads showing relevant products to users who have items in their shopping cart, which would help remind them to come back and complete their purchases.
Normally, advertisers can use data such as contextual information about the way an ad is displayed along with private information to choose the most relevant ads. However, FLEDGE aims to change this. FLEDGE on Android uses a couple of APIs for both advertisers and ad tech platforms to provide support for interaction-based use cases via methods that limit access to personal cross-app identifiers.
These APIs include:
- Custom Audience API — This API revolves around audiences designated by advertisers based on the audience’s intentions. The API allows for audience information to be stored on devices and associates the information with certain potential ads, along with metadata like bidding signals.
- Ad Selection API — The Ad Selection API provides a framework responsible for orchestrating ad tech platforms’ workflows. These workflows leverage on-device signals to match users with the ad that’s most likely to appeal to them based on locally stored candidate ads. The API also conducts more processing on candidate ads that ad tech platforms return to users’ devices.
Attribution Reporting
In today’s mobile advertising environment, mobile attribution and measurement solutions often rely on Advertising ID and other cross-party identifiers. The new Attribution Reporting API will help boost user privacy by eliminating the need to rely on these identifiers and provide support for certain use cases for conversion and attribution measurement across the internet and apps.
To achieve this, the Attribution Reporting API uses certain structural mechanisms that allow for improved privacy. This framework will do so by:
- Incorporating certain noise-adding methods to maintain user privacy
- Limiting the number of bits that event-level reports can access
- Introducing certain available trigger (i.e. conversion) limitations, along with the number of ad tech platforms that are linked to one attribution source
- Enabling conversion data of high fidelity in aggregate reports
This API will also support certain use cases, including:
- Optimization — The API will provide certain reports at the event level that support ad spend optimization by providing certain data around per-impression attribution data.
- Conversion Reporting — This data helps advertisers with campaign performance measurement by identifying conversion values and counts across multiple dimensions, including ad groups, campaigns, and ad creative.
- Invalid Activity Detection — This reports invalid activity detected to help prevent ad fraud and fraudulent traffic.
The following is some additional detail about how the Attribution Reporting API works in four main steps:
1. Enroll a Specific Ad Tech Program
Ad tech platforms need to undergo a lightweight enrollment process to confirm the integrity of privacy mechanisms and allow access to the Attribution Reporting API. Android has yet to detail the process and is open to feedback at this time.
This enrollment process helps avoid unneeded duplication of ad tech platforms to collect more data about user app and site activities. Ad tech platforms can enroll multiple times if needed without combining data from previous enrollments to get around privacy limitations.
When enrolling, ad-tech platforms provide a variety of information including business and contact details, use cases for attribution reporting, and postback URLs that register attribution sources, receive reports, and attribute triggers.
2. Register an Attribution Source
Views and ad clicks count as attribution sources to the Attribution Reporting API. When registering these sources, the API looks for an input event, such as an “InputEvent” object for click events and “null” for views. It also looks for an Attribution Source URI, with the platform requesting metadata connected to the attribution source.
When sending a request to the Attribution Source URI, the API expects the ad tech platform to respond with the metadata contained within. new HTTP header with a variety of fields. These fields include a source event ID, destination where the conversion event happens, and optional fields such as expiry, source priority, and install and post-install attribution windows.
3. Register a Trigger
The API enables ad tech platforms to register conversions or triggers such as post-install events or installs. It’s possible to register the same event using either multiple calls to the “triggerAttribution()” method or redirects within the “Attribution-Reporting-Redirects” field.
4. View Measurement Data in Attribution Reports
This API allows for two main types of reports, including aggregatable reports that provide high-fidelity conversion data that’s richer than event-level reports, along with event-level reports that associate a specific view or click with a small amount of conversion data.
You can learn more about the details of what to expect with the Google Privacy Sandbox on Android through Android’s Developers site.
How App Samurai Can Help You Adapt to the New Privacy Sandbox
The Privacy Sandbox on Android will help maintain privacy for app users while giving advertisers and publishers the ability to continue advertising using certain changes. While there will be certain limitations seen with these APIs and SDK Runtime integrations, advertisers will still be able to connect with audiences using the right strategies.
To help make the most of the Privacy Sandbox on Android, consider using App Samurai as part of your app marketing efforts. Using this innovative mobile growth platform, you’ll be able to launch and track campaign performance to effectively connect with and acquire users. Although you may no longer be able to benefit from third-party cookies, you’ll have access to plenty of actionable insights and optimize your campaigns with App Samurai behind your mobile marketing campaigns.