Back to blog
Tracking3 min read

Four holes conversion data leaks through, and the fix for each

ITP, ad blockers, bots and relay emails each break tracking in a different place. That's why no single fix closes all of them.
ITP, ad blockers, bots and relay emails each break tracking in a different place. That's why no single fix closes all of them.

Data doesn't leak from one place. It leaks from four holes at once, each with a different cause. That's why "install the pixel properly" never closes the gap.

The easiest way to see it is to put all four side by side:

The holeWhat breaksThe fix
Safari ITPThe cookie expires and a returning visitor looks newAn event path that doesn't depend on the browser
Ad blockersThe script never runs, so no event is writtenServer-side sending
BotsNon-human sessions inflate the denominatorSession classification: human or bot
Relay emailsOne person splits into two profilesIdentity keys that don't rest on email alone

Two of them close with a server path

Safari's ITP shortens the lifetime of first-party cookies. A customer who came from your ad, left, and returned after that window is recorded as a brand new visitor with no source. The loss isn't spread evenly either. It hits iPhone audiences hardest, and that's often the audience with the higher average order value.

Ad blockers don't shorten anything. They stop the tracking script from executing at all, so no event is written and there's nothing to reconcile later.

What doesn't fix them: a longer cookie, a second pixel, or renaming the script and self-hosting it. The browser sets cookie lifetime, not your site, and blocklists match domains and patterns rather than filenames.

What does fix them: taking the order from a path that never touches the browser. Your store's server already knows the order happened, and it can send that straight to the platform.

One closes with session classification

Search crawlers, monitoring tools and scrapers open your pages, view products, and generate events that look like visitor behaviour. Nothing inside the event itself distinguishes them.

The damage runs two ways. The denominator grows, so your conversion rate reads lower than it is, and a specific channel looks busier than it is because part of its activity is automated. Then you make a decision on that picture, cutting a working campaign or chasing a page problem that doesn't exist.

What fixes it: classification at session level, from user agent and device behaviour, so you know what you're looking at before you interpret it.

One closes with the identity model

Sign-in services from Apple and Google can hand your store a relay address instead of the real one, and Apple Private Relay masks the IP as well.

If your identity model rests on email alone, one person becomes two profiles. Their history splits, their lifetime value halves, and the channel that brought them in loses half its credit.

What fixes it: an identity model that treats email as one signal among several, alongside click IDs, phone, your store's customer ID and the order ID, and that excludes relay email patterns from identity keys.

Why the order matters

Those fixes work at different layers, which is the practical case for treating measurement as layers rather than as a feature:

  1. Does the event arrive? Collection
  2. Is it attached to the right person? Identity
  3. Is it counted once? Deduplication
  4. How is credit shared? The attribution model

Most teams start at the fourth. They try last click against first click and get a different number each time. If the first three layers are leaking, changing the model changes the shape of the error without removing it.

In Flowfy, a browser SDK runs alongside a server path fed by your store's webhooks, so an event lost on one side arrives on the other. With it come session classification as human or bot, relay email detection excluded from identity keys, and 14 identifier types resolving into one customer. Failed events are held in a queue instead of dropped. Automatic alerting when events stop is on the roadmap and hasn't shipped; the line between the two today is in the getting started guide.

Questions that come up

Does server-side tracking replace the pixel? No. Run both. The browser sees things the server can't, like a page view or an add-to-cart in a session that didn't convert, and the server sees what the browser was blocked from sending.

If both send the same purchase, won't it count twice? Without deduplication, yes. The two paths need a shared event key so the system knows they're the same purchase and ignores the second copy.

Can I recover data that's already lost? No. Touchpoints aren't reconstructed after the fact. What wasn't recorded is gone.

The first hole to close

Check one hole this week: whether you have an event path independent of the visitor's browser. If you don't, ad blockers and Safari set your accuracy ceiling, and that's the first hole to close. Then move to bots and identity, rather than changing the attribution model while the floor is still leaking.

Tracking

Why a fixed alert threshold produces false alarms

Alert me if events drop below 100 a day is a rule that works for one store, for about a month. A threshold that doesn't know your normal fires when you're fine and stays quiet when you're not.

3 min read