Our position, stated plainly. Not legal advice — written so that your counsel has the facts they need.
The roles
You are the controller. We are the processor.
You decide to run analytics on your site and you decide what is collected. We process what arrives on your instructions and for no other purpose. We do not use your data for our own ends, do not sell it, do not share it, and do not join it with anything.
Is the data personal data?
Honestly: it depends on the mode, and the safest answer is to treat it as personal data on the default.
On the first-party cookie mode, a persistent identifier tied to a device is generally treated as personal data under the GDPR even when it carries no name. Assume it is, and process it accordingly. That is the position this documentation takes, and it is why the DPA exists.
On the two cookieless modes, the argument for pseudonymous-and-not-personal is stronger: the identifier is derived from a secret that is deleted within 24 hours, after which nobody — including us — can reverse it, because the input no longer exists. That is a meaningful difference from a stored pseudonym. Whether a given regulator accepts it is not ours to assert, and we do not.
Either way, no IP address is stored on any mode, which removes the single field most often at issue.
What supports each principle
Data minimisation. The complete stored field list is on What we store, and what we don't and it is short. No IP, no fingerprint, no form data, no session replay, no query strings, no third-party calls.
Purpose limitation. Your data is used to render your dashboard and answer your API calls. Nothing else.
Storage limitation. Rows are deleted at the end of your tier's retention window — 3 years on Starter, 5 years on Pro — automatically, not on request. See Data retention.
Integrity and confidentiality. Data is isolated per organisation at the database level rather than by query convention. Access requires either a signed-in session with an accepted membership, an API key scoped to your organisation, or a share link you created. There is no fourth path.
Data subject requests
A visitor asking you to exercise their rights runs into a structural limit, and it works in their favour.
We cannot identify a specific person's data, and neither can you. There is no name, no email and no lookup table. The identifier is a hash.
On the cookieless modes, the input needed to reproduce it is deleted within 24 hours, so a request that arrives the next day cannot be matched to anything even in principle.
On the cookie mode, matching would require the visitor's own
ts_vidcookie value, which only they have. There is no way to find it from an email address or a name.
The practical consequences for the usual rights:
| Right | Position |
| Access | There is no data identifiable to an individual to produce. |
| Erasure | Nothing individually identifiable exists to erase. On the cookie mode the visitor can clear the cookie, which severs the link at their end. Site-wide deletion is available to you at any time — see Deleting your data. |
| Rectification | Nothing to rectify — there are no attributes about a person. |
| Objection | A visitor can block the script, use an ad blocker, refuse cookies, or set localStorage.truestat_ignore on your origin. Your site can also honour a signal by not loading the tag. |
| Portability | Your site's aggregate data is exportable by you. There is no per-person export. |
If you get a request you need help answering, write to privacy@truestat.io.
Legal basis
Yours to determine, and it differs by mode:
On the cookie mode, storing the cookie engages the ePrivacy rules independently of the GDPR, and consent is the usual basis. See Do you need a cookie banner?.
On the cookieless modes, nothing is stored on the device, so the ePrivacy storage rules do not engage. Legitimate interest is the basis most operators rely on for the processing itself, and the minimality of what is processed is what makes that argument reasonable.
Sub-processors
Two, and they are listed with what each holds:
| Sub-processor | Role | Region |
| Supabase | Database and authentication — this is where your analytics data lives | EU (Frankfurt, eu-central-1) |
| Stripe | Payment processing — billing details only, never analytics data | Global, with EU processing for EU customers |
Our hosting provider serves the application and terminates requests but does not store your analytics data.
Details on Where your data is stored.
Transfers
Analytics data is stored in the EU. See Where your data is stored.
Data processing agreement
Available — see Data processing agreement.
Breach notification
If we become aware of a breach affecting your data, you are notified without undue delay, with what we know at the time rather than after the investigation concludes. Security contact: security@truestat.io.