Tags: analytics concept

User Counting

Date: 2026-08-16

---

The least reliable number in any tool, and the one most often put on a slide. “Users” means devices with surviving identifiers, which is neither people nor devices, and it moves for reasons that have nothing to do with traffic.

---

What it is

A user, in almost every analytics tool, is a distinct identifier — usually a cookie or storage value scoped to one browser on one device. Not a person. Not a device.

The gap between the label and the thing:

one person, one month

  work laptop, Chrome        →  1 identifier
  home laptop, Chrome        →  1
  home laptop, Safari        →  1
  phone                      →  1
  tablet                     →  1
  cleared cookies in week 3  →  +2
  Safari 7-day cap fired     →  +3
                                ──
  counted as                    10 users

Ten “users”, one customer. And that’s without private browsing, a second household member, or an app.

Why the number moves on its own

Nothing about traffic has to change for user counts to shift materially:

• Browser storage caps. Safari truncates script-set cookie lifetime, so a returning Safari user past the window is counted as new — Browser Privacy Restrictions
• Consent changes. A banner redesign that reduces acceptance shrinks the counted population, and it isn’t a random slice — Consent Management
• Blocking. A share of users never get an identifier at all — Ad Blockers and Tracking Loss
• Login rate changes. More identification means more merging, so counts fall — Identity Stitching
• Traffic mix. A campaign shifting device or browser mix changes the average identifiers-per-person
• Bots, each arriving without storage, generating one apparent user per request — Bot and Internal Traffic

In plain terms: user count is a measure of how many surviving identifiers you have, which depends on browser policy, consent and login behaviour at least as much as on how many people visited.

Why tools never agree

Each tool has its own identifier, its own cookie lifetime, its own bot filter, its own consent gating and its own stitching. Two tools on the same site routinely differ by tens of percent on users while agreeing closely on orders — because orders are events and users are an inference.

That divergence is expected, not a bug to reconcile. See Tool Discrepancies.

What to use instead

• For volume, use sessions or pageviews. Cruder, but they count events rather than inferring entities
• For value and retention, use identified users only, and say so — Anonymous and Identified Users
• For conversion, prefer a task-scoped denominator — checkout_started → purchase needs no user identity at all — Funnel Analysis
• For anything longitudinal, you need durable identity. If most of your traffic is anonymous and non-returning, cohort and lifetime analysis is not available at user level however the tool labels it — Cohort Analysis

If you must report it

• Never compare user counts across tools. Different definitions, different answers
• Never compare across a tracking change — a consent update, a new SDK, a replatform. Annotate the date and expect a step — Metric Drift, Annotation and Change Logs
• Segment by browser before drawing conclusions, since the inflation rate differs sharply between Safari and Chrome
• State the definition alongside the number. “Distinct browser identifiers over 30 days, excluding known bots” is honest; “users” is not
• Watch the ratio of users to sessions over time. A rise usually means identity is decaying rather than that people are visiting less often — that’s the diagnostic signal worth monitoring

The blunt version worth keeping: users is the metric most likely to be wrong and least likely to be questioned, because it sounds like it means what it says.