Category: Tiide intelligence | Reading time: 5 min
If you’ve just set up server-side tracking – or you’re looking at a dashboard that mentions recovered events – you might be wondering what exactly that means. Are these new conversions? Did something change on your website? Is the number real?
The short answer: recovered events are real conversions that were always happening. You just couldn’t see them before.
Here’s what’s actually going on.
What is a recovered event?
A recovered event is a conversion – a purchase, a lead form submission, an add to cart, any action you’re tracking – that was completed by a real visitor but never made it to Google or Meta under your previous tracking setup.
Not because the conversion didn’t happen. Because the signal that was supposed to report it got intercepted before it arrived.
Under traditional client-side tracking, that signal is sent from inside the visitor’s browser. Ad blockers catch it. Safari’s privacy restrictions interfere with it. Privacy settings limit it. The visitor completes the action, your site registers it, but the tracking pixel never fires – and the platforms never find out.
Server-side tracking routes that signal through your own server instead. When an event that would have previously been lost is successfully captured and delivered via the server-side route, that’s a recovered event.
Where do they come from?
Recovered events come from the visitors your pixel was failing on. Specifically:
Ad blocker users. Browser extensions like uBlock Origin identify tracking pixels by their source domain and block them from loading entirely. When the pixel can’t load, no event fires. These visitors can browse your site, add items to their cart and complete a purchase without a single event reaching your ad platforms. Server-side tracking uses your own domain rather than a third-party one, which means it isn’t on any block list.
Safari and iPhone users. Apple’s Intelligent Tracking Prevention caps the lifespan of cookies set via JavaScript – the mechanism most client-side tracking relies on – at seven days. For any visitor whose purchase journey spans more than a week, the attribution trail goes cold before they convert. Server-side tracking uses longer-lived, server-set identifiers that aren’t subject to the same restrictions.
Privacy-mode browsers. Browsers like Firefox with Enhanced Tracking Protection, or any browser in private/incognito mode, apply additional restrictions that degrade client-side tracking further. Server-side collection is largely unaffected.
In each case, the visitor was real, the conversion was real, and the revenue was real. The only thing that was missing was the record of it.
Why does the number sometimes look surprisingly high?
When businesses first implement server-side tracking and see their recovered event count, the reaction is often surprising. Sometimes the number is 10% of total conversions. Sometimes it’s 35%. It might even be higher.
This can feel alarming – as if something was broken, or as if the new numbers can’t be trusted. But it reflects something straightforward: the gap between what was happening and what was being measured.
The size of the gap depends on your audience. If your customers skew toward iPhone users, Safari, younger demographics or technically sophisticated buyers, your recovered event count will be higher. If your audience is predominantly desktop Chrome users in markets with lower ad blocker adoption, it will be lower.
Neither is a problem with your tracking. It’s just a reflection of who your customers are and how they browse.
What recovered events mean for your campaigns
Recovered events aren’t just a reporting improvement. They have real consequences for how your campaigns perform.
Bidding gets smarter. Google’s Smart Bidding and Meta’s Advantage+ both learn from conversion signals. When those signals are incomplete, the algorithms make decisions based on a partial picture – potentially underbidding on high-value audiences or misallocating budget toward segments that look productive on incomplete data. Recovered events give the algorithm a more complete dataset to learn from, which improves the quality of its decisions over time.
Attribution gets clearer. Events that previously dropped out of the attribution path – because a cookie expired before the conversion or because an ad blocker prevented the click event from firing – now resolve correctly. Channels and campaigns that appeared to underperform may show their true contribution once the missing events are restored.
Reported CPA drops. More conversions counted against the same spend means your cost per acquisition figures improve. This isn’t a change in business performance – it’s a change in measurement accuracy. Your true CPA was always lower than your reported CPA. Now they’re closer to each other.
Creative decisions become more reliable. If you’ve ever paused a campaign or replaced creative based on conversion data that was incomplete, you may have made the wrong call. Recovered events fill in the picture, so future decisions about what to run, what to cut, and what to scale are based on evidence rather than a partial view.
Are recovered events double-counted?
No – and this is worth being clear about, because it’s a common concern.
Server-side tracking runs alongside your existing client-side pixel, not instead of it. When both channels capture the same event, deduplication logic identifies the overlap using a shared event ID and counts it once. Recovered events are specifically the events that the pixel missed – the ones the server-side layer captured that the browser-side layer didn’t.
The result is more complete data, not inflated data.
How to see your recovered events in Tiide
Tiide’s dashboard shows you recovered events in real time – broken down by platform, event type and time period. You can see exactly how many purchase events, lead events or custom conversions were captured server-side that would have otherwise been lost.
This makes the value of server-side tracking concrete and visible, rather than abstract. It’s also a useful thing to show clients or stakeholders who want to understand what changed after implementation – the recovered event count is the clearest possible illustration of what was missing before.
The bottom line
Recovered events are not new conversions. They are not fabricated results. They are the conversions that were always happening – completed by real visitors, generating real revenue – that your previous tracking infrastructure was failing to capture and report.
Getting them counted doesn’t change your business. It changes your understanding of it. And that understanding is what every campaign decision, budget allocation and performance conversation should be built on.
