Apple announced a number of privacy related updates in iOS14, which impact how in-app advertising and attribution works. The IAB Tech Lab’s Programmatic Supply Chain Working Group is releasing a set of extensions to OpenRTB to support these updates, along with a couple of optimizations that we would like to get feedback on.
Since then, Apple seems to have realized that their changes have a far greater impact on the developer community and has recently given the ecosystem more time to adjust to these changes by delaying the enforcement of the IDFA consent opt-in.
At the moment (pre-iOS14 final release), our understanding is that the rollout of iOS 14 API / features, namely SKAdNetwork and AppTrackingTransparency, are not impacted. The solutions discussed below are still relevant and we now have time to collectively ensure the new specifications are tested and implemented before Apple’s early 2021 rollout. We hope to engage with Apple and the developer community for feedback on some of the options below (before Apple enforces the changes).
While Apple’s specifications describe how to interface with iOS (apps prompting for the IDFA, using IDFV, registering SKAdNetworks, signing ads, etc), they have not specified how the communication across the various entities involved in delivering ads (SDKs, SSPs, exchanges, DSPs…) should be defined using OpenRTB. The IAB Tech Lab’s Programmatic Supply Chain Working Group has created a set of specifications that enable these features to be supported across the ad delivery supply chain.
The OpenRTB specifications are available here and include:
- An extension to the Bid Request and Bid Response objects to communicate SKAdNetwork information between publishers, SSPs, DSPs, and intermediaries
- An extension to the Device object to communicate IDFV and AppTrackingTransparency authorization status
- Guidance and tools to help developers manage their Info.plists and work with various Ad SDKs
In addition, while #1 currently provides basic support, we recognize that the SKAdNetwork ID list may become too long and passing all the IDs would make the OpenRTB payload very big. We’ve included two alternate, more efficient proposals for transmitting long/complete lists.
We are calling for the industry to do the following:
- Immediately register for an SKAdNetwork ID if you intend to support SKAdNetwork and sign ads.
- Work on the extensions that support communicating the basic list of SKAdNetwork IDs.
- Consider experimenting with the IDFA authorization status (and IDFV if relevant).
- Review and provide feedback by October 16th on the more efficient options of communicating the SKAdNetwork IDs — including thoughts on how long the lists are and how varied the lists are across your various partners.
As always, we believe that collaboration with a clear goal of prioritizing privacy and standardization is the best approach to building solutions that can be successfully implemented.
What Else Can You Do?
We call on anyone interested in the topic to join Project Rearc for the larger privacy-centric addressability discussion, in addition to providing feedback on the proposed solutions highlighted above.
About the Authors
Natalie Binns, Product Manager, Fyber
Jeff Carlson, Manager, Technical Solutions Consulting, Twitter
Amit Shetty, Sr. Director of Product, IAB Tech Lab