Cookieless by default

No cookie banner. No consent gate. Just your numbers.

Skomi works out who a visitor is on our server, from a secret that is replaced every day and never written down. Nothing is stored on their device: no cookie, no local storage, nothing to ask permission for.

On by default for every new site. It is not a setting you have to find.

Check it yourself

The only privacy claim you can verify in thirty seconds

Every analytics vendor says something about privacy. Almost none of it can be checked from outside. This can: open any site running Skomi, open your browser's developer tools, and look at what we put on your machine.

On any page running Skomi
Open developer tools, go to Application, and read Cookies, Local Storage and Session Storage for the site. Skomi's rows are the ones beginning skomi_. On a cookieless site there are none.
And if you find something
Two keys can appear, and only after the visitor has done something: that they dismissed a feedback widget, or already sent a comment, so the site does not ask twice. Neither identifies anybody. Nothing is written just for arriving.
How it works

The identifier exists for a day and is never written down

A visitor is recognised by a one-way hash of the site, the network address and the browser string, mixed with a random secret. That secret is generated in memory, replaced every day, and stored nowhere.

Yesterday cannot be recovered

When the secret is replaced, the old one is gone, from us as well. Nothing Skomi works out on its own can link yesterday's visitors to today's, because the material needed to do it no longer exists.

The site is part of the hash

The same person on two different sites we measure is two unrelated identifiers. Nothing Skomi works out about a visitor is shared between sites, and no report reaches across them.

The key is destroyed every night

The salt the identifier is hashed under is random, is never written down, and is replaced daily. Yesterday's derived identifiers cannot be recomputed by anybody, including us. The IP address itself is kept with the visit and is never shared. It appears in no report. The one place you see it is a traffic alert, which exists so you can exclude an address sending implausible volume.

Unless you tell us who someone is

One thing can follow a visitor across days: your own id for a signed-in person, sent by your site. It is off until you switch it on, it stores nothing on anyone's device, and we refuse anything that looks like an email address. Visits where nobody is identified are recorded exactly as described above.

What it costs

Two things stop working, and we would rather you heard it here

Identity that cannot cross a day is the whole point, and it has a price. It is the same price for anyone doing this honestly, and anybody claiming otherwise is keeping something on the device.

Returning visitors count twice
Somebody who visits on Tuesday and again on Wednesday is two visitors, so unique visitors over a long period reads high. Daily figures are exact.
Retention has nothing to show
Cohort retention follows one person across days, which is precisely what cannot be done. The page says so rather than drawing an empty grid.
Everything else is unaffected
Daily visitors, sessions, bounce rate, sources and campaigns, pages, countries, goals, funnels, revenue, heatmaps and session recordings all work exactly as they would otherwise.
Your decision

You can turn it off, and then you need a banner

If Retention matters more to you than the banner does, a single switch per site tells the tracker to keep an id in the browser instead. That is storage on someone's device, and it needs consent under ePrivacy and the GDPR exactly as a cookie does. It is off until you turn it on, the setting says all of this next to the switch, and it is a per-site decision rather than an account-wide one.

Measure your site without asking permission first

Free while you are small, and cookieless from the first page view.