Safari Is Deleting Your Attribution: What ITP Actually Does and What Works Against It

If a meaningful share of your customers are on iPhones, some of your attribution is being deleted on a timer, and nothing in your dashboard will tell you. Intelligent Tracking Prevention is Safari's privacy system, it has been tightening for years, and its effect on advertising measurement is bigger than most teams realize — not because it blocks your tracking outright, but because it shortens the memory of it. Here's what it actually does, and which countermeasures are real versus cosmetic.

The mechanism, without the hand-waving

ITP doesn't simply block cookies. It classifies them and limits how long they live, and the limits are aggressive:

• Third-party cookies are blocked outright in Safari. This is the part everyone knows, and the part server-side tracking was largely built to answer.
• First-party cookies set by JavaScript — which includes the cookies most analytics and ad pixels create — are capped at seven days. After that they're deleted, and the returning visitor looks brand new.
• That cap drops to 24 hours when the visitor arrived via a link with tracking parameters from a domain Safari classifies as having cross-site tracking capability. Read that again, because it matters: the exact traffic you pay for, arriving with click IDs attached, is the traffic most likely to get the one-day treatment.
• Cookies set server-side via HTTP headers on your own domain get longer lifetimes, which is the crack that the durable fixes go through.

Why this hits high-ticket hardest

The damage is proportional to how long your buyers take to decide. An impulse purchase that happens twenty minutes after the click is unaffected. A $2,000 purchase that happens nine days later, after the customer thought about it, asked a partner, and came back via a Google search of your brand name, is invisible: the cookie identifying that person as having clicked your ad expired on day seven, or day one.

So the loss isn't random. It concentrates in your most valuable, most considered purchases, which means the attribution you lose is systematically worth more than the attribution you keep. Accounts in considered-purchase categories routinely see reported ROAS well below reality, and then make budget decisions on the understated number. That pattern is the sibling of the problem described in why conversions dropped but spend didn't, except it never "drops" — it's just permanently lower than truth.

What actually works

In rough order of impact per unit of effort:

• Server-side events with durable identity. The Conversions API (and its Google equivalent) sends conversions from your server, carrying hashed email, phone, and click IDs you stored at the time of the click. This sidesteps cookie expiry entirely, because your database remembers who someone is even after Safari has forgotten. This is the single highest-leverage fix, and the setup is covered in how to set up the Conversions API.
• Capture click IDs at the landing page and store them server-side. fbc for Meta, gclid for Google, li_fat_id for LinkedIn. Read them from the URL on arrival and write them to your database against the session or the eventual account, not just into a browser cookie that ITP will delete. A click ID in your database is permanent; one in a JS cookie has a one-week shelf life at best.
• Set your tracking cookies server-side via HTTP headers on your own domain, typically through a server-side tagging setup. These get considerably longer lifetimes than JavaScript-set cookies. This is most of the real value people get from server-side GTM, as distinct from the marketing around it.
• Ask for identity earlier in the funnel. An email captured at a newsletter signup or an account creation gives you a stable identifier that outlives every cookie policy. This is unglamorous and it is the most durable advantage available, which is why the whole industry keeps repeating the phrase first-party data — see first-party data and the future of tracking.

What doesn't work (or barely does)

CNAME cloaking — pointing a subdomain at a tracking vendor to make their cookies look first-party — was widely used and is now specifically handled by ITP, which caps cookies from CNAME-delegated subdomains at seven days too. It also creates real security and maintenance headaches. Treat it as a dead end rather than a strategy.

Longer attribution windowsfeel like an answer and aren't. If the identifying cookie is gone on day seven, setting a 28-day window doesn't resurrect it. You've widened a net with a hole in it.

Fingerprinting-style workarounds are actively targeted by browser vendors, legally fraught in several jurisdictions, and a poor foundation for anything you want to still work next year.

How to size your own exposure

You don't have to guess how much this affects you. Three measurements, none of which take long:

• Find your Safari share.In your analytics, segment sessions by browser. If Safari plus iOS in-app browsing is a small minority of your traffic, ITP is a minor issue. If it's a third or more, it's shaping your numbers materially.
• Find your typical time-to-purchase.If most conversions happen same-session, cookie expiry can't hurt you much. If your median is several days, the seven-day cap is cutting into your core business.
• Compare platform-attributed revenue to real revenue segmented by browser where you can. Chrome-heavy segments will reconcile more closely than Safari-heavy ones, and the gap between them is a decent estimate of what ITP is costing your reporting.

Multiply Safari share by considered-purchase behavior and you have a rough number for how much of your attribution is currently being deleted on a schedule. For a lot of DTC and B2B brands that lands somewhere between 15% and 40% of purchase attribution — not sales lost, but sales the platform never learns about.

Don't confuse ITP with the other three things

Four distinct forces get blamed interchangeably for missing conversions, and the fixes are different, so it's worth separating them. ITP shortens cookie lifetimes in Safari, so it specifically damages delayed conversions from returning visitors. Ad blockers stop the pixel from loading at all, which loses the event entirely and in real time, covered in do ad blockers affect your pixel. ATT governs app-level identifiers on iOS and affects app campaigns more than web ones. And consent banners withhold tracking until a visitor actively agrees, which on mobile means most of them never do, per consent mode and your tracking.

The tell that distinguishes ITP from the rest: your same-session conversion tracking looks fine, your immediate events reconcile well, and the loss concentrates in conversions that happen days after the click. If instead you're losing events at the moment they should fire, you're looking at blockers or consent, not cookie expiry. Getting this diagnosis right matters because server-side events fix ITP thoroughly, partially fix blockers, and do nothing at all about a consent banner that never got consent.

The optimization cost, which is the real cost

Under-attribution has two effects and people usually only think about the first. The obvious one is reporting: your ROAS looks worse than it is and you may under-invest in channels that are actually working. The subtler and more expensive one is training. Every conversion the platform doesn't see is a person it never learns to look for. If Safari users with long consideration cycles are systematically missing from your conversion data, delivery gradually skews toward the fast-converting, easy-to-track segment, which is often the lower-value one.

That's why fixing this isn't just a reporting cleanup. Feeding those lost conversions back through server-side events changes who the algorithm chases, and that effect compounds over the following weeks in a way a reporting correction never would.

A 90-minute remediation plan

If the sizing exercise above says ITP is costing you real money, here is the order that recovers the most attribution per hour spent:

• First 20 minutes: capture click IDs properly. Confirm your landing pages read fbc, gclid and any other click parameters on arrival and persist them somewhere durable — a server-side session record or your database, not only a JavaScript cookie. This is cheap and it stops the bleeding immediately for every future click.
• Next 40 minutes: get server-side purchase events live with the identity you just started storing. If you already run the Conversions API but only pass browser data, adding stored click IDs and hashed customer details to those calls is usually a small change with a large effect.
• Next 20 minutes: verify.Open Events Manager, confirm the server events arrive, check match quality, and confirm dedup is working so you haven't traded under-counting for double-counting.
• Last 10 minutes: record the baseline.Write down this week's platform-reported revenue against actual revenue. That ratio is what will tell you whether the fix worked, and later, whether it stopped working.

Most teams see the ratio move within a week or two, and the delivery effect follows over the next month as the platform digests conversions it previously never saw.

It changes again, so watch it

ITP is not a fixed rule set. It has been revised repeatedly, each iteration tightening something that used to work, and the same is true of the equivalent systems in other browsers. Anything you build against today's specifics has a shelf life.

Which argues for two habits rather than a one-time project. First, prefer fixes that don't depend on browser storage at all — server-side events keyed to identity you own will survive whatever the next version does. Second, keep an eye on the ratio between what your platforms report and what your business actually books, because that ratio is where a browser policy change first becomes visible to you. If it steps down one week and nothing in your marketing changed, the browser probably changed. Teams that watch that number find out in days; teams that don't find out at the quarterly review, after a quarter of decisions made on numbers that were quietly getting worse.