Ensure you avoid duplicated attributions in iOS14.5+

Apple’s iOS 14.5 is a complex topic that will have serious ramifications on the industry. Over the past year, we have been talking to a number of advertisers and ad networks about how they will be impacted by the changes. This is the first installment in our blog series where we help shed some light on some of the most complex topics.

Today we’ll discuss one important topic to pay particular attention to: the possibility of duplication when using SKAdNetwork alongside other forms of attribution.

Let’s start with Self Attributing Networks (SANs). All SANs have confirmed that they will measure campaign performance via SKAdNetwork (SKAN) attribution.

For advertisers who only buy inventory on SANs, this will work well, these channels only use SKAdNetwork — there is a single source of attribution. However, issues may arise for advertisers who run on other media channels.

Let’s assume that some ad networks or affiliate networks offer to support a mixture of both deterministic attribution and SKAdNetwork for billing purposes. These hybrid campaigns will create a certain rate of duplication.

Imagine you run a non-SKAdNetwork campaign and you have a user consenting both on the publisher app and your app, that channel will track the user using IDFA, however if your user had also clicked (or seen) a SKAdNetwork ad from another media source in the past 30 days then SKAdNetwork would give credit for that install — causing you to double pay. There is also no possibility of de-duplicating because the SKAdNetwork install is aggregated.

This is because if a user consents on the source app, clicks on a non-SKAdNetwork ad, installs and consents on the target app, attribution will be done on IDFA and no SKAdNetwork data will be sent. The ad network which served the ad will receive an attributed postback with the IDFA and will charge the advertiser for that user.

Now, if that user actually clicked (or viewed) a SKAdNetwork ad from another ad network before the install from another channel, SKAdNetwork will return a claim to that channel for that same user, which the advertiser will be charged for.

There is a very real risk that advertisers could get charged twice for the same user, simply because two different channels use two different attribution methods.

So what steps can you take to prevent this duplication? We suggest that advertisers think about the following steps:

1. Choose your media sources wisely.

In the new iOS 14.5 world, smaller sources of traffic, ones that cannot scale, will be less desirable. SKAdNetwork attribution is quite susceptible to fraud. If a fraudulent party spoofs clicks, they will be able to trick SKAdNetwork into attributing, diverting attributions away from major, legitimate, sources of traffic. This is because SKAdNetwork is not yet built to capture fraud but rather returns attribution for whatever it sees as the last click (or view).

Additionally, rebuilding campaigns in this new world will require a lot of effort. Therefore advertisers will want to focus first and foremost on sources that can scale. We believe it prudent to focus on the largest platforms, network partners and DSPs.

2. Try and get SKAdNetwork as the billing default across all channels

Understand how each media channel is billing you.

Given that Self-Attributed Networks will use SKAdNetwork for attribution you should make SKAdNetwork your billing default.  This is the only way to avoid duplication rates. Advertisers paying networks on a CPI should ask to be billed on SKAdNetwork installs. Advertisers buying dynamic CPM to CPI optimization should ask these networks to use SKAdNetwork installs to optimize the buys, so as not to artificially inflate media costs.

We believe that advertisers who follow the above steps, will have a better chance at clean billing and, at the very least, will not be overpaying.

With that being said, there are still open questions and considerations that could make this convoluted in the short term. These questions are important to keep in mind as you consider how you wish to approach your planning and forecasts:

[object Object]0. What will networks do for their older SDKs that don’t support SKAdNetwork? What about newer SDKs that do not support SKAdNetwork view-through attribution? How will advertisers be billed for this traffic? Will this traffic simply not be accessible? It is paramount that every advertiser understands these questions and is able to get answers from each network they use
[object Object]1. What will SANs do prior to iOS 14.5? Will they leave current methods live for pre-iOS 14.5? If this is the case, then the market can continue to operate as it has for all traffic under iOS14.5 — and only use SKAdNetwork on 14.5+. This approach has the benefit of being cleaner and will buy the industry as a whole more time to adapt as adoption for iOS14.5 slowly ramps up. However, as explained above, any conflict on any channels could lead to duplication. For that reason, we encourage all advertisers to ask their most trusted media sources about how they are approaching this shift in our industry.

• Ensure you have the ability to scale by making sure to focus on the platforms as well as the largest network partners and DSPs.
• Work out how you will be billed for traffic in older network SDKs that don’t support SKAdNetwork or newer SDKs that don’t support view-through attribution.
• Contact your partners to ask how they plan to bill for traffic under iOS14.5 and traffic for iOS14.5 plus.

If you have any questions about the implementation of iOS14, don’t hesitate to reach out to your CSM or account manager. And pay attention to the Adjust blog in the coming weeks for more information about how to prepare for the imminent launch of iOS14’s privacy changes or check out our always up-to-date iOS and SKAN Solutions.