At some point in the last few years your dashboards got worse and you did nothing to deserve it. Same campaigns, same pixel, same checkout — but reported conversions dipped, retargeting audiences shrank, and the cost per purchase you saw in the platform stopped matching the orders you could count by hand. You did not break anything. The measurement layer underneath your ads broke.
This post explains exactly what broke — App Tracking Transparency, Safari's Intelligent Tracking Prevention, the slow death of the third-party cookie — what the platforms lost the ability to see, why they started showing you statistical estimates instead, and why the durable answer is tracking that lives on your own domain and your own server.
The Machinery That Used to Do the Work
Ad measurement used to ride on two pieces of shared plumbing.
The first was the third-party cookie. A platform's pixel ran on millions of sites, and every site read and wrote the same cookie from the platform's domain. That one identifier stitched a person's browsing across the entire web: the platform saw the ad impression, the click, the product page, and the purchase — all linked to one profile, automatically.
The second was the mobile device ID (Apple's IDFA, Google's advertising ID). Inside apps, where cookies do not exist, the device ID played the same role: one stable identifier shared by every app, available by default, joining an ad tap in one app to a purchase in another.
Both identifiers had the same property: they worked across properties owned by different companies, with no effort from the advertiser. That property is exactly what got removed.
What ATT Actually Changed
With iOS 14.5, Apple shipped App Tracking Transparency. ATT is often described as "Apple killed tracking," which is not quite what happened. ATT did something narrower and more consequential: it put the IDFA behind an explicit, per-app permission prompt — the "Ask App Not to Track" dialog — and made denial the practical default, because most people, when asked plainly, say no.
Three details matter:
- ATT governs apps, not the web. It gated the device ID and cross-app data sharing. The web side of the collapse came from browser policy (next section).
- The identifier did not degrade — it vanished. For users who decline, there is no fuzzy version of the IDFA. The deterministic join between an ad tap in Instagram and a purchase elsewhere is simply gone.
- What Apple offered instead is aggregate. SKAdNetwork-style reporting returns delayed, thresholded, campaign-level counts — useful for directional reads, useless for joining a specific conversion to a specific click.
For platforms whose ad delivery was tuned by per-user conversion feedback, this was a structural loss, not a reporting inconvenience.
Safari ITP and the 24-Hour Cookie
The web story is Safari's Intelligent Tracking Prevention. ITP blocks third-party cookies outright — the cross-site identifier described above just does not exist in Safari anymore, and Firefox applies similar blocking. Chrome has spent years signaling restrictions of its own while shipping replacement APIs.
The platforms adapted with link decoration: append a click ID to the landing URL (gclid, fbclid, ttclid), have the on-site pixel store it in a first-party cookie via JavaScript, and read it back at conversion time. Clever — and ITP answered it directly. Safari caps the lifetime of cookies written by JavaScript to 7 days, and as short as 24 hours when the visit arrives decorated with tracking parameters from a known tracker domain.
Here is what that does in practice — illustrative math, not a study: a customer on an iPhone clicks your ad on Tuesday, thinks about it, and buys on Saturday. The click-ID cookie the pixel wrote on Tuesday expired days ago. To the platform, Saturday's buyer is a stranger. The conversion happened; the attribution of it did not.
What the Platforms Stopped Seeing
| Signal | Before | After ATT + ITP |
|---|---|---|
| Device ID (IDFA) in apps | Available by default | Opt-in prompt; mostly denied |
| Third-party cookie | One profile across the whole web | Blocked in Safari and Firefox; restricted elsewhere |
| JS-written first-party cookie | Lived for months | Capped to 7 days / 24 hours in Safari |
| Click ID at conversion time | Read from a durable cookie | Gone unless you captured and stored it yourself |
| Conversion counts | Observed events | Observed plus modeled estimates |
The downstream symptoms are the ones you felt: retargeting pools that shrank because the platform could no longer recognize returning visitors, frequency caps that stopped working across sites, and conversion counts that undercounted iOS- and Safari-heavy traffic.
Modeled Conversions: Filling the Gap with Math
The platforms did not leave the holes empty. Where the deterministic join broke, Google, Meta and TikTok introduced conversion modeling: statistical estimates of how many conversions probably happened in the unobservable segment, based on the behavior of the users they can still see.
To be fair: at platform scale, modeling is a reasonable engineering answer, and a modeled number is usually closer to reality than a raw undercount. But it changes what your dashboard is. Part of the "Purchases" column is no longer a count of events — it is an inference. You cannot tie a modeled conversion to an order ID, audit it against your store, or know which campaigns absorbed more guesswork than others. And the entity producing the estimate is the same one selling you the ads.
Why First-Party Tracking Survives
Every broken mechanism above has one thing in common: it depended on a third party identifying your visitor across sites it does not own. That is the precise behavior browsers and operating systems decided to end — and they are not going to reverse it.
What none of these policies restrict is your own relationship with your own visitor on your own domain. A first-party setup inverts the architecture:
- The tracking script is served from your domain and sends events to your endpoint — your site observing your traffic, not a tracker observing the web.
- Click IDs and UTMs are captured at landing and stored server-side, in your database. A row in Postgres does not expire after 24 hours because Safari said so.
- The conversion truth comes from server-side events — a checkout webhook from Shopify or Stripe carrying the real order and the real amount — not from a browser script racing cookie policy.
- The join between click and order happens on your server, under rules you can inspect. This is the architecture Decisa is built on: own-domain click capture, webhook-fed orders, and an attribution join you can audit order by order.
The result is measurement that does not care what the next iOS release changes, because nothing in the chain depends on cross-site identity.
What to Do This Week
- Capture click IDs first-party. Store
gclid,fbclid,ttclidand UTMs at landing, server-side — not only in a cookie. - Move conversion truth to the server. Webhooks from your checkout, not browser events, define what an order is.
- Send verified conversions back through Meta's Conversions API and Google's enhanced conversions so bidding algorithms learn from real orders instead of modeled ones.
- Re-base your decisions. Keep platform numbers for in-platform optimization; make budget and scaling calls on your own joined data.
Tracking did not break because you misconfigured a pixel. It broke because an entire architecture — identifying people across other companies' properties — was retired. The replacement is not a better pixel. It is owning the data path yourself.