- TLC Home Home
- Discussions Discussions
- Documentation Documentation
- Knowledge Base Knowledge Base
- Education Education
- Blog Blog
- Support Desk Support Desk
Apple's annual user conference took place in June (for the first time, an entirely virtual event), and among all the exciting announcements about new hardware and apps, was the slightly less exciting, but equally headline-worthy change of direction regarding usage of the IDFA (Identifier for Advertisers - Apple's user-resettable marketing ID). The change essentially means that while it's still technically possible for marketers to access the IDFA, they can only do so with the user's explicit consent, which comes in the form of a mandated (and quite intimidating-looking) "permission to track" modal dialog when the app launches for the first time.
It's worth noting that users have always had control over the IDFA from the Settings app - if "Limit Ad Tracking" was enabled, apps couldn't access the IDFA at all - but this is the first time that the option to opt out has been presented in such an obvious place, and many users would have been unaware of the old setting and have probably never changed it. With the new setting, if the user declines consent, then the IDFA isn't available to the app, which makes it difficult for app publishers to identify, amongst other things, the effectiveness of their ad campaigns, and makes it more likely that users will see ads that aren't relevant to them.
Many advertisers and marketers are understandably concerned about this move, and wondering what it will mean for not only their ad campaigns, but maybe even their jobs; whole industries are built around the current model of attribution, and perhaps advertisers will suddenly decide it's not worth the hassle to spend money on advertising to iOS users. I think this scenario is unlikely, and in the worst case, ad spend may shift temporarily towards Android, but it's easy to see why people are concerned. The industry has come through many tumultuous events in recent years (GDPR, ITP, CCPA), and I'm sure that it will continue past this latest speed bump.
The spirit of the new Apple guidelines appears to be that you must gain explicit user permission through the new AppTrackingTransparency framework whenever you track your users in a way that links their data with data from third-party SDKs, ad networks, or data brokers, for example, Oracle Bluekai, Lotame, and MediaMath.
Tealium does not directly use the IDFA, and our SDKs do not collect it by default (there is an optional module you can use if you need this). If you are collecting the IDFA and using it anywhere in the Tealium platform as a visitor identifier (something we don’t recommend due to its transient nature), then it’s important to note that you will no longer have access to it if your users opt out of tracking. Instead, we would recommend using a known first-party identifier, such as a hashed email address. If you are sending the IDFA to any third-party tools using connectors or tags, be aware that these integrations may stop functioning correctly if a user opts-out of tracking. We recommend checking if any of the connectors or tags in your Tealium account are using the IDFA, and if so, contact the vendor and find out what their recommendations are to continue using their software for users who have opted-out (assuming those vendors’ products still comply with Apple’s AppTrackingTransparency guidelines).
Apple's guidelines give the following definition of in-app tracking:
Tracking refers to the act of linking user or device data collected from your app with user or device data collected from other companies’ apps, websites, or offline properties for targeted advertising or advertising measurement purposes. Tracking also refers to sharing user or device data with data brokers.
- Source: https://developer.apple.com/app-store/user-privacy-and-data-use/
- Retrieved: 24th July 2020
According to this definition, a Tealium customer using the AudienceStream platform to build visitor profiles and act on this data solely using the tools we provide would not fall within this definition, since there are no data brokers (DMPs) involved, and the data is not being sent anywhere outside of the Tealium platform. Tealium also does not provide any advertising or ad measurement capabilities. If you are sending data to an analytics platform that you own, and one that does not incorporate third-party data, then it appears that this would also be allowed under the new rules, without obtaining explicit permission. If, however, your analytics platform is linked to an ad network - for example, if your Google Analytics property is linked to your Google Ads account - this would require explicit permission from the app user.
The following table explains in simple terms when you should use the AppTrackingTransparency framework in conjunction with the Tealium SDK. Please note that these are just guidelines, and you should use your own judgement and work with your company's legal team to make sure you are satisfied that your app is compliant, to ensure your app doesn't get rejected when you submit it to the app store.
Using the SDK to...
Send data to Tealium AudienceStream and use the data solely to enrich what your company knows about the user. No server-side connectors enabled.
Send data to Tealium AudienceStream and forward some of this data to third-party vendors through connectors
Send data to Tealium EventStream and forward the data to your analytics vendor through a connector
The AppTrackingTransparency framework sits alongside existing privacy requirements, and using this framework alone does not guarantee compliance with local privacy laws, such as GDPR and CCPA. Fortunately, Tealium can help with this; enter the Tealium Consent Management modules, available for both iOS and Android! These modules make it easy to manage your app users' consent settings at a very granular level, and have support for GDPR and CCPA, and are easily extensible to accommodate future privacy laws, such as the catchily-named SB220 for Nevada (other countries also in the process of updating their privacy laws, most of which are modeled after GDPR, include Thailand, Japan, and New Zealand).
Depending on the requirements of the active consent policy, the Tealium Consent Management modules allow your users to opt-in/out of all tracking, or a customizable category-based opt-out, with 15 predefined categories to choose from. Whether you need to use the AppTrackingTransparency framework or not, the Tealium Consent Management modules can complement and enhance your app's approach to privacy and user consent, and we encourage you to check them out!
Learn more about Consent Management for Mobile.
Tealium has always strongly advocated for first-party data, as this is always more reliable than third-party data. If you're curious to see third-party data in action, take a look at the Oracle Data Cloud Consumer Data Privacy tool, which enables you to view a PDF report showing all the information Oracle has gleaned from your online activity. It was news to me that I have a brand affinity for Victoria's Secret, Chanel, and Gucci, but perhaps this reveals more about my online shopping habits than I care to share here! Joking aside, there's a lot of high-quality first-party data waiting to be tapped into that you can make use of directly in Tealium without having to send your data to any third parties, and Tealium does not use or share any of this information for our own purposes.
In a post-IDFA world, assuming most users opt out of tracking, it's pretty much a foregone conclusion that measuring ad campaign effectiveness is going to get harder, and it's a fact that marketers will get much less visibility (at least at a granular per-user level) of how effective their ad spend has been. However, where Apple takes away with one hand, they give with the other, in the form of enhancements to the SKAdNetwork framework. This provides a method for ad networks to validate app installs anonymously, and still measure the effectiveness of individual campaigns via a postback from the App Store directly to the ad network. The only data the ad network receives is confirmation that the app was successfully installed, along with the campaign ID and, optionally, conversion value.
The conversion value helps to assign a monetary or other value to the app install, which helps to see if a particular campaign has been more valuable than another; not simply which campaign generated the most installs. If, for example, your ad appears in an app selling luxury watches, you might find that it generates more revenue per user than if it appeared in a social media app, even if the social media app generated more installs overall. If you need to assign a conversion value, it's worth noting that the time taken to report back to the ad network will increase, so it may take longer to see how successful your campaign has been.
When your app is first launched, you should call
SKAdNetwork.registerAppForAdNetworkAttribution() , which will inform the SKAdNetwork framework that it should send an attribution postback to the ad network. Rather than sending immediately, this API starts a 24 hour timer, after which time, if no conversion events have been registered, the postback will fire some time within the next 24 hours (so in the worst case, you could be waiting 48 hours to see the results).
If you wish to report conversion events, you can do this by calling
SKAdNetwork.updateConversionValue() , which accepts an integer value representing the amount of the conversion. This value has no unit, so it's up to you (or the ad network) to determine its meaning - be that dollars, pounds, or number of levels completed in a game. Each time you call
updateConversionValue() with a new value, you overwrite the previous value, assuming the new value is higher than the current value. Additionally, a new rolling 24 hour timer is started, and only once this expires does the conversion event get sent back to the ad network, so if the user used your app once per day, and each time it was just under 24 hours since they last used it, it could be several days before the install finally gets attributed. When the last timer has expired (meaning
updateConversionValue() hasn't been called within the past 24 hours), the conversion event will be reported any time between 0-24 hours later (this is random every time, so the only guarantee you have is that it will be within 24 hours).
To save developers the monotony of manually adding the required API calls to their app code, we're currently working on a module for the iOS library that will allow you to easily call the SKAdNetwork APIs by using your existing Tealium event tracking to both register for attribution and update conversion values. We hope to have this ready in time for the iOS 14 release, so watch this space for updates!
Update - October 2020: SKAdNetwork support for the Tealium Swift library has now arrived! See release notes for details. Requires Tealium Swift 2.1.1.
Hopefully this post has made the new privacy changes in iOS14 seem a little less intimidating, but if you're still a little unsure, feel free to start a discussion on our Developer Forum, or contact the support team, who will be happy to help.
Copyright All Rights Reserved © 2008-2023