# Why your docs analytics doesn’t need a cookie banner

Cookie banners exist because analytics scripts store an identifier on the reader’s device. Count page views on the server with a hash that changes daily and there is nothing to store, nothing to consent to, and no banner.

_Source: https://docszero.com/resources/docs-analytics-without-a-cookie-banner_
_explainer · 6 min read_
_Published 10 September 2026_

> **In short:** A banner is required when you store or read something on the reader’s device, not when you count visits. Count server-side, derive the visitor from a hash that changes every day, never store the address, and there is nothing to ask permission for.

## What the banner is actually for

It helps to be precise about what triggers a consent banner, because "analytics" is not the trigger and a lot of people believe it is.

Under the ePrivacy rules that produced the banner you keep clicking, consent is about **storing information on, or reading information from, a reader’s device**. A cookie is the obvious case. So is `localStorage`, and so is a device fingerprint assembled from screen size, fonts and timezone. If you put an identifier on someone’s machine so you can recognise them next week, you need to ask first.

Counting how many times a page was served is not that. The request already reached your server; noticing it did is not storage on anyone’s device. The banner is not the price of knowing your traffic. It is the price of a particular way of measuring it.

> This is an explanation of how the mechanism works, not legal advice. Your obligations depend on where you and your readers are, and on everything else your site loads. If you embed a third-party script, that script’s behaviour is yours to account for.

## Why the usual analytics needs one

A conventional analytics script runs in the reader’s browser and sets an identifier that persists. That identifier is what makes the interesting numbers possible: returning visitors, sessions, time on page, a funnel across several days. Those metrics are the reason the identifier exists, and the identifier is the reason for the banner.

It is a fair trade for a shop. For documentation it is usually a bad one. You wanted to know which pages get read and where readers come from, and you have paid for it with a modal in front of your docs, a third-party script on every page, and a paragraph in your privacy policy about a company your readers have never heard of.

### And the banner costs you the numbers anyway

The awkward part: a meaningful share of readers decline. Whatever you were measuring, you are now measuring the subset who clicked accept, and you have no way of knowing how that subset differs from everyone else. You have added friction to your docs and made your data worse in the same gesture.

## How counting on the server works instead

The alternative is older than the banner. The server already knows a request happened; it records that, and derives what it needs without keeping anything about the person.

Here is the whole mechanism Docszero uses on published sites:

- A page is served. The server records the path, the referrer and the time.
- A visitor value is computed: a one-way hash of a secret, today’s date, the address and the user agent, truncated to 32 characters.
- The address itself is never written down. The hash is what gets stored.
- Because the date is an ingredient, the value changes at midnight. It cannot follow anyone into tomorrow, or across to another site.
- Known crawlers are recorded and flagged, so they can be excluded from the reader counts rather than inflating them.
- No cookie is set for any of this, so there is nothing to consent to.

### What the hash can and cannot do

Within a single day, two requests from the same reader produce the same value, which is what makes "unique visitors today" a real number rather than a guess. Tomorrow the same reader produces a different value, which is what makes following them impossible — including for us. The secret means nobody can take a stored value and work backwards to an address.

## What you give up, honestly

This is not free. The daily rotation that makes the banner unnecessary is the same property that makes several familiar metrics impossible, and any page that tells you otherwise is selling something.

| Metric | Cookie-based analytics | Daily-rotating hash |
| --- | --- | --- |
| Page views | Yes | Yes |
| Unique visitors today | Yes | Yes |
| Top pages and referrers | Yes | Yes |
| Returning visitors across days | Yes | No, by design |
| Sessions and time on page | Yes | No |
| Multi-day funnels and attribution | Yes | No |
| A consent banner | Required | Nothing to consent to |

For documentation those trade-offs are mostly free. You want to know which pages carry the load, which ones nobody finds, and where readers arrive from, so you know what to write next. Multi-day attribution is a marketing question, and your docs are not a marketing funnel.

If you genuinely need cohorts and sessions across weeks, use a tool built for that and accept the banner. It is the right answer for the question you are asking.

## What this looks like in Docszero

Reader analytics is on for every published site, including sites on the free plan, and there is nothing to install: no snippet, no key, no third-party domain in your page.

- Views, unique visitors and a daily series for every site.
- Top pages and top referrers, ranked, on paid plans.
- Two days of history on Free, ninety days on Pro and Agency.
- CSV export on paid plans, so the numbers leave with you.
- No cookies, no sessions, no script, and no banner to add.

Protected pages are excluded from CDN caching for unrelated reasons, and none of this changes when a site is password-protected: the same counting applies, and the password cookie is a separate, necessary thing that has nothing to do with measurement.

## Questions

### Do I need a cookie banner for website analytics?

You need consent when you store information on, or read it from, a visitor’s device — a cookie, localStorage, or a fingerprint assembled from device characteristics. Counting requests on the server and deriving a visitor value that changes daily stores nothing on the device, so there is nothing to consent to. Your overall obligations depend on where you and your readers are and on everything else your pages load.

### How does cookieless analytics identify a visitor?

It does not identify anyone. Docszero computes a one-way hash of a secret, the current date, the request address and the user agent, truncated to 32 characters, and stores that. The address is never written down. Because the date is part of the input, the value changes every day, so it cannot be used to recognise the same reader tomorrow or on another site.

### What can’t you measure without cookies?

Anything that requires recognising the same person across days: returning visitors, sessions, time on page, and multi-day funnels or attribution. Page views, unique visitors within a day, top pages and referrers all work normally. For documentation those are usually the numbers you actually act on.

### Are bots included in the reader numbers?

No. Known crawlers are recorded and flagged rather than dropped, so they can be excluded from visitor counts while still being visible if you want to know what is crawling your docs.

### Can I get the raw numbers out?

Yes, CSV export is included on paid plans, alongside ninety days of history, top pages and referrers. The free plan shows totals for the last two days.

---

Published by Docszero (https://docszero.com) — docs, minus the setup. Upload Markdown, a Word document or a PDF and get a searchable documentation site. Free for one site; export the source on every plan.