I’ve been working on WebmasterID, a privacy-first web analytics platform, and this week we focused heavily on a problem that sounds simple but turned out to be structural:
How do you stop an analytics UI from turning “we don’t know” into 0?
One example: a database read could fail, an empty array would propagate through the application, and eventually the UI could render a perfectly convincing “0” or “No data” state.
Technically clean UI. Semantically false.
We ended up separating states such as measured zero, unavailable data and failed reads much more explicitly, then attacking those assumptions with mutation tests and rendered-browser checks.
We also shipped a deeper Events workflow:
• deterministic cursor pagination
• individual event addressing
• event detail inspection
• tenant-isolation checks
• safer rendering of event properties
• explicit distinction between failed reads and the actual end of an event stream
Production telemetry also disproved/reinforced a few assumptions.
Our sessionId, for example, cannot honestly be called a “visit.” The same visitor can produce different session tokens seconds apart. The default implementation is tab-scoped, and the token can also be explicitly overridden.
So the UI uses session token, not “visitor journey,” “landing page,” “exit page,” etc.
Another interesting case:
trafficCategory = direct can coexist with utmSource = chatgpt.com.
In other words, Direct and campaign attribution are different dimensions. “Direct” means that no referring source was observed/classified; it does not prove that someone typed the URL or that campaign metadata doesn’t exist.
The latest Events Deep Dive gate ended at 383 test files / 42,122 passing tests.
The principle we’ve ended up using internally is:
An analytics product should be allowed to say “unknown.”
A smaller amount of defensible intelligence is more useful than a dashboard full of precise-looking assumptions.
Top comments (0)