You might’ve heard that Apple is making changes to its user tracking policies that will impact the use of device identifiers in iOS 14. Now, if you’re not using tracking for advertising, these new policies won’t affect you. And since the data that Brightcove analytics collects is anonymous and isn’t shared between publishers, it’s not subject to Apple’s new policies.
But let’s take a look at what’s changing and what you need to know as an app publisher.
What is IDFA?
IDFA is Apple’s Identifier for Advertisers, a unique ID string that identifies a particular device. It’s used in a few different ways, but the most common one is to support personalized advertising. Say I’ve opened the app for my favorite local restaurant chain, but I didn’t actually buy anything. Then I open the app for my local news publisher and start watching a video. When the app goes to fetch a preroll ad, it passes along my device’s IDFA, and the restaurant chain might choose to pay a little extra to run an ad about their latest meal deal. Everybody wins — the advertiser reaches someone who’s more likely to make a purchase, the publisher gets paid more for the preroll, and I see an ad that’s actually relevant to me.
But that same mechanism can get a bit creepy. The industry is trending away from sharing this sort of data without more transparency, and the latest move from Apple is a way to push for more privacy by default.
What’s changing?
With iOS 14, if an app doesn’t get explicit permission to provide the IDFA of the device it’s on, then it won’t get something unique. (This new policy will go into effect in early 2021.) This won’t make things fail, but it’ll prevent the advertiser from seeing that an ad request comes from a device they want to sell to, so the value chain is broken.
Apple is making a key change to support this, with a new API to request permission for the IDFA. This only needs to be requested once for each app, and a user can change whether they opt in or out any time in Settings (similar to how permission for location tracking is handled now). As an app publisher, you should explain to your users why you’re asking for this information – the value of personalizing ads. Just throwing up the system dialogue when a user first opens the app is a sure way to get a lot of opt outs. (Especially if you’re also asking for location permissions at the same time!)
For customers using the Brightcove Native iOS SDK, we’ve added support for the OS-level opt-in/out API, along with the latest Google IMA SDK (v3.12.1). Without integration with this API, any requests for the IDFA on iOS 14 – regardless of user preference – will have a value of 0, just as if the user had opted out. This update ensures that developers have access to the IDFA whenever possible. You’ll find this in our September release of iOS SDK v6.7.12, with full iOS 14 compatibility.
What else is there?
IDFA was designed for personalized advertising, but it has also been used in a couple of other ways that Apple is offering alternatives for.
If an app publisher has a network of apps but doesn’t identify users themselves (e.g., via a login), they can access an IDFV (Identifier for Vendors), which is structured like an IDFA but is only unique across that publisher’s apps. So it can’t be used to share an ID between a news publisher and the restaurant, but it does allow a publisher to track a user’s viewing habits across different apps in their own network. (This doesn’t require a user to opt in.)
Another common use case is attributing app installations – IDFAs are used to identify referrals between apps that might be bounced through the App Store. Apple has provided a new StoreKit API (SKAdNetwork) to support this particular use case that also doesn’t require end user opt in.
Should publishers be worried?
No one really knows. Apple has provided users with a way to opt out of the IDFA since iOS 7 way back in 2013, but it’s buried in Settings so it never caught on.
At the other extreme, as Safari has made it harder and harder to work with 3rd-party cookies, publishers have found that advertiser demand (and therefore revenue) has dropped. The IDFA change doesn’t go as far, so if you’re thinking about deploying a native app, you can still monetise it more effectively than you can mobile web on iOS.
It’s likely this will land somewhere in the middle. Encouraging users to opt in and explaining the value of getting relevant ads will certainly help. And separately, publishers should be looking at other ways to trade on their own first- or second-party data to maximise the value of their inventory.