Can You Attribute Conversions Without Third-Party Cookies?

Yes. And most of your conversion tracking never used a third-party cookie in the first place.

A cookie is third-party only when the domain that set it differs from the site in the address bar. That single rule decides whether a browser blocks it — not who wrote the script, not where it is hosted, not whose logo is on the dashboard. The pieces attribution actually runs on are all yours: a cookie your own server set, the click ID that arrived in your own landing URL, the email a visitor typed into your own form, and the order sitting in your own back office.

So the useful question is not how to survive without third-party cookies. It is which parts of your measurement were quietly leaning on them, and what replaces those parts. That is an audit, and it takes about twenty minutes.

Which cookies in your stack are actually third-party?

Open your site in a browser, open developer tools, and look at Application → Cookies. The browser groups cookies by the domain that owns them. Every cookie listed under your own domain is first-party, whoever put it there. Every cookie listed under someone else’s domain is third-party in this context.

Run down the list and most marketers get a surprise. The Meta Pixel’s _fbp and _fbc are written on your domain — first-party. Google Analytics’ _ga, your session cookie, your consent cookie, your A/B test cookie: all first-party. The scripts come from someone else’s server, but the cookies belong to you, and a third-party cookie block does not touch them.

What usually shows up under someone else’s domain is narrower than people expect:

• A cookie set by an ad server through an image or iframe request — an ad-network container, a retargeting partner, a DSP pixel.
• The storage of a widget running in an iframe on its own domain: chat, a booking calendar, a form platform’s embed, a review widget.
• A cookie used to recognise the same person across unrelated sites — the whole point of the thing, and the reason browsers are removing it.

That third bullet is the one that matters. Everything third-party cookies did for measurement reduces to recognition across sites you do not own. This is the stack-level version of first-party attribution: not a definition, a list of cookie domains you can check right now.

How do you find out what breaks before it breaks?

You do not have to speculate, because a large share of your traffic is already running the experiment. Safari and Firefox block third-party cookies by default, and Safari’s tracking prevention also caps how long a cookie written by JavaScript survives — seven days for a script-written cookie, which is why so many tools “forget” Safari visitors within a week even though the cookie is first-party.

Two tests, in order.

Test one: segment your own reports by browser. Compare Safari and Chrome on the metrics that depend on recognition rather than behaviour — returning-visitor share, multi-session journeys, the share of conversions that read as Direct. People do not shop differently on Safari. If Safari’s returning-visitor rate collapses or its Direct share balloons, that is your measurement failing on the browser that already enforces the strictest rules.

Test two: run your own funnel with third-party cookies blocked. Turn the setting on, click one of your own ads, fill the form, buy the thing, then look for that conversion in every system you rely on. Note which ones show it, which show it with no source, and which never saw it. Repeat with an ad blocker on: the two failure modes look identical in a dashboard, but ad blockers break conversion tracking at the network layer rather than the storage layer, and the fixes differ.

Write down what survived: that list is your real measurement stack. Everything else was decoration.

What actually stops working when third-party cookies go?

Four things, and only one of them is usually load-bearing for a lead-gen or ecommerce operator.

View-through attribution. Crediting an impression that nobody clicked requires the ad platform to recognise the same browser on its own site and on yours. Take away the shared cross-site cookie and the join has no key. Deterministic view-through credit does not degrade, it disappears.

The browser-side half of platform matching. When a pixel event fires, the platform resolves it to a person using what arrives in the payload and the identity it already holds. Weaken the browser signals and the payload carries more weight — which is why the parameters you send server-side stopped being optional.

Cross-domain identity between sites you own. Landing page on one domain, checkout on another. Third-party cookies used to make that hand-off free; without them the two domains are strangers until you carry an identifier between them yourself.

Embedded widgets in iframes. A form platform, booking widget or chat tool that keeps its identity on its own domain loses that identity when its storage is blocked or partitioned. This is why an iframe embed so often produces leads labelled Direct: the frame cannot see the parent page’s URL and its own cookies are no longer trustworthy.

Retargeting audiences also erode, but that is targeting, not measurement. Losing the ability to reach someone is a media problem; losing the ability to count them is what this article is about, and the two get muddled constantly.

What replaces each piece if you only use your own domain?

Four jobs, four replacements. Every one of them lives on infrastructure you already control.

Recognise a returning visitor. Use a first-party ID cookie that your server sets in the HTTP response, not one written by document.cookie from a script. The distinction is not cosmetic: script-written cookies are the ones Safari’s tracking prevention caps; a server-set cookie is treated as ordinary site state and survives far longer.

Know where they came from. Capture the click ID and UTM parameters from the landing URL on the first pageview and store them server-side against that visitor ID. The click ID is the highest-value identifier in the chain — the only one tying a visit to a specific ad click — so it is worth knowing the difference between gclid, fbclid and UTM parameters before deciding what to store. Grab it at first touch; it will not be in the URL again.

Know who they are. The email or phone number a visitor types is the only identifier that crosses browsers, devices and cookie deletions, and the one that joins a purchase made three weeks later back to the click that started it. Getting from several anonymous sessions to one person is a discipline of its own — visitor identity resolution is the layer that does it.

Know what they bought. Take the order from your store or payment processor’s webhook, server-to-server, rather than from a browser request on a thank-you page. The browser is the least reliable participant in the entire transaction and always has been.

Then there is delivery. Once you hold those four signals server-side, send the conversion from your server to the ad platform’s API instead of hoping a browser request completes — which is what the Conversions API is for on Meta, with equivalents on Google, Pinterest, TikTok and Microsoft. Nothing in that path touches a third-party cookie.

How do you carry attribution across two domains you own?

By putting the identifier in the link, or by re-identifying the person at the destination.

Link decoration is the mechanical option: when a visitor moves from yourbrand.com to yourcheckout.com, append your visitor ID or the original click ID to the URL, read it at the destination, and write it into that domain’s own first-party cookie. Third-party cookies simply hid the need for this. Browsers increasingly treat link decoration as a tracking signal and some limit what a destination may persist from a decorated URL, so test the hand-off on Safari rather than assuming Chrome’s result holds.

Re-identification is sturdier. If the visitor supplies an email or phone on either side of the hop, you can join the two sessions on that instead of on any cookie. It survives link stripping, cookie clearing and a device switch, because the join key is a person rather than a browser.

Most durable setups use both: decoration when it works, identity when it does not.

What can’t you measure at all without third-party cookies?

Two things, honestly.

Deterministic view-through credit. If nobody clicked, nothing arrived in your URL, and no cookie spans both sites, there is no chain of evidence connecting the impression to the sale. You can estimate its value with a geo or audience holdout test — run the channel in one region, withhold it in a matched region, compare total conversions — but you cannot attribute an individual sale to an individual impression. Platform-reported view-through numbers are the platform’s model, not a measurement you can audit.

Anonymous cross-device journeys. A visitor who browses on a phone, buys on a laptop and never gives you an email on either is two separate people in any honest system. This is a matching problem, not a cookie problem, which is why tracking leads across devices depends on the person handing you an identifier somewhere in the journey.

One more, because it causes more arguments than either: your numbers will never fully agree with the ad platform’s. You count conversions you can prove; the platform counts conversions it can model, over its own window, including views you cannot see. Two methods, two numbers — the gap is not a bug in your setup. Decide on the one you can audit.

How does PartialLeads attribute conversions without third-party cookies?

By holding all four of those signals on the merchant’s own infrastructure, then dispatching server-side. Nothing in the path depends on a cookie from a domain the visitor never visited.

The visitor ID (pl_vid) is stored in localStorage with a first-party cookie backup on a one-year TTL, and the cookie is set by the server, not written by the script — precisely the case Safari’s seven-day script-cookie cap does not apply to. Returning visitors stay recognisable on the strictest browsers.

Attribution is captured at first touch: UTMs from the landing URL with a document.referrer fallback, plus every click ID the major platforms use — gclid, gbraid, wbraid, fbclid, msclkid, ttclid and epik. For the iframe problem above, the tag relays attribution across frame boundaries with postMessage, so a form embedded from another platform resolves to the campaign that paid for the visit instead of landing in Direct.

Identity comes from what the visitor typed. Email and phone are captured as they are entered rather than on submit, normalised server-side (phone to E.164, with a country fallback from session geo), and used to union a person’s sessions across six tiers — visitor ID, email, phone, IP and user-agent, device fingerprint, and shared click ID. A visit-sibling rule heals a converting session that lost its source by inheriting attribution from a sibling session in the same visit.

Purchases arrive server-to-server from Shopify, WooCommerce, GoHighLevel, Stripe or a universal webhook, get matched to a session by visitor ID, email, phone or IP in that order of confidence, and write both a first-touch and a last-touch attribution row. The conversion then fans out to Meta, Pinterest, TikTok, Google Ads and Microsoft server-side, with a deterministic event_id and unique dedup tables so a retried delivery physically cannot double-count.

Two honest constraints. First, server-side match quality still improves when the platform’s own first-party cookie was captured in the browser — _fbc is reconstructed from a URL fbclid when the cookie is missing, but _fbp is not synthesised from nothing, so keep your base pixel. Second, PartialLeads controls dispatch, not matching: every order in your store admin produces a conversion event, but whether the platform resolves it to a user depends on its own graph, consent and opt-out state.

Sources

• https://developers.facebook.com/docs/marketing-api/conversions-api/
• https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/customer-information-parameters
• https://developers.facebook.com/docs/marketing-api/conversions-api/deduplicate-pixel-and-server-events