Six ways tracking breaks, and how to check each one
Tracking doesn't fail in unlimited ways. It fails in about six, and each one has a fingerprint. Here are the six, and the check to run if you only have time for one.

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 hole | What breaks | The fix |
|---|---|---|
| Safari ITP | The cookie expires and a returning visitor looks new | An event path that doesn't depend on the browser |
| Ad blockers | The script never runs, so no event is written | Server-side sending |
| Bots | Non-human sessions inflate the denominator | Session classification: human or bot |
| Relay emails | One person splits into two profiles | Identity keys that don't rest on email alone |
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.
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.
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.
Those fixes work at different layers, which is the practical case for treating measurement as layers rather than as a feature:
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.
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.
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 doesn't fail in unlimited ways. It fails in about six, and each one has a fingerprint. Here are the six, and the check to run if you only have time for one.

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.

The score a platform gives you counts how many identifiers arrived with the event. Here's what it actually counts, three common objections to it, and what genuinely raises it.