What Stateless Analytics Is
Stateless analytics counts traffic by classifying each request on arrival. No session is opened, no cookie is set, and no visitor record is kept between requests.
The idea behind stateless analytics
Most web analytics tools answer the question "who came back?" by keeping a record of each visitor across visits. They set a cookie, assign an ID, and link every subsequent request back to that same ID. That chain of links is the session. It is also the thing that makes those tools subject to cookie consent, GDPR data subject requests, and the risk of a breach that exposes real behavioral histories.
Stateless analytics asks a different question: what happened on the site during a given period? That question does not require a visitor record. It only requires that each incoming request be examined on its own terms and counted into the right bucket. No prior state is consulted. No future state is written. The request is counted, and then it is gone.
The word "stateless" describes the absence of that cross-request memory. A stateless system treats every request as the first and only request from that source. It classifies the request by characteristics that arrive with it — the page path, the referring URL, the reported screen width — and adds one tally to the matching counter. Nothing else is stored.
What the board actually shows
When you open your dashboard, you see a board covering a date range you choose. The board shows page views — the total count of tracked requests for each page path — plus referrers, screen-resolution classes, and a daily breakdown. Every figure on the board is a count derived from tally marks. There is no table of visitors behind those numbers. There is no way to drill into a single visit and read what one person did.
The totals you see are additive. If the board shows 400 page views across four pages, those pages add up to 400. If it shows 60 referrals from a search engine and 40 from a newsletter, those add up to 100 referral hits. The numbers are transparent in exactly that way: you can check the arithmetic yourself. That quality — provable from the counts alone — is a direct consequence of the stateless design.
Referrers are recorded as the domain or path the browser reports in the HTTP Referer header. Resolution classes are width bands: the script reads the reported screen width at load time, maps it to a label such as "tablet," and increments the counter for that label. Neither the raw width pixel value nor any other identifying detail is stored in the long-term record.
Why no session is needed for this
A session exists to connect visit A and visit B by the same person. If the analytics goal is "how many page views did /blog get on Tuesday?", no session is needed. The answer is the count of qualifying requests that arrived with the path /blog on Tuesday. Each of those requests can be counted independently, in isolation, without knowing anything about the visitor who made it.
This is the core claim of stateless analytics: for the traffic questions most site owners actually need answered — which pages are popular, where traffic comes from, what devices visitors use, how totals change over time — identity adds nothing. The numbers would be the same whether or not a session was opened. Dropping the session is not a compromise. It is the correct tool for the job.
When a request is counted and discarded, there is nothing left to breach, subpoena, or sell. That is a practical benefit, not a marketing position. The design produces that outcome because counting does not require storing.
How this differs from a count of unique visitors
Unique visitor counts require a way to tell whether request B came from the same person as request A. Without a cookie, fingerprint, or other cross-request identifier, there is no reliable way to make that determination. Stateless analytics makes no attempt to do so. The board does not show a unique-visitor figure because such a figure cannot be derived from class counts alone without introducing identity.
What the board shows instead is total page views, which is a clean and honest number. If 200 page-view events were recorded for a page, the board shows 200. Whether those came from 50 people or 200 people, the board does not speculate. Some operators find this a limitation; for most, the page-view count is the number they actually care about.
If you have been accustomed to analytics tools that show unique visitors as a primary metric, the adjustment takes one or two weeks of reading the board before the pattern becomes comfortable. The page-view figures and the daily trend lines give you a reliable sense of how traffic is moving without requiring you to trust a de-duplication algorithm you cannot inspect.
Troubleshooting
If your page-view counts feel unexpectedly low compared with a previous tool, the most common cause is that the previous tool was counting sessions or users, not raw page views. Switch the comparison metric in the old tool to raw page views (or hits) and the numbers will usually align closely.
If you see counts but cannot see which specific pages are listed in the board, check that the script tag is placed correctly and that the page paths your site sends match the URLs you expect. The board shows exactly the paths the script reports, so a mismatch in path format will create separate rows that look like different pages.
If the board appears empty after a fresh install, confirm the site key in the script tag matches the key assigned to your site in the dashboard settings. A wrong key causes events to be counted under a different site, not dropped — so the data exists, just on the wrong site record.