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 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 identifier is stored on the visitor's device. Instead, it 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 — the Install tab.
Pick Cookie, Cookieless or Strict under "Visitors are identified by". It saves as you click.
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.
The tag, in each mode
Cookie — the default. Nothing extra:
<script
defer
data-website-id="ts_a1b2c3d4e5f6"
data-domain="example.com"
src="https://truestat.io/js/t.js"
></script>Rotating hash and strict. The same src, plus the receipt:
<script
defer
data-website-id="ts_a1b2c3d4e5f6"
data-domain="example.com"
data-ts-mode="cookieless"
src="https://truestat.io/js/t.js"
></script>data-ts-mode="strict" for the strict mode. One script file, in every
mode — there is no separate cookieless build to swap in, and the src never
changes.
That is worth a sentence because other analytics tools do it the other way, with a second script file per mode. The cost of that design is a site left on the wrong mode by a tag nobody remembered to update. Here the setting decides and the tag records; they cannot disagree in a way that changes what is collected.
So switching modes requires no deploy. If you never touch the HTML again, the new mode still applies from the moment you save.
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.
GDPR, and what each mode changes about it
The mode you pick does not decide whether GDPR applies to you — running analytics on visitors in the EU means it applies either way, and you are the controller in all three modes.
What the mode changes is narrower and worth being exact about:
| Cookie | Cookieless | Strict | |
| Identifier on the visitor's device | Yes, one first-party cookie | No | No |
| Other storage | — | One sessionStorage key | One sessionStorage key |
| A privacy notice describing analytics | Still expected | Still expected | Still expected |
| Access and deletion requests | You still honour them | You still honour them | You still honour them |
The first row is the one that moves. The others do not, and a page that implied otherwise would be selling a compliance outcome we are in no position to promise.
This table used to carry a row claiming ePrivacy was out of scope on the
cookieless columns. That was withdrawn: the ts_ep key is storage, ePrivacy
asks about storage rather than about cookies, and whether an exemption applies
is your counsel's call and not ours.
Do you need a cookie banner? sets out the facts about
that key.
For the roles, the legal basis, and what a DPA covers, see GDPR. None of it is legal advice — it is written so your counsel has the facts.