Exploring Google Privacy Sandbox on Android’s two report types

Following its initial announcement in February 2022, Google has officially begun its beta testing of Privacy Sandbox on Android for select Android 13 devices. As we announced in our recent blog exploring the beta launch, Adjust is excited to be fully on-board as an early tester, getting hands-on with this next step forward in Google’s data-privacy centric initiative.

Today, we’re taking a look at one of the most interesting aspects of Privacy Sandbox on Android (PSA) from an attribution and measurement standpoint. To understand PSA’s approach to measurement, it’s first important to keep its fundamental goal in mind: removing or reducing reliance on cross-party identifiers (GAID) and providing improved user privacy while supporting key use cases for attribution and conversion measurement across apps.

This is to be achieved via the two report types, event reports and aggregatable reports. Both of these report types are likely to become an essential component of any mobile marketer’s strategy when working with PSA.

After a trigger (PSA’s word for events that can be attributed to conversion) is attributed to an attribution source, an event-level report is generated and stored on the device where the app was installed until it can be sent back to each ad tech’s postback URL during one of the time windows for sending reports. These time windows are similar to Apple’s SKAdNetwork (SKAN) measurement windows but are more specific, offer some customizability, and the event-report is sent sooner than the SKAN postback. The windows look like this:

• Ad view (impression) attribution sources: Sent one hour after the source expires. Expiry of the source can be configured to between one and 30 days.
• Ad click attribution sources: Sent before or when the source expires, at specified points relative to when the source was registered, and cannot be configured. The time between the attribution source and the expiry (when the event report is triggered) is split into multiple reporting windows, each of which has a deadline that starts from the attribution source time. At the end of each of these reporting windows, the device collects all of the triggers (events) that have occurred since the previous reporting window and sends the event report. These are the reporting windows that can be set:
  • 2 days: All triggers that occurred up to two days after the source was registered. This is sent one hour after the window closes.
  • 7 days: Same as above but for triggers between two and seven days.
  • Custom length of time: Defined by the ‘expiry’ attribution of an attribution source, which cannot be less than one day or more than 30 days. The event report will be sent one hour after this custom expiry.

Of Privacy Sandbox on Android’s two report types, event reports are the ones that can be compared to SKAN’s postbacks. They provide upper-funnel data (campaign, sub-campaign, creative, click ID, etc.) to associate a specific view or click with a small amount of conversion data. They are most useful when very little information is needed about the trigger, as the event level trigger is limited to three bits of trigger data. What they can’t do or support is the encoding of granular data like a specific price or trigger time. An example flow could look like: Click ID 12345 led to a purchase on XYZ app.

The three bits are similar conceptually to SKAN’s conversion values in the sense that when an event happens in the app, it can be tracked at bit-level. The main difference is that PSA’s event reports have fewer bits. Only the three most important events can be tracked for clicks and only one can be tracked for impressions. Clients will be able to configure the priority of these events via the bits, similar to conversion value mapping.

In addition to the limited/anonymized event level reports, PSA also offers aggregatable reports, which provide granular trigger data more quickly. As the name suggests, however, this data is delivered as an aggregate and is not associated with a specific trigger or user. These reports are rich in lower-funnel data like revenue, number of purchases etc. and feature upper-funnel breakdowns like campaign level and geo. An example could be something like: Campaign X led to a total of 1000 conversions and a total $20,000 revenue. While you don’t get click- or device-specific trigger info, this aggregate information is extremely valuable and is completely different to any reporting received from SKAN.

Up to 128 bits can be used for reports with trigger values like revenue and other trigger types, with aggregation key definitions and values that must be defined during the source and trigger registration stage. The configuration and specifics around how this works are currently subject to testing—we’ll provide more information as soon as we have it.

Much like event reports, aggregatable reports leverage source-prioritized attribution. However, they support more conversions attributed to a click or a view, and work like this:

1. The device sends encrypted aggregatable reports to the ad tech, which they cannot use directly. This is why they’re called aggregatable and not aggregated.
2. The ad tech then sends a batch of these aggregatable reports to an aggregation service, which must be deployed in advance and be based on binaries provided by Google.
3. The aggregation service reads the batch of reports, decrypts them, and aggregates them.
4. These resulting aggregates are sent back to the ad tech in a summary report and et voilà, you have aggregated data to work with.

An example of the data an aggregated report could contain:

1. Destination: The app's package name or eTLD+1 web URL where the trigger happened.
2. Date: The date when the event represented by the attribution source occurred.
3. Payload: Trigger values, collected as encrypted key/value pairs, which is used in the trusted aggregation service to compute aggregations.

At Adjust, we’re continuing to work closely with Google as an early tester so that we can build industry-leading solutions that help advertisers thrive while placing user data-privacy center stage. If you’re an app that’s interested in participating in the ongoing beta, you can request access to a limited number of devices and register to utilize the Privacy Sandbox APIs. Google is planning to have more beta releases in 2023, meaning apps and attribution providers/analytics suites like Adjust will have the opportunity to continue testing solutions and using the new APIs to serve relevant ads to opted-in users and test their effectiveness. We recommend familiarizing yourself with PSA as much as possible so you can be fully prepared and ready once it is rolled out in full by the end of 2024.