Your Dashboard Cannot Tell You It Is Broken

Two stories, one cell

A conversion report shows zero for Tuesday. There are exactly two stories that produce that cell, and they have nothing in common.

In the first story, the campaign ran, the site worked, visitors arrived, and none of them converted. That is a business problem. It might be pricing, it might be a landing page, it might be a Tuesday. Whatever it is, the number is real and the report is telling you the truth.

In the second story, forty people converted and the tag never fired. Maybe a deploy moved the thank-you page. Maybe a consent change stopped the tag from loading. Maybe someone paused something in a container three weeks ago and nobody connected it. That is a measurement problem, and the number is not real at all.

Nothing on the screen distinguishes them. The cell says zero in both cases, in the same font, in the same color. Whoever opens that report has to decide which story they are looking at, and most of the time they decide without noticing they decided.

Why the tools present it this way

This is not a vendor being careless. It is a category error baked into how reporting works, and it is very close to universal.

A reporting tool queries a dataset and counts rows. When it finds none, it has to render something, and the honest rendering would be "no data was received for this period," which is a different statement from "the value for this period is zero." Almost every reporting layer collapses those two into the same cell, because the layer genuinely cannot tell them apart. It never saw the events that did not arrive. From inside the query, absence of data and data showing absence are identical.

Some tools do better than others. A few will distinguish a null from a zero if you go looking, and a well-built report can be made to show a gap rather than a floor. But the default nearly everywhere is a zero, and the default is what people read.

Which means the burden sits outside the dashboard. Nothing inside it can resolve the ambiguity, because the information needed to resolve it was never collected.

What it costs, mechanically

The damage is not that a number was wrong for a day. It is that an optimization loop ran on it.

Conversions read low, so bids come down. Budget moves to the campaigns that still appear to be working, which are simply the ones whose tags are still firing. Creative gets blamed and swapped. A landing page gets rebuilt. Smart bidding, which is doing exactly what it was told, learns from a signal that has a hole in it and adjusts delivery accordingly.

Every one of those decisions is defensible given the data on screen. That is what makes this expensive. Nobody is being lazy. A team can spend a full quarter making careful, well-argued decisions about a number that was never collected, and the record of that quarter will look like diligent work.

And it lasts, because there is no error state to end it. A broken tag does not page anyone. It produces a plausible number, and plausible numbers survive review. The five patterns in 5 Signs Your Conversion Tracking Is Broken mostly share this property: they degrade the data without ever announcing themselves.

There is a partial escape, which is having two systems that should agree. When GA4 and Google Ads report different conversion counts, at least the disagreement is visible, and someone has to go and find out why. That is genuinely useful, though the usual causes are configuration rather than collection, as we covered in Why GA4 and Google Ads Never Match. The dangerous number is the one with no second opinion anywhere, because there is nothing for it to disagree with.

Why thresholds cannot fix it

The instinct is to set an alert. Conversions below X, send an email. It feels like monitoring and it is the standard answer.

It cannot work here, and the reason is worth being precise about. A threshold alert reads the same cell the dashboard reads. It fires identically whether the zero came from a quiet Tuesday or a dead tag, because it has access to exactly the same information: one number, no context about whether that number was collected. It adds noise without adding information.

Worse, it trains people. An alert that fires on every genuinely slow day becomes an alert people dismiss, and the one time it fires for a real outage it gets dismissed too. A monitor that cannot distinguish the cases teaches its audience to ignore it, which leaves you worse off than having no monitor at all.

What works: monitor time, not value

The fix is a heartbeat rather than a threshold. Instead of alerting on what the number is, alert on when the number last arrived.

"This purchase event has not been seen in six hours" is a completely different statement from "purchases are below target." The first one can only be true if collection stopped. It is immune to a slow day, because a slow day still produces some events, and it is immune to seasonality, because a quiet December still has a pulse. The time dimension is precisely what separates the two stories, and it is the one dimension threshold alerts throw away.

Practically, that means picking the events that matter (usually a small list: the primary conversion, the key ecommerce steps, the consent signal, whatever the revenue report is built on), establishing what normal timing looks like for each, and alerting when one goes quiet for longer than its normal gap. A low-traffic form might reasonably go a day without a submission. A checkout on a busy site should not go twenty minutes. The window is per event, not global, and getting those windows roughly right is most of the work.

The same logic applies one layer up, to the reports themselves. A dashboard fed by a scheduled job can keep rendering yesterday's numbers indefinitely after the pipeline behind it dies, which is the failure we walked through in The API Retired Today. Your Dashboard Didn't Notice. Freshness monitoring covers both cases for the same reason: it asks a question about time that stale data cannot answer.

The mirror image: a clean result that was never a result

The same coin has another face, and it shows up in scanning rather than reporting.

A scan runs against a site and comes back with nothing. No trackers found, no violations, no issues. Two stories again: either the page is genuinely clean, or the scanner was blocked. A bot wall, a challenge page, a geo redirect, a login gate. The crawler received something that was not the page, found no trackers in it, and reported no trackers, which is technically accurate and completely useless.

Absence of findings is not a finding. An empty result is only meaningful if you can show the check actually ran and actually saw the thing it was checking. Otherwise "clean" is a claim about the scanner's experience, not about the site.

This applies to our own scanning as much as anyone's, and saying so is not modesty. It is the reason we record what a scan actually retrieved alongside what it found, so an empty result can be distinguished from a blocked one. Any tool that reports a clean result without evidence that it reached the page is telling you something it does not know. That includes ours when we get it wrong, and it is worth asking any vendor, including us, how their scanner proves it saw the page.

The ten-second test

Open the report your team actually acts on. Take the headline numbers, the four or five that drive decisions. For each one, answer this: what proves it was collected today?

Not what proves it is accurate, which is a much harder question. Just what proves it arrived. A freshness timestamp, a heartbeat check, a monitor with a name you can point at. Something that would have made noise if collection had stopped.

If the honest answer is "someone would probably notice," that number is not monitored. It is being watched by human pattern recognition, which is excellent at spotting a number that looks wrong and quite poor at spotting a number that looks fine and is not there. Zero looks fine. Zero looks like a bad week.

Most teams find that the numbers driving the largest decisions are the least verified, because the largest decisions are made from the most summarized reports, and summarization is where provenance gets stripped. Auditing that properly is a bigger job, and the GA4 audit checklist covers the collection side of it in detail.

The test gets harder, and more necessary, the more of the journey happens somewhere you do not control. When the conversion completes on a vendor's platform on a vendor's domain, the number arrives through a handoff that can break on their release schedule rather than yours. That is its own problem, and we walked through it in Your Restaurant Website Is Not One Website, but the ten-second test still applies. What proves it was collected today?

Monitoring is not a nicer dashboard

It is easy to treat monitoring as a reporting upgrade, another view, more charts. It is not. It is the layer that tells you whether the reporting means anything, and it has to sit outside the reporting to do that job, because a system cannot report on its own absence.

Your dashboard cannot tell you it is broken. It was never built to. Something else has to.