IDFV - Apple's ID for Vendors Explained

The ID for Vendors (IDFV) is a possible alternative that app owners can use in place of an IDFA to power some ad serving functionality if an IDFA is unavailable.

If a user opts out via the new App Tracking Transparency framework in iOS 14, app owners will not have the IDFA available to power advertising features like frequency capping or audience targeting.

Apple has given app owners the green light to use IDFV without consent:

But only allows developers to use the IDFV within the context of their own app or network of apps.

What is IDFV?

The IDFV is an identifier that is unique to an iOS device and persists on any app issued to the App Store from the same developer account. The value will remain identical on different apps on the same device as long as the same developer account published the apps to the App Store.

This is unlike the IDFA value since that value will persist across any app. The IDFV is much less useful than the IDFA for this reason. However, it may soon be the only identifier available to an app developer since Apple will start requiring users to manually opt-in to allow tracking in early 2021. If a user opts out, iOS will not permit an app to read a user’s IDFA value and will only have IDFV available.

IDFV for Advertising

There are two main use cases where an app publisher and their ad partners may want to utilize IDFV.

Frequency Capping

The IDFA value is used to track the number of times a particular user saw an ad. If an app does not have access to an IDFA, it can share the IDFV with an ad partner to assist with frequency capping.

This will only facilitate frequency capping within the context of a single app or a network of apps from a single developer. The IDFA value provided advertisers with a mechanism to control the frequency users see an individual add across all apps, so this is a dramatic step backward.

At a minimum, the IDFV value will limit ad fatigue within a single developer’s ecosystem.

Audience Targeting

App owners could presumably use the IDFV value to build first-party data sets based on the actions performed by users within the context of the app owner's ecosystem. A developer could pipe IDFV values to a DMP and organize them based on actions performed in their app as long as they are not connected to data collected fr0m any other third party.

For example, if a user is constantly browsing content related to power tools within an app, an app owner could place the IDFV in a “power-tool-lover” segment on their DMP. The app owner could push this segment to their ad server or SSP and sell inventory targeted to “power-tool-lover” users to a power tool advertiser.

Even though this use case is technically possible, it could be a risky business decision since Apple could decide to restrict this use case in the future.

Encouraging users to log in and subsequently assigning a proprietary identifier to that login might be the more prudent strategic business decision since Apple could not limit the usage of that identifier. Publishers can then build out custom first-party data sets using this PPID (publisher-provided identifier) for audience ad targeting.

The inevitable demise of the IDFA inches closer every day, and the ID for Vendors (IDFV) could function as a replacement to power some advertising functionality. However, when Apple's AppTracking Transparency framework goes live, developers will still have to implement SKAdNetwork to power app install tracking. Third-party data targeting based on IDFA will no longer offer the scale advertisers expect.

The times they are a-changin', and developers and advertisers will have to continue adapting to Apple’s new and more private world.