In February 2022 Google announced their plans to enhance user privacy on Android and marketers jumped to attention. Following the shockwaves around Apple’s App Tracking Transparency (ATT), questions of what exactly Android is planning on doing and how it affects businesses were, and still are, at the forefront of everyone’s minds.
This excitement is abuzz, despite the fact that the deprecation of Google Advertising ID (GAID) will only be in 2024. And, for good reason as it changes life as we know it for marketers everywhere.
To help you prepare for Privacy Sandbox, we outlined some of the primary changes that this initiative introduces and what the basis for the new normal will be. The information outlined here is based on close collaboration with the team at Google, extensively reviewing documentation, and hands-on testing of the solution. Let’s dive right in.
Here lies GAID: The end of user-level insights on Android
As the basis for Privacy Sandbox, let’s explore the ways GAID is primarily used today:
- Attribution: GAID helps marketers measure the effectiveness of their campaigns and understand their user journey.
- Audience management: GAID helps marketers personalize their remarketing campaigns.
- 3rd party data sharing: GAID helps ad networks build persona graphs to help them assign the best ads per each persona.
Now that we understand how GAID has been used, let’s determine who is the party that primarily leverages it, so we can identify what needs to change when GAID is deprecated and how.
|Goal||Actions required by|
|Remarketing||Marketers, Ad networks, MMP|
When reviewing the usage of GAID, we can see from the above table that marketers will primarily be affected by its deprecation in their current measurement and remarketing efforts. Let’s zone in on those areas to determine how to prepare.
When it comes to measurement and analytics, there’s no need to panic. The deprecation of GAID does not signal the end of marketing measurement.
As of yet, Android has not announced any plans to deprecate Google Play Install Referrer, which is one of the main attribution methods on Android,, and this speaks volumes when it comes to business continuation. Currently, 29% of AppsFlyer’s install attributions on Android are conducted via Google Play referrer.
To help you prepare for Privacy Sandbox, we suggest looking into what your current data looks like. In AppsFlyer’s raw data reports, you can see that one of the fields is called <match_type>. Under <match_type>, you can identify how many of your current installs use Google Play Referrer attribution. This simple data query may help ease any concerns of significant changes to attribution measurement.
Despite the importance of the Google Play Install Referrer, there is no denying that GAID is currently the basis and cornerstone for a large portion of measurement activities.
To help marketers continue in their attribution efforts without GAID, Privacy Sandbox introduces new methods for campaign measurement with the launch of the Attribution API. This API offers two types of reports: event-level reports and aggregated reports. Each report presents different advantages and insights, as follows:
While event-level reports offer limited measurement of install and post-install events, the reporting is on the click ID level, which allows ad networks to get accurate signals for the ad shown. However, to protect end-user privacy, reports are delayed by a minimum of one day for view through attribution and two days for click through attribution and a maximum of three postbacks are attributed per source. While at the surface, some may want to compare the postbacks that Sandbox offers with those that SKAN provides, a deep understanding of Sandbox proves that these postbacks are different both in nature and in use. As this solution currently stands, event-level reports are most impactful for ad networks to use for optimization, and are less insightful for marketers.
Aggregated reports offer richer insights to marketers, as they may include detailed campaign dimensions, such as the campaign name, date, adset, geo, and creatives. The details of the campaign dimensions included in the aggregated reports are up to the network and MMP and advertiser to define. The postbacks that compose the aggregated reports are sent the same day. The aggregated reports provide install and post-install LTV, giving marketers actionable insights for campaign learnings.
Both the aggregated and the event-level reports offer cross-network attribution, with the determination of cross network last click attribution shared solely with the MMP.
Marketers can configure lookback windows of up to 30 days, but bear in mind that they need to be configured for every ad network – an incredibly arduous task when undertaken by marketers themselves. Configuring lookback windows is streamlined when using an MMP, as they will integrate and coordinate directly with the ad networks, taking over the heavy lifting.
While all of this sounds great, there are some downsides: it will now be more complex than ever for marketers to deduplicate their data. This is because the Attribution API is aggregated and doesn’t provide advertiser-side user-level data, making it impossible to merge this data with analytics received from Google Play Install Referrer.
To overcome this challenge, AppsFlyer incorporates a single source of truth mechanism, deduplicating attribution data and enhancing data with insights.
Today, remarketing leans heavily on the use of GAID, as marketers can define audiences by user preferences, interests, and app use to generate a list of GAIDs to activate a remarketing campaign. In light of GAID’s upcoming deprecation, Google introduced FLEDGE, an on-device (not sent to any servers), privacy-centric audience management and advertising solution.
For marketers, the changes FLEDGE introduces may be felt in varying levels. For example, AppsFlyer customers who use the Audiences tool won’t feel a significant change; audience creation within AppsFlyer supports the FLEDGE changes and will allow different ad networks to personalize ads based on the configurations each marketer sets.
However, if you are used to creating audiences within your own BI, there might be some heavy lifting to do. Creating user lists and sending it to different partners is no longer going to be possible.
So, how can you adapt? There are a few options:
- Manage FLEDGE. with FLEDGE, you will still be able to create audiences and ‘tag’ them as available to be targeted by a specific ad network; however, you will have to communicate this integration with the different partners. For example, if you want to create an audience of “add-to-cart-did-not-purchase” and assign it to a DSP, you can potentially do that, but it’ll require an integration with that DSP (to pass and get data from them.)
- Work with an MMP. AppsFlyer is already building the integrations to enable FLEDGE through different partners, which will support audience management in the post-GAID era and will facilitate personalized remarketing.
For ad networks
In addition to the changes felt by marketers, FLEDGE introduces many changes to ad networks in two primary aspects:
- Defining audiences: In FLEDGE’s current structure, an SDK, which has the ability to communicate with FLEDGE, is required on the advertiser’s app in order to add or remove a user from an audience. Ad networks, with the help of MMPs, will need to build integrations that enable audience-building functionalities.
- Bidding on a user that belongs to an audience: Other than building audiences, A major part of FLEDGE is actually helping ad networks with a privacy-centric bidding solution. FLEDGE offers an on-device bidding exchange between the SSP and the DSP. Ad networks will be required to adapt their bidding strategies and solutions in order to guarantee that the right ads are shown to the right users in the most cost efficient manner.
Beyond AppsFlyer’s current solution and inline with our higher level vision to promote privacy-centric insight, we are supporting the ecosystem by facilitating audience creation on the ad network side. As noted, FLEDGE is an on-device solution; any audience creation requires an on-device presence (SDK). AppsFlyer will facilitate any audience building by any ad network via dedicated integrations.
One of the main inputs for ad networks’ targeting capabilities is 3rd party data. That is, when app.game.com sends usage data of user123 to an ad network, which t can then be used to target user123 with ads in a different gaming app.
The notion of cross-app targeting based on user-level data is a significant part of what Google is trying to prevent; we are likely to see a major impact on ad networks’ abilities to target in the post-GAID era. The good news is that there are solutions that might help ad networks ensure contextual ad delivery including
- Topics: As one of the solutions suggested by Google, Topics help with cross-app marketing. This is an on-device solution and is designed to protect user privacy while enabling cross-app targeting signals. Different ad networks will have to adopt Topics and optimize based on Topics.
- Attribution API signals: As noted above, one of the key features the Attribution API offers is event-level reporting, which offers a limited number of postbacks based on user-level data. For example: an ad network will have the ability to know that click-id123 has made a purchase on the advertised app, but these reports will be delayed to protect end user privacy.
Winter Sandbox is close, but that doesn’t mean that the frost will bite
While change is scary (and Privacy Sandbox brings a lot of that) the shifts Android is introducing are moving the ecosystem in the right direction: away from user-level data addiction and toward privacy-forward approaches.
To start preparing for the deprecation of GAID today, we encourage marketers to lower their reliance on user-level data and start embracing and utilizing aggregated insights.
Finally, prepare for a cozy winter by continuing to learn more about this evolving framework; Google provides ample documentation, and, as always, AppsFlyer is here to answer any questions and help you navigate any new changes, before they arise.