The release of iOS 14.5 is fast approaching. In order to help advertisers successfully transition, we’ve created this checklist. We’ve combined some of the basics along with some less-obvious and more than note-worthy changes. 

We believe the combination of the two is a recipe for success. If you’ve already been through the basics – just skip to the relevant sections. 

1. Update your MMP’s SDK
2. Confirm DSPs’ integration with your MMP. 
3. Set Up a Conversion Value
4. Understand Your MMP’s Solution
5. Understand Your DSP’s Solution
6. The Bottom Line

In our previous post, User Acquisition and Retargeting in iOS 14 here, we’ve covered the absolute basics:

1. The expected changes
2. What internal data will be available for publishers
3. Attribution using SKAdnetwork
4. Retargeting post-iOS 14.5
5. Fraud in iOS 14
6. Important steps DSPs can take when running campaigns without IDFA (such as contextual targeting and frequency capping). 

Unlike our previous post, which is a great resource for anyone interested in the big picture overall overview of the upcoming changes, this post is a deep dive into the changes, what changes and preparations should be made, what to expect in your first SKAN UA campaigns, and more. 

In preparation for iOS 14.5, MMPs, along with all other relevant parties, have been working to conform to Apple’s new requirements. In order for your MMP to continue and deliver your performance data, publishers must have their latest SDK installed and verify that it’s iOS 14.5 compatible. As you’re most likely wearing both hats (publisher and advertiser), it’s crucial that you update your MMP’s SDK. 

Yes, we are aware of how stating-the-obvious this is, but if we’re being honest, you’d be surprised at how many haven’t been fully integrated yet. Check-in with your MMP to make sure that once iOS 14.5 is out, your campaigns, from all sources, can continue to run. 

There’s no announced release date for iOS 14.5. It’s better to come prepared than be caught off guard the day of the release. 

The biggest challenge is in understanding the value of these new anonymized users, assuming most users will not opt-in with ATT to share their IDFA. The key to determining value in the post-iOS 14 era is through setting up a conversion value.

SKAdnetwork is an Apple-developed and privacy-compliant attribution framework. SKAN helps advertisers measure their app marketing efforts while maintaining user privacy. Since it works without IDFA or any other advertising ID it doesn’t require users’ consent (i.e, they can be opt-out of ATT and you’ll still get postbacks with conversion values for them). 

The best way to understand how SKAdnetwork postbacks work is to compare it to the current way postbacks work.

1. The user opens App A, sees an ad for App B and installs it. 
2. The MMP’s SDK identifies the new user according to his IDFA.
3. The MMP attributes the install and sends the postback to the relevant DSP that had the last ad engagement with the user (and has an active attribution window).
4. This postback includes the IDFA and additional data about the user. 
5. An event postback is sent through the MMP to the DSP in real-time, and in many cases with the inclusion of how much revenue was generated in that single purchase. 

Since these postbacks include the IDFA, MMPs are able to attribute installs and events on a 1-to-1 level and DSPs can use this granular data to train ML models, bid on lookalikes, etc. 

SKAN postbacks offer a few changes.

• Conversion Values: since there are no identifiers, users’ activity is measured through a set of numerical values, each representing key events for the advertised app, with their definition up to the discretion of the app developer. 

• • Conversion Model: the conversion model is the way user activity is encoded into the conversion values. For example, a model can be event-based, it can incorporate time dimension, it can focus on retention or on purchases, etc. 

• The 24-hour timer: after a user installs the advertised app, a 24-hour ‘event’ timer is started. This timer can reset if another key event occurs (an event set as a numerical value in the conversion value section) within this window, or expire if it doesn’t. 

• The Random Delays: after the 24-hour timer expires, the conversion value is locked in and a random delay starts before sending the relevant DSP a postback (the random delay seems to be designed to dissuade marketers from attempting to connect it to impression data and maintain some semblance of user-level data). As far as we can tell now, it can be up to 24 hours. After the delay, the postback is locked in and sent to the DSP. 

• The Single Anonymized Postback: there’s only one postback per app per user (if there’s an event past the 24-hour timer it’s not going to be reported through a postback). This postback contains the install and the user’s latest conversion value. 

Now, let’s go back to our previous example of how attribution technically works, but post iOS 14.5. 

1. App B has set up a conversion model that helps predict users’ performance: 0 = install, 1 = level 3, 2 = level 10, 3 = deposit. 
2. The user opens App A, sees an ad for App B and installs it. According to App B’s conversion model, the current conversion value is set to 0 (i.e, the app has been installed) and the 24-hour timer starts. 
3. Within 4 hours of the install, the user reaches level 3 (i.e, conversion value 1) which triggers the 24-hour timer reset. 
4. 22 hours pass and the user has been making its way up the levels, finally reaching level 10. The current conversion value changes to 2, and the 24-hours timer resets again. 
5. An hour later, the user makes the first deposit. The conversion level changes to 3 and another 24-hour timer begin. 
6. There are no other events happening in these 24 hours and the conversion value gets locked at 3. Now, the random delay begins. 
7. In an unknown time frame (up to 24 hours since the last timer expired) a single anonymized postback carrying the conversion value 3 will get sent from the user’s iOS device to the DSP. 

This conversion model is based on events, and this example is kind of an ideal scenario, in which all of the conversion model’s events happen within their allocated time frame. 

Getting a postback with the maximum conversion value makes it easier to predict the value of this user. So let’s look at an alternate scenario that started the same, but didn’t go exactly according to plan.

1. This scenario also starts with the user installing the app. 
2. Within 4 hours the user reached level 3, which means the current conversion value is 1 and the 24-hour timer begins. 
3. This time 24 hours pass but the user doesn’t reach level 10. This means that the conversion value has been locked in at 1, but the postback hasn’t been sent yet (due to random delays). 
4. Another 2 hours pass and the user does reach level 10, but now, unfortunately, it won’t affect the conversion value and it won’t be sent as another postback. 
5. The user makes a deposit immediately after reaching level 10. Again, since the conversion had already been locked, this event won’t change the postback value. 
6. The single anonymized postback carrying the conversion value 1 will get sent from the user’s iOS device to the DSP.
7. This outcome won’t necessarily represent the user’s predicted value and gaining actionable insights from this postback are likely to pose a challenge. 

These two possible scenarios exemplify the challenges of setting up a conversion value and how using an events-only conversion model might not be sufficient. 

We’ve heard discussions and have seen attempts to incorporate time dimensions into the conversion model. We generally think this might be a good idea for some apps, depending on the possible time dimension (day of the week may not be indicative for most apps, but if other time dimensions can be measured it may be insightful). Either way, we encourage advertisers to explore all possible setups before committing to a conversion model. 

There’s no denying that this change will greatly impact everyone. MMPs, aiming to continue to deliver performance data and help advertisers make data-based decisions face some pretty big challenges. 

Our recommendation is to take the time and understand the upcoming changes and the available solutions to guarantee an easier transition. Keep in mind that there’s no perfect solution that will maintain user-level data. As long as users didn’t opt-in through ATT, user-level data won’t be available, and performance will be valued based on the aforementioned conversion value. 

AppsFlyer chose to focus on four core areas: their SDK, SKAdNetwork, Web to App Campaigns, and AppsFlyer Privacy-Centric Attribution. 

Their bottom-line, as we understand it, is to provide advertisers with predictive analytics. They aim to use conversion value in a comparative manner that will provide advertisers with long-term predictions. 

Read AppsFlyer’s iOS 14.5 readiness page to learn more

Adjust’s focus is on simplifying the setup of the SKAdNetwork conversion value, along with some additional tools to help developers make sense of performance data post-ATT.

Their initial intent seems to be to provide support for their advertisers as they set their conversion value and follow the data changes.

Read more about Adjust’s readiness for iOS 14.5 

Tenjin, unlike other MMPs, promotes a change in the current payment models MMPs offer. As a free MMP to begin with, their claim is that MMPs should stop charging for attributed installs, as the challenge to validate the value of the installs will be greater, if at all possible. This outstanding stance is worth mentioning. 

Similarly to other MMPs, they too offer support, an updated SDK, and setting up SKAN conversion values.

Read more about Tenjin’s iOS 14.5 readiness 

Most MMPs, at this point, offer iOS 14.5 support in the form of a SKAdnetwork-compatible SDK, ATT guidance, and SKAdNetwork conversion value setup. While this may seem pretty basic support, considering how much is still unknown, it makes sense to first offer these essentials and after further experiencing the new post-iOS 14.5 ecosystem, make the necessary adjustments and conjure relevant solutions for advertisers’ new needs and requirements. 

Read more about these MMPs iOS 14 preparedness: Singular, Branch, Kochava

Another part of the industry that’s going to be significantly impacted are ad networks and DSPs. Since they’re inherently different, their solutions will differ as well. 

Ad networks and DSPs are usually bound together under the same duopoly-alternative solution, though they themselves differ significantly. There are different types of DSPs (managed, self-service, or in-house), and they all use different technologies (such as programmatic buying or ML-based targeting).

Though they differ, all DSPs and ad networks alike, will be impacted from the move from IDFA to SKAN. Much like MMPs, each offering their own solution but dealing with the same bottom-line, so do the DSPs. 

Their way of dealing with these changes will very much depend on their existing technology. For example, a DSP that utilizes machine-learning models for targeting may still use this technology, and the data still available in the bid request to target relevant users and adjust the bid according to engagement predictions but would lose its ability to recognize more complex and specific patterns. 

As DSPs will lose their ability to accurately predict user value (and MMPs will struggle to measure it, as well), the focus would be to adjust the campaigns according to the data at hand. This means lowering bids, and seeing how well and indicative the conversion value can actually be. 

It’s safe to assume prices will decrease – both CPMs of the ad inventory bought and as a result, and most likely, so would the average CPI. With the loss of predictability, DSPs or any other performance-based player would have to lower their bids, which will affect the entire RTB ecosystem. Our estimation is that everyone will try to maintain a significant and representative scale and learn the meaning of the delivered conversion value. 

After some data is gathered, advertisers can deduce the relationship between the conversion value to how indicative it is of actual user value (how does one translate it into ROAS and LTV effectively?). If it does work as an accurate indicator, advertisers can start estimating the value delivered by DSPs accordingly or consider using different conversion values if they seem to not be indicative enough. 

Once there’s a better understanding of the change and its effects, scale can be gradually increased.  

The only thing we truly know is that there is still a lot that can only be learned through trial and error. We don’t have a vote of confidence, we can’t say that there won’t be any hurdles along the way, and that’s mostly because no one can truly say that. 

We do know that advertisers should think long and hard about their conversion model since it’s the key indicator for their bottom line. They should consult with their colleagues about setting their conversion value in a way that would help make their acquisition reliably measurable and effective. This setup is not “one-size fits all” and it will differ between different apps, as we’ve indicated earlier. 

The chosen conversion model and its subsequent values should be, as much as possible, helpful in drawing revenue-related insights. These results should then be measured as much as possible against actual revenue and tested to see if the chosen conversion model manages to indicate and predict performance or not. If it’s the latter, then it calls for a change of a conversion model.

We don’t actually know how many users will decide to opt-in through ATT and what it would mean. Will the decision to pot-in have any indication of the value of the users? 

So no IDFA, and yes, there are some problems. It’s not the end of the world, but it’s definitely a challenge and a change. There are a lot of unknowns and there will be a learning curve followed by gradual adjustments to the effects of these changes. 

We hope we’ve helped clarify some of the key changes, some things that you should take note of, and all of the preparations you should be making. 

For further information

• UA and Retargeting in iOS 14 – an overview of the changes to come.
• The Context Calculator – how we maintain targeting accuracy post-iOS 14.5.
• Mobile Measurement Platforms – leading attribution platforms and how they differ.
• The Basics of RTB – understand how the RTB ecosystem works.