The good news is that if you’re working purely on web audiences, there’s minimal change from this update. If you’re promoting an app, however, then you’ve probably already seen a significant impact on your campaigns. We’ll break down exactly why this happens.
This post will dive into the recent Apple update and how it affects the advertising landscape in general, and native ads specifically.
What is IDFA?
The Identifier for Advertisers (IDFA) is an anonymized unique identifier that doesn’t include any personally identifying information (PII) and is more secure than other data-sharing methods. In essence, the IDFA is a mobile ad ID (MAID) assigned by Apple to each device.
Think of it as the browser-based cookie of the mobile app world. iOS users have always had the option to reset their IDFA or turn off access to it to prevent advertisers from tracking them. With the introduction of iOS 14.5, users were given the option to opt-in to tracking rather than the previous approach of opting out.
IDFA provides benefits for the entire app and marketing ecosystem. Its core functionality enables a mobile app on an iOS device to track users’ interactions (clicks, downloads, purchases, etc.) across other company’s apps, websites, and offline assets.
Using IDFA to deliver targeted ads allows advertisers to track campaign performance and provide users with a more personalized app experience. In turn, that creates a better overall customer experience and increases app developers’ revenues.
What is App Tracking Transparency (ATT)?
Apple’s App Tracking Transparency, commonly referred to as ATT, is one the largest updates presented in their iOS 14.5 update released this spring. This framework continues Apple’s commitment to user privacy by enforcing strict limitations on how apps track user engagement and report to ad networks.
At its core, this framework suggests that a user cannot be tracked using a unique identifier (IDFA) without explicit permission. Without such consent, only anonymous tracking is permitted.
Additionally, ad networks SDKs (equivalent to web tracking pixel) are replaced with a single framework by Apple (SKAdNetwork) that will handle the conversion reporting. This ensures that the data reported is fully anonymized and removes plenty of excess code bloating the apps.
The anonymization of the data happens with several mechanisms:
- Campaign level reporting
- Conversions are stripped of additional parameters
- Reporting is delayed randomly 24-48 hours
For example:
(Source)
Let’s break this down some more.
Campaign level reporting means that the data passed back to the ad network is limited to the campaign that drove the conversion. This means that any breakdown offered beyond that will be a result of statistical modeling. This limit was put in place so that advertisers don’t “cheat” and break the campaign down into ad sets with distinct users.
Similarly, conversions are limited to 16 only, with the reporting returning a number (i.e., 05) which the ad network can then match with a human-readable name (e.g., Purchase). These conversions won’t carry parameters, as these can also be abused to pass sensitive user data. For example, this means that a Purchase event won’t pass any value, items purchased, and other important metadata.
Finally, the reporting will be delayed by a random window of 24-28 hours so that advertisers can’t match an identified user with an anonymous one. The reporting will also be limited to a seven-day window, after which no attribution will be given.
App Tracking Prompt
You’re probably wondering what all the fuss is about when it comes to the app tracking prompt. The prompt, which appears on all apps but Google’s, is used to get the user’s consent for tracking advertising campaigns.
Without this consent, ad networks cannot collect the user’s IDFA and can only report on the app installation event.
There is mixed reporting on the opt-in rates, some optimistic and others pessimistic, but it may actually be that these don’t really matter.
In either case, Taboola’s SDK has already been updated to support this since September 2020.
Apple’s limitations on website tracking
So Apple is cracking down hard on apps. These limitations are enforced quite strictly via the app store, and there’s no way around them.
But the reality is, most users also spend a significant part of their time online on websites, so Apple wanted to address that as well.
Apple has already embedded Intelligent Tracking Prevention (ITP) in their Safari browser. This has been in place since 2017, enforcing strict limits on third party cookie tracking on Safari.
To apply the same standards for app tracking for Safari users, Apple released Private Click Measurement (PCM) as the equivalent web standard of ATT. It bears similar restrictions to ATT (Campaign level reporting, stripped conversions and delayed reporting).
However, unlike ATT, this framework isn’t enforced on Safari, as there are many potential ways to bypass it. Neither is it carried out on other browsers available on Apple devices.
For example:
(Source)
At this point, ad networks can choose to opt-in to using this framework, but no major network has chosen to do so.
In practice, this means that all tracking pixels from web analytics and ad networks will continue to work just fine across browsers on Apple devices.
App to browser tracking
So app to app tracking will be limited, and web to web traffic is still generally quite the same. But what happens when trying to track traffic coming from an app to a website? For example, how will a user clicking through from the Blinkist app to a website be tracked?
In this case, an app to web tracking scenario, there are two components to consider:
- The outbound link
- The tracking pixel on the destination page
If you’re advertising on Facebook Ads, you probably recognize the FBCLID parameter (Facebook’s Unique Click Tracking Parameter) appended to links. Previously, such outbound links would have been “decorated” with a click ID. This ID associates the anonymous user landing on the advertiser’s site with an identified user on Facebook.
In this way, Facebook can match that click of a specific ad with a specific user to provide accurate attribution.
With Apple’s ATT, this type of link decorating is prohibited, so only non-identifiable parameters are allowed, such as UTMs (Source, Medium, Campaign, etc.).On the destination page, tracking pixels will continue to work uninterrupted (as explained above), so no major change here.
How does the iOS 14 update impact native advertising?
It depends. When implementing Taboola native ads, placements vary between publisher websites and apps, so campaigns are bound to be impacted by this change.
You can expect a bigger impact if you’re promoting an app, as the tracking will be limited on both the publisher’s app and the app promoted. This will result in fewer reported conversions. However, on Taboola, while tracking may be limited on publisher apps, Taboola’s publisher make-up is only about 5% apps.
To compensate, some of the data will be reported using probabilistic modeling, both through reporting partners such as Appsflyer, Adjust, or Kochava and on the ads management reports.
We also recommend that app advertisers try testing web-based landing pages before driving to their app store. When you run just app to app, the IDFA is required to track, but if you introduce a web-based landing page in the middle of that journey it will introduce more signals that help in probabilistic attribution.
If you’re promoting a website, you’re likely to see a smaller drop in reporting. As explained, the app to web tracking will take some hits, but the relative flexibility of the website tracking pixels can counterbalance it – meaning you’ll still get conversions from all of Taboola’s sources; but on our app placements, it is just harder to attribute those conversations to their original click for tracking purposes.
We recommend separating Android and iOS traffic in your campaigns (a general best practice) to ensure clean tracking of Android users in their campaigns. This also helps the Taboola algorithms better optimize for these distinct types of traffic.
Additionally, with the attribution on iOS devices limited to seven days, we recommend using up funnel events for optimization. With similar limits enforced on the Safari browser, this recommendation applies to web traffic too.
For example, if the product you’re selling is expensive and has a long consideration cycle, e.g., a diamond ring, consider using the “Add to Cart” event as a conversion goal for the campaign.
Since there are more events of this type (compared to Purchase events) and it is still highly correlated with the Purchase events, the optimization will be powerful.
If you have a shorter consideration cycle or a high volume of Purchase, choose to optimize against the down funnel actions.
Conclusion
iOS 14.5 creates a lot of challenges for app advertisers, and Native Advertising offers a good route to overcome them. As our mobile placements are mostly on the open web, the IDFA is already not at play! And for the small number of our placements found in apps, there are still measures you can take to accurately track your performance.
What does iOS 14.5 mean for marketers? You came to the right place to find out!