Blog Is the loss of a full bit really worth i...

Is the loss of a full bit really worth it? The truth on single-source iOS 14.5+ attribution

Katie Madding, CPO, Adjust, Aug 15, 2022.

Measurement on iOS 14.5+ has become more complex for mobile marketers and advertisers. To aid in this complexity, mobile measurement partners (MMPs) and analytics platforms have been working on solutions since the initial announcement in April of 2020. As we embrace these changes at Adjust, we’re building next-generation solutions that empower clients to put data-privacy center stage while driving growth.

Our approach focuses on leveraging device-level and SKAdNetwork (SKAN) data side-by-side to build comprehensive reports in a highly accurate, tabular format. Some other solutions on the market take an ‘all-in-one’ or ‘single-source’ approach, which essentially attempts to estimate the overlap between installs attributed via the SKAN framework with installs attributed via the App Tracking Transparency (ATT) framework. This might sound good in theory but it is deeply flawed. Most importantly, it comes at the price of a full bit.

The problem with all-in-one iOS campaign data

By estimating the overlap of SKAN installs and ATT installs, it’s theoretically possible to see which SKAN installs were already attributed by ATT. This would mean marketers would be able to confirm, on an aggregated level, that Total SKAN installs = Total paid MMP installs. One way this could be used is to confirm unexpected differences between the two datasets. This troubleshooting process, however, has no next steps. You’ve just wasted a crucial bit only to prove numbers that don’t match.

Let’s illustrate this with two examples

First, we have the example we like to call False Hope:

Timeframe: July 2022

MMP paid installs: 80k

MMP organic installs: 40k

SKAN installs: 100k, where using the attributed bit, 80k returned with 1, meaning they were attributed

In this scenario, a UA Manager could falsely believe that all of their SKAN Installs were attributed and that their MMP is showing the same number of paid installs and that the correct number is being reported. This is the wrong conclusion. While at a high level the numbers look as if they match, we have to take one step further. Of the 80k SKAN attributed installs, let’s say that 40k were attributed to Facebook and the other 40k were attributed to Google with minimal campaign information. The MMP on the other hand shows 20k to Facebook, 20K to Google, 20k to a web campaign (which is not possible to run via SKAN today), and 20k to AppLovin. So while the totals match, the attributed partners do not. You can cross-reference attribution windows via your MMP but because you can’t see the SKAN windows, you don’t have the ability to properly compare the data sets. Just because the totals match doesn’t mean you’re any closer to a single source of truth.
Second, we have the more common example, what we like to call The Dead End:

Timeframe: July 2022

MMP Paid Installs: 80k

MMP Organic Installs: 40k

SKAN Installs: 60k, where using the attributed bit, 40k returned with 1, meaning they were attributed

Here, the UA manager can see that only half of the installs shown by the MMP as paid are represented in their SKAN totals. The UA Manager can then look to see if perhaps these 40k ‘missing’ installs were from campaigns SKAN does not support—web, email, influencer, etc. Let’s just say the MMP had attributed 50k to various web campaigns, and 20k to Google and 10k to Facebook. The SKAN installs were attributed to Google and Facebook, so 30k each. How do you map these numbers together? The 40k missing on the SKAN side doesn’t match the 50k to the various web campaigns. Also, why were Google and Facebook so differently attributed by SKAN and by the MMP, respectively? You could in theory dig out the exact reasons for how the attribution happened on the MMP side, but cannot do the same on the SKAN side. In other words, you hit a dead end.

Performance KPIs you could theoretically deduce from a single source model are overall eCPI, CPE, and ROAS but with the inherent limitations in terms of accuracy, optimizing campaigns (scale, pause, stop) based on the calculation used to estimate performance would be highly inadvisable. We get into the specifics regarding accuracy limitations in detail below.

In short, single-source models provide an estimated, high-level overview of the total iOS installs from both frameworks, at the price of a full bit.

The bit logic explained

With single-source, the sixth bit (the highest) is assigned to a TRUE/FALSE flag, meaning that half of the 63 conversion values that can be used for mapping event and/or revenue range conditions are lost. In the binary representation, it looks like this:

Each bit can take a value of 0 or 1. So, in the first scenario, we can go from 000000 to 111111, or from 0 to 63 in decimal representation, meaning that all 63 conversion values can be used for mapping conditions. In the second scenario, however, we can go from 00000 to 11111, or 0 to 31 in decimal representation, with the 6th bit now being flipped to TRUE or 1. This means that for CV=1 to CV=31, any event condition mapped to the CV assumes that no ATT attribution happened. Similarly, for CV=32 to CV=63, any event condition mapped to the CV assumes that ATT attribution did happen. With one bit used for the ATT attribution flag, the CV value sent from the device will include either a TRUE or a FALSE, or translated into binary, either a 1 or 0.

The consequence of this is that you would need to basically repeat the same event condition twice in your CV schema (from CV=1 to CV=31, and again from CV=32 to CV=63) in order to take into account the possibility of ATT attribution happening or not. Most importantly, you lose half of the available CVs you have at your disposal and receive a postback from SKAN including a CV designed to tell you whether the SKAN install was also attributed via the ATT framework or not. It’s important to note that this postback will not include the attributed partner as per ATT. It would be theoretically possible to pass this info via the postback, but then you would need to use even more bits and there aren’t enough available bits to code in partner information without using them all up.

To make sense of this and achieve an ‘all-in-one’ or ‘single-source’ dataset, the following calculation is made:

Total installs = ATT paid installs + ATT organics + SKAN paid installs (no ATT flag)

This calculation falsely assumes that the number of SKAN paid installs (with ATT flag) is the same as the number of ATT paid installs during a specific timeframe.

A dangerous number of estimations

These models are far too reliant upon estimations in an ecosystem that depends on accuracy. Here, we’ve identified the four key estimations all-in-one/single-source models make and explained the problems inherent to each.

1. Different and unknown estimation models: The Total installs calculation itself assumes that the number of paid installs attributed via SKAN that include the ATT flag is the same as the total number of paid installs attributed in the ATT framework. We know from experience that this is incorrect. The reasons for this include:

The partners you are running with need to support both frameworks for the data to match, which is currently not the case with for example influencer and web traffic.
SANs might not be able to claim installs in the ATT framework due to lack of user consent, but the exact same users might very well be attributed to a SAN in the SKAN framework (since attribution happens regardless of user consent).
Lack of access to engagement information and the attribution waterfall from SKAN means it’s not possible to investigate how an install was attributed to a specific partner.
SKAN and ATT have different attribution windows.

2. Partner attribution per framework: The calculation assumes that if SKAN attributed an install to a specific partner, so did the MMP (as we mentioned above, the partner source is not included in the bit that carries the info whether the install was attributed via the ATT framework or not). This is information that cannot be confirmed or denied, so it simply cannot be relied upon. It is possible to assume that the number of installs on either side evens out as you are only looking at totals but, as stated in the previous point, this assumes that you are running with the exact same partners in both frameworks, meaning the situation becomes complicated when there is a partner discrepancy. This situation is not unusual, considering how SKAN works.

Advertisers can only run internal marketing campaigns (cross-promotion, email marketing, influencer campaigns, and mobile web campaigns) within the ATT framework. With a single-source model, however, these installs will also be sent with the attribution flag ‘true’ and will be added to the number of SKAN installs with an ATT flag, assuming that, due to an inventory overlap, SKAN attributed these same devices to an ad network. This means you cannot assume that ATT paid installs = SKAN paid installs (with ATT flag) and any derived overall eCPI or ROAS will be inaccurate.

3. Day of install: The day of install is also an estimate on the SKAN end, as the postback doesn’t include the exact timestamp. This estimation can be made based on the CV window used and if the postback includes a non-zero CV or not. A major complication here is that for Google, the SKAN timestamp doesn’t refer to the day Google received the postback as it does with all other partners. Instead, it refers to the estimated day of engagement which itself is an estimation done by Google. So, you need to estimate the SKAN install date based on Google’s estimated engagement time. Again, this is simply far too many estimations to rely on.

4. The privacy threshold: Apple’s privacy threshold creates further complications when attempting to create a single-source calculation. Some postbacks sent from SKAN to partners include CV=null, meaning you don’t get the desired information from the postback needed to answer ‘was this SKAN install attributed in the ATT framework or not?” The share of postbacks coming back with null values varied greatly between partners and campaigns (~10%-40%) and it is not always clear why one campaign has a higher share of null values than another. Only Apple can truly answer what hits or does not hit the threshold. When it comes to SKAN paid installs (no ATT flag), there is no way to estimate via a multiplication factor because of the ambiguity of how the privacy threshold is applied. Any attempt would, once again, be an estimation.

Side-by-side data is the key to accurate, reliable iOS campaign reporting

A single-source or all-in-one approach to iOS campaign data is based on far too many estimations. The solutions currently on the market that aim to combine SKAN and ATT data depend on layers of estimations and sacrifice half of the conversion values available to clients—sacrificing a bit in exchange for inaccurate and inactionable data is not a price worth paying. If you want the best, most optimized data to help you grow then cheap tricks simply cannot be relied upon. Clear, accurate, and actionable data is essential when making important strategic decisions such as where to allocate budget, which campaigns to pause and scale, or which channels to focus on.

By taking all of the SKAN limitations that exist into account, Adjust recommends side-by-side reporting via our analytics solution Datascape. All available data is displayed in an easy-to-understand format that doesn’t take any shortcuts, meaning it can be your true single source solution. With a range of SKAN-related KPIs (conversion, revenue, and events), Datascape empowers you to build comprehensive reports that can be leveraged side-by-side with your regular Adjust attribution data. This is the best way to ensure accuracy.

The most effective way to navigate measurement in the complex iOS ecosystem is via machine learning and predictions which will provide you with accurate eCPI, CPE and ROAS—something Adjust is developing next-generation solutions to solve for. At the end of the day, what a marketer needs is simple: a tool that clearly demonstrates the revenue a campaign receives for every dollar spent so that the decision to pause or scale a campaign can be made quickly and confidently.

For more information, you can get in touch with your Adjust contact person or see our iOS & SKAN Solutions.