A global market-share chart, a site’s analytics, CDN logs, and a community sample answer different questions. Their numbers can disagree without any of them being broken because the population, time window, geography, device mix, bot filtering, and counting unit differ. A browser-share number needs a passport: enough context to travel from a dashboard into a product decision without losing its identity.

Start with the population

The first sentence should say what was measured. “In our anonymized documentation traffic from May 2026, mobile Chromium accounted for 62 percent of page requests after known bots were removed” is a bounded observation. “Chrome has 62 percent market share” is a claim about a much larger population that the same number cannot support.

When publishing an estimate, include:

  • measurement window and timezone
  • geography and device scope when known
  • source system and counting unit
  • bot, crawler, preview, and duplicate-request filters
  • whether the number is observed, modelled, or editorial
  • the decision the estimate is meant to inform

If a field is unavailable, say so. Scope is more valuable than a decimal place.

Why two valid reports can diverge

Consider an illustrative comparison. A CDN log counts 100,000 requests and reports 62,000 mobile Chromium requests. Product analytics counts 40,000 sessions and reports 19,200 mobile Chromium sessions. The percentages differ because one metric counts requests and the other counts sessions; a single session can load many assets, while cached pages can reduce requests. A dashboard that merges the two without naming the unit creates a false disagreement.

The same issue appears with bots, preview clients, logged-in support traffic, and regional samples. Keep the denominator beside the percentage and make the filter version reproducible. If the filtering rule changes, mark the report as a new measurement rather than presenting it as a clean continuation.

Turn the number into a decision

Support may need to know which browser family appears often enough to prioritize a help article. QA may need a risky version range even when its volume is small. Content editors may care about search demand rather than traffic. One number cannot serve all three jobs.

For a support decision, report a family bucket and an action threshold. For QA, report version range, journey, and failure severity. For content, report query class and page usefulness. The estimate is a routing signal; it is not a universal ranking of browsers.

Show uncertainty honestly

Use a range when the sample is small, the source is modelled, or the filter is changing. Avoid percentages with more precision than the collection method supports. If a rare browser appears in a handful of requests, say “observed in a small sample” instead of converting five rows into a market claim.

Separate observed facts from inference. A User-Agent may support a family label while leaving the exact device uncertain. A request count may indicate interest while saying nothing about whether a page solved the user’s problem. Put those limits next to the number so it is not copied out of context.

A publication template

Scope: UA Hub reference-page requests
Window: 2026-05-01 through 2026-05-31 UTC
Unit: filtered page requests, not unique people
Source: edge logs with known bots and previews removed
Result: mobile Chromium was the largest observed family bucket
Limit: no claim about global browser share or user identity
Decision: prioritize the Android WebView and mobile Chromium examples

This format gives a reader enough context to act and enough limits to avoid overreading the result. It also makes the next report comparable without pretending that two different systems are identical.

Version the method, not just the number

Keep the filter version, parser version, and report owner beside the result. A new bot rule can lower request volume. A parser update can move a row from unknown to Chromium. A change in cache behaviour can alter the unit being counted. Those are new measurements, even when the date window overlaps. Label the revision instead of silently drawing a line between incomparable points.

For a small sample, publish the count before the percentage. An illustrative note might say that 17 of 240 filtered requests matched a mobile WebView bucket during one UTC day, observed in a documentation sample and not suitable for global market-share claims. That sentence gives a support or content team enough context to choose a next check without pretending that the sample estimates every browser user.

Make the decision reversible

Use an estimate to choose a fixture, prioritize an article, or schedule a support review. Do not use an unbounded estimate as the only reason to block a browser or collect more identifying detail. Set an expiry or review date for the decision. If the next measurement no longer supports it, retire the rule and record why.

Browser share is a measurement, not a fact detached from a method. Our standard is that every number carries its population, denominator, filters, uncertainty, and intended decision with it.