Without Identity
Every request is counted on its own, with no cookie, no fingerprint, and no cross-request link. The analytics work because the questions they answer never required knowing who asked.
What identity means in the context of analytics
In analytics, identity is the mechanism that lets a tool say "this request and that earlier request came from the same person." It could be a cookie that stores a visitor ID. It could be a fingerprint built from browser attributes, IP address, and screen characteristics. It could be a login token that ties a session to a registered account. Whatever the mechanism, the effect is the same: individual requests are linked into a chain that represents one visitor's journey.
That chain is useful for certain questions: Did this person convert after viewing that page? Did they return within seven days? How many pages did they view in one sitting? Those questions require the chain. Answering them without it produces guesses, not facts.
But the questions most site owners ask on a daily basis are different: How many page views did we get today? Which pages are most visited? Where is the traffic coming from? Is mobile traffic growing? None of these questions ask about any individual visitor. They ask about the aggregate pattern across all visits. That aggregate does not depend on the chain.
How counting without identity works
When a visitor loads a page, the tracking script fires a lightweight event. That event carries the page path, the referrer domain, and the screen-resolution class — three attributes that arrive with the request and describe the visit in aggregate terms. The server receives the event, verifies the site key, and increments the appropriate counters. No visitor identifier travels in the event. The server does not assign one. The event is processed and the connection is closed.
The counters are organized by site, date, and dimension. One counter tracks page views for /about on August 15. Another tracks the count of "tablet" resolution class visits on the same date. A third tracks referrals from a named source. Each counter is just a number. It does not carry any trace of which requests contributed to it.
Because each event is self-contained, the system never needs to look up a prior record to process the current one. The counting logic sees the event, finds the matching counters, adds one to each, and moves on. This is what makes the design stateless: no state from a previous request influences how the current request is handled.
What you give up and what you keep
Without identity, you cannot count unique visitors. You cannot reconstruct a single visitor's path through the site. You cannot measure bounce rate in the traditional session-based sense. You cannot build a funnel that follows one person from landing page to checkout. These are real limitations, and the help article on what we do not offer covers them plainly.
What you keep is a complete, accurate count of traffic activity: how many times each page was loaded, where that traffic came from, what screen sizes were in use, and how the daily totals trend over time. For content sites, blogs, documentation hubs, and informational pages, these numbers answer the practical questions that drive decisions: is this content reaching people, and is that reaching growing or shrinking?
You also keep a clean record that does not require a consent banner for analytics purposes, does not accumulate a database of behavioral histories, and does not produce a liability if something unexpected happens to the data store. The tradeoff is deliberate and the system delivers on it consistently.
Resolution classes as the unit of device measurement
Because no fingerprint is used, device measurement is done through resolution classes rather than device signatures. The script reads the reported screen width at load time and maps it into a named band. A very narrow width goes into the phone class. A moderate width goes into the tablet class. A wide width goes into the desktop class. The exact pixel value is not stored. Only the class name is counted.
This means you can see that 65% of visits arrive from phone-class screens without knowing the specific device model, operating system version, or any combination of attributes that could be used to re-identify a visitor across sessions. The class count gives you the planning signal you need — are most readers on small screens? — without building a detailed portrait of any individual.
The resolution class bands are documented in the script reference, along with the width thresholds that define them. If you want to understand exactly what each label means before reading the board, that reference is the right starting point.
Troubleshooting
If the device breakdown on the board looks wrong — for example, all visits showing as one class when you know your audience is varied — check that the script fires after the page has rendered, not in the document head before layout is applied. Very early execution can read a width before the browser has finished its layout pass, which can misclassify the resolution.
If you expected to see referrals from a specific source but the board shows none, confirm the source is not setting a Referrer-Policy header that strips or masks the referrer. Many privacy-focused tools and link shorteners scrub the referrer entirely, which means those clicks arrive with no referrer data and fall into the direct bucket on the board.
If you are comparing visit counts from before and after moving to this system and the numbers look structurally different, remember that session-based tools often count a visit once per session even if multiple page views occurred. This system counts every page view individually. The page-view total will match; the "visitor" or "session" total will not, because this system does not compute those figures.