Messing around with API proposals in a sandbox environment is one thing. Operationalizing them so they’re eventually usable in the real world is another.
On Tuesday, mobile measurement platform AppsFlyer announced it has a working solution in beta for the Protected Audience API (formerly FLEDGE) within the Android Privacy Sandbox. The tool was developed in partnership with mobile demand-side platform Remerge.
The Android Privacy Sandbox is similar to the Chrome Privacy Sandbox in that both are incubators to build technology for targeting and measurement without cross-app or cross-site tracking.
The purpose of the Protected Audience API is to help advertisers and ad platforms retarget audiences without relying on mobile ad IDs.
“In certain cases, like with AppsFlyer and Remerge, companies aren’t just testing independently but have progressed to a point where they are coming together to design solutions that span across different parts of the ecosystem,” said Lee Milstein, head of privacy partnerships and infrastructure at Google.
Milstein also noted that a number of other companies are planning to make their testing progress public during the second half of this year.
You, me and DSP
AppsFlyer’s solution allows advertisers and DSPs to create custom first-party segments for reengagement campaigns without needing an SDK integration of their own.
In other words, mobile ad platforms can piggyback on AppsFlyer’s existing SDK footprint, which is integrated with more than 9,000 ad partners, to use the Protected Audience API.
AppsFlyer’s approach here is not dissimilar to the approach taken by companies like mParticle and Twilio, which allow companies to access data from multiple sources without having to manage various integrations.
“On the web, all you need is a line of code to build an audience. But on the app side, you need an SDK, and it doesn’t make sense for app developers to install an SDK for every DSP they want to create an audience on,” said Roy Yanai, AppsFlyer’s VP of product management.
Generally speaking, Yanai added, “app developers want as few SDK integrations as possible.”
Constructive criticism
AppsFlyer has been actively testing the Android Privacy Sandbox since its beta release in February.
In general, testing within the Android sandbox appears to be progressing faster than in the Chrome version, where buyers and sellers are taking more of a wait-and-see approach.
One theory as to why app-focused companies are more willing to roll up their sleeves is because this isn’t their first rodeo.
“Perhaps the mobile world is more receptive because we’ve just been through the iOS Armageddon,” Yanai said. “We all anticipated the Android change would be coming, which could be why it’s been a smoother process.”
Google has also been listening to feedback from the app community, some of which has already been incorporated into updated versions of the Android Privacy Sandbox APIs.
For example, Google updated the technical proposal for the mobile version of the Topics API to make it clear that advertisers can use any of the three topics returned by the API for ads personalization.
Google also listened when mobile attribution companies objected to the fact that self-attributing networks, like Meta, would have an advantage in claiming last-click attribution credit over third-party ad networks through the Attribution API in the Android Privacy Sandbox.
Based on feedback, Google added an example to the spec that includes a way for multiple parties to register views, clicks and conversion events.
“They’re being attentive; it’s not just lip service,” Yanai said. “If Google sees consensus around something that needs to be fixed, adjusted or enhanced, it happens.”
Proceeding apace
In addition to its solution for the Protected Audience API, AppsFlyer has also been working on a tool to support the mobile app Attribution API, which is Google’s answer to Apple’s SKAdNetwork.
But all this development work is being done without knowing exactly when or if Google will phase out the Android ad ID, which is the device ID advertisers use to track user behavior across apps.
In February 2022, when Google first announced the Android Privacy Sandbox, it rather obliquely said it would support all existing ad platform features, including the ad ID, for “at least two years” and that it would “provide substantial notice ahead of any future changes.”
Based on that timeline, it’s possible the android ad ID has less than a year to go. Google declined to share anything more about its plans.
Yet it’s very possible Google will get rid of its ad ID rather than going the Apple ATT route of requiring a double opt-in because it already offers an alternative.
Roughly one-third of AppsFlyer attribution on Android is happening through the Google Play Store’s Install Referrer API, which is a secure mechanism for retrieving referral data directly from Google Play without the need of a device ID, Yanai said.
“I can’t promise anything because I’m not Google, so I don’t know,” he said, “but as long as you can still use the Google Play Referrer, I’d say they’re likely to deprecate the Google advertising ID without doing the consent mechanism thing like Apple.”
