Conversion Tracking Without Third-Party Cookies

Your ads dashboard says the campaign drove 40 conversions this month. Your order system says 63 people bought after clicking that campaign's links. You've checked the date ranges twice, refreshed both screens, and the gap won't close.

So which number is wrong? Neither, really. The 63 is what happened. The 40 is what the tracking managed to see. Somewhere between the click and the purchase, 23 conversions passed through a blind spot, and the dashboard reported the ones it could witness as if they were the whole story. No error message, no warning banner, nothing that looks broken, which is what makes this problem so easy to live with for months.

Undercounting is invisible by definition.

The blind spots have a common cause. Most conversion tracking still leans on third-party cookies and pixel scripts, and browsers, ad blockers, and consent rules have spent the last few years quietly dismantling both. The rest of this page walks through where exactly those conversions vanish, and how moving the tracking into the link itself, with the conversion reported server-to-server, gets most of them back. If you're newer to how clicks get measured at all, the complete link tracking guide covers the full journey from click to attributed revenue; this page goes deep on the conversion half.

How cookie-based conversion tracking worked

For about fifteen years, the answer to "did that ad click turn into a sale?" was a small file sitting in someone's browser. A person clicks your ad. The ad platform drops a cookie on their browser as they pass through, and that cookie carries an ID tying this browser to that click. Days later, the same person lands on your order confirmation page, where a pixel script (a snippet of the ad platform's JavaScript) wakes up, reads the cookie, and reports that the click from Tuesday just bought something. Attribution done, dashboard updated, budget justified.

The clever part was that nobody had to build anything. You pasted one script onto your thank-you page, and the ad platform handled the rest. The cookie was the memory, the pixel was the messenger, and neither one asked anything of your own systems. Your order database never even knew tracking was happening.

Notice, though, what the whole arrangement depends on. The cookie is set by the ad platform's domain, not yours, which makes it a third-party cookie in the browser's eyes. And the pixel is a script loaded from that same outside domain, running in a browser you don't control. Two links in the chain, both living entirely on someone else's turf.

That was fine as long as browsers treated all cookies the same and let every script load. Neither is true anymore. The cookie gets blocked or expired at one end, the pixel gets stripped at the other, and when either link fails, the conversion still happens. Someone still buys. The sale just arrives with no history attached, and the ad platform quietly counts it as nothing.

The mechanism didn't degrade gracefully. It fails silently, one blocked cookie at a time, which is exactly why the gap crept up on so many teams without anyone deciding anything.

Where the conversions disappear

Picture the path a single conversion has to survive. Someone taps your ad on their phone, browses for a minute, comes back that evening on the same device, and buys. For the ads dashboard to count that sale, a third-party cookie had to be set, kept alive all day, and then read by a pixel script that actually loaded on the purchase page. Every one of those steps now has something standing in its way, and each obstacle takes its own bite.

The biggest bite is the browser itself. Safari has blocked third-party cookies outright for years, Firefox does the same, and Chrome caps and partitions them enough that the old cross-site handoff is unreliable there too. Depending on how much of your audience is on iPhones, that alone can blind you to 15–30% of conversions. The cookie was never set. There was nothing for the pixel to find.

Then come ad blockers, which don't bother with the cookie at all. They stop the pixel script from loading in the first place, so even a user whose browser would happily carry the cookie reports nothing. Blocker usage runs somewhere around 25–40% of users depending on your audience; a developer-tools company and a gardening shop live in different worlds here. Call it another 5–15% gone, on top of the browser losses.

Consent banners take their share too. In regions where tracking needs opt-in, some meaningful slice of visitors clicks "reject all", and a correctly configured banner then suppresses the pixel entirely. These people convert, they're just legally invisible. Another 5–10% in consent-heavy markets.

The quiet one is in-app browsers. Someone taps your ad inside Instagram or TikTok, and the app opens its own embedded browser with its own isolated cookie jar. If they later finish the purchase in Safari proper, the cookie that recorded the click is sitting in a jar the purchase page can never see. For campaigns that live on social, this is often the largest single leak.

These causes overlap, so you can't just add the percentages. But the honest range, once you stack them, is that 20–40% of real conversions are invisible to cookie-based tracking. That's not a misconfiguration you can hunt down and fix. It's the normal operating condition now, which is also why your click counts, sessions, and ad platform numbers never quite agree with each other. The dashboard showing 40 when the order system says 63 isn't lying. It's counting what it can still see.

First-party tracking: moving the ID into the link

Picture the moment someone clicks your ad. In the old model, that click was the cue for a third party to reach into the visitor's browser and leave a cookie behind, a little note saying "this person came from campaign X." Everything downstream depended on that note surviving until the purchase, and on a script being allowed to read it back. Both of those are exactly the steps browsers and blockers now interfere with.

First-party tracking sidesteps the whole fragile arrangement by putting the identifier in the URL itself, where nobody can quietly delete it. When someone clicks your tracking link, the redirect appends a unique click ID to the destination address as _actu_clid, so the visitor lands on yoursite.com/pricing?_actu_clid=6f1c2d4a-9b3e-4c17-8a52-0d7e5f1b9c33. That parameter travels with the visitor as part of the page request, the same way any query string does. No cookie gets set by a foreign domain, because no foreign domain is involved. Your link, your ID, your destination.

And that changes what can go wrong. A browser can refuse third-party cookies all day long; it can't refuse a query parameter, because query parameters are just part of how the web addresses pages. An ad blocker can strip a tracking pixel from the purchase page, but there's no pixel to strip here. Nothing on the page needs to phone home. The visitor's browser isn't being asked to remember anything or run anything. It's just loading a URL that happens to carry a short identifier, the same mechanism ad platforms have always used with their own parameters, except this one belongs to you. If you've ever squinted at a gclid or fbclid glued to your URLs, you already know the shape of this — what click IDs actually do is worth understanding, because the first-party version survives precisely where the platform versions get stripped.

The second half is how the conversion gets reported. Your site stores that click ID when the visitor arrives, usually alongside the session or the eventual order. When the purchase happens, your server tells the tracking system about it directly, machine to machine, carrying the click ID as proof of which click earned the sale. That conversation happens between two servers, far away from any browser, which means there is nothing for a content blocker to intercept and no consent-banner script to suppress. The browser's role ended the moment the page loaded.

So the click ID rides in on the link, waits quietly in your order data, and comes back over a channel no browser extension can touch. The next section walks through what that server-to-server report actually looks like in practice.

Server-side reporting: closing the loop

Picture the moment the order comes in. Someone clicked your ad three days ago, wandered off, came back through a bookmark, and finally bought. Your checkout fires, your order lands in the database, and sitting quietly in that order record is the click ID that rode in on the link. Now you have both halves of the story in one place. All that's left is to say so.

Your purchase system makes one server-to-server call to a conversion endpoint with the click ID and the order value. That's the whole report. No browser involved, no script that an ad blocker can strip, no cookie for Safari to expire. Your server talks to ours, and the click that started everything gets matched to the money it produced.

If your checkout platform speaks webhooks instead, same idea in the other direction — you can also subscribe to real-time conversion events so your own systems hear about matches the moment they happen, which is handy when you want conversions flowing into Slack or a warehouse without polling anything.

A one-line HTTP call from code you already control. If your checkout can send an order confirmation email, it can report a conversion. The hard part was never the request; it was having a click ID worth sending, and the previous section already solved that.

And there's a second act. Recording the conversion for your own dashboard is useful, but ad platforms need to hear about it too, because their bidding models learn from conversions and a starved model bids badly. So the same server-side conversion gets forwarded onward through connections to your ad platforms, which means Google and Meta keep learning from purchases their own pixels never saw. The measurement gap that was quietly mis-training your bidding starts to close from both ends: you see the real number, and the platforms optimize against something closer to it.

We built Acturity's conversion tracking around exactly this loop, because the pattern is the same for every team. The link carries the ID in, the server carries the conversion out, and the platforms stay smart. One request, and the dashboard finally agrees with the order system.

What accuracy to expect, honestly

So you set this up, and the numbers climb. The dashboard that used to show 40 conversions against 63 real orders now shows 55, maybe 58. And then you wait for the last few to appear, and they don't.

They won't. First-party tracking closes the gap the blockers opened, but some conversions were never trackable by any link-based method. The person who clicks your ad on their phone during a commute and buys on their laptop that evening arrives with no click ID at all, because the ID lives in the click, and the laptop never clicked anything. Cross-device journeys look like conversions from nowhere. No amount of server-side plumbing changes that, and the same goes for the reader who copies your URL into a fresh private window out of habit, or the strict-consent visitor who declined everything. Those people exist, they buy things, and they stay partly invisible.

Which sounds like bad news until you notice what actually changed. Cookie-based tracking wasn't just incomplete, it was incomplete by a different amount every quarter, shrinking a little more each time a browser update shipped or an ad blocker gained users, with nobody able to say how much was missing this month versus last.

First-party tracking gives you a floor that holds still. If you capture 90% of conversions today, you'll capture roughly 90% next quarter, and a 15% drop in the numbers means a 15% drop in reality, not a Safari release. A stable undercount you can reason about beats a precise-looking number that's quietly rotting.

The click ID also can't settle which touchpoint deserves the credit when a customer clicked three of your links before buying. That's a modeling choice, not a measurement one, and we walk through it in attribution models in plain English. Get the floor solid first. Everything downstream, attribution included, is only as honest as the count it starts from.