Count visitors without a cookie banner

You can count visitors without a cookie banner by sending only what a web server already sees (the page address, the referrer, the screen size, the browser language and the user agent), by dropping the IP address once it has been turned into a country and city, and by telling visitors apart with either a random first-party id that never leaves your site or a hash that changes every day. None of that identifies a person or follows them across the web, which is what consent banners exist to ask about.

What the banner is really about

Consent banners became common because analytics tools dropped third-party cookies that let an advertising network recognise the same person on thousands of sites, and because they stored IP addresses and fingerprints that identify a device. The rules in Europe and elsewhere ask for consent for that kind of tracking. They do not ask you to stop counting how many people read a page, as long as what you keep cannot identify someone and is not used to follow them elsewhere.

So the question to ask of any tracker is not "does it use a cookie" but "can what it stores identify a person, and is anything shared between sites". Get those two answers right and the banner goes away.

What the script sends

Here is a pageview as Glai's script posts it, with nothing hidden:

{ "s": "your_site_id", "v": "7f3a9c…", "n": "pageview",
  "u": "https://acme.com/pricing", "r": "https://chatgpt.com/",
  "t": "Pricing", "sw": 1440, "sh": 900, "l": "en-AU" }

That is the site id, the visitor id, the event name, the page and its title, the referrer, the screen size and the language. The server adds what every server already has from the request: the browser and device type read from the user agent, and the country, region and city worked out from the IP address. Then the address is dropped. It is not written to the database and it does not appear in any report.

Two ways to tell visitors apart

A random first-party id

On the first visit the script makes a random string and keeps it in the browser's local storage and in a first-party cookie on your domain. It is not derived from anything about the person; it is a coin toss. It is different on every website that uses the tracker, so two sites cannot compare notes. What it buys you is a journey: the same visitor seen again next week, the pages they read in order, and a payment tied to their first visit. That journey is why the id exists, and it is the thing to explain in your privacy policy.

A daily hash that stores nothing

In strict mode the script writes nothing to the browser. The server counts the visitor with a hash of the day, the site, the IP address and the user agent, made with a secret key. The hash changes at midnight and cannot be turned back into the address. You still get visitors, sessions, sources and pages for the day, and you lose journeys across days and attribution of payments by visitor id. It is the right mode for a site that wants the absolute minimum.

What you still have to do

1. Say it in your privacy policy. A sentence that you use privacy-friendly analytics, what is collected, that no IP address is stored and that nothing is shared between sites. The rules where your visitors live are still yours to check.
2. Do not send personal data in events. A custom event with someone's email in a property turns a harmless counter into a record about a person. Use ids, plans and page names.
3. Decide about identify. A tracker can tie a visitor to an email after sign-in, for the journey view. That is your choice, your data and your users; mention it if you use it.
4. Keep retention sensible. Raw events have a retention period on every plan and are deleted after it; payments keep only the source they came from.

What this is not

It is not fingerprinting. A fingerprint combines many stable signals (fonts, canvas, hardware) into an id that identifies a device for months without storing anything; the daily hash deliberately includes the date and a secret so it cannot. It is not a loophole for advertising: there is no profile, no segment and nothing to sell. It is counting, done carefully, which is why a shared dashboard of these numbers can be public without exposing anyone: it shows totals and breakdowns, never a person.

The same care is what makes revenue attribution possible without a banner: the id that ties a payment to a visit is random and yours, not a third party's. Read the install guide for the two attributes that switch strict mode on, or create a free account and see your first visit, banner-free, in a minute.

Questions people ask

Is a first-party cookie allowed without consent?

A random id in a first-party cookie, used only to count visits on your own site and not shared with anyone, is treated very differently from an advertising cookie. Many regulators exempt such measurement, but the rules vary by country, so state what you do in your privacy policy and check the ones that apply to you.

Can the daily hash be reversed to find the IP address?

No. It is a keyed hash of the day, the site, the address and the user agent, made with a secret kept on the server. Without the secret it cannot be computed, and even with it a hash cannot be turned back into its inputs. It also changes every day.

What does the tracker know about a visitor's location?

The country, region and city worked out from the IP address at the moment of the request, at the level of a city, never a street. The address itself is then dropped and is not stored or shown anywhere.

Does strict mode still show where visitors come from?

Yes. The source comes from the referrer and the UTM parameters of each visit, not from the visitor id, so sources, campaigns, pages, countries and devices all work. What you lose is the link between one day's visit and the next, and payment attribution by visitor id.