iOS 14 and MMPs: Where we stand right now
Two weeks have passed since WWDC 2020, and the mobile marketing ecosystem is still evaluating what the future will look like. Various players in the industry, including MMPs, networks, publishers, and advertisers, have analyzed the changes and suggested different paths for our collective future.
At Singular, we strive to take an active role in shaping the future of our industry.
That’s why we’re the first MMP to announce full support for SKAdNetwork and have already released open-source code for ad networks, publishers, and advertisers to start getting used to SKAdNetwork and its capabilities.
We understand we are not able to control all the variables, and many unknowns are still to be solved. But we are working with partners, other MMPs, and Apple to potentially innovate additional solutions. I want to take this opportunity to recap the current situation and get up to speed with the latest developments.
Apple released SKAdNetwork over two years ago, but it was still relatively unknown until WWDC this year.
We’ve written quite extensively about what SKAdNetwork is, but as a quick reminder, SKAdNetwork is a privacy-preserving framework — a chunk of code — developed by Apple for mobile app install attribution. It runs on-device to measure conversion rates of app install campaigns without compromising users’ identities.
The main advantages of SKAdNetwork:
- Aggregate-level accurate and potentially fraud-free attribution
- Supports measurement of all ad networks, including self-attributing networks or SANs (Google, Facebook, Twitter, Snap, etc.)
- Developed and promoted by Apple, so likely to be the standard for mobile attribution on iOS
- Significantly improved as of version 2
The main limitations of SKAdNetwork:
- The number of tracked campaigns is capped at 100, including all granularity levels from campaign to creative (although publisher and country are supported separately)
- Limited to a single conversion value metric for each app install
- No support for long cohorts
- No view-through attribution
- No user-level data
- Partial real-time attribution feed
As things currently stand, SKAdNetwork is likely to become a leading methodology for mobile measurement on iOS, mostly because it is aligned with the privacy-centric standard Apple is promoting. This is why we’ve been preparing for its adoption for over a year, and why we announced a SKAdNetwork solution to support our customers and the ecosystem the day after WWDC.
However, it will be a gradual process and we are also working to promote some key improvements that would help it accommodate the full needs of marketers.
Proposed solutions for user-level attribution
Maintaining user-level attribution is definitely the path that would minimize disruption of the ecosystem, supporting the measurement methods which are used today, including granular attribution and user-based cohort analysis.
There are a few interesting suggestions in the industry that would potentially preserve user-level attribution.
We are analyzing these methods and actively participating in discussions with industry leaders and other MMPs to find creative solutions. Obviously, if Apple accepts a satisfactory solution, the entire industry would follow and Singular would be a key part of that.
However, there is a big “if” behind all these methods.
The essence of user-level attribution is combining user-identifiers such as IDFV from the advertiser app with marketing data generated on the publisher app. While Apple didn’t provide an explicit statement about methods that do this, this is clearly not in the spirit of Apple’s privacy guidelines for the IDFV:
Let’s take a look at two of the main suggestions so far …
1. Fingerprinting and probabilistic matching
Fingerprinting has always been an alternative method for matching a touchpoint (a click or impression) with an app install. This method uses identifiers such as IP address, user-agent, device type and other metadata about a device to connect each touchpoint. Every MMP uses this method as a default in cases where IDFA isn’t available (for example, an app install driven by a mobile web ad, or a device with Limit Ad Tracking on, hiding the IDFA).
This method works quite well, but since it’s not 100% accurate, it’s considered a probabilistic method. MMPs have been improving this mechanism for a while, and while we see more room for innovation and claims about improved accuracy, there still exists the question of Apple’s opinion on fingerprinting.
While probabilistic matching is relatively non-invasive from a privacy standpoint, Apple has taken a very active stance against it as part of the ITP framework, which was designed to bring privacy to the Web, and their IDFA changes seem to be following that same framework. More so, in one of the WWDC videos they seem to consider “fingerprinted ID” as a type of tracking that should not be allowed if the user didn’t explicitly opt-in.
Some of the most powerful players in the mobile marketing ecosystem are the SANs, the self-attributing networks. There is an existing precedent for Google using fingerprinting to match their UAC search campaigns which originate in a browser with app installs (if Facebook and others follow suit, that could establish fingerprinting as an acceptable method). However, while Google uses this method to attribute users and build cohorts internally, MMPs and advertisers do not get access to the raw data and can’t use it for deduping attributions.
The main advantages:
- Fully integrated with the existing ecosystem
- User-level attribution
- Decays quickly, so more privacy-safe than persistent unique identifiers
The main limitations:
- No clear statement from Apple accepting this method, so might not be a long-term solution
- SANs may not support it or they may prevent deduplication of attributions with other networks
- IP-based methods are more exposed to fraud
- Accuracy isn’t perfect, though a satisfying level of accuracy can be achieved
2. Privacy-preserving attribution with supply-side consent
Some believe that means you can access the IDFA as long as it stays on the device, but that’s technically inaccurate based on the current iOS 14 beta (and yes, we checked the code). Others have come up with interesting ideas to run code on the device itself as part of the mobile measurement partner SDK (software development kit) inside the advertiser app. The idea is that this would send data which is sufficient for accurate IDFA-based attribution without actually sending the IDFA itself.
The main incentive for these suggestions is to solve inaccuracies when using IP and probabilistic matching. That’s potentially attractive.
But there is a challenge: all those methods share a core assumption that user-level attribution is permitted even without the advertiser receiving consent from the end user.
One way to do this is to calculate an attribution hash (a cryptographic transformation) on the IDFA and IDFV and send the hash to the MMP. This would ensure that the MMP and the advertiser would not learn the user’s identifier. If this happened, attribution could still be completed by the MMP using the publisher-side clicks, which do include the IDFA, thanks to “supply-side” consent (the end user approving it on the publisher app).
How this would work:
- You are in NewsCo’s app
- You approve NewsCo’s use of your IDFA
- You see an ad you like for an app install for CoolNewGame
- You click on the ad
- Newsco records a click that is associated to your IDFA and sends it to the MMP
- You install CoolNewGame
- The MMP SDK sends an attribution hash to the MMP’s server
- The MMP matches the attribution hash to the click
There are other options as well. Another potential solution involves making changes to SKAdNetwork to supply IDFV in its notifications if the user opted-in on the supply-side. And yet another uses advanced mathematical constructs such as Zero Knowledge Proofs to perform attribution while preserving privacy.
All these suggestions rely on Apple accepting the concept of single-side consent and assume that supply-side consent is sufficient for attributing user-level installs on the demand-side.
This is both a significant leap of faith and an interesting philosophical question since the user didn’t approve tracking on the demand side.
Additionally, each of those suggestions would require some code change on Apple’s side. As an example, calculating the attribution hash requires direct access to the IDFA without consent, which is currently not supported by Apple. This requirement is also quite naive and prone to malicious abuse. If supported, it would require Apple to provide additional functionality to support the solution without actually giving direct access to the IDFA, most likely by providing the attribution hash directly via the AppTrackingTransparency framework.
The main advantages:
- Compatible with the existing ecosystem
- Perfect accuracy, similar to IDFA-based matching
The main limitations:
- Requires substantial policy change by Apple
- Requires some application/code changes on Apple’s side
- Provides weaker guarantees for maintaining the end-user privacy
There’s a lot going on and much of it is very technical.
We’re committed to supporting SKAdNetwork. At the same time, we are constantly thinking about new solutions and analyzing every suggestion by every player in the industry. This is a time of massive change, and we must be agile in response to new ideas in order to provide the best possible solutions for our customers.
With all of that in mind, we have to stay in compliance with Apple’s new rules and regulations. At Singular, we’re investing in multiple options in order to ensure that our customers will benefit from the highest quality of data possible, both in the short and long term.
Join the conversation
Have questions? You’re not alone. Our entire industry needs to adapt to these new privacy enhancements in iOS 14, and we have to do it fast. We invite you to join our community coalition, Mobile Action Privacy (MAP), on Slack to connect with other thought leaders, ask questions, and share ideas.