IDFA 101: The Past and Present of Mobile Advertising on iPhones
Reading Time: 11 minutes
The long-awaited iOS 14.5 is finally here. Apple released the update, iOS 14.5, on April 26. While this packs a lot of benefits for iPhone users such as the ability to unlock the iPhone with the Apple Watch, it also spells further doom for you, the mobile advertiser, with its App Tracking Transparency (ATT) framework.
What this feature does is that it requires apps to send standard iOS prompts to iPhone users to be able to track their activities when they’re not in the app, such as when they’re using other apps or when they’re surfing the internet.
Already, Apple had killed the Identifier for Advertisers (IDFA) with the introduction of iOS 14, which now makes device ID advertising on iOS more difficult. You may ask, so what is the alternative to IDFA device ID tracking? We’ll answer that in this article as well as explain in detail everything you need to know about IDFA.
What is IDFA?
IDFA, which translates to an Identifier for Advertisers, is a mobile advertising ID given to the users of Apple devices. With this Apple advertising ID, you can track user data on iPhone devices to provide customized advertising to iPhone users. IDFA allows you to perform device ID tracking without revealing personal information about your activities.
Because IDFA is unique to each iOS user, you can see just one IDFA per user and use it to provide unique adverts to that user as well as track the user’s response to your ad campaign.
While IDFA is specific to Apple users, Google Advertising ID (GAID) or Android Advertising ID (AAID) is specific to Android users. Like IDFA, GAID allows advertisers to track ad activities on Android devices without disclosing their identity to the users.
How does IDFA work for attribution?
Before the introduction of iOS 14 and its advertising ID privacy policy, here’s how advertisers have been using IDFA. First, they publish one of their adverts via an ad network on a mobile app. The iPhone user using this app then sees the ad and clicks on it.
The user’s browser opens and s/he is then directed to the Mobile Measurement Partner’s (MMP) page. The process is very swift, so the users wouldn’t know that they have been directed to the MMP’s webpage. They’ll only notice a long URL on the address bar.
When the MMP website opens, the MMP takes ad ID tracking info from the user’s devices such as his/her IDFA, IP address, location, device type, and user agent. The MMP will use this ad ID tracking information to tell mobile app advertisers the channel from which installs are coming.
From the MMP’s website, the user is then led to the initial link s/he clicked, which can be the advertiser’s app page on the App Store. Now, the MMP helps the mobile advertiser perform device ID tracking outside the app as the app wouldn’t be able to do so as the user is no longer in the app.
If the user eventually installs and opens the advertiser’s app, the SDK of the MMP will then track the IDFA, IP, and user agent of the user’s device and match them with the corresponding click. With this, the advertiser now knows which channel or ad network the user installed the advertised app from.
What happened to IDFA with the release of iOS 14.5?
IDFA was such a great aid to mobile app advertisers, but Apple in its bid to protect its users’ privacy, gave them the choice of blocking IDFA identifier at the app level with the introduction of iOS 14.5 and its privacy update. This iOS privacy update implies that apps will have to ask for permission to collect and share data for device ID advertising.
Will probabilistic attribution be back?
Before the advent of IDFA in 2012 with iOS6, MMPs were using a probabilistic method called fingerprinting to track the ad campaigns of mobile app marketers. Fingerprinting performs device ID tracking of new install of an advertiser’s app by using the user’s location, device type, user agent, and IP.
However, fingerprinting isn’t 100 percent accurate, which is why it is termed probabilistic. If an advertiser tries to measure and track the clicks and installs coming from frequently-used devices in a crowded area, the possibility of getting an accurate result is slim. This is because it is impossible to precisely know the install coming from a specific ad network.
Now, with the update in the iOS privacy policy through iOS 14.5, which makes IDFA device ID tracking difficult, MMPs have switched back to probabilistic attribution methods other than fingerprinting. The challenge with fingerprinting is that if the iPhone user does not opt-in, it’s difficult to use it.
Is the deprecation of IDFA a matter of privacy?
Yes, Apple’s deprecation of IDFA is a matter of privacy. Apple stated in a video announcing the deprecation of IDFA that it cares for its users’ privacy. Here are some IDFA usage examples Apple are afraid of:
Example 1: Someone is planning to buy a surprise gift for her partner. She then visits a website and finds a gift. If later, she and her partner browse Facebook together and come across an ad for this surprise gift, the woman would feel betrayed. Meanwhile, her IDFA device ID had only been used to provide her with customized adverts.
Another Apple IDFA example is the ease at which data from different apps can be merged through IDFA.
Example 2: An iPhone user may have an app that records his name through his IDFA device ID, another app that records his address, and a third app that records his phone number. In a case where data is leaked, the user’s name, address, and phone number can be matched via IDFA.
However, the deprecation of IDFA changes the mobile advertising industry immensely. There ought to be another way of providing customized adverts for iPhone users that can be tracked. Apple introduced SKAdNetwork, not as an alternative for IDFA device ID tracking but as a solution to deterministic attribution without IDFA.
What is SKAdNetwork?
SKAdNetwork is Apple’s alternative to probabilistic attribution. It is a way of assigning conversion data to app installs on iOS apps that is friendly to Apple’s privacy policy. The SKAdNetwork shares this data related to conversion with advertisers and ad networks while providing zero data related to the user or the device. So far, SKAdNetwork is the only solution to deterministic attribution without IDFA, even though it does not provide all the data that you need.
The way SKAdNetwork works is this:
- A publisher mobile app has assigned ad space on its screen.
- The AdNetwork bids and sends an ad to the publisher.
- The iPhone user clicks the ad and is directed to the App Store where he installs the advertiser app.
- SKAdNetwork tracks his journey and sends a postback to the AdNetwork, telling it an install has occurred via their ad.
- The advertiser is also able to see the conversions on SKAdNetwork’s Dashboard
It is clear from the above that SKAdNetwork aims to replace the MMPs. However, its mechanism is remarkably different from the former Apple ad ID, IDFA.
What is a postback and how does it work?
A postback is the real-time notification of app install or in-app event that attribution providers send to ad networks. Before the deprecation of IDFA, the postback would contain the iPhone user’s IDFA and granular data for device ID advertising. Although the SKAdNetwork’s postback serves as an equivalent to those of MMPs, it doesn’t include IDFA, the exact time, or the location of the app install. The user’s IP and user-agent are only visible if the user had approved of it earlier.
The SKADNetwork postback includes conversion value instead. This is an overall conversion data that states how many installs occurred, how far the user went into an event funnel as well as the Ad network containing the app. Before the Apple IDFA changes, it was possible to make user-specific tracking as it was easier to see what the users do within different apps. With this knowledge, advertisers were able to call back the users by displaying targeted ads to them. Now, advertisers would have to interpret the overall data themselves with Apple advertising ID gone.
What is conversion value?
The conversion value in SKAdNetwork is a single number between 0 and 63 that you can set for any in-app event that you want to track. The chosen number is what the app shares with Apple. Apple then includes this number in the SKAdNetwork postback that it sends to the ad network responsible for the app install.
What this means in simpler terms is that SKAdNetwork tells the ad networks that it can send a postback stating that a user performed certain events or otherwise. However, the app advertiser needs to choose a maximum of 64 events and assign values to them. So, you will need to decide which event is more valuable.
As install normally takes Event 0, you’ll have to choose the other 63 events to get a postback from SKAdNetwork when a user takes these actions.
Conversion value and timer
Conversion value in SKAdNetwork comes with its limitation. One of these limitations is the timer that Apple introduced to protect its users’ privacy. This timer has a time window of 24 hours that starts counting down when a user clicks on your ad and installs your app. If you choose to update the conversion value, such value can only be increased and not reduced. For example, if the former conversion value was 20, you can’t update it to 20.
Here are scenarios that perfectly explains how the SKAdNetwork timer works:
Scenario One
When a user installs your app, Apple informs the AdNetwork of his action through SKAdNetwork. However, this notification isn’t sent in real-time. After this install event, SKAdNetwork starts the 24-hour timer. If the user doesn’t perform any other action within the first 24 hours, SKAdNetwork starts a second random timer between 0 to 24 hours. It chooses a random moment between 24 and 48 hours after the install to send a postback to the Ad Network with conversion value zero.
Scenario Two
When a user installs your app, the first timer starts. If the user performs a second action within 24 hours, the first timer starts over. However, if there are no additional events in 24 hours, Apple then starts the second random timer. Within 24 to 48 hours, SKAdNetwork sends a postback to the ad network with the conversion value 1, informing it of the second event the user started. Event 1 overshadows event 0, which is the install, such that you can’t tell the particular time that the install happened.
Scenario Three
When a user installs your app, the first timer starts. If within 24 hours, the user initiates an event, the first timer starts over. If he then initiates another event with a higher conversion value within 24 hours, the timer starts over again. If, at this point, the user repeats the first event it does not cancel out the timer because its conversion value is lower than the second event. The timer will continue instead. Then at the end of the 24 hours timer of the second event, the random timer starts for the second time and SKAdNetwork sends a postback to the ad network with the conversion value of the latest event.
The message here is that the postback takes the event with a higher conversion value into account. Typically, SKAdNetwork sends postback within the second 24 hours after the last event of the user, and each event causes the timer to start over one more time unless it’s the repeat of a previous event.
This timer implies that you need to wait at least one week after initiating an ad campaign to see the results. As you can’t track in real-time, you can’t see the result quickly and act accordingly.
Time to develop new strategies for app user tracking
When you know about conversion value and timer, you can determine the 64 events of your app and their conversion values. This, in line with a well-developed strategy, will help you make the most of the aggregate data that comes with the postback.
One of the strategies you can employ is giving one event four (4) different price tiers, making it a total of sixteen (16) events that can be tracked with the 64 conversion values. For example:
AddToCart 0-$5 – Value 16
AddToCart $5-$20 – Value 17
AddToCart $20-$50 – Value 18
AddToCart $50-$100 – Value 19
Purchase 0-$5 – Value 20
Purchase $5-$20 – Value 21
Purchase $20-$50 – Value 22
Purchase $50-$100 – Value 23
Another strategy you can employ is ensuring that users who complete the same event have different conversion values if they have completed different event funnels. For example:
Install; ProductView; AddtoCart; Purchase – Value 10
and
Install; ProductView; AddtoCart; ClearCart; ProductView; AddtoCart; Purchase – Value 15
The issue, however, is that the mobile marketing ecosystem may not yet be fully equipped to set these new strategies. So, it’s time for MMPs to sit back and strategize as they are the most trusted partner of advertisers to aggregate all their ad channels’ data.
How were advertisers using IDFA for targeting in their ads?
When the Apple ad ID, IDFA, was still functional, programmatic networks displayed ads requested by app publishers after a real-time bidding process. This implied that advertisers were bidding higher to be seen by relevant prospective users. Here is how it worked: An app wants to display an ad to its users. Advertisers bid on that ad space and user in real-time. In other words, they know certain details about the user who will see the ad such as location, gender, and age. Thereby, it becomes possible to bid more for a relevant user with these enhanced targeting capabilities.
With this auction-based model which programmatic networks facilitate, you can compete for ad impressions in real-time instead of being placed in an order of demand partners. This ensures that publishers get the highest Cost per Impression (CPM) for their available inventory.
Also, before the Apple IDFA changes, IDFA made personalized advert possible using the iOS advertising ID. To target a user from other apps:
- You use your MMP to generate target user segments.
- The MMP can export the IDFAs of these users to be shared with programmatic ad partners.
- These partners then display your ad to these users on another app, using IDFA
- If the user clicks the ad, your app launches, and the user is re-engaged with your app.
- The MMP then continues to track events and Lifetime Value (LTV) analytics.
Upcoming trends with the end of targeting
With the deprecation of IDFA, however, it is impossible (in case of low opt-in rates) to know who will see the ad, and because there is no guarantee that the ad will be seen by relevant people, advertisers will tend to pay less per impression to keep their install costs constant. On the other hand, ad networks will want you to pay more as the install rate of ads will decrease and they will have to show your ad to more users. This conflict seemingly reached an equilibrium with a slight increase in install cost, but the effect on different verticals can vary.
Also, retargeting capabilities are in a risky position. At the moment, you can retarget a user only if the user uses the same e-mail address on different platforms. For example, if a user installed a flower delivery app but uninstalled it after a while, chances are that the app will call him back before Valentine’s Day. You can show the user some ads for flowers on social media platforms if they signed up with the same email address. Besides this, the flower delivery app cannot know where to find the user since it can’t track his IDFA anymore.
Finally, as ad partners have lost visibility on conversion metrics, it wouldn’t be unusual to expect ad networks to replace CPI-based operations with CPC- or CPM-based operations to push the impression-to-install conversion risk to the advertiser side.
