New guidelines on iOS 14 have emerged since this post was published, meaning some of the information in this article may be outdated. Please reach out to your dedicated Adjust rep, or firstname.lastname@example.org, for the latest guidance on iOS 14.
Apple’s announcement at the WWDC 2020 on their user privacy changes has taken a lot of people by surprise, and many in the space have decried these changes as the end of the mobile industry as we know it.
At Adjust, we don’t believe this is quite the watershed moment many are making it out to be. However, we have been spending the last few days mapping out the best way forward - bearing in mind that many technicalities still need to be ironed out before iOS14 is released in September.
We are working closely with Apple to gain clarity on several areas. Yet the nuances of Apple’s proposed regulations become much clearer once we break these new rules down into their individual elements and analyze their impact on the different players in our ecosystem.
SKAdNetwork vs. AppTrackingTransparency
To start, it’s worth clarifying the two main options for attribution and ad measurement that Apple has presented us. They represent different approaches to the same problem, and it’s important not to conflate the two.
On the one hand, Apple introduced the AppTrackingTransparency (ATT) framework that manages access to the IDFA with required user consent. Apple also outlined exemptions for this framework that might provide the ability for attribution as it exists today. We believe that focusing on this framework and creating tools within these rules is the best way forward - but before diving into this further, let’s have a look at the other potential solution.
Often mentioned in the same breath, SKAdNetwork (SKA) is an entirely different approach to attribution that removes user level data entirely. Not only that, but it also puts the burden of attribution on the platform itself.
This poses three fundamental problems:
The first issue is that user level data is necessary in today’s world of user acquisition - not to profile users or serve them targeted ads - but to analyze how campaigns are performing on a granular level. SKA’s proposed 6-bit of downstream metrics with a fixed 24 hour timer does not offer nearly enough insights to manage the highly competitive performance-focused UA campaigns of today. Marketers will no longer receive retention data, revenue tracking or granular event tracking, meaning they will no longer be able to run their current campaigns.
Indeed, the data tracked with SKA and the granular, in-app events tracked by MMP SDKs cannot be tied together, which limits any kind of campaign analysis to the install metrics only.
The second issue revolves around the level of granularity SKA allows for its aggregated data, where only 100 different campaigns will be visible per network. Looking at our clients who run an average 15 campaigns per network you might think this isn’t such a big problem. But beneath each of these campaigns, there are often countless sub-levels for different geographies, device types or creatives. With SKA, using 10 creatives in five countries, for example, would only allow you two distinct campaigns per network. Coupled with the random delay of data from each device, this means making granular real time decisions is near impossible.
Moving attribution away from the MMPs, who have loads of experience in this area, could stifle innovation. The minor changes to SKA from version 1.0 to 2.0 suggest a lack of alignment with the needs of its customers when it comes to ads that power app discovery on the platform. SKA provides no ability to deep link (deferred or conditional) and does not consider anything but the act of downloading as attributable. When it comes to ad fraud, they will at best be solving the issue by making most advertising not viable in the first place.
MMPs are driven to provide configurable, meaningful attribution that allows clients to spend billions of dollars on driving new users into their apps and retaining existing users. Competition has bred some of the most advanced technology used today to power the growth of this industry. Relying on SKA to provide the future base for this industry is simply not viable.
User consent: challenges and opportunities
At the moment, very few believe users would opt into giving access to their IDFA with the pop up message ATT will introduce. Users are understandably wary of sharing more data than necessary - especially if the pop up provides little context on how this data will be used.
But Apple introduced this consent management precisely so users can better understand how their data will be used - so there’s an opportunity here to explain the benefits.
Let’s remember that user level attribution today needs access to the IDFA in the source app, showing the ad, and the target app, advertised in the ad. Imagining a way forward becomes much easier if we break these two cases down.
If an app monetizes through advertising and provides a free service for the user, it is not beyond the realm of possibility that the user will agree to access their IDFA. Most people already accept this when using social media or search engines.
Instead of just throwing the pop up to ask permission, an app could show an explanation of what will happen with the data and why the app needs it. Many news websites today, for example, ask users if they would rather have a paid subscription or use the ad-supported version of their site. The same model is absolutely a realistic and viable option for apps.
Another benefit of this approach is that an app could either ask the user repeatedly, or after letting them understand the value of the app. This would work in a similar way to how access to the push token is handled by many apps: first users see a screen from the developer explaining why push notifications will improve their experience, and then the system pop up is shown. Apps would only throw the ATT pop up after a screen from the app explaining what is happening and why.
Since the timing of consent and access to the IDFA isn’t crucial in the source app, brands also have some time to convince the user. And it makes sense for our industry to start standardizing a framework for asking permission so users can more quickly understand what is going on. Such a framework could also allow the user to be more explicit about which use of their data they agree to.
As Steve Jobs said, “ask them” [i.e. consumers] so that they know what they’re signing up for - and let them know precisely what you’re going to do with their data.
Now for the target app this might be much harder. Attribution usually happens in real time, and would require the user to give their consent very early on. Especially for apps that monetize directly from the user, they might be hard-pressed to get users’ consent for “tracking across apps and websites owned by other companies” and to “serve personalized ads to you”.
So what are our options here?
On-device attribution and granular consent
Apple has provided two exemptions for accessing the IDFA prior to user consent:
The first one describes a way to use the IDFA on the device itself as long as no user or device identifiers are sent off it.
Adjust and other MMPs are currently working on cryptographic solutions using practises such as zero knowledge theorems that might allow us to attribute without having to transfer the IDFA off the device. While this may be challenging if we have to use on-device for source and target app, it is easier to imagine a solution if we are allowed to receive the IDFA from the source app and only have to perform the matching on-device in the target app.
We will be sharing our ideas with Apple and seeking approval for such a solution soon.
We believe that obtaining consent in the source app and on-device attribution in the target app might be the most viable path for user level attribution on iOS14.
Another technology that might provide on-device attribution is by introducing a similar solution to the GooglePlayStore Referrer as discussed in my last article - but it’s still unclear whether Apple will consider adding such an API to their AppStore.
It’s also worth considering that Apple may be willing to allow MMPs to read the IDFA in the target app for attribution only, and require the ATT permission for any additional products such as segmentation or data forwarding to other parties. This way, MMPs could provide compliant measurement without ever using the IDFA outside the scope of the target app.
MMPs would not need to share the IDFA with anyone and would act only as the extension of the app publisher.
Apple would also have an effective tool to police the handful of MMPs it would be overseeing, by disallowing IDFA access for attribution to certain SDKs if they do not follow the rules. As a privacy-centric company, it’s a move Adjust would welcome and encourage.
Adjust will work with other MMPs, clients and partners to discuss these options with the Apple AppStore team, and we hope to find a solution that works within the AppTrackingTransparency framework by the release time of iOS14 in September.
As an industry, we need to coordinate a response to the new rules of iOS14 and use this opportunity to create a sustainable future for app developers and advertisers.
Adjust believes that user consent is crucial for any app that monetizes through advertising and that there are options to provide user level attribution and granular data within the ATT framework for advertisers.
We are looking forward to working together with Apple, our clients, partners and other MMPs to shape the future of our industry.
Stay tuned for more updates.