What iOS 14.5 actually changed
Before April 2021, tracking a user across apps and websites was mostly invisible to that user. Apps could read a device identifier called the IDFA (Identifier for Advertisers), and websites relied on cookies and pixels. Both let advertisers connect an ad click to a purchase later on, often on a completely different app or site, without asking the person in the middle for permission first.
Apple announced the change in mid-2020 and enforced it starting with iOS 14.5 in April 2021. The mechanism is called App Tracking Transparency, or ATT. Every app now has to show a plain, explicit system prompt before it's allowed to track a user across apps or websites owned by other companies. The prompt isn't a settings toggle buried three menus deep. It's blunt: it asks permission, in words, right in front of the user, the first time a relevant app is opened.
When people are asked directly like that, the vast majority say no. Industry tracking studies since ATT launched have consistently put opt-in rates at well under a third of users, and often much lower depending on the app category. That means the IDFA and similar identifiers are simply unavailable for most iOS users, most of the time, by default rather than by exception.
- The prompt appears the first time a relevant app is opened, not buried in settings.
- Declining is one tap, and it's the path most users take.
- Apps that skip the prompt or track anyway risk App Store rejection.
- The restriction applies to tracking across apps and sites owned by other companies, not to a business's own first-party data about its own customers.
That last point matters more than it seems. ATT didn't outlaw measurement. It outlawed a specific, previously-invisible method of measurement that depended on the user never being asked.
Why this broke advertiser reporting industry-wide
It's easy to think of this as "the Meta problem," since Meta's ad reporting took a lot of public heat over it and even quantified the impact publicly. But ATT applies to every app on iOS, not one advertising platform. Any business measuring conversions through a device identifier or a client-side browser pixel saw the same thing happen: a real drop in attributable data, specifically on iOS traffic.
That's an important distinction. The users didn't stop converting. They stopped being visible as having converted, at least through the tracking methods that used to work. A purchase that happens in Safari after an ad click in an app might never get connected back to that ad, because the identifier that used to make the connection is gone.
This hit iOS traffic specifically, which for many consumer-facing businesses is a large, often the largest, share of mobile users. Reported conversions dropped, cost-per-result numbers got worse on paper, and attributed revenue no longer matched actual revenue nearly as closely. Marketing teams who had spent years tuning campaigns around a certain cost-per-acquisition suddenly saw that number jump, not because the campaigns got worse, but because the reporting got blinder.
It also complicated multi-touch attribution. If a user saw an ad on one app, browsed a product on another, and eventually converted through a third, the chain used to be reconstructable through shared identifiers. With ATT, each of those touchpoints can end up isolated, making it look like conversions came from nowhere or from the wrong channel entirely.
The knock-on effect on ad performance, not just reporting
The reporting gap gets most of the attention, but it's only half the problem. Ad platforms don't just report on conversions, they use conversion data to decide who to show your ads to next. That's what delivery optimization is.
When the platform can see fewer real conversions, its model of "what a good customer looks like" gets blurrier. It has less signal to learn from, so it optimizes against an incomplete picture instead of the real one.
Less visible conversion data doesn't just make your reports look worse. It can make the ads themselves perform worse, because the algorithm is optimizing toward a target it can only partly see.
In practice, that can mean spend drifting toward audiences that look good on the limited data the platform can still see, even when they aren't actually your best customers. The waste is quieter than a reporting discrepancy, but it's often more expensive, because it compounds every day a campaign runs on a distorted signal.
It also shows up in the learning phase most ad platforms use when a campaign is new or recently edited. That phase relies on gathering enough conversion signal quickly to stabilize delivery. With fewer visible conversions to learn from, campaigns can take longer to exit the learning phase, or bounce back into it more often, both of which tend to raise costs.
Server-side tracking as the industry's response
Server-side tracking sends event data from a business's own server directly to the ad platform, instead of relying on a browser pixel or an on-device SDK to catch the event on the user's side.
That distinction matters because server-side tracking isn't gated by the same on-device tracking prompt. It doesn't depend on ATT consent, browser cookie settings, or whether an ad blocker is running in the user's browser. Your server already knows a purchase happened; it just tells the ad platform directly, on a channel that isn't blocked at the device.
- Events fire from infrastructure you control, not the visitor's browser or device.
- It isn't affected by ad blockers, browser tracking prevention, or a declined ATT prompt.
- It can often capture events further down the funnel that client-side pixels miss entirely.
This is the same underlying idea behind Meta's Conversions API, but the pattern isn't specific to one platform. Google, TikTok, Snapchat, and most major ad platforms now offer their own version of a server-to-server events connection, because the same tracking restriction affects advertising on all of them. It's become the general shape of the industry's response to the whole category of device-level tracking restrictions that started with iOS 14.5.
Most setups run server-side tracking alongside client-side tracking rather than replacing it outright, using deduplication so the same conversion isn't counted twice. The client-side pixel still catches what it can; the server-side connection fills in what the browser or device tracking permission would otherwise hide.
This isn't a one-time fix, it's an ongoing shift
iOS 14.5 wasn't an isolated event. It was the most visible entry in a longer trend of browsers and operating systems restricting cross-site and cross-app tracking by default.
Safari's Intelligent Tracking Prevention has been narrowing what third-party cookies and scripts can do for years, well before ATT existed, and it has kept tightening since. Chrome has moved through its own phased approach to restricting third-party cookies, with plans and timelines that have shifted more than once but never reversed direction. Android has introduced its own privacy-focused advertising changes too. Each of these moves the same way: less client-side, device-level visibility for advertisers over time, not more.
That's why treating server-side tracking as a one-time patch for "the iOS 14.5 thing" undersells it. The durable direction is server-side, first-party data strategies that don't depend on whatever tracking permission the device or browser happens to allow this year. Businesses that build their measurement around data they collect and own, then send to ad platforms directly, are the ones least exposed to the next platform announcement.
Getting this set up for your own ad accounts
Setting up server-side tracking properly means connecting your own server or systems to your ad platform's server-side API, mapping the right events, deduplicating against your client-side pixel, and keeping that connection accurate as your funnel, forms, and checkout flow change. Done manually, that's ongoing engineering work, not a one-time setup task, which is exactly why a lot of businesses that know they should do this never get around to it.
Go4Lead.tech built Relay to handle this without requiring a developer to maintain it. Relay is our Meta Ads tracker and Conversions API tool, giving you real-time ROAS, spend, and lead attribution with server-side tracking built in, recovering conversions that would otherwise be lost to iOS's tracking restrictions and browser-side ad blockers. You can see how it works on our products page.
If you're already seeing a gap between your ad platform's reported results and what your own sales or lead data shows, that gap is very likely this same problem, and it's worth closing before the next round of browser or OS privacy changes widens it further.