Making Privacy Sandbox on Android work: conflicting credit, shared aggregation keys

What if multiple ad networks claim credit for every single mobile app user you acquire under Privacy Sandbox on Android?

Sounds unlikely? Actually, it’s precisely how Privacy Sandbox on Android is architected. As currently architected, attribution decisions are only based on touch points: clicks or impressions. And attribution is done individually for each ad network. In fact, each ad network gets a postback with that attribution decision.

When every ad network claims credit

There could be a few issues with this …

In a real world scenario where you potentially have multiple ad networks all serving clicks and impressions to the same user … you could have multiple ad networks all trying to claim credit for that eventual conversion.

Jonathan Chen

There’s a huge problem in that for an industry that’s built around last-click attribution. There’s also a huge opportunity in that for an industry that’s built around last-click attribution. MMPs like Singular will have to review “triggers,” as Google calls conversion events, match them with installs, take into account the priority that each trigger has been given, and de-dupe install credit claims. This is important in a pay-per-install world so that marketers don’t get double billed, but it’s also an opportunity to explore partial-credit models and (dare we say it) a limited version of multi-touch attribution.

There are a lot of complexities here, and a lot of concerns around potential fraud. We’ll explore that more in coming posts and reports.

Aggregation keys: learning to share

Google is building a framework and an architecture so that ad networks, advertisers, and measurement partners can tag data like clicks, impressions, campaign variables, and cost. Those can’t be connected in as granular a way as GAID allows, of course: this is inside the privacy sandbox. But in an aggregation service running in a trusted execution environment in the cloud, measurement partners can connect pre-install and post-install data in a privacy-safe way.

The requirement: common aggregation keys.

In order to get the resulting attribution report, your aggregation keys need to match … so you need to figure out how to communicate with your ad network: ‘Like, hey, what key did you use when you started the click … I need to use that same key.”

Jonathan Chen

It’s very likely that MMPs will play important roles there just as the manage conversion models under SKAdNetwork on iOS.

Privacy thresholds vs differential privacy: a key difference

Though they’re both designed to serve similar purposes, there’s a key difference between the privacy thresholds in Apple’s SKAN framework and the differential privacy in Google’s privacy sandbox.

Privacy thresholds actually withhold data from marketers and measurement platforms until the thresholds have been surpassed. This is sometimes referred to as censorship of the data. The idea is that if there’s too little data, marketing platforms could infer too-granular data with a fairly high level of certainty about their new users within a particular time frame.

Differential privacy is … different. (Sorry.)

It is introducing noise to postbacks, but not just random noise

“The way the sandbox introduces the noise is through differential privacy. And one of the things about differential privacy is, when you look at a large enough dataset, it should still be accurate. When you look at specific chunks of data, like for an individual user, you can’t know with 100% certainty that it is true, but in aggregate, everything is accurate.”

Jonathan Chen

All the data is there: it’s just mixed up so that Google ensures that individual privacy is maintained. Which means that campaign-level reporting should be excellent.

Less stress (more data, more postbacks)

I’ve heard multiple marketers tell me SKAN is stressful because you basically have one shot at getting it right. You get one postback, and it contains all the data that you’re ever going to be able to definitively tied to a specific conversion (not a device, not a user, just a conversion). Which means that, if you’re going to use that data for predictive LTV, for ROAS calculation, and for campaign optimization, it’s extremely high leverage.

At lot weighs on that one postback.

In that sense at least, Privacy Sandbox on Android is going to be a lot less stressful. While each of the PSA postbacks has less data (3 bits for conversion events attributed to a click, and 1 bit for conversion events attributed to an impression) there are 3 postbacks for click-attributed conversions and 1-2 postbacks for impression-attributed conversions.

That means in the most common case, clicks that lead to installs, you get three shots at getting revenue, events, funnels, or engagement data. In other words, users who don’t engage, buy, or act immediately are not instantly lost in terms of pLTV or ROAS.

Stay tune for more Privacy Sandbox and SKAN insights

We’ve already shared a lot about Topics API and SDK Runtime as well as a deep dive on mobile attribution in Privacy Sandbox and an introduction to Sandbox integration. There’s more to come (and yes, still on SKAN, which is still extremely challenging for most mobile marketers).

Scroll down just a bit on our blog home page to sign up to the Singular digital marketing newsletter.