Cookieless attribution works if you stop asking the browser to remember the click. Log the click on a server, carry an identifier in the URL, store it on your own order record, and send the conversion server to server. Everything else is degraded or legally risky in the EU. That covers third-party cookies, script-set cookies that expire in days, and fingerprinting.
The stack most teams built between 2012 and 2019 depended on a third-party cookie dropped on the landing page and a pixel that matched it on the conversion page. For the basics of the term, see what marketing attribution is. This post is a map of what survives, what Elido covers today, and where you need your own back-end.
TL;DR
- Safari caps script-written cookies and storage at 7 days of inactivity, and at 24 hours for cookies created on a link-decorated landing page. Chrome still allows third-party cookies, with user choice. Treat them as unreliable either way.
- Two paths hold: a click or link ID passed through to your order record and sent server to server, and server-set first-party cookies.
- Cookieless is not consentless. ePrivacy Article 5(3) reaches fingerprinting and local storage, and GDPR still needs a lawful basis for server-side processing.
- Elido logs clicks server-side and ties Stripe and Shopify revenue to links. It doesn't generate click IDs or forward conversions to ad platforms yet.
What changed in browsers
Three sources give the current picture, all accessed 2026-10-24.
WebKit's tracking prevention page says Safari deletes cookies created in JavaScript, and other script-writeable storage, after 7 days without user interaction on the site. It also says that when a click ID is detected in the landing URL, the expiry of JavaScript-created cookies on that page is capped at 24 hours. ITP 2.3, published September 23, 2019, extended similar limits to other script-writeable data. Cookies set in an HTTP response header by your own first-party host are not capped by these rules. The exception is a cloaked third-party host such as a CNAME or IP-cloaked subdomain, where WebKit caps the expiry at 7 days.
Firefox partitions third-party cookies by top-level site through Total Cookie Protection. A cookie set by a tracker on your checkout and on a competitor's checkout becomes two separate cookies.
Chrome never completed the phase-out. On April 22, 2025 Google announced it would not roll out a standalone third-party cookie prompt and that users keep choosing in settings. The Privacy Sandbox blog adds that some Privacy Sandbox technologies are being phased out. So the practical question is no longer "when do cookies die" but "which share of my audience blocks them", and I can't give you an honest EU-wide percentage. Check your own analytics by browser.
One more claim you'll see in vendor decks: that Safari's Link Tracking Protection strips click IDs such as fbclid or gclid in private browsing and Mail. WebKit's tracking prevention page didn't mention it when I fetched it, so I'm not repeating a parameter list here. Test your own landing pages in those contexts before you rely on a click ID surviving.
The two paths that still work
Both start from the same fact: a server sees the click before the browser's storage rules apply.
Path 1: server-side identifiers
When a user clicks an ad, the platform appends a click identifier to the landing URL, such as fbclid for Meta or gclid for Google. The identifier lives in the URL, so cookie partitioning doesn't touch it. Your landing page reads it and stores it on the cart or order. When the order is paid, your back-end reads it off the order and sends the conversion to the platform's server-side API, such as Meta's Conversions API or the GA4 Measurement Protocol.
Deduplication matters if you also keep the browser pixel. Meta's docs say a Pixel eventID must match the Conversions API event_id, with the same event name, and that duplicates received within 48 hours are discarded. Use the order ID for purchases. For which customer fields must be hashed, read Meta's customer information parameters page; I didn't verify those rules for this post.
The weak points are real. Clearing cookies loses a cookie-stored ID. A conversion on another device has no link unless the person is logged in. The click ID can also vanish before the landing page sees it.
Path 2: a redirect you control
A redirect on your own domain is a server-side event. When someone clicks a branded short link, the redirect host can write a click record at that moment, with timestamp, referrer and user agent, instead of waiting for a page-load tag to fire. If you also set a cookie, set it in the Set-Cookie header on a first-party host. That avoids the script-written 7-day and 24-hour limits above.
A pixel can't replicate that. It is also where Elido's current scope ends.
What Elido does today, checked against the code
I checked every claim this post used to make against the services. Here is the result.
| Capability | Status |
|---|---|
| Server-side click log written when the redirect is served | Yes |
Click forwarding to GA4 (link_click event), Mixpanel, Klaviyo, Brevo and Datadog | Yes, per-workspace integrations |
| Server-side Meta and TikTok events on click | No |
Stripe and Shopify orders matched to a link via elido_link_id | Yes |
| Revenue by link, campaign, day and platform | Yes |
elido_click ID appended to the destination URL | No |
| First-party cookie set by the redirect | No |
Public conversions API (POST /v1/conversions) | No |
Conversion forwarding to Meta CAPI or GA4 with hashing and event_id | No |
The honest version of "a short link as the attribution surface" is narrower than this post used to say. The redirect gives you a click record and per-link reporting. To close the loop on revenue, put the link's ID in the order: elido_link_id in Stripe metadata, or a elido_link_id note attribute on a Shopify cart. When the order webhook arrives, Elido attributes the revenue to that link. Anything beyond that, such as hashing an email and calling Meta's API, is code in your back-end today. For how that fan-out is built, see server-side conversion tracking via short links, and for the Safari-specific angle, click attribution after Safari ITP. The conversion tracking feature page describes the dashboard side.
Identity stitching: what works and what doesn't
Server-side IDs cover the common case. One person, one device, one session, no stripped parameters. The rest needs an identifier the person gave you.
Deterministic matching works. If someone logs in or enters an email at any point, you can send a hashed email with the conversion as a matching signal. Hashing has to follow the platform's rules for normalisation, so read the vendor's page before you build it.
Probabilistic fingerprinting, on the other hand, is the wrong fallback in the EU. It combines screen size, fonts, timezone, canvas output and similar signals into an identifier without a cookie. Whether that needs consent is a legal question, and Article 5(3) of the ePrivacy Directive applies to accessing information on a user's device, not only to cookies. The EUR-Lex page didn't load for me on 2026-10-24, so I'm paraphrasing from the Directive's well-known scope and not quoting it. I'm also not naming specific regulators' decisions here. Privacy-focused browsers keep cutting the entropy these methods rely on. Accuracy drops where you need it most.
Cross-device is the gap you can't close server-side. A click on a phone and a purchase on a laptop connect only if the person identifies themselves on both.
Consent still applies
"No cookie, no consent" is a common misreading. Article 5(3) is about the device, so any storage or access there needs consent unless it is strictly necessary. A cookie set for analytics is not strictly necessary because it is first-party.
Server-side processing changes where the data flows. Ad blockers and partitioning don't touch it, and you control what leaves your back-end. It still needs a GDPR lawful basis under Article 6, usually legitimate interest for campaign-level analytics after an assessment, and harder for individual-level profiling. The GDPR for URL shorteners guide covers Articles 6, 28 and 30, and cookie consent for short links covers the banner question.
On IP handling, Elido truncates the visitor IP at the edge (IPv4 to /24, IPv6 to /48) before the click is stored. Country, region, city and approximate coordinates are derived first and kept with the click, and the full user agent is stored, so treat the click row as personal data. If minimisation matters for your DPA, ask for the current retention and IP handling in writing.
What you give up
Server-side attribution recovers most of the lost signal, not all of it.
Cross-device identity goes first: it is lost unless the person logs in.
View-through attribution suffers next. It depends on the ad platform matching an impression to a later conversion across its own device graph. Expect noisier numbers than click-based reports.
Long lookback windows shrink. Each platform sets its own attribution windows, and they can be shorter than the 28 or 90 days some teams used with cookies. Check the current window for each platform you report on. Subscriptions and B2B cycles lose the most.
Multi-touch for anonymous users is the last casualty. Without an identity graph you default to last click. Hashed email for logged-in users lets you rebuild sequences for that slice of your audience, using the rules-based models that fit your data.
A practical stack
For a team running paid traffic into the EU, this is what I'd build with what exists today.
- Branded short links for email, SMS, QR codes and organic posts. You get a server-side click record and per-link reporting from the start. Keep ads pointed at the landing URL itself: Elido drops query parameters added to a short link, so an ad's
fbclidorgclidwould not survive the redirect (pass-through is planned, not available yet). - Capture the platform click ID on landing (
fbclid,gclid) and write it to the cart or order. Test that it survives on iOS Mail and private tabs before you trust it. - Put
elido_link_idin Stripe metadata or Shopify note attributes so revenue reports by link without any cookie. - Send purchases server to server from your back-end to Meta and GA4, with the order ID as the dedup key.
- Hash email for logged-in users to cover cross-device and fill gaps where the click ID is missing.
- Import offline conversions in batch for long B2B or subscription cycles, using the platform's offline API.
None of this needs a CDP. It needs a click log you trust, an identifier on your order, and a back-end that talks to the ad platforms.
Related on the Blog
Frequently asked questions
What is cookieless attribution?
Cookieless attribution ties a conversion to the click or campaign that caused it without relying on a third-party cookie. In practice that means a server-side click log, a click or link ID carried in the URL and then stored on your own order record, and server-to-server calls to ad platforms. It recovers most of what browser pixels lose, but not cross-device journeys or long lookback windows.
Are third-party cookies gone in Chrome?
No. On April 22, 2025 Google said it would not roll out a new standalone prompt for third-party cookies in Chrome, and that users keep choosing in Chrome's privacy settings (Privacy Sandbox blog, accessed 2026-10-24). Safari and Firefox already restrict them by default, which is why attribution built on them is unreliable for a large part of your traffic regardless of Chrome.
Does going cookieless remove the need for consent in the EU?
No. Article 5(3) of the ePrivacy Directive covers storing or accessing information on a user's device, not only cookies, so fingerprinting and local storage are in scope too. Purely server-side processing sits outside Article 5(3) but still needs a GDPR lawful basis. Ask your own counsel which applies to your setup.
Is a first-party cookie set by my server safe from Safari's limits?
Mostly. WebKit's tracking prevention page says cookies and storage created in JavaScript are deleted after 7 days without user interaction, and that a cookie set from a link-decorated landing page by script lasts 24 hours. Cookies set in an HTTP response header on your own first-party host are not capped by those rules, with an exception for cloaked third-party hosts, which get a 7-day cap.
Can a URL shortener do cookieless attribution?
It can supply the first half: a server-side click record written when the redirect is served, before any browser-side privacy feature runs, plus per-link and per-campaign reporting. Elido also matches Stripe and Shopify orders to a link through an elido_link_id value you put in the order metadata. It doesn't yet generate click IDs or forward conversions to Meta or GA4, so those steps run in your own back-end.
What can't cookieless attribution recover?
Cross-device journeys where the person never identifies themselves, view-through conversions that depend on an ad platform's own device graph, and clicks older than the platform's lookback window. Hashed email from logged-in users closes part of the gap. For anonymous visitors, last click is the ceiling.
Try Elido
Paste a URL, get a working short link
No signup. Link lives for 30 days. Sign up to keep it forever.
No signup needed. Sign up free for 50 links a month.