How TrueStat decides that two page views came from the same person, what each option costs, and how to switch.
There are three modes. You pick one per site. The default sets a cookie.
The site settings identity-mode control showing all three options — first-party cookie (default, selected), rotating hash, strict cookieless — with the accuracy note rendered next to the selected one. Light theme, desktop.
The three modes
| First-party cookie (default) | Rotating hash | Strict cookieless | |
| Sets a cookie | Yes, one | No | No |
| Cookie banner needed | Likely, in the EU/UK | No | No |
| Same visitor recognised across days | Yes | No | No |
| Same visitor recognised within a day | Yes | Yes | Within the hour |
| New vs returning visitors | Works | Not available | Not available |
| Unique visitor accuracy | Highest | Good within a day | Lowest — visitors on a shared network merge |
First-party cookie — the default
The script stores a random identifier in a cookie called ts_vid on your own
domain. Every page view from that browser carries the same value, so a reader
who arrives in March and comes back in May is one visitor rather than two.
What the cookie contains: a random UUID. Nothing else. No name, no email, no address, no browsing history, nothing derived from the person.
What we store: not the cookie. The value is hashed together with your site's internal id before anything is written, so the same browser visiting two different customers' sites produces two unrelated identifiers and no cross-site profile can be built from our data.
You probably need a cookie notice for this mode
This is a plain statement of the trade-off, not legal advice, and if you have a legal team this is the paragraph to send them.
It is a first-party, analytics-only cookie that stores no personal data and is never shared. Several jurisdictions treat that category leniently. Several do not. Under the EU ePrivacy rules the exemption for storing information on a user's device is narrow, and a persistent analytics cookie is generally considered to fall outside it — which means a notice and, in many readings, consent.
"No cookie banner needed" is not true of this mode. It is true of the other two. If avoiding the banner is why you chose TrueStat, switch to rotating hash below, and read what it costs before you do.
Rotating hash — no cookie
No storage on the visitor's device at all. Instead, an identifier is computed on our servers from the request:
identifier = SHA-256( today's secret salt + IP address + user agent + your site id )Three properties of that, precisely:
The IP address is never stored. It goes into the hash as an argument and comes back out as 32 characters of hex. It is not written to any column, log line or error message.
The salt rotates every 24 hours (UTC) and the previous day's salt is deleted. Once a day's salt is gone, nobody — including us, including with full database access — can work out who a session was, because the input that produced it no longer exists.
Your site id is in the hash, so the same visitor on two customers' sites produces two unrelated identifiers.
What it costs
After the salt rotates, the same person looks like a new visitor. Concretely:
A reader who visits on Monday and again on Thursday is counted as two visitors, not one returning visitor.
New vs returning breakdowns are not available.
A visit that crosses midnight UTC mid-session splits into two visitors.
Any question of the form "this campaign paid off three weeks later" is unanswerable. Same-day and single-visit numbers are unaffected.
This limitation is shared by essentially every cookieless analytics product. It is not particular to TrueStat.
Strict cookieless — the hardest privacy posture
Everything the rotating hash does, plus two further coarsenings before the hash:
The IP is widened to its network. IPv4 drops the last octet (a
/24); IPv6 keeps only the first three groups (a/48).The user agent is reduced to a rough class — platform plus browser engine, e.g.
macos:blink— rather than the full string.The hour is folded in, so an identifier expires within the hour rather than lasting the day.
What it costs
Unique visitors are undercounted. Everyone behind one office router, one mobile carrier NAT or one household connection, on similar devices, collapses into a single visitor. Sessions crossing an hour boundary split in two, which overstates session count and understates session length.
We would rather understate than overstate on a mode chosen for privacy, so that is the direction the error runs — but it is a real error and you should not compare a strict-cookieless site's visitor count against anything.
How to switch
Open the site's settings in the app.
Change the identity mode.
Save.
The server decides which mode runs, from your site's setting — not from the tag on your page. So switching does not break a site whose HTML you have not updated, and you cannot get this wrong by pasting a stale snippet.
The snippet does change visibly when you pick strict cookieless: it gains
data-ts-mode="strict". That attribute does nothing on its own. It is there so
the tag on your page documents which mode the site is on, and so switching has a
visible effect rather than appearing to do nothing.
What switching does to your existing numbers
Historical data is not rewritten. Identifiers already stored keep whatever they were. So there is a discontinuity at the switch: for a day or so, visitors who were being recognised across days stop being recognised, and your unique visitor count will step up as they are recounted.
Page views are unaffected — they do not depend on identity at all.
If a visitor has cookies disabled
On the default cookie mode, a visitor whose browser refuses storage sends no identifier. Rather than record nothing, TrueStat falls back to the rotating hash for that visitor. Their views within a day still group correctly; only the cross-day link is lost — which is exactly what refusing storage asked for.