SKAdNetwork

As I continue to interpret Apple’s documentation around SKAdNetwork ATT framework, I’m realizing that SKAdNetwork is a remedy to historical IDFA misuse. One area worth investigating is how Apple differentiates between IDFA and IDFV. In the new iOS 14 framework, IDFA will require consent from the user whereas IDFV will not. So how do IDFA and IDFV differ?

Fundamentally, each ID has a different level of exposure to developers. IDFA can be accessed as a unique ID across any iOS developer whereas IDFV is unique and sandboxed to a single developer’s account. Apple views sharing unique IDs across developers as privacy unfriendly, while keeping a unique ID within the bounds of a single developer’s set of apps is privacy friendly. According to Apple, the biggest area for abuse is how the IDFA can be used and shared across different developers.

Over the last several years, ad networks used the IDFA for the purposes of hypertargeting ads across different publishers. Social networks used this key to join internally available data with external networks to create richer user profiles. It’s a huge change.

From now on, all networks which leverage the IDFA for creating richer user profiles will only be able to use the data they capture internally. You can think of the networks bucketed into two broad categories:

Networks with unique targeting capabilities

• Facebook and all its O&O sub-brands
• Google
• Tiktok
• Apple
• Snapchat
• TWitter

Networks with device and site level targeting capabilities

• Applovin
• Ironsource
• Unity
• Vungle
• Mintegral
• Ad Colony
• Tapjoy
• Fyber
• etc.

Networks with unique targeting capabilities will continue to have these same targeting capabilities when serving impressions, but conversions and tying users to external data and feedback loops will be next to impossible. The feedback loops connecting downstream ROI to campaigns at the user level will break and a lot of the optimization technology will be worthless or need to get rebuilt.

Networks with device and site level targeting capabilities will likely respond in one or more of the following ways:

1. Developing/acquiring more O&O content to build on
2. Adding more developer oriented data capture services (user management, economies, etc.)
3. Modifying network optimization code for new SKAN fields (like store_id)
4. Switching to different business models like CPM or subscription
5. Creating walled gardens on unique data sets

As an example, expect companies like Applovin and Ironsouce to double down on their O&O gaming content (pitching themselves as a new type of Spotify, Netflix, or Facebook) and Unity to build more data capture B2B services directly into their gaming engine (free or subscription). Also expect to see unique attempts at new data collection services aimed at 3rd party user/economy management; this is an area where users don’t directly interact with each other like they do on Facebook/Insta/Snapchat/Twitter, but indirectly through unified logins and profiles that can be aggregated for better end user experiences.