Managing the Implications of Apple’s IDFA Opt-In

IFA or IDFA (ID for Advertisers) for Apple was launched in September of 2012 with the release of the iPhone5/IOS6. Since then, especially for App advertising, this has been the de-facto ID (like the 3rd party cookie in standard web) for user tracking/targeting on mobile devices. With the upcoming (September 2020) release of IOS14, Apple is continuing their recent trend of placing focus on consumer privacy and limiting external identifying signals. With this in mind, Apple has implemented several restrictions on the IDFA which is likely to drastically reduce this ID’s prevalence, making it minimally useful for its current purpose and possibly leading to its eventual death.  

IDFA Opt-in Overview and Impact

Once a user has upgraded to IOS14, which will be automatically prompted for any Apple device user once it has been released, the IDFA will initially stop being available on all of the users’ Apps. When the user next accesses an App after the IOS14 update, they will receive a one time prompt via a text box controlled by Apple containing verbiage from the App Publisher requesting the user Opt-In to allow that App to leverage the IDFA again. If the user ignores/dismisses, or denies the Opt-In message, the Publisher is never allowed to again proactively prompt the user to Opt In. If the user decides to Opt-In at a later time, after not doing so upon the initial prompt, the user will have to navigate the App Settings to do so. This will be the case for every App individually; there is no universal user Opt-In. If the user opts in, the IDFA will again be available to be passed for use in RTB trading.    

Apple’s changes to IDFA opt-in are expected to have a significant impact on targeted programmatic advertising spend on Apple Apps as BidSwitch Research has seen that ~38% of App usage originates from IOS devices. There are numerous estimations on what user opt-in behavior will be with some claiming ranges from only 5-10% and others claiming normal ranges of 25-60%. A generally accepted opt-in rate for IOS devices on Apps from a few years ago was lower than Android but solidly in the middle of the range at 40%. 

With the wider focus on consumer privacy and the implementation of privacy regulations around the world (GDPR, CCPA, LGPD, PDPA, and more coming), it appears that user opt-in rates on “tracking” signals has seen a drop off between 5-10%. Based on this, conservatively we can assume a 65% drop in IDFA prevalence. Based on preliminary testing by some industry players this will cause a drop of ~50% on “targeted” app trading. 

Minimizing the Impact of IDFA Opt-In

In an attempt to minimize the impact on their App publishers, Apple has pushed the adoption of their SKAdNetwork solution (released March 29th 2018 as part of IOS11.3) which will allow for user engagement tracking and signaling by Apple i.e. recording install, click, etc. This is currently seeing a lot of traction across the industry, with proposals already being made for industry review and sign-off for best practice on how to implement and utilize. Even implemented at scale, there are limiting factors that won’t make this a viable replacement solution alone; in particular the 100 campaign ID cap, and potential effect on standard mobile practices around creative pre-caching. 

It’s also important to note that some “user” ID is still needed with SKAdNetwork. The preference is the IDFA if present but many are looking at other signals including IDFV (Introduced for Apple devices the same time as IDFA, September 2012 IOS6).  The ID for Vendors (IDFV) is an App Developer specific “static” identifier historically used for cross promotional IOS campaigns and campaigns trying to reach Limited Ad Tracking (LAT) users on IOS devices, without the use of fingerprinting. IPv6 and even Device ID as a last resort are also being considered for replacement signals. 

“ID-like” Solutions

In addition to the SKAdNetwork solution, the ad-tech industry is also reviewing the use of contextualization, supplemental signals (like IDFV and IPv6, etc), and potentially soft fingerprinting as additional solutions to run in parallel to SKAdNetwork. The general assumption at this point with regards to fingerprinting is that while some signals utilized are not currently explicitly blocked by Apple, if they do not like the behavior/signals being utilized, they will likely just kill that signal. 

To avoid this and hopefully build some trust between Apple, users, and the technology providers, some in the industry are proposing to not do any fingerprinting and to just use contextualization signals and the SKAdNetwork. We at BidSwitch are currently reviewing all of these solutions as well. In addition, BidSwitch is participating in industry groups, like the IAB Tech Lab (ORTB and ReArc groups), trying to tackle these challenges. We do not currently have an official stance regarding a solution, however, once evaluation is done, we will look to implement/adopt a solution aligned with the industry decided best practice. We will still consider support for any solution adopted by our partners, but this would be a separate conversation apart from any more universal implemented solution. 

Next Steps for Publishers 

In the short time that publishers have left until IOS14 is released, there are a few actions that publishers can take to make sure that they are prepared. If they haven’t already integrated with SKAdNetwork, publishers should take time now to do so as the spec for the pub is available. Moreover, pubs must submit opt-in wording for the one-time display by Apple in order to obtain user Opt-In to maintain IDFA usage once IOS14 is present. As this is their one shot at convincing users that they should enable IDFA, this deserves careful consideration.

Written by Isaac Schechtman, Sr. Director Product Strategy