Apple’s SKAddering of Mobile Attribution with SKAdNetwork in iOS 14
Advice on Marketing in the SKAdNetwork era from our Managing Director Frank Maschmeier
We’re currently witnessing a huge change in the industry, and we should make sure we understand how the world of app marketing gets a lot more complicated. The era of Apple’s iOS 14 comes along with the powerful rise of SKAdNetwork, first introduced in 2018. Most of us are going to miss the old days soon, where attribution was a no-brainer.
In that period that is currently ending, Installation of an app could easily be attributed to the advertising that led to the interaction. IDFA. a unique identifier of one device and, in most cases, one individual, did the trick. It was the IDFA that was registered by the app that displayed ads. And when another app was installed, the same IDFA was used to confirm the desired outcome of the ad on display. A successful install was attributed in the networks and could be tracked down to the channel and even the individual creative. This mobile attribution was easy to set up and very transparent so as to allow for permanent monitoring of marketing measures and quick adaptations and optimizations in the marketing mix.
Although it has been postponed a little until early 2021, Apple is serious about changing this well-established process. The announcement was first made at WWDC on 22 June. Actually, it is proposing the end of the fail-proof deterministic model of mobile attribution. The corporation has announced that it will get rid of IDFA. Alternatively, it wants users to explicitly accept the use of IDFA for the process mentioned above. How likely is that to happen?
As the eradication of IDFA progresses, Apple does offer a limited alternative route to mobile attribution in its SKAdNetwork framework so as to support app marketing via ads in other applications. In this framework, it is not individual clicks that are connected with events, but up to 100 ad campaigns. Each ad network will be given an identifier (SKAdNetwork ID), which will be submitted as the ad is being put on display within an app. When an install occurs, Apple identifies the network that was running the campaign and notifies the same of the event that was tracked (install, registration, purchase or similar). This means a loss of optimization and fine-tuning options, as it becomes impossible to track the individual ad that led to an event or even track a variety of events within the app.
As unfortunate as this new setup may be, I would highly recommend to stick to mobile attribution, even with the more limited capabilities available. A limited set of data is better than none. And I would like to highlight some of the more interesting points that arise and have been underestimated. Here’s my list of 6 points to look out for:
1. A little later, but no less important
IOS 014 is already here. When Apple rolled out the update, it removed the prominent privacy issues, notably to avoid chaos. Facing the complexities of SKAdNetwork, many players in the market simply weren’t prepared. In late August, with the IOS update looming, a number of relevant DSPs (Demand Side Platforms) reported not supporting SKAdNetwork or simply working with their own ID. How would media buying, run by agencies, be feasible in this setup? When Apple announced to delay the changes, this was met with relief by said players.
I would warn the industry, however, not to sit back and rely on hopes. It is highly unlikely that Apple will not follow through. Quite the opposite: From what is publically available, we can read that the rules may become even stricter than hitherto expected. Just consider these points:
- Any act of incentivizing a tracking consent is prohibited
- Penalizing customers by blocking them from access will not be tolerated
- SingleSignOn via Facebook, Google or similar will only be allowed when the user has accepted tracking.
In the light of these developments, I would urge anyone in the industry to confront what’s coming. If you’re unprepared for the new regulations as they will be rolled out in early 2021, you shouldn’t hope for any leniency on Apple’s side.
2. The crucial role of SKAN-IDs in your plist file
Get ready to offer mobile attribution in this new era! Make sure that you are prepared for the SKAdNetwork environment by using a SKAdNetwork-ID (SKAN-ID). To do so, the SKAN-ID of the responsible ad network must be included in the plist file in publishers’ apps. In this file, configuration information for the specific app is collected and sent to Apple. If you want to include a new ad network, you need to update the plist file, and in turn you’ll need to initiate an app update on the AppStore for the changes to take effect. So you can’t just change your delivery partners as you wish. You need to plan ahead.
Here’s a real problem: A publisher that displays an ad banner linking to a network which is not included in the plist file. It’s bad luck when this happens, as there won’t be any postback for this event, no money for the publisher. App developers that rely on mobile ads to monetize need to make sure that their plist files are up to date and their apps updated accordingly, with the SKAN-IDs in place.
For advertisers or agencies: If you wish to cooperate directly with app publishers, you need to consider the preparation time necessary to add such plist file entries. Alternatively, you should take care that your SKAN-ID is widely distributed beforehand. For publishers, it may be a good idea to try and implement all available SKAN-IDs. This would make it much easier to start working smoothly with ad networks.
- Lists of the SKAN-IDs of common AdNetworks can be found here:
3. Fingerprinting won’t be more than a short time alternative
Here’s a big challenge when apps are being advertised with banners on the mobile web. This is where the app-to-app IDFA won’t work. MMPs such as AppsFlyer or adjust produce so-called fingerprints to circumnavigate the problem. Fingerprinting is the process to identify users individually and allow for mobile attribution in these circumstances. When a user clicks the ad banner, device information is gathered and collected by the MMP. If this information matches post-install data in an application, the fingerprint leads to attribution, meaning monetization on the publisher’s side.
If you want to be smart and use this process for app-to-app ads, it may work for a little while. But you can be sure that Apple won’t like it. The company doesn’t seem to have a lot of room for humor when it comes to consent of collecting data. Fingerprinting, however, implies that no consent is given. Be assured: Apple will ban any SDK of MMPs or ad networks that determine transactions based on this individual data. This means you shouldn’t waste resources on the development and upkeep of workarounds. Invest the same resources in a long term approach to SKAdNetwork and you will be much better off.
So far, Apple hasn’t clearly stated how mobile app attribution from web to app will work. So you should monitor closely how this unfolds if you use such channels for distribution.
4. Quick or exact? What kind of postbacks would you like?
The next lines are only interesting for advertisers. SKAdNetwork only sends one postback per install, indicating either an install or a specific in-app-event. Apple determines the schedule for the transmission of these postbacks. If no other event is registered with Apple within the first 24 hours after the install, Apple transmits the install information following a random timer of up to 24 hours. So minimum elapsed time from install to postback is 24-48 hours.
If you as an advertiser decide to register an event with Apple, the timer resets and a new window of 24 hours starts. Apple will wait for another event trigger. In this scenario, it’s possible to send up to 64 events in a hierarchical order. If an event with lower hierarchy is triggered, the timer won’t reset. Only the event with the highest priority will be transmitted, not the most current one. Even though MMPs now state they will map all your existing events to SKAdNetwork events and you will be iOS14-ready by default, you’d better look into this yourself.
Imagine that several events are configured in your app. The timer would reset several times, so it would take up to weeks for you or the ad network to receive information that could help you optimize the sources. Therefore, I strongly advise you to re-specify the trackable events and use them to prolong the time until you have a good understanding of the average lifetime value of your customers.
At certain intervals, you’d initiate the post of an event that matches a LTV category, meaning you rather open drawers than track actions. This way, you will track the lifetime value of a user. If your picture of the economics changes, you can overwrite any value within the same 24 hour interval. You could do so by re-specifying these drawers with higher value event postback IDs. Depending on the number of drawers you put in, you could do this in further cycles. It will be yours to decide between quick reaction or exact understanding. You then need to make a choice whether you want to wait longer without being able to optimize on the fly, or to accept this and go for higher accuracy in your predictions.
5. Face it: There’s no proper test environment
We like to rehearse things before we get serious, but this becomes much more complicated with SKAdNetwork. If you want to run tests, you need three things:
- Publisher Test App
This can be a beta version of your renewed app published via Apple Testflight, but your app (or, to be specific, your app bundle id) needs to have been published on the AppStore before. Beware that there are enormous wait times before the postback comes in. Luckily, in September Apple released a so called SKAdNetwork profile, allowing you to test at least close to real time. If in reality you’d wait 24 hours, with such a profile activated you only wait 5 minutes. If you receive postback information in this environment after 15 minutes, this means you’d have waited 3 days in the actual world.
- Ad server
To transmit information about a click to Apple, you need to have a working ad server in place. Every call has unique parameters and must be signed with the key file of the ad network.
This gitlab resource may help when setting up one:
- Advertiser Test App
The advertiser test app needs to load at least function registerAppForAdNetworkAttribution() to initiate a postback. Additionally, if you want to test event tracking, individual events can be tracked by function updateConversionValue(). These functions must be live on the version of the app available on the AppStore.
On the Slack channel “Mobile Attribution Privacy” (mapworkinggroup.slack.com) a user named “Pramod J” mentioned that Pubmatics Test App calls the function registerAppForAdNetworkAttribution() when opening the app. Therefore, this app can be used for a test promotion with SKAdNetwork.
Note that the efforts to test from end to end are remarkable. Reserve enough time for this process or speak to other industry players if you want to use their setup.
6. When Postbacks hit the ad network
Under Apple’s SKAdNetwork rules, ad networks receive the information on successful installs and need to forward this information to their clients or MMPs (Mobile Measuring Platforms). This indirect process is important if advertisers want to keep track of what’s happening on all their ad channels. This means that advertisers need to collect data from a number of different ad networks. Technical interfaces to enable this process are currently still under development. Fortunately, most MMPs offer solutions to receive the postbacks from ad networks and aggregate the data for the advertiser.
For “Ad networks”, see these URLs for MMP solutions:
- AppsFlyer: The SKAN setup for “Ad networks” can be found here.
- Adjust: “Ad networks” should contact their Adjust partner managers. Adjust provides a PDF file with the necessary steps on how to forward the SKAdNetwork-postback.
- Singular: Singular provides the necessary information to integrate for partners who are willing to support this SKAdNetwork setup. See their information here.
- Kochava: Kochava Support for SKAdNetwork can be found here.
- Branch: Branch Support for SKAdNetwork can be found here.
Ad networks be ready: When the first users get tracked via SKAdNetwork, you should monitor closely whether your setup actually works. There’s a host of possible errors that can happen here, e.g.:
- an incorrect ad network signature was supplied when a banner click initiates an AppStore session. There’s no postback from Apple.
- an advertiser forgets to call method registerAppForAdNetworkAttribution() when initializing the app. Under these circumstances, there’s no Apple postback.
- a postback from Apple can’t be verified with Apple’s signature. In this case, there’s no forwarding of the information to the MMP or advertiser.
- when the AppStore is opened, but a wrong campaign ID is transmitted, the postback will be attributed to the wrong source.
As you can see, there’s a simple message: It’s complicated.
But you shouldn’t despair. You should act. I hope I’ve given you some important things to think about. If you want to discuss your strategy for the new world of mobile attribution in more detail, please contact me or my team.