The traffic you never see

Anyone who has compared orders in the shop database with transactions in analytics knows the two numbers disagree. The usual response is "analytics always loses a bit" and moving on. That sentence is true and completely useless, because it skips the only question that matters here: does it lose at random, or in a particular direction?

If at random, your analytics is a smaller copy of reality. Every proportion holds, you multiply by a constant and the conclusions stand. If in a particular direction, every proportion in the report is shifted, and the shift is invisible because it leaves no empty row behind. The answer, unfortunately, is: in a particular direction. Here are the four mechanisms that do it, and what to do about them.

Mechanism one: cookie consent

A tool that requires consent sees only the people who clicked it. And the share of people who click depends heavily on how the banner was built. That dependency is measured, not felt.

The most cited study here is Dark Patterns after the GDPR by Nouwens, Liccardi, Veale, Karger and Kagal, presented at CHI 2020. The team analysed 680 consent management platform deployments across the top ten thousand UK sites and complemented it with a field experiment.

Two other numbers from that paper matter more than the compliance rate. Removing the opt-out button from the banner's first page raised consent by 22 to 23 percentage points. Conversely, putting granular controls on the first page lowered it by 8 to 20 points. Same traffic, same site, same content, and the share of measured visits differs by tens of percent depending on button layout.

More important still is who clicks. People in a hurry to reach the content accept more often; people careful about privacy accept less. Those are not the same people and they do not behave the same way on your site. The missing traffic is therefore not a random sample: it is a sample of visitors with particular habits.

Mechanism two: the browser that does not ask

The second layer of loss depends on neither the user nor you. Browser vendors set it, and it applies by default.

In March 2020 Safari blocked all third-party cookies and, less discussed but more consequential for analytics, introduced a seven-day cap on script-writable storage. After seven days of browser use without interaction with a given site, everything its scripts wrote is deleted: localStorage, IndexedDB, sessionStorage, Service Worker registrations. Cookies set from JavaScript had received the same cap a year earlier.

The practical consequence is that in Safari the notion of a "returning visitor" has a seven-day horizon unless the person logs in. Someone who comes back once a month is new every time. This is not a tool defect or an outage: it is the default behaviour of a browser with double-digit market share, used on Apple devices by many people who believe they are using something else.

While we are here, a common misconception deserves dispatching. The "cookieless future" did not arrive and is not arriving soon: in April 2025 Google announced it would not introduce a standalone third-party cookie prompt in Chrome and would keep its current approach. Third-party cookies still work in Chrome. What disappeared was the promise of one deadline for everybody. What remains is fragmentation: every browser, different rules.

Mechanism three: blockers and requests that never arrive

The third layer is scripts that never loaded. Content blockers with filter lists, corporate proxies, data-saver modes, privacy extensions, mobile networks dropping the request. There is no single credible figure for the whole web here, because blocker usage varies dramatically by audience: a programming blog and a children's shoe shop are different worlds.

You do not need anyone else's number, though, because this one you can measure yourself, and it is one of the few measurements that takes fifteen minutes. Take the count of order-confirmation page views from your server logs or database and compare it with the same page views in analytics, for the same day. The difference is your real loss rate, consent and blockers and everything else included. For most sites it lands somewhere between a few and a few dozen percent.

Mechanism four: data the tool deletes itself

The fourth layer is the most surprising, because it has nothing to do with collection. The data arrives, it is stored, and then it disappears in front of you.

In free Google Analytics 4, event-level data retention is two or fourteen months, and user-level data caps at fourteen months. The default when a property is created is two months, which is why a great many implementations are still on two months today: nobody changed it.

There is a subtlety here that trips up almost everyone. The retention limit does not apply to standard aggregated reports, only to explorations and funnel reports. A plain traffic chart going back three years will show data. But the moment you want to ask your own question, one that goes beyond a canned report, your horizon shrinks to fourteen months. Year-on-year seasonality analysis, comparing April with April, is exactly that kind of question.

Then there is the (other) row. When the number of distinct dimension values exceeds a table's row limit, GA4 collapses the rarer values into a single bucket. The documentation states that any dimension with more than 500 values should be considered high-cardinality. For page paths, campaign names or product identifiers, five hundred is not many. The effect: a question about the long tail gets answered with "other", and that is not an error signal, it is ordinary report content.

Why skew is worse than loss

Suppose you lose thirty percent of your traffic. If those thirty percent were random, the situation would be simple and largely harmless: every percentage in your reports would be correct and only the absolute numbers too low. Multiply by 1.43 and you have reality.

That is not the situation, because each of the four mechanisms is selective, and all of them lean the same way.

Every row of that table is one specific wrong conclusion you can draw from a correctly functioning tool. "Our customers are mostly on Android." "German traffic is negligible." "Almost nobody comes back." "Only ten products sell." All four can be artefacts of measurement.

What to do about it

The good news is that most decisions do not need absolute numbers. They need a stable method of measurement, one that is wrong in the same way on Tuesday and on Thursday. Then a change in the report is a change in reality rather than a change in measurement conditions.

• Measure your loss rate once and write it down. Orders in the database against orders in analytics for the same day. Repeat quarterly. A sudden change in that number is more informative than the traffic chart itself.
• Do not change how you measure in the middle of a period you will later compare. Changing the banner, the tool, or how the script loads cuts the time series. If you must, record the date and mark it on your charts.
• Treat the browser and country breakdowns as the most skewed part of the report. Those are precisely the dimensions where the loss mechanisms bite hardest and most selectively.
• Check your retention setting today. In GA4 it is one field in property settings. If it sits at two months, next year's seasonal comparison already does not exist and cannot be recovered.
• Consider measurement that needs no consent. If a tool writes nothing to the device, the entire first layer of loss disappears, and its selectivity with it. That is not a cure for everything, but it removes the one mechanism capable of moving your numbers twenty-odd points through button layout alone.

Analytics is an instrument for comparison, not for counting. Refuse that and you will spend forever hunting missing percentages. Accept it and you start asking the questions this data can genuinely answer, of which there are plenty, none of them beginning with "exactly how many".