Data Loss

A team that has just started collecting behavioral records treats the totals as fact for a while. If the signup button shows 620 presses, 620 people pressed it. There's no reason yet to separate "records get written" from "all records get written."

The distinction becomes necessary the moment two numbers measure the same thing. The ad platform reports 1,000 clicks on a link while internal analytics counts 620 visits; the payment provider shows 48 approvals while only 41 checkout-completed records exist. Meetings run long over which one is right, and the answer is usually that neither is wrong — one of them is missing a share that never arrived.

Pagedeck had exactly that conversation. The click count on a campaign Ravi was running and the visit count Mia watched were more than 30 percent apart. The first suspicion was that the ad platform inflated its numbers; the second was that Mia's query was off. It was neither. For a slice of the people who clicked, the script that sends the record never ran in their browser at all.

Data loss is the name for that missing share. Once it has a name, teams can measure how much goes missing and read the rest with that in mind.

A record is created on the user's device, crosses the network, reaches the collection server, and gets loaded into storage. Loss can happen at any of those four stages.

1. Blocked before creation. Ad blockers and browser tracking protection stop the collection script from loading at all. This is where the largest share disappears under client-side tracking, which sends records straight from the user's device.
2. Cut off in transit. A user who taps a button and immediately navigates away closes the page before the request finishes, and a phone losing signal underground loses whatever it was sending at that moment.
3. Dropped on arrival. If the collection server stalls briefly or exceeds its limits, an entire window of requests never gets in. With no retry on the sending side, there's nothing to recover from.
4. Filtered during loading. A row whose property values don't match the expected format doesn't pass, and gets set aside in a rejects pile — which is the same as gone if nobody reads the pile.

Two of the four are fixable and two are not. Stages 3 and 4 shrink when you fix the server and the loading rules; stages 1 and 2 happen on the user's device, where the sending side has no way to guarantee delivery.

Stage 4 is the one teams overlook longest, because nothing looks broken. Collection keeps running, the dashboard keeps drawing, and the only trace is a rejects table nobody has opened since it was created. A weekly count of rejected rows costs almost nothing and turns that silent stage into a visible one.

The awkward part isn't that the totals shrink. It's that they don't shrink evenly. Ad blocker usage varies by audience: if 25 percent of desktop browser users run one and app users don't, a table putting the two side by side makes desktop look like the weaker channel. A uniform 20 percent shortfall can be read around. A shortfall concentrated on one group makes the comparison itself wrong.

The term comes up whenever people are working out why two numbers disagree.

1. Reconciling tools. When the ad platform, the payment provider, and internal analytics count the same thing differently, the first question is which side is losing records. Usually it's whichever side sends from the user's device.
2. Reading a funnel analysis, which shows how many people drop out at each step. If loss is concentrated at one step, that step looks like an exit point. A checkout-completed rate that comes in unusually low is more often loss than genuine abandonment.
3. Judging campaign performance. Attribution decides which touchpoint gets credit for a conversion, and when the arrival record is missing, that conversion gets filed as unknown origin. Budget gets cut from channels whose measured performance is lower than their real performance.
4. Deciding what to do about it. Records tied to money move to server-side tracking, which writes the event from the server that handled the request and so can't be blocked. For the rest, measure the loss rate periodically and read around it. Comparing against a reference number like payment approvals gives you the percentage that goes missing.

"Ad clicks and visits are 30 percent apart — could that be loss?"

Checking whether one of the two numbers is missing a share that never arrived.

"We moved the checkout-completed event to the server."

Records involving money now take a route that blockers can't interrupt.

"This figure is before loss correction, so it reads low."

Don't compare the numbers directly; account for the missing share first.

After the episode above, Pagedeck built one way to measure the loss rate. Every week they compare the count of approvals from the payment provider against the checkout-completed records stored internally, and treat the gap as the loss rate directly. The first measurement came to 14 percent.

Events tied to money and accounts then moved to the server, and the rate dropped below 3 percent. Actions that happen only inside the screen still ship from the device, since the server never sees them, so Mia reads those numbers as week-over-week movement rather than absolute counts. If a similar share goes missing every week, the direction of the change is still trustworthy.

The comfortable assumption is that loss is uniform, so ratios are safe. Numerator and denominator shrink together and the ratio holds — plausible enough. But the share lost differs by step. Records for opening the first screen almost all arrive while checkout-completed records go missing at double-digit rates, which pushes the conversion rate down on its own. Read experiment results in that state and a perfectly good improvement gets scored as no effect.

The other mistake is thinking server-side tracking eliminates loss. "Can't be blocked" sounds like "always arrives." Server-side records still go missing through collection outages and failed retries, and anything that happens only inside the screen never reaches the server to begin with. What the move buys isn't the absence of loss — it's loss that doesn't tilt toward one group of users.