What Tastatur collects

Written to be checked rather than believed. Every claim on this page corresponds to code you can read — the file paths are given so you can go and look.

The short version

No cookie is set on the site you visited. Tastatur sets none there and reads none. (The site owner's own Tastatur dashboard uses login cookies, which are a different thing entirely and are covered below.)

Nothing is stored on your device. No localStorage, no sessionStorage, no IndexedDB, no cache abuse.

No fingerprinting. No canvas, WebGL, font, audio, plugin, battery or hardware probing. You can read the entire tracking script — it is served unminified at /t.js.

No cross-site or cross-device identity. The identifier is scoped to one site and lasts under 24 hours by construction.

No advertising, no data sales, no third parties. Your data is never pooled with another customer's and is never used to improve our own product.

What is actually transmitted

When you load a page on a site using Tastatur, the script sends exactly this and nothing more (see lib/tracker/t.js, function payload()):

Site token

Which site is being measured. Public by design.

Page path

The path only — the query string is discarded except utm_* campaign tags, and personal data is stripped from the path itself.

Referrer host

news.ycombinator.com, not the full referring URL. The path of a referring page can itself identify someone.

Window width

Bucketed server-side into one of five sizes, then discarded. The exact pixel value is never stored.

Event name

"pageview", or a custom name the site owner chose.

The part most tools are vague about

Your IP address and user-agent string reach our server, because every HTTP request carries them. We will not pretend otherwise — under GDPR an IP address is personal data (Breyer, C-582/14), and under the CCPA it is expressly listed as personal information.

Here is what happens to them:

1. They are combined with a rotating secret and a site identifier into an HMAC-SHA-256 digest, truncated to 128 bits.

2. The user-agent is reduced to four coarse facts — browser family, major version, operating system, and one of desktop/mobile/tablet. The string itself is discarded.

3. The IP is used once more to look up a two-letter country code. No region, no city, no coordinates, no network operator.

4. Both are then out of scope and gone. Neither is written to the database, to a log, or to disk anywhere.

This happens in app/lib/ingest/identifier.rb, the only place in the codebase where a visitor's IP address is used for anything. The two ingest endpoints read it from the request in order to hand it over. Nothing else in the application receives it, and neither path stores it.

One exception, stated here rather than buried: if you hold a Tastatur account, we record the IP of your two most recent sign-ins to the dashboard, so you can spot a login that was not you. That is about you as a customer, not about visitors to any site you measure, and it is listed in the privacy policy.

Why the identifier stops working every day

The secret in step 1 is replaced every 24 hours and the old value is destroyed. Once it is gone, the digests made with it cannot be recomputed or matched against anything — not by an attacker with our database, and not by us.

That secret lives only in a Redis instance running with persistence disabled and excluded from every backup. This is deliberate and it is the load-bearing detail: a salt written into a snapshot would sit in a backup next to the very events it would de-anonymise, and a restore would bring it back.

The honest characterisation. While a salt is live, the data derived from it is pseudonymous, not anonymous. Once the salt is destroyed the link cannot be rebuilt and the data is unlinkable. We describe it that way rather than calling it "fully anonymous", because during the salt window that would not be true.

The practical consequence for reporting: a visitor who returns tomorrow is a new visitor as far as Tastatur is concerned. A 30-day visitor count is therefore the sum of 30 daily counts, not a count of distinct humans. That is a real limitation of measuring without tracking, and we would rather state it than quietly report a number that means something different from what it says.

Cookies, precisely

On your visitors' devices

Nothing

No cookie is set and none is read. Nothing is written to localStorage, sessionStorage or IndexedDB. No identifier is stored on the device in any form. This is the part that determines whether you need a consent banner for Tastatur, and it is the promise the product is built around.

On this dashboard, for you

Up to three

A first-party session cookie, set when you sign in, so you stay signed in. A second if you tick "stay signed in". A third if you use two-factor authentication and ask us not to send a code to this browser every time. All strictly necessary for a login and exempt from consent on that basis. They are set on our site, for account holders, and never touch the sites you measure or the people who visit them.

We say this explicitly because "no cookies" is used loosely in this category. A login needs a session cookie; pretending otherwise would be nonsense rather than privacy. What matters is that nothing of ours reaches your visitors.

If you are a visitor reading this because a site you used links here: the second column does not apply to you at all. It describes the login on this analytics dashboard, which only the site's owner uses. Nothing was stored on your device.

Small numbers are withheld

A report row that describes two or three people is not a statistic; combined with outside knowledge it can identify them. So any breakdown row seen by fewer than the site's threshold of distinct visitors is withheld, and if withholding a single row would let you recover it by subtraction, a second row is withheld too. The dashboard says when this has happened rather than silently showing a shorter list.

Opting out

Tastatur honours Do Not Track and Global Privacy Control by default. If your browser sends either, no identifier is computed and no event is recorded — only an anonymous counter is incremented so site owners can see that some requests opted out.

Because we store nothing on your device, we have nowhere to record a per-person opt-out — and building one would mean keeping a durable identifier for exactly the people who asked us not to. A browser header is the right mechanism here.

Your rights

The site owner is the data controller; we are their processor. Requests to access, erase, restrict or object should go to the operator of the site you visited — they decide what is collected and for how long, and they can delete a site's entire history at any time, which removes it here immediately and irreversibly.

For our part, what we hold carries no identifier that resolves to a person. Once the day's secret is destroyed nobody, including us, can work out which rows belonged to you, so there is no lookup we could honestly offer you: any search we ran on the strength of a shared address and a browser header would be as likely to return somebody else's browsing as your own. GDPR Art.11(1) covers exactly this position, and the unlinkability it rests on is the same property described further up this page.

Shorter answers to the questions this page gets asked about — consent banners, GDPR, why the numbers differ from Google Analytics — are on the FAQ.

Tastatur is free software under the AGPL-3.0. If you want to verify anything on this page, the source is the authority — this document only describes it.

IP geolocation by DB-IP (db-ip.com), used under CC BY 4.0.