Note: As of January 28th, 2021, Apple has changed its policies regarding attribution on iOS 14. Read about that update and Branch’s latest stance here.
A special thanks to Alex Bauer for his help on this post. His mobile newsletter is one of the best in mobile and even though I work at Branch, my one must-read when it comes out.
If you are in mobile and have not lived under a rock for the past couple of weeks, you know some big changes are coming. At WWDC in 2020, Apple announced that in iOS 14 (likely to be released in September of this year, just a few short months from now), the IDFA will no longer be a relevant or widely-used identifier. My co-founder, Alex, wrote a great post on what the iOS14 changes mean for the mobile industry, and our Head of Product wrote an equally interesting article on the history of IDFA and the changes that Apple is proposing.
The main learning after the past few weeks: there is a lot of uncertainty in the market and people are looking for answers. Apple proposed SKAdNetwork — a solution that solves the privacy issues that Apple cares about, but which has so many limitations that it’s unlikely to be widely adopted in the short term. I have seen several FAQ articles from other MMPs, some of which seem to take Apple’s point of view. My take is different.
I once did a talk comparing the mobile ecosystem with Game of Thrones — the big platforms like Apple have all the power, and this allows them to make changes (which they promote as “good for the ecosystem”) based on their own priorities, fears, and views on morality. This move by Apple, righteous and in disregard of the broader ecosystem, reminds me of Daenerys and her dragons. So instead of taking the perspective of the hegemon, I will take the perspective of the mobile app developer or publisher who is struggling to get their app discovered. I was once in their shoes, trying to get an app off the ground and struggling to understand how users got to my app and the ROI of my efforts.
I am not saying that privacy doesn’t matter — it does, very much, and Branch has been an advocate for user privacy since the beginning. I am saying that Apple is like an elephant in a room full of mice, not fully comprehending (or perhaps simply not caring) what effect they are having on the rest of the ecosystem that has supported their success.
Why is Apple removing the IDFA in iOS14?
The public explanation is to improve user privacy. Apple has indicated that they want to crack down on an entire ‘dirty data industry’ based on IDFAs.
Specifically, since the IDFA was a common ID that all apps could read and recognize, it was perfectly-suited for vacuuming up PII data from across the ecosystem to compile user profiles. Apple might believe that since they created and supported the IDFA, they were partially responsible for enabling unscrupulous companies to do this. By blocking access to this ID, Apple can wipe its hands clean and move on — use of the IDFA for responsible marketing (including the mobile attribution industry) is simply collateral damage.
What should you do?
Be certain that you aren’t relying on any of the use cases Apple is truly targeting with this change, and then ensure that you (and the vendors you work with) are taking steps to prepare for the side effects.
What are the realistic rates for IDFA opt-in?
Users have to opt-in everywhere for IDFA attribution to work (both the app where the ad is served and the destination app being advertised). While it’s conceivable that users may opt-into certain apps accessing their IDFA (ex: apps with enormous market sway like Facebook, Twitter, etc.) it is unlikely that smaller apps advertising on these platforms will attain the same level of user opt-ins. Moreover, looking at the opt-in rate on something that provides a lot of user value and has friendlier language, like location tracking, many users chose to disable it or be asked every time. With this new “permission to be tracked” opt-in, even incredibly informed users are likely to be influenced by the frightening language that Apple is requiring, and reject tracking by apps that they are unfamiliar with. The problem is that after this initial rejection, they will then need to dig deeply into settings to reverse their choice, which will further lower aggregate opt-in rates (and that’s assuming they even wanted to change their minds). A Reddit thread on this shows initial user reactions, and confirms our suspicions that voluntary opt-in rates will be extremely low.
Some MMPs have proposed that advertisers will be able to push higher rates of user opt-in by requiring users to either give access to their IDFA or use a paid version of their services. However, companies relying on this method will be at a competitive disadvantage against similar apps that do not pursue this path. For that reason, we do not think it will be widely adopted for apps prioritizing growth.
What should you do?
Think realistically about whether users are likely to opt into giving tracking permissions to your app. If not, start preparing for the changes you’ll need to make before September.
Will Apple roll back the iOS14 changes, delay the implementation, or come to some sort of compromise?
Many have asked why Apple is making this change now, in the middle of a global COVID-19 pandemic that was already causing massive disruption to the mobile industry, and whether they will reconsider if the mobile measurement and advertising industries can simply find a way to convince them of the potential harm.
From our perspective, it’s clear that Apple has been working toward this move for years, and it’s extremely unlikely that they will make any adjustments now. In fact, it’s quite possible that things will become more strict over time, as Apple observes how various areas of the ecosystem evolve to cope with this change.
For a real-world example of how things could play out, one need look no further than the ITP (Intelligent Tracking Prevention) system that Apple has spent the last few years deploying on the web; the initial version was extremely disruptive, but Apple made no concessions to soften this impact — in fact, they’ve taken aggressive steps to close loopholes and make the policy even stricter over time.
What should you do?
Be realistic about how the mobile ecosystem is likely to change. Rather than waiting for a miracle, take proactive steps to ensure that your app is set up to thrive in this new reality.
Will Google follow suit and remove the GAID?
We think this is likely to happen. Because Google is in the unique position of having platform-wide visibility on Android without relying on GAIDs, it’s definitely in their best long-term interest to get rid of it. Now that Apple has broken the ice, and provided the rationale of privacy for doing so, Google has no reason not to do the same thing.
This means that the mobile industry should prepare for a future in which there are no persistent, platform-wide identifiers.
What should you do?
For now, there is no immediate action to take. Branch will continue using GAIDs in predictive modeling, and if/when Google removes GAIDs, our predictive modeling algorithm will be ready to fill in the gap.
If users won’t opt in, is SKAdNetwork the only option to do measurement on iOS?
Fortunately, it is not. In fact, we believe it’s quite unlikely that the entire industry will adopt SKAdNetwork (considering the challenging implications of having only aggregate data to work with). We think the more likely scenario is that some networks will adopt SKAdNetwork, while others will continue to look at other types of device-level measurement for more granular campaign data.
What should you do?
Make a list of the ad networks you currently work with, and find out what their plans are with regard to supporting SKAdNetwork-based measurement (but keep in mind that many networks are currently still evaluating their options, and may not have an answer right away).
What are the alternatives to SKAdNework?
Without IDFAs, most of the attribution industry is likely to fall back on basic probabilistic modeling (a.k.a., ‘fingerprinting’, although this term has a far more invasive meaning elsewhere in the ad tech industry). This has long been the default “plan B” in situations where IDFA-based modeling was not possible (ex: cross-platform web-to-app campaigns, or when Limit Ad Tracking is enabled).
Most in the industry are already familiar with the significant drawbacks of basic probabilistic modeling, but we expect many will conclude this is an acceptable tradeoff in return for maintaining device-level insights.
What should you do?
Find out how your MMP currently handles the attribution waterfall when IDFAs are not available, and ask what preparation (if anything) they are doing to improve this methodology ahead of the iOS 14 launch.
What options exist for improving the accuracy of basic probabilistic modeling?
Fortunately, there are ways to improve attribution accuracy, even when universal IDs like IDFA do not exist. Branch’s predictive modeling solution is one of these.
The basic idea is that Branch has built the concept of a “link graph”, which is a collection of cookies and other IDs across the user’s device. We’ve matched these across all of the apps using Branch with a variety of mechanisms including deep linking, user logins as well as statistical and machine-learned algorithms. Our wide adoption across the industry gives us this foundation.
From this collection of cookies and IDs, Branch builds an anonymous profile of the range of IPs for a given user across all of their apps. For example, we can see when they are accessing the device from common public networks like the home or office, as well as their private addresses when they are on cellular. With this, we can detect if a user switches from cellular to their home network between the click and the app session to match correctly where other simple technologies will fail. Importantly, we can use this insight to improve accuracy both when making a match, and when deciding not to make a match.
The best analogy is one based on statistics. When you’re running an experiment where there’s uncertainty, the sample size matters. You need enough samples to accurately determine the distribution. Traditional MMPs use one sample (the IP of the last click) to match the IP of the app session. Branch predictive modeling uses a huge number of samples, collected over the user’s anonymous profile, making it much more accurate than a single data point.
We have published data that demonstrates the benefits of predictive modeling (for example, this case study with Nextdoor, which saw a 25% reduction in misattributed conversions), though these dates from prior to Apple’s removal of the IDFA. Our team is working on updated studies now, and we expect to see continuing improvements — we’ll be happy to share details as soon as they’re available.
What should you do?
If you have been holding off on upgrading your attribution stack because your current solution was “good enough,” now is a great time to reconsider — it may no longer be sufficient in this new world.
Does Apple’s new iOS14 policy also prohibit fingerprinting?
To date, Apple’s marketing materials don’t appear to take the stance that fingerprinting is prohibited. However, we’re assuming that ‘fingerprinting’ as a technique will be limited (or completely forbidden) when Apple makes updates to the official Developer Agreement in the near future — Apple is most likely fine-tuning this policy language based on observations of initial industry reactions to their WWDC announcements.
To understand why, it’s critical to know what Apple is trying to prevent. They have been very explicit and precise about their language so far, and it revolves around combining data from multiple apps owned by different companies to create a shared profile where companies can access data they couldn’t access otherwise. The IDFA made this very easy (it allowed different companies to share user data with one another with a common ID), but there are other vendors offering very similar data-sharing functionality via universal, cross-company ‘fingerprint IDs’.
In the past, Branch has occasionally used the term ‘fingerprinting’ for convenience (as have all other MMPs). However, the functionality we’re referring to is fundamentally different from the universal ‘fingerprint ID’ systems that Apple is targeting, and what the broader ad tech ecosystem recognizes as ‘fingerprinting’.
Why? When Branch is referring to IP-based modeling solutions, we’re processing data that you as the company own and no other third party has access to. You use Branch as a data processor (under GDPR language), and your users agree to terms of use with your business that allow you to privately share their data with Branch to process and provide services. This means when a user clicks on one of your ads, metadata logged from that click (such as the IP) is yours. And when the user opens your app, metadata you observe from that session is also yours. For the purposes of analytics and attribution, there is no combined profile across companies since you’re only accessing your own data to accomplish this task.
Branch predictive modeling complies with Apple’s policy, in both letter and spirit, since no new data is shared with other companies. Customers can only access data from user interactions that they could access even without Branch, which means we believe it will continue to comply, even if Apple takes a strong position against ‘fingerprinting’ as it is typically used by the broader ad tech industry. We simply make connections between the customer’s user events using the ‘matching clean room’ of predictive modeling.
In short, for the purposes of attributing the interactions of your own users, Branch is only processing data from your owned properties (links, web visits, app visits). We do not permit things like directly sharing this data with 3rd parties without the user’s consent, which would be against the spirit of Apple’s language, and would not be supportive of any product that did so.
What should you do?
The changes Apple actually made are quite disruptive already — buying into unfounded speculation will simply tempt you to throw the baby out with the bathwater.
Will the removal of the IDFA in iOS14 mean more fraud?
Assuming the industry rallies around probabilistic modeling, then there will almost certainly be more attempted fraud. This is simply an inevitable side effect of removing an ecosystem-wide identifier like the IDFA, but we anticipate that the industry will decide this is acceptable in return for maintaining device-level insights.
If this is the case, then the next question is how best to counteract this fraud. Preventing fraud is ultimately a question of data scale, and leveraging that scale to make fraudsters work hard enough that they decide to go defraud someone else instead. Because Branch has broad knowledge of legitimate user behavior across both web and app (cross-platform activity is much harder to fake than single-platform activity), our DEFEND fraud detection engine will continue to have a significant advantage in determining which conversions are valid.
What should you do?
Find out what steps your MMP is taking to harden their fraud prevention algorithms in preparation for a world where probabilistic modeling is ubiquitous. If you’re working with a vendor that charges extra for fraud prevention features, consider revisiting your contract to ensure you’re fully covered.
Will Branch and other MMPs still be able to do attribution for SAN networks?
We hope so, and we’re in active discussions with all of the self-attributing networks to encourage them to choose an approach that will not create even more data fragmentation in the industry. That said, while we’re not yet sure exactly what is going to change here, we know that something will. All current MMP integrations (both from Branch and from other attribution providers) use the IDFA to confirm device-level attribution on iOS. This allows us to make the attribution decision at the device level. When the IDFA goes away, all of these integrations will break. For more background, we summarized the three main options that they are considering in our earlier post.
What should you do?
Most MMPs will likely do what they can to handle any SAN-related technical changes on your behalf, but it’s possible you may also need to make code updates. If you depend on SAN networks, consider pre-emptively allocating some engineering time over the next few months, just in case. And, assuming you find device-level data valuable, reach out to your account manager and let them know.
Can the IDFV be used as a replacement for IDFA?
IDFVs are unique to each app publisher, and Apple has strict policies against attempting to map IDFVs together. This means they cannot be used for attribution across apps, and cannot be used as a replacement for IDFAs.
IDFVs can still be helpful for certain use cases, such as internal BI systems, and Branch will pass them through in your data when they are available.
What should you do?
If you used IDFAs for data stitching, identity resolution, or other analytics, consider whether IDFVs can fill this gap for you. If not, start looking for alternative identifiers. Here’s a cheat sheet to help you get started:
- If you don’t care about stitching impressions/clicks to app events and only care about stitching events from your own app, IDFVs may be sufficient for your needs.
- If you are stitching impressions and clicks to app events, you will need to consider a solution like Branch’s cross-platform ID (CPID), which is a unified ID that Branch builds based on data that spans your web and app activity. If you are using our premium products, contact us to learn more about how to leverage CPID for this enhanced functionality.
If you did not depend on IDFAs for any data processing, then you likely do not need to change anything.