Cookieless Conversion Tracking: How It Works

Say your ads dashboard shows 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 cookies set by a tracking script and on 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 a long time, 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 and lands on your site. The ad platform's script, loaded on your page, saves a cookie in their browser, 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 written by the ad platform's script, and the pixel is a script loaded from the platform's 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 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 and Firefox block third-party cookies by default, and in Chrome people can switch them off with one setting, so the old cross-site handoff is unreliable everywhere. Safari also limits cookies written by scripts to seven days, and to 24 hours after a click that carries a tracking ID. Depending on how much of your audience is on iPhones, that alone can blind you to a large share 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. How many of your visitors run one depends on your audience; a developer-tools company and a gardening shop live in different worlds here.

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.

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 can be the largest single leak.

These causes overlap, so you can't simply add them up, and nobody can give you one number that fits every site. What you can say is that a real share of conversions is invisible to cookie-based tracking, and the size of that share depends on your audience. 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

In the old model, a click on your ad was the cue for the platform's script to leave a cookie in the visitor's browser, 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 it is much harder to remove quietly. 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 example.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, but a query parameter is simply part of the page address, so there is nothing to refuse. 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 an identifier, the same mechanism ad platforms have always used with their own parameters, except this one belongs to you. Some browsers do strip well-known ad-platform parameters; those lists target the platform names, not a parameter your own link adds. 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 can survive 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. The browser's role ended the moment the page loaded. Whether privacy law asks for consent for the data you collect is a separate legal question, so check it with your own advisers.

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

Now 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.

Once a conversion is recorded, you can also subscribe to conversion events by webhook so your own systems hear about it as it lands. Events are queued and normally arrive within a few seconds, not instantly. That's 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. Your own server can send the same purchase to an ad platform's server-side interface, such as Meta's Conversions API, so the platform can learn from purchases its own pixel never saw. The measurement gap that was quietly mis-training your bidding starts to close from both ends: you see a number closer to the real one, and the platform optimizes 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, and the server carries the conversion out. One request, and the dashboard gets much closer to the order system. If you want to see the pieces wired together with GA4 and ad platforms, the post on connecting link data to GA4 and ad platforms compares server-side and client-side setups.

What accuracy to expect, honestly

So you set this up, and the numbers climb. In our example, 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 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. Say you capture 90% of conversions today. That share should move far less from quarter to quarter than cookie-based tracking does, so a sharp drop is more likely to be real. 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.