Can Ad-Tech adopt a standard for ATT 6-bit conversion values? FAQ

Under normal conditions advertisers would obviously prefer more granularity when looking at LTV. However, SKAdNetwork introduces a unique constraint where developers are forced to limit the amount of time within which they record conversion events. Data science teams therefore need to study how user actions occurring within X hours after the install can be correlated to predict future value. The longer the measurement window, the more buckets are likely to be needed. At 24 or 48 hours, we think it’s unlikely that there would be significant gains in using more than 8 segments.

Facebook requests a maximum period of 24 hours for collecting conversion events. More: Facebook for Developers

Facebook supports “14 standard app events”. We recommend that advertisers correlate these into a maximum of 8 buckets predicting LTV.

Waiting a longer period following the install to record LTV events will substantially limit advertising performance, as this will also delay the install notification (both install and conversion value information are sent in the same SKAdNetwork postback). This will make campaign optimisation difficult.

In the case of an advertiser recording LTV events for 1 week following the install, the ad network will have no knowledge of campaign performance until at least 8-9 days after the impression. As an example, imagine launching a new creative on a Monday and not knowing how well it performed until Wednesday the following week.

Apple’s documentation specifies that postbacks are sent “0-24 hours after a 24-hour timer expires”. This introduces a random element, making it impossible simply to subtract a fixed amount of time in order to guess the day the app was first opened. Doing so would guarantee a reporting error of 1-2 days either side of the actual day of install, for a significant share of installs.

We have also seen SKA postbacks arriving outside of these fixed bounds. In some cases up to several days later than expected, most likely due to the fact that SKA postbacks are not sent when the device is in lower power mode or off)

In both scenarios pictured, the install happens at the same time and the window for measuring conversions is the same. However, scenario 1 may result in a postback on day 2, while scenario 2 may result in a postback on day 4. If the ad network tries to work out the install day using the time the postback is received only, they will be wrong about half the time.

One suggested improvement may be to count the number of days that have elapsed since the install, rather than encoding the specific day of the week that the install occurred on. This could enable advertisers to use less than 3 bits of the conversion value to declare the install day. For example, only 2 bits would be needed to represent an integer of 3 (meaning: “install occurred 3 days ago).

However, this approach encounters the same issues which prevent ad networks from inferring the install day from the time that the postback is received. The random element of the SKA postback (sent at a random time ‘0-24 hours’ after the timer expires) makes guessing the install day impossible, and will guarantee an error for a significant share of installs.