The marketing attribution stack most teams built between 2012 and 2019 depended on two things: a third-party cookie dropped by the ad platform on the landing page, and a browser pixel that fired on the conversion page and matched back to that cookie. Both halves of that pair are now degraded. Neither will recover.
This post is not a lament for the cookie. It is a map of what actually works in 2026 — which attribution paths have survived, which have been marketed as solutions without actually being solutions, and what a working stack looks like in practice for teams running paid acquisition into EU traffic.
TL;DR#
- Apple's ITP 2.3, Firefox Enhanced Tracking Protection, and the ongoing Chrome third-party cookie phase-out together mean 60–70% of EU web traffic now blocks or severely limits third-party cookies by default.
- Two attribution paths still function: server-side identifiers passed through a click ID, and first-party cookie planting via a redirect chain your domain controls.
- Cookieless does not mean consentless. The ePrivacy Directive 2002/58/EC and GDPR still require consent for non-essential analytics, regardless of the storage mechanism.
- Probabilistic fingerprint stitching is not a compliant fallback in the EU; deterministic email-hash matching combined with a server-side click ID is the only approach that holds up under both accuracy and regulatory scrutiny.
What changed: a brief timeline#
Safari began restricting third-party cookies in 2017 with ITP 1.0. The restrictions escalated quickly. ITP 2.3, released in September 2019, capped the lifetime of script-set first-party cookies to seven days, and to twenty-four hours when the referral chain included a known cross-site tracker. That change alone broke the standard click-ID-to-cookie handoff that most attribution vendors relied on.
Firefox's Enhanced Tracking Protection shipped Total Cookie Protection to all users in 2022, partitioning every third-party cookie by top-level site. A cookie set by pixel.example.com on your checkout page and your competitor's checkout page are now two entirely separate cookies — cross-site correlation is gone by construction.
Chrome's timeline has shifted several times since Google announced it in 2019. The current position, documented on the Privacy Sandbox site (accessed 2026-05-12), has the deprecation proceeding for a subset of users with a full rollout still in progress. Regardless of Chrome's final date, the EU picture is already settled: Safari and Firefox together account for the majority of mobile and privacy-conscious desktop traffic in EU markets. Attribution strategies that require third-party cookies are already broken for a large share of your European audience.
The combined effect measured across typical EU performance-marketing accounts: browser-side pixel attribution is undercounting conversions by 25–45% depending on the traffic mix, with iOS-heavy verticals (fashion, beauty, apps, subscription services) at the upper end of that range.
The two surviving attribution paths#
Path 1: server-side identifiers#
The core mechanic is straightforward. When a user clicks your ad, the ad platform appends a click identifier to the landing URL — fbclid for Meta, gclid for Google, and so on. That identifier exists in the URL, not in a cookie, so ITP and cookie partitioning do not touch it.
Your landing page reads the click ID from the URL and writes it to a first-party cookie on your own domain, or passes it through to your cart and eventually onto the order record. When the user converts, your back-end reads the click ID off the order and sends the conversion server-to-server to the ad platform's conversion API — Meta's Conversions API, GA4 Measurement Protocol, Mixpanel's server-side events endpoint.
This path works because it never touches third-party cookies. The click ID is in the URL query string at the moment of landing. Your first-party cookie on your own domain is not restricted by ITP in the same way as third-party cookies (though it is subject to the 7-day cap on script-set cookies if the referral chain is suspicious — more on this below). The conversion event flows server-to-server, entirely outside the browser.
The weak points are real. If the user clears cookies between landing and conversion, the click ID is gone. If the conversion happens on a different device, there is no cross-device link unless you have a logged-in user with a known email address. And iOS 17 introduced Link Tracking Protection in Private Browsing and Mail, which strips known click ID parameters from URLs — fbclid, gclid, msclkid are on the strip list. A user arriving via the Mail app with link tracking protection on will not carry the click ID into your site at all.
Path 2: first-party redirect chain#
The second surviving path uses a redirect you control as the attribution surface. Instead of the ad platform's click ID, you generate your own persistent identifier at the moment of redirect on your own domain.
When a user clicks a link on your domain — whether a short link, a campaign landing redirect, or a branded deep link — the redirect handler on your edge runs before the browser's privacy restrictions apply. It can:
- Set a first-party cookie with a server-generated click ID on your domain.
- Append the click ID as a URL parameter to the destination URL.
- Log the click event server-side with the full technical context (IP, user-agent, referrer, timestamp) at the moment of click rather than at the moment of page-load.
Because this is your domain and your server-side cookie, it sits outside the third-party cookie restrictions that ITP targets. The cookie is set by your server via a Set-Cookie response header on the redirect response — server-set cookies are not subject to the 7-day ITP cap that applies to document.cookie writes from JavaScript.
This is the attribution surface a URL shortener provides that a browser pixel cannot. The redirect resolves on the shortener's domain. If that domain is your own branded domain, your click ID is first-party, server-set, and architecturally positioned before any browser-side privacy restriction runs.
How a short link becomes the attribution surface#
The redirect flow works like this. Your ad's destination URL is a branded short link — for example, go.acme.example/summer-sale. The user clicks. The redirect request reaches Elido's edge handler, which:
- Looks up the destination URL.
- Generates a
elido_clickidentifier and logs the click event server-side. - Sets a first-party
Set-Cookie: elido_click=<id>; Domain=go.acme.example; SameSite=Lax; Secure; Max-Age=604800on the redirect response. - Appends
?elido_click=<id>to the destination URL before forwarding.
The destination page receives the click ID in the query string. Your tag manager or theme code reads it and stores it on the cart or order record. When the conversion happens, you POST to POST /v1/conversions with the click ID and the order details — Elido handles the SHA-256 hashing of customer identifiers and the server-side fan-out to Meta CAPI, GA4 Measurement Protocol, and Mixpanel.
The click ID never lived in a third-party cookie. It was server-set, first-party, logged before the browser's privacy layer had a chance to interfere. For the full mechanics of the server-side forwarding step, server-side conversion tracking via short links covers the deduplication, hashing requirements, and retry semantics in detail.
For the broader question of how ITP specifically degrades click attribution and what the short-link redirect chain does about it, click attribution after Safari ITP is the operational companion to this post.
Identity stitching: what works and what does not#
Server-side click IDs solve the attribution problem for users who click a link and convert in the same browser session on the same device, without clearing cookies, without link tracking protection stripping the parameter. That still covers the majority of e-commerce conversions. But it does not cover everything, and the approaches teams use to fill the remaining gap vary significantly in both accuracy and legal exposure.
Deterministic matching works. If the user is logged in, or provides their email address at any point in the funnel (email capture, newsletter signup, checkout), you can hash that email address with SHA-256 and include it in the conversion event. Meta CAPI, GA4, and Mixpanel all accept hashed email as a matching signal alongside or in lieu of a click ID. The match rate for known-email traffic is high — Meta internally reports match rates above 90% when a normalised, hashed email is present. This is the primary stitching mechanism that survives cookie deprecation intact.
The deduplication pairing matters here. Each conversion event needs an event_id (for Meta) or transaction_id (for GA4) that is identical between the browser-side pixel and the server-side send. Without it, both events ingest and the conversion is double-counted. The order ID is the standard dedup key for purchase events.
Probabilistic fingerprinting does not work — and is not legal in the EU. Browser fingerprinting assembles a unique identifier from the combination of screen resolution, installed fonts, timezone, user-agent, canvas rendering fingerprint, and similar signals. The identifier is probabilistic — it assigns a high-confidence match between two events without a shared cookie or login. Some attribution vendors offer this as a "cookieless measurement" solution.
In the EU, this approach has a specific legal problem. The ePrivacy Directive 2002/58/EC, Article 5(3), requires consent for accessing or storing information on a user's terminal equipment. The EDPB's position, repeated in several supervisory authority decisions since 2022, is that fingerprinting falls within Article 5(3)'s scope regardless of whether the identifier is technically a "cookie". The Austrian DSB, the French CNIL, and the Italian Garante have each issued enforcement actions on fingerprinting without consent. The "we don't use cookies, we use fingerprinting" claim is not a compliance argument; it is the argument that invites closer scrutiny.
Even outside the legal exposure, probabilistic fingerprinting degrades in accuracy as browser entropy decreases. Modern privacy-focused browsers actively lower entropy by normalising canvas output and limiting the resolution of timing APIs. The signal quality drops precisely in the population — privacy-conscious, iOS-heavy — where you most need accurate measurement.
Cross-device stitching via CRM is the remaining gap. For users who convert on a different device than they clicked on, deterministic email matching is the only approach that works. If the user is logged in on both devices, the user ID is the link. If they are not logged in, the click ID on device A and the conversion on device B cannot be connected without the user voluntarily providing an identifier (email, phone) that you can hash and match. This gap cannot be closed server-side. It is a real attribution limit in the cookieless world.
The compliance overlay#
The framing of "cookieless attribution" can mislead people into thinking that because no cookie is being set, no consent is required. That is not what the law says.
The ePrivacy Directive 2002/58/EC, Article 5(3), applies to any storage or access of information on a user's terminal equipment — not just cookies. A first-party cookie set for analytics purposes requires the same consent as a third-party cookie set for tracking purposes, if that cookie is non-essential. The server-set click ID cookie described above is analytics-adjacent; it may or may not require consent depending on your controller's assessment of purpose and the applicable national implementation of the Directive.
What the server-side approach does do — and this is its real compliance advantage — is shift the processing off the user's device and onto the server. The click event log, the conversion event forward, the identity stitch: these happen in your back-end and Elido's back-end, not in a browser script. That means ad blockers do not intercept them, browser privacy features do not partition them, and the data minimisation posture is controllable by you rather than dependent on what a third-party tag decides to send.
The GDPR lawful basis question is separate from the ePrivacy question. Even with server-side attribution, you need a lawful basis under GDPR Article 6 for processing click data on identifiable EU subjects. For campaign-level analytics, most controllers ground this in legitimate interest under Article 6(1)(f) after a Legitimate Interest Assessment. For individual-level profiling or retargeting, the basis is harder. The GDPR for URL shorteners cornerstone covers the Article 6, 28, and 30 analysis in detail; the summary here is that cookieless ≠ consentless, and the compliance overlay does not disappear because the storage mechanism changed.
Elido's click-event defaults reflect a data minimisation posture: IPs are truncated to /24 (IPv4) before persisting, full user-agent strings are parsed and dropped. The full resolution data is available per-workspace if your use case requires it, but the default is the conservative setting. That matters for the DPA addendum conversation with your buyers. For more on that conversation, solutions/marketers covers the procurement touchpoints for marketing teams.
What you give up#
The honest accounting matters. Cookieless server-side attribution recovers most of the signal lost to browser-side degradation, but it does not recover all of it.
Real-time cross-device identity. As noted above: if a user clicks on mobile and converts on desktop without a login event linking the two, the attribution is lost. There is no compliant server-side fix for this. The gap is structural.
Precise view-through attribution. View-through attribution — crediting a campaign for a conversion that followed an ad impression, not a click — requires the ad platform to have matched the user across both events. Server-side conversion APIs handle click-based attribution well; view-through depends on the platform's own cross-device graph, which itself degrades in proportion to signal loss. Expect view-through reporting to be noisier and less reliable than click-based numbers.
Long lookback windows. Most server-side conversion API endpoints impose a lookback cap on how far back in time a click can be attributed to a conversion. Meta CAPI's standard lookback is 7 days for click-through. GA4's Measurement Protocol has an attribution window that varies by channel. These caps are shorter than the 28-day or 90-day windows some teams used in the cookie-based world. Subscription products and considered purchases with long research cycles will see more conversions fall outside the attributable window.
Last-click dominance. Without a multi-touch identity graph, server-side attribution defaults to last-click — the most recent click ID in the chain gets credit. For brand awareness campaigns that drive assisted conversions over a long period, last-click server-side attribution will systematically undervalue upper-funnel spend. The mitigation is CRM stitching via hashed email: if every logged-in user's email is on every conversion event, you can reconstruct a multi-touch sequence for the logged-in portion of your audience. For anonymous users, last-click is the ceiling.
A practical stack#
Given the constraints above, here is the attribution stack that works for a performance-marketing team running EU traffic in 2026.
Short-link click ID as the entry point. All ad destinations are branded short links on your domain. The redirect sets a server-side first-party cookie and appends the click ID to the destination URL. This gives you a persistent, server-set identifier that survives ITP and cookie partitioning for the session.
Cart and order plumbing. The click ID is written to a cart attribute on page load (from the URL parameter or the first-party cookie). On order creation, the click ID is on the order's custom attributes. This is the durable handoff — once the click ID is on the order, it does not expire.
Server-side CAPI to Meta. On order paid, your back-end (or the conversion forwarding feature) POSTs to Meta CAPI with the click ID, the SHA-256 hashed email, and the fbc/fbp identifiers from the first-party cookies. The event_id is the order ID, matching the browser-side pixel. Meta deduplicates within the 48-hour matching window.
Server-side Measurement Protocol to GA4. Simultaneously, a GA4 server-side event is sent with transaction_id equal to the order ID. The client_id is the GA4 _ga cookie value if available, the click ID as a fallback. GA4 deduplicates on transaction_id within the session window.
CRM email-hash stitch. For any conversion where the click ID is missing (organic, direct, brand search), the hashed email address is the attribution signal. This populates the "known-user" segment of your attribution and supports basic multi-touch reconstruction for logged-in customers.
Offline conversion import for long lookback. For subscription products or B2B pipelines where the conversion happens weeks after the click, offline conversion import via the platform's batch API (Meta's Conversions API offline events, Google Ads offline conversions) allows you to send attribution events past the real-time lookback window. The match key is still hashed email or phone; the time window is extended. This does not solve anonymous long-cycle attribution, but it closes the loop for the portion of your audience that provided an email address.
The stack above does not require a CDP. It requires a URL shortener that generates and persists server-side click IDs, a back-end that plumbs the click ID through to the order, and a conversion forwarding layer that handles the hashing and API fan-out. For the technical implementation of the fan-out layer, server-side conversion tracking via short links has the payload shapes, deduplication mechanics, and retry semantics. For where this fits into a full campaign UTM workflow, see solutions/marketers.
The version of this stack that does not work: one that relies on the ad platform's own cross-device graph for identity resolution, hopes that iOS users have App Tracking Transparency enabled in a way that benefits your measurement, or uses probabilistic fingerprinting to fill the gaps. The first is outside your control. The second is wishful. The third is a compliance liability in the EU.
Work with what holds.