IDFA is Gone, but Is User Tracking Gone Too?

Anastasia Reusova
9 min readFeb 12, 2023

IDFA and 3 More Ways to Measure and Personalize In-App User Journeys, CRM and Still Do Targeting

Image generated by Midjourney.

The ability to track user behavior and deliver pertinent adverts is vital in the realm of mobile devices and app development. The IDFA (Identifier for Advertisers), similar to AAID (Android Advertising Identifier), and the IDFV are two of the most often utilized unique identifiers on iOS devices (Identifier for Vendors). The former is well-known, restricted and missed, but the latter is hardly discussed. Apart from those two, there are other ways to spot a user on-app, which we’re also going to touch upon.

What is IDFA?

The IDFA (Identifier for Advertisers) is a unique identifier that is assigned to each iOS device by Apple. Advertisers utilize it to monitor consumer activity and serve up more targeted and individualized ads to specific consumers. This is accomplished by monitoring user preferences and activity across numerous apps and websites, then using this data to target advertising that are more likely to pique the user’s interest.

As most of us has experienced, clicking on an ad for a particular brand, you begin to see advertisements for this brand across different channels. Similarly, you can get picked up by a topic, such as “skincare products” and so on. Ads that are more pertinent to users’ interests and behaviors can be displayed thanks to the IDFA, which gives marketers the ability to monitor user behavior across numerous apps and websites.

In iOS 10, Apple introduced “Limit Ad Tracking” setting for users who do not wish to be tracked by advertising networks. If the setting is enabled the system returns a default all-zero id for that device.

Source: Wiki

It’s crucial to remember that users can reset or restrict the use of their IDFA by going to the privacy settings on their iOS device. Wiki says that 20% of users enable Limited Ad tracking after the abovementioned change by iOS. And the number seems to be true.

As a result, users have more control over how their personal information is utilized for advertising. Therefore, when using the IDFA, you must be aware of privacy issues and should only gather and use data in accordance with relevant laws and regulations.

What is IDFV?

Instead of being given to a specific app, the IDFV (Identifier for Vendors) is a special identifier that is given to an app developer. This implies that regardless of whether they are installed on the same device, all apps created by the same developer will have the same IDFV. Moreover, IDFVs are not shared with an external network of publishers.

App publishers can use it to track users throughout their ecosystem of apps, but it cannot be transferred outside of their network to other publishers.

Source: What Everyone In Programmatic Needs To Know About Post-IDFA Targeting Options

The IDFV is made to give vendors and app developers a mechanism to monitor user activity across several apps. Developers may gain a more full view of how users interact with their apps by having a single identifier across the app ecosystem. For instance, if a user downloads many shopping apps from you, the IDFV will persist, and you’ll be able to analyze user journeys across multiple applications.

Therefore, while IDFA can be shared between apps and platforms, this is not the case for IDFV. For example, your app can use the same IDFA that Chrome or Adjust does, IDFV does not travel outside of your app eco-system.

It’s important to keep in mind that the IDFV is exclusive to iOS devices and isn’t available on Android or any other operating systems. In contrast to the IDFA, users are unable to limit or reset the IDFV’s use, which makes it easier to violate. When utilizing the IDFV, you must be aware of privacy issues and should only gather and use data in line with existing laws and regulations.

Looking for Them: BigQuery

IDFAs and IDFVs are comfortably seated inside BigQuery GA4 or Firebase export schema. Both have a very similar data export schema, and app data is stored in the same way. You can use BigQuery Sandbox or BigQuery Free Tier in case you don’t work with BigQuery already.

The table below is a public Firebase dataset for the Flood-it! gaming app.

Snapshot of Flood-it!: Firebase public dataset in BigQuery. By Author.
SELECT
*
FROM `firebase-public-project.analytics_153293282.events_20180930`

Vendor are advertiser IDs are sitting under STRUCT data type, so unlike data stored in ARRAYs, they don’t even require unnesting on the data extraction.

Vendor ID (IDFV) and Advertiser ID (IDFA) sit under device RECORD in the Firebase export schema. By Author.
Snapshot of the device RECORD. By author.
Snapshot of [GA4] BigQuery Export schema reference. By Author.

It’s worth mentioning that as the adoption of GA4 has been happening, the fields in the export schema have been changing as well, so the screenshot above may be slightly different from what it’ll look like on a different date. Device field, however, has been there for Firebase, it’s there for GA4, and I don’t think it will go away any time soon.

BigQuery has those fields nulled out for the purpose of a test data set, but here’s how accessing them would look like:

SELECT  
user_pseudo_id,
device.operating_system,
device.vendor_id AS IDFV,
device.advertising_id as IDFA
FROM `firebase-public-project.analytics_153293282.events_20180930`
WHERE device.operating_system = 'IOS'

IDFA vs. IDFV: Key Differences

To summarize the above, there are several key differences between IDFA and IDFV, including:

  • Purpose: marketers use IDFA to track user behavior and display targeted ads, while IDFV is mostly used by vendors and developers to track user behavior and gather data for analytics.
  • Control: by accessing the privacy settings on their device, users can reset or limit the use of their IDFA, whereas they are unable to do so with the IDFV. This gives users greater control over how their IDFA is used.
  • IDFV cannot be shared across different platforms and advertising networks, while it is the case for IDFV.

IDFA vs. IDFV: Key Similarities

  • Platform: Both are available for iOS devices only.
  • Persistence: Both IDFA and IDFV are persistent and will remain the same even if the user does not use their device for a long period of time.
  • Privacy Concerns: Both IDFA and IDFV are subject to privacy regulations and must be used in accordance with applicable laws and regulations. Advertisers and developers must be mindful of privacy concerns when collecting and using data and should only collect and use data that is necessary for their intended purposes.

Are There Any Other Alternatives?

You must use IDFAs and IDFVs responsibly. So what if regulations or Apple Policies change, you have to comply.

Third Parties like CRM

Let’s say, you are using a CRM tool which can be integrated with your iOS app. It is likely to collect data to help build relevant user journeys.

If you are wondering why anyone would do it or share data with an external tool, here are a couple of examples. I see the purpose of those in maximizing customer value, which eventually leads to creating value for the business as a result of that. The baseline of customization lies in user communication preferences and opting customers into the comms they prefer.

However, the true power of customizing and personalizing user campaigns to connect users with the most relevant experience. An example of such actions in the context of e-commerce may be informing customer about price drops, low in stock items in their cart or wishlist, creating personalized recommendations lists and so on. Of course, this can be extended to other business model.

So, if a CRM tool is integrated with your app, chances are, you can get a user identifier from there. In case of GA4 or Firebase implementation, the data can be collected as user property and exported to your BigQuery (the export is finally free in GA4). You can use this data for analysis, building data models (such as Propensity Model, for example) and feed it back into the CRM tool. The circle is closing.

While a CRM tool is still a third-party tool, meaning it will have almost full control over the user identifiers, it is way better than either nothing or user_pseudo_id’s in BigQuery. When using a CRM id, you can use it for the customer benefit, connecting them to the relevant and most exciting experiences with your product.

A big advantage of CRM identifiers is that they are often platform-agnostic and can be collected on web, iOS, Android, etc. In some cases, CRM solutions allow to merge profiles which happen across multiple devices but supposedly belong to the same user.

Of course, it goes without saying that you need to keep in mind the police is surrounding CRM communications.

The Best of the Best? First Party Tracking

Let’s say, CRM is great but you don’t fully trust the tool and want to own the data. Maybe it’s not possible to expose CRM user identifiers to your app. You can implement a first-party user tracking with your tech team. It will require effort but this is definitely my personal preference.

If you have a universal tracker in your app which is set up as a user property, it may be a little bit hard to reconcile this data with customer IDs once the user logs in, however, you can always use this custom identifier on a session level two, for example, segment your customer is based on their browsing behavior, personalize an app experience via different media. It can be personalized content, such as banners, offers call mom app layout, and what not.

I don’t think this method is widely used, and it does require close collaboration between the data team and the engineering team, however, it also implies ownership of the data, which is always great in the context of a business.

And when it comes to owning business processed, the way I see it, is whatever technology or instruments you develop in-house, may give your business a strategic advantage going forward, over its competitors. Ultimately, any in-house solution can be developed into a new strategic direction for your business. In the context of an e-commerce, we see companies such as Farfetch outsourcing their platform solutions, so why not do it with the data. I am not saying it’s going to be easy but you will develop a valuable know-how that can lead you to more success in the future, be it consulting or outsourcing industry specific solutions.

The downside of the first-paty method is, of course, the need to maintain generated cookies. Apart from that, you’ll need to consider “edge” and “unhappy” cases when a user clears the cash, reinstalls the app, logs in and logs out. On top of that, it may be hard to reconcile user identifiers across different patforms (web, iOS, Android, etc.).

And it goes without saying that as with any other method, you need to consider privacy regulations and rules.

Tracking is not Gone

So, to sum it up, the loss of IDFA tracking on iOS was definitely a blow when it comes to marketing activities but that’s definitely not the end of user tracking and analyzing in-app journeys. There are still ways to track and measure.

In this post we talked about IDFVs (which can also be used for targeting), user identifiers on CRM tools as well as setting up in-house tracking.

Good thing to remember is that tracking is generally subject to privacy regulations and must be used responsibly in accordance with relevant laws and regulations. Advertisers and developers must be mindful of privacy concerns and only collect and use necessary data for their intended purposes.

Resources

--

--