App Tracking Transparency

Every iPhone carried a single advertising identifier. Not a name or a phone number, but enough to recognize the same device, so when several companies passed that number around they could line up what one person looked at in one app and bought in another. How many of yesterday's ad viewers installed the app today came back as a clean number.

None of that was visible from the user's side. You'd look at a pair of running shoes in a shopping app, meet an ad for those shoes in an unrelated game, and there was no screen that explained why and no switch to turn it off. Asked whether consent had ever been given, the honest answer was that a sentence about it sat somewhere in the terms accepted at signup.

Apple put a door in that flow starting with iOS 14.5 in 2021. An app that wants to track has to ask first, through a popup the system draws, and a refusal means the number is withheld. App Tracking Transparency (ATT) took a choice buried in the terms and moved it to the middle of the screen.

The policy defines tracking narrowly. Recording what a user taps inside your own app doesn't count. It becomes tracking the moment those records are joined to data held by another company — handing your usage logs to an ad network that merges them with what it collected in other apps lands squarely inside the rule.

The mechanism has three steps.

1. The app asks the system for permission, and the operating system draws a popup with fixed wording. The app can't rewrite the text and there are only two buttons, accept and decline, so nudging one side through design is closed off.
2. The value returned depends on the answer. Allow it and the app reads the advertising identifier normally; decline and it receives a value of all zeros. Nothing is withheld, exactly — everyone gets the same value, which leaves the recipient unable to tell one device from another.
3. The answer is final as far as the app is concerned. Changing it means the user walking into system settings. That's why many apps place their own explanation screen in front of the system popup, describing what the data is for before the real prompt appears, which lifts acceptance compared with a popup that arrives with no context at all.

Acceptance rates vary widely by category and by how well the request is explained. Apps with an obvious purpose, like banking or shopping, sometimes get close to half. An app that fires the popup seconds after install with no preamble gets something like four in twenty.

Ad measurement was the first thing to wobble. Attribution — deciding which ad gets credit for a conversion — starts by matching the device that saw the ad to the device that paid, and for a user who declined there is nothing to match on. App advertising reports moved from per-person to per-group as a result. A campaign reports how many installs it produced, but not who installed.

Retargeting, showing ads again to people who already visited, also narrowed inside apps, because the audience used to be assembled from device identifiers. The direction matches what happened on the web as third-party cookies got blocked, and the two shifts arrived within a few years of each other.

Weight moved toward first-party data as a consequence. Signup details and usage records gathered inside your own service don't depend on anyone else's tracking and aren't touched by this policy. That's why marketing teams put effort back into in-app account creation and collecting an email address.

Anyone shipping an app meets the rule at review. Doing anything that counts as tracking without the prompt gets the build rejected, and a live app can be pulled after a complaint. Even a work tool that barely advertises has to check this once, because attaching an analytics package is enough to raise the question.

"The ad dashboard says 300 installs this month and our own numbers say 470."

The gap comes from users who declined and therefore don't appear in ad reporting. Neither figure is wrong; they count different populations.

"Let's put an explanation screen in front of the prompt and A/B test it. Acceptance is at 22 percent right now."

Someone who knows the only place left to move the number is ahead of the system popup.

"That isn't tracking, it stays inside our own app, so no prompt is needed."

Drawing the boundary the policy actually defines.

Ravi raised this the year Pagedeck first shipped an iOS app. He wanted to run install ads, and without a link between the person who saw the ad and the person who upgraded inside the app, there was no way to decide which channel deserved more budget. The team settled on an explanation screen ahead of the prompt.

Noa designed it. She avoided the word tracking and wrote that the app only checks which ad brought you in, and she gave the continue button clear weight. Acceptance went from 22 percent to 34, which still left two out of three unmatched. So Ravi gave up on channel-by-channel comparison and added a question at signup asking people where they came from.

The most common misreading is that a decline means you can no longer see anything about the user. The word tracking in the prompt makes it sound like in-app records are cut off too. What's blocked is only the joining of your data to another company's. Which screen people drop off at, where the signup flow stalls — all of that still reports normally for users who declined. Miss the distinction and teams switch off their product analytics along with the ad integration, trading one lost measurement for every piece of evidence they had for fixing the product.

Reading the policy as a law is the other frequent mistake. The name sounds official and there are real consequences for ignoring it. But this is a rule one company applies to its own platform, and the consequence is a rejected review or a pulled app rather than a fine. Blurring the two wastes legal review time. Consent required by law still has to be collected separately, and an allow tap on the prompt does not stand in for it.