Streaming is available in most browsers,
and in the Developer app.
-
Explore App Tracking Transparency
Learn more about App Tracking Transparency and how it helps people using your app have choice and control over tracking. App Store Policy now requires that all apps receive permission through the AppTrackingTransparency framework in order to track people's data. We'll explain how this policy defines tracking, whether your app needs to adopt this framework, and how to implement it effectively.
Resources
- App Store Guidelines: User Privacy and Data Use
- Attributing ads with SKAdNetwork and Private Click Measurement
- Protecting the User’s Privacy
Related Videos
WWDC23
WWDC22
WWDC21
-
Download
♪ instrumental hip hop music ♪ ♪ Hi, I'm Julia from Privacy Engineering, and welcome to "Explore App Tracking Transparency." At Apple, we believe privacy is a fundamental human right.
Part of engineering great privacy is giving people choices and control over how their data is used.
When people have these choices and understand how their data will be linked or shared, they are more likely to trust and engage with your app.
That's why, beginning last year, App Store policy requires apps to receive users' permission before tracking users across apps and websites owned by other companies by adopting the AppTrackingTransparency framework.
Today, I'm going to talk to you about when and how to adopt App Tracking Transparency.
First, I'll start with some background on tracking to help you understand if and when your app needs to adopt the AppTrackingTransparency framework.
Then, I'll highlight some key things to keep in mind when adopting the framework in practice.
Let's get started with some background on tracking.
So, how is tracking defined for App Tracking Transparency? Tracking refers to 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.
Let's talk through some example scenarios to better understand how tracking is defined.
First, let's look at an advertising scenario that doesn't involve tracking.
Suppose I download an app called Pal About, and the Pal About app has a feature that lets me search for places and events that are happening nearby.
Now suppose I use Pal About to search for places that serve waffles near me, which results in Pal About storing waffles as an interest of mine.
Pal About later wants to show an ad for breakfast places targeting people who like breakfast foods.
Using the data Pal About stores about me from my searches, Pal About shows me the breakfast ad.
In this example, Pal About doesn't link my data with any data from an app or website owned by another company to show me the breakfast ad, so this scenario would not be considered tracking.
For another example that wouldn't be considered tracking, suppose the company that owns Pal About -- Pal About Inc. -- has another app that I use called Pal About Plus.
And Pal About's server links together data collected about me in Pal About Plus, like my interest in tacos, with data collected about me in Pal About.
After linking this data, Pal About shows me an ad for a taco truck using the fact I like tacos collected from Pal About Plus.
In this example, the Pal About app doesn't need to get my permission to track because it isn't tracking.
Pal About doesn't link my data from Pal About with any data from an app or website owned by another company.
Let's now consider a scenario that would require Pal About to get permission to track.
Suppose there's a food delivery app I use that's owned by a different company than Pal About.
And I've used the food delivery app to place orders late at night.
When I signed up for the food delivery app, I gave the app my email address -- the same email address I used to sign up for Pal About and that Pal About stores for my account.
The food delivery app includes code that shares my email address and the fact I often order at night with Pal About.
The Pal About server uses my email address to link together my interest in waffles, collected by the Pal About app, to the fact I order at night, collected in the food delivery app.
Finally, Pal About uses the combination of my ordering habits and my interest in waffles to show me an ad for a restaurant that serves all-day breakfast.
This scenario would require Pal About to request permission to track because it linked user data from Pal About -- my email address -- with another company's user data -- my email and habit of ordering at night -- for advertising purposes.
In this example, data is linked together across apps with an email address.
Even if the email address or another user identifier is hashed before it is used to link data, it would still require permission to track because it would still be linking data about a user from the app with another company's data about that user.
The type of identifier and whether or not it is hashed doesn't change the fact it is being used for tracking, which is what requires permission.
Another thing you'll need to consider to determine if your app needs to request permission to track is how third-party SDKs use and share data from your app.
As a developer, you're responsible for the behavior of your whole app.
Returning to our example, suppose the Pal About developer hasn't written any code themselves that would require permission to track, but would like to include a third-party SDK in their app for advertising-measurement purposes.
Whether Pal About needs permission to track in order to include the SDK depends on whether or not the SDK combines user data from Pal About with user data from other companies' apps or websites.
For example, if the SDK shares user data from Pal About to provide analytics about ads in Pal About, but doesn't link the user data it collects from Pal About with user data from other companies, it doesn't require permission to track.
Now suppose instead, the SDK shares user data from Pal About with an ad network, and the ad network links the data it receives about how I use Pal About with data about ads I saw in other companies' apps to compare the impact of ad campaigns in those apps.
This requires Pal About to request users' permission to track because this SDK is tracking.
This is considered tracking regardless of whether Pal About uses the SDK for those purposes, or even if Pal About only gets aggregate reporting after Pal About users' data is linked with other companies' users' data.
If you're unsure about whether an SDK you want to use would contain code that would require App Tracking Transparency, you should ask the developer of that SDK.
This responsibility applies not just to SDKs, but to any libraries or third-party code your app uses.
So far, we've looked at examples that involve linking user data.
Now let's look at another scenario that's considered tracking: sharing user or device data with data brokers.
First, how are data brokers defined? Data brokers are defined by law in some jurisdictions.
But in general, a data broker is a company that regularly collects and sells, licenses, or otherwise discloses to third parties the personal information of particular end users with whom the business does not have a direct relationship.
Let's look at sharing data with a data broker in an example.
Suppose the Pal About app includes client code that sends my interest in waffles and an account identifier to a data broker.
This scenario counts as tracking whether or not the data that is shared is linked with data from other companies for advertising or advertising measurement.
Sharing of user data with a data broker requires permission to track.
And even if Pal About client code doesn't directly send my account identifier and my interest in waffles to the data broker, but instead this interest is sent to Pal About's server and the server later shares accounts interested in waffles with the data broker, this would require getting permission to track even though my device isn't communicating with the data broker directly.
We've now talked through how the definition of tracking applies to some example scenarios.
For more information about how App Tracking Transparency defines tracking, you can visit the User Privacy and Data Use page.
Now, if you've determined that your app would like to track users, you'll need to ask for and obtain the user's permission before you do so.
Here's how.
To ask for permission for your app to track, you'll need to present the app tracking authorization request prompt by calling the requestTrackingAuthorization method.
Calling this method will cause a system permission alert -- like this one for Pal About -- to appear over your app.
This is a one-time prompt.
The system will remember the user's choice and won't prompt again unless the app is uninstalled and reinstalled.
The next thing you'll need to do is provide a NSUserTrackingUsageDescription key in your app's info.plist.
The string provided here will be shown in the system prompt and informs the user why the app is requesting permission to use data for tracking the user or the device.
A great purpose string is clear, concise, and helps users understand why they are being asked to allow tracking.
This string doesn't need to include the app's name, because the system will automatically identify the requesting app and display the app name in the system prompt.
If you don't include a usage-description string, your app will crash when the system prompt is shown.
Finally, use trackingAuthorizationStatus to determine the user's app-tracking permission status for your app.
If a user has selected Allow for this app, then you have their permission to link their activity in that app across other apps and websites as long as their tracking authorization status remains authorized.
Users can change and grant or revoke their tracking authorization at any time, so make sure your app checks the tracking authorization status each time it is launched and only continues to track when the value of the tracking authorization status is authorized.
Users can control whether apps have their permission to track on a per-app basis.
Just because a user has given one of your apps permission to track doesn't mean you have their permission to track in another app owned by the same company.
Different apps must each individually request permission from the user for that particular app before data from that app can be linked to apps or websites owned by other companies for marketing or advertising.
If your app doesn't have tracking authorization for a user, there are a couple things to keep in mind.
First, per the App Store review guidelines, your app must not gate any of its functionality on whether the user agrees to allow tracking.
Second, the IDFA API will return all zeros if the user has asked your app not to track.
If a user has opted out of tracking, there are nontracking alternatives for advertising or advertising measurement for your app.
For example, your app could choose to serve first-party ads or contextual ads.
And for advertising measurement, we continue to build and improve privacy preserving ad-attribution technologies that ad networks can adopt.
For more information about recent improvements to SKAdNetwork and private click measurement, you can refer to "Meet privacy preserving ad attribution" and "What's new in SKAdNetwork." You'll also need to declare what data your app uses to track for display in your app's privacy nutrition label.
Filling out your privacy nutrition label when submitting your app to the App Store and getting permission to track using the AppTrackingTransparency framework are two separate steps that are both required if your app would like to use data for tracking.
For more information about nutrition labels and how to fill them out for your app, see "Create your Privacy Nutrition Label." Finally, let's talk about fingerprinting.
With permission, tracking is allowed.
But fingerprinting is never allowed.
Regardless of whether a user gives your app permission to track, fingerprinting -- or using signals from the device to try to identify the device or user -- is not allowed per the Apple Developer Program License Agreement.
Some examples of user or device data used for fingerprinting include properties of a user's web browser and its configuration, the user's device and its configuration, the user's location, or the user's network connection.
Collecting any data solely for the purpose of generating a fingerprint is also not allowed.
It's important people have transparency and control over how their data is used for tracking.
We hope that by tuning in to this session, you now have the tools you need to determine when and how to give people that control by adopting the AppTrackingTransparency framework.
Thanks for watching.
♪
-
-
Looking for something specific? Enter a topic above and jump straight to the good stuff.
An error occurred when submitting your query. Please check your Internet connection and try again.