What’s the standard for ATT 6-bit conversion values?

This guest post was written by David Philippson, the CEO of DataSeat

Last week Apple published a privacy white paper, “A day in the life of your data”, to coincide with Tim Cook’s presentation to the EU on data protection. This solidified the timeline for IDFA deprecation, specifying that App Tracking Transparency (ATT) is being rolled out in ‘early spring 2021’.

So how prepared is the Ad-Tech industry 9 months after the initial announcement? The answer is not very. Most notably, there is no agreed standard surrounding how to use SKAdNetwork’s ‘campaign id’ and ‘conversion value’ parameters. Most app developers seem to be waiting on Facebook to define this. Meanwhile, some MMPs are developing solutions to allow the conversion values to be managed via their SDKs. Following extensive discussion with advertisers and measurement partners, our view is that conversion value and campaign ID should be considered together to maximise the impact for LTV forecasting, MMP reporting, AND crucially to give network partners the most valuable information for optimisation.

SKAdNetwork refresher

Let’s start with a brief reminder on SKAdNetwork (SKA). Ad networks pass a signature containing a campaign ID via the ad, and following a successful install the advertised app may update a conversion value to communicate actions performed by the user. Both of these are sent back to the ad network in a single SKA postback.

The full list of variables which the ad network receives in this postback are below. This includes the app being advertised (‘app-id’), and the publisher app (‘source-app-id’) – provided this meets Apple’s privacy threshold.

Each time the advertised app updates the conversion value the postback timer is reset. This results in a new delay of at least 24 hours until the ad network receives the postback.

Accordingly, ad networks are keen to limit the number of times conversion value is updated. Facebook, most notably, are insisting on no updates after 24 hours following the install. And while advertisers typically want to measure conversions for many days or weeks to more accurately predict LTV, the increased delay in the resulting postback has a significant negative effect on optimisation which outweighs the benefit of more detailed LTV prediction.

Given this, we think that a 6-bit conversion value (64 IDs) is unnecessarily large for encoding LTV buckets alone, and that better outcomes for advertisers, ad networks, and MMPs can be achieved by using part of that ID to communicate something else. Our suggestion is install day, achieved by passing the day of the week that the first open occurred.

Using conversion value to communicate pLTV and install day

First, why encode install day and not something else? The diagram below shows the relative feature importance from a contextual targeting model that was trained for one advertiser’s User Acquisition campaign:

Of these top features, two or three are available directly from the SKAdNetwork postback:

• Publisher app (‘source-app-id’)
• Geo (country and region), determined using the IP address from the postback connection

‘Time’, which represents both time of day and day of week, is consistently a key driver of performance but cannot be derived from SKA postbacks. This is because iOS purposefully sends the postback at a random time within a 24 hour period, making it impossible to guess the install time by subtracting a fixed amount of time from the time the postback is received. Doing so would guarantee incorrect reporting for a significant share of installs.

Inability to accurately report the install day will be very challenging for marketers. Imagine, for example, updating your campaign targeting settings and then not knowing which of the resulting installs were driven before vs. after your change. Studying incrementality in general will be harder if it’s not possible to draw a clear line here.

Since we think that the 6-bit conversion value ID (0-63) is overkill for encoding predicted LTV over such a short period, our suggestion – as has been suggested by some others – is to split the 6 bits. The top 3 bits (left) represent the predicted value of the user (up to 8 events or pLTV buckets). The lower 3 bits (right) provide another 7 values which can be used to record the day of the week that the user first opened the app – indicating the install day.

Example: remember, the LTV buckets (left column) are entirely up to the advertiser

This strategy would allow MMPs to continue to report installs per day as accurately as they currently do, and helps ad networks to optimise campaign performance. And passing day of week information in the conversion value ID instead of the SKA campaign ID frees up the latter for ad networks to experiment with passing other dimensions useful for campaign success.

Most advertisers already have extensive data on LTV, so by clustering this into up to 8 groups from which an average LTV is calculated, they will still be able to model a predicted LTV. The above example particularly focuses on a gaming app use-case. A retail app could equally use their own relevant buckets, such as ‘registered’, ‘product viewed’, ‘product in basket’, ‘product purchased’ etc.

One potential hurdle worth noting is that the conversion value ID is subject to a privacy threshold (similar to the source app ID), which will prevent a percentage of conversion IDs from being reported to the ad network. At present it’s not known how restrictive this threshold will be, but in a bad case scenario advertisers with relatively small volumes of new users may benefit from restricting themselves to using a smaller subset of the 64 available IDs.

We believe the key to success is making the most of the limitations SKA imposes. For the industry to thrive we need established standards. If we can agree to these, then all players in the Ad-Tech value chain – networks, DSP, SRNs, & MMPs – will be better able to rebuild their value propositions to thrive within the new constraints imposed by Apple. While we don’t have the foresight to know whether this will be the most valuable use of the 6-bit conversion value for all parties, we think it is important to broach the discussion so that we can all benefit from alignment, and avoid pushing in different directions.

For more information on the above, see our FAQ here: Dataseat Conversion Value FAQ. For a more detailed technical implementation guide and example code see Github: dataseatSKAConversionValues.

David Philippson is the founder and CEO of DataSeat, an in-house mobile programmatic advertising solution. Prior to DataSeat, David served as the co-founder and COO of AD-X, one of the first attribution platforms for mobile, which was acquired by Criteo in 2013.

Photo by Maximalfocus on Unsplash