Between 2017 and 2021, three changes landed that together removed most of the tracking infrastructure paid social was built on. Each one broke something specific, and knowing which is which tells you what is still available.
The three changes
Intelligent Tracking Prevention (Safari, from 2017). ITP limits cookies written from JavaScript to 7 days (and to 24 hours in some conditions), and blocks third-party cookies. It later extended to script-writable storage. The practical effect: any click identifier your pixel writes through document.cookie has a short, unreliable life.
ATT — App Tracking Transparency (iOS 14.5+, 2021). Apps must ask permission before tracking a user across other companies’ apps and websites. Without consent, the app gets no cross-app identifier. This is why the ad platform’s own reporting started leaning on modelled conversions.
Third-party cookie blocking (Safari, Firefox, and browser privacy features generally). Cookies set from a domain different from the one in the address bar are blocked or partitioned. Chrome announced a full phase-out, then withdrew it in 2024 in favour of a user choice — which does not restore the old model, it just leaves the outcome to each user.
What each one broke
| Change | What stopped working |
|---|---|
| ITP | JavaScript-written cookies lasting longer than ~7 days |
| ATT | cross-app identity; platform-reported conversions became partly modelled |
| Third-party blocking | pixels, tags and CNAME-cloaked subdomains as first-party |
Notice what is not on that list: a cookie set by the server, via a Set-Cookie header, on the domain the user is actually visiting, from the same response that renders the page.
Why the first-party server-side cookie survives
The distinction is not technical trivia, it is the whole mechanism:
- ITP’s limits apply to cookies written by JavaScript. A
Set-Cookieresponse header is written by the server. - Third-party blocking applies to cookies set from a different domain than the page. A first-party cookie comes from the same domain.
- ATT applies to tracking users across other companies’ apps and sites. A first-party cookie measures the visit to your own site.
This is why the design in first-party tracking insists on one thing: the landing page and the tracking must be on the same domain. Not a redirect to the page from a tracking domain — the page itself served by the tracking domain.
A redirect chain is where the identifier dies. One request, one response, one cookie.
What this costs you in practice
First-party tracking is not free:
- You need a domain you control. DropCPL assigns one per landing page.
- Cross-domain journeys are not visible. If a user clicks an ad on your tracking domain, then converts on a different domain you own, that conversion is not tied to the click. Keep the conversion on the page that received the click.
- Windows are explicit, not implied. DropCPL’s
click_idlives 7 days. Longer consideration cycles (B2B with month-long sales cycles) will not be attributed to the original click — which is a reason to route leads out with their attribution rather than trying to reconstruct it later.
The setup that still works
- Serve the landing page from the same domain that logs the click.
- Set the click identifier server-side,
HttpOnly, first-party. - Attribute the form submission with that identifier — no dependency on a script firing.
- Send the conversion back to the platform through its server-side API, with a deduplication ID, so its optimiser keeps working.
- Decide on the first-party number, not the modelled one — see real CPL vs platform CPL.
Related
- First-party tracking — the implementation
- Real CPL vs platform CPL — why the two numbers differ
- What is creative attribution — why the click has to survive