Android Privacy Sandbox: A Practical Guide to Integrating

By Jonathan Chen April 7, 2022

We’ve been taking a deeper look at how mobile ad tech partners can collaborate and integrate with Privacy Sandbox on Android, to facilitate attribution and attribution reporting.

As a mobile measurement provider, we’re glad to see that although the framework is technically complex, there are many mechanisms in place to address the advanced data needs of ad networks, advertisers, and measurement providers alike. In this article, we identify the key mechanisms that pose interesting challenges, and a practical approach that ad networks (and publishers), mobile measurement providers (MMPs), and advertisers can use to integrate in the attribution framework.


Android Privacy Sandbox: A Practical Guide to Integrating

Before we begin, here are some key terms to understand:

  • Attribution source – Google lingo for an ad touchpoint (click or impression)
  • Trigger – Google lingo for app conversion event (install, post-install events)
  • Ad Network – we’ll use this as a generic term for any entity that serves an ad and will register an attribution source
  • Mobile Measurement Provider – this is a generic term for a third party marketing analytics platform for mobile apps
  • Attribution framework – the “Attribution Reporting” design proposal published by Google, one of four proposals in the Privacy Sandbox on Android which was announced earlier this year

Challenge #1 – Siloed Attribution

We’ll start off with the first challenge with the attribution framework. The attribution framework details an interesting design decision:

Attribution reporting


What does this mean? Well, if a user saw ads from both Network A and Network B, and the user then downloaded the app, Network A and Network B will both be notified that they won the attribution! Sharon from BestGame’s user acquisition team will not be getting the traditional last-touch attribution needed for crediting and analysis. So MMPs still have a job to do, which is to find a way to provide a dataset that de-duplicates and provides the needed last-touch marketing insights.

Challenge #2 – Coordinating Aggregation Keys

The attribution framework supports reporting attribution results via two methods – event-level and aggregatable reports. The particularly interesting one to understand is aggregatable reporting. In order to get an aggregatable report, aggregation keys need to be defined.

Coordinating Aggregation Keys


This means that in order to get an aggregatable report, one needs to be able to influence matching key values on both the attribution source and trigger registration process. This isn’t easy for a single entity to do, and this is the reason why ad networks (and their SDKs) and mobile measurement providers (and their SDKs) manage their respective sides of the ad-to-conversion journey today.

So with these key challenges and constraints, an effective integration strategy must address the following:

  1. Facilitate “last-touch” attribution reporting which is still a must for marketing teams to make their decisions.
  2. Keep aggregation key management as simple as possible so that each “ad tech platform” in the ad-to-conversion journey can retrieve their respective aggregatable reports, all while ensuring advertisers have control over what data can and can’t be shared.

Opportunity-Built-In Redirect Capabilities

The good news is the attribution framework has a key mechanism that allows for a solution to both constraints, by allowing redirects in both attribution source and trigger registration!

Attribution source redirect:

Trigger redirect:

Trigger redirect

A practical integration for ad networks and third-party measurement

Using redirects, multiple ad tech platforms can be part of the registration flow for both attribution sources and triggers, thereby allowing all ad tech platforms to utilize the attribution framework for their own purposes.

Let’s take a look at how this all could work for a hypothetical mutual advertiser


A practical integration for ad networks and third-party measurement

Attribution Source Registration Flow

  • Ad Network SDK servers serves ad in publisher app/site, user clicks on ad.
  • Ad Network SDK registers ad click and calls registerAttributionSource, sending information about the ad via a click ID.

Attribution Source Registration Flow

  • Ad Network servers receive ad click and replies with attribution source metadata associated with the campaign via the documented HTTP headers, including aggregation keys for ad network reporting. For the given campaign, advertiser has configured a measurement URL (of the MMP), and the response includes a redirect to the MMP measurement URL with populated macros as supported by the ad network.
Attribution Source Registration Flow
  • MMP servers receive ad click and reply with attribution source metadata and attribution settings configured for the ad network (e.g. MMP attribution windows, campaign metadata, etc), including aggregation keys for the advertiser app with the chosen reporting schemas.
Attribution Source Registration Flow

       * we’ll cover this in more detail, in our next post about reporting with the attribution framework

After the attribution source registration flow, both the ad network and MMP have their respective “clicks” and aggregation keys registered in the attribution framework.

Trigger Registration Flow

  • User downloads the app.
  • MMP SDK in the advertiser app detects install and calls triggerAttribution, sending information about the install to MMP servers.
Trigger Registration Flow
  • MMP servers receive install and replies with trigger data information, including the same aggregation key used during attribution source registration, as well as forwarding the trigger to any ad networks the advertiser has chosen to forward app conversion events to. In Singular lingo, this is our “Partner Configuration” dashboard where advertisers pick and choose which postbacks to configure to ad networks. Much like postbacks to ad networks today, the MMP can allow advertisers to customize postbacks to each ad network via MMP postback macros.
Trigger Registration Flow

* we’ll cover this in more detail, in our next post about reporting with the attribution framework

  • MMP servers receive ad click and reply with attribution source metadata and attribution settings configured for the ad network (e.g. MMP attribution windows, campaign metadata, etc).
  • Repeat steps 6-8 for additional and optional post-install events.

After the trigger registration flow, the MMP and all eligible ad networks have received triggers notifying them of a conversion event (install), and are able to provide the second piece of their aggregation keys. If the attribution framework attributes the trigger to an attribution source (both the MMP and ad network) it will be reflected in their  respective aggregatable reports.


With this proposal, ad networks and MMPs are able to share and facilitate attribution for each other to benefit mutual advertisers MMP attribution reporting and ad network campaign optimization needs.

MMPs are able to receive all touchpoints from ad networks so that MMPs can perform last-touch attribution across all of the advertisers ad networks. Most interestingly, the attribution source registration flow is very similar to how ad networks and MMPs operate today. Ad network tracking links commonly facilitate “on-device” redirects to the configured MMP measurement URL. In theory, this should make it easy for ad networks and MMPs to re-tool their existing measurement URLs to work with the framework. However, this could be more technically challenging for ad networks who do not have synchronous touchpoint processing.

Ad networks are able to receive all configured and permissioned app events from the MMPs, so ad networks can optimize their campaigns using their own configured event and aggregatable reports composed of their own attributions. The trigger registration flow is a similar concept to MMP-to-ad-network postbacks. In theory, this should make it easy for ad networks to re-tool their postback endpoints to accept trigger registrations.

What questions remain

Our first Privacy Sandbox on Android blog post details some initial questions we had in using the attribution framework. We’ve answered a few of them with this proposal, but we’ve added a few more in the process

  1. How can discrepancies be tackled?
    The proposal allows ad networks and MMPs to attribute independently with their own logic. Given the privacy-centric nature of the framework, it could be that discrepancy investigations would be difficult to unravel as each ad tech platform will have their own attribution results from the framework.
  2. What are some integration variations that could exist?
    In theory, an MMP-centric version of the integration proposal could exist, in which it is uncommon for ad networks to have triggers registered, and all reporting and attribution is facilitated via the MMP via asynchronous attributed postbacks to ad networks. This could operate similarly to attributed-only postbacks today.
  3. How does the Privacy Sandbox discourage or limit independent measurement via the attribution framework?
    Touchpoints and triggers are still HTTP requests to an ad tech platform’s back-end. Ad tech platforms can in theory continue to rely on information sent in the HTTP requests to attribution and report. Will the SDK Runtime sufficiently limit independent attribution, while at the same time provide enough data for effective attribution source and trigger registration strategies?

What’s next?

While it’s a bit early to implement, we welcome feedback and collaboration with our ad network partners. Reach out to your Singular partner manager and join our Mobile App Privacy slack community if you haven’t already. We’re actively sharing our feedback with Google, and we invite you to as well.

Keep an eye for our next blog post, where we will deep dive into the reporting strategies we see event and aggretable reports using in the Privacy Sandbox on Android attribution framework.


Stay up to date on the latest happenings in digital marketing

Simply send us your email and you’re in! We promise not to spam you.