Privacy Policy

This policy covers two groups, and they are not treated the same. Customers are people with a TrueStat account. Visitors are people who browse a website that runs our tracker — they have no account and no relationship with us.

For customers we hold an account. For visitors we hold no name, no email, no advertising identifier, and no profile that follows them from one customer’s site to another.

Each recorded event is one row containing, at most:

• the page path, hostname and entry path
• the referring URL and the traffic channel derived from it, plus any UTM parameters
• country, region and city, derived from the IP and then discarded (see below)
• browser, operating system and device class, derived from the user-agent string
• a timestamp, and an opaque session identifier
• whether the request came from a bot, and which one — this is what makes AI crawler reporting possible
• for customers using revenue tracking, a payment amount and currency, plus any custom event name and properties they choose to send

Custom event properties are chosen by the site owner. We do not inspect them, and a site owner who puts personal data in one is the controller of that data — our terms ask them not to.

A visitor’s IP address reaches our collector, is used to derive an approximate location and to compute a hashed session identifier, and is then gone. It is never written to the analytics store, never written to a log line, and never attached to an error report. There is no code path in TrueStat that returns or displays an IP address.

The session identifier is hashed together with the site’s own id. That is deliberate: the same person visiting two different customers’ websites produces two unrelated identifiers, so there is no cross-site profile to build — by construction, not by promise.

Site owners choose one of three identity modes per site, and the choice changes the answer here. We would rather state this plainly than claim a blanket exemption:

• First-party cookie (the default) stores a random identifier in a first-party cookie on the customer’s own domain. It holds no personal data and is never read by us on any other site, but it does persist across days — which is what makes “returning visitor” and long-horizon attribution answerable at all. In several jurisdictions a cookie like this still requires a notice, so sites on this mode should keep one.
• Salted hash sets no cookie. The identifier is a hash whose salt rotates every 24 hours; once a day’s salt is deleted, no later access to the data can re-derive who a session was.
• Strict cookieless sets no cookie and additionally coarsens the inputs before hashing, so the identifier describes a rough population bucket rather than a device. It is the most private mode and the least precise, and we say so where the choice is made rather than in a footnote.

The two cookieless modes set no cookie of any kind and need no consent banner for TrueStat. TrueStat’s own website uses a cookie only to keep you signed in.

An account holds an email address, an organisation name, the sites you have added, your settings, and your subscription state. Passwords are handled by our authentication provider and we never see them; if you sign in with Google there is no password at all — see Signing in with Google below.

Card details never reach our servers. Checkout and billing run entirely on Stripe; we store an identifier that points at your Stripe record and the plan you are on.

You can create an account or sign in with a Google account instead of a password. When you do, Google sends us your email address, your name and your profile picture, and a confirmation that the email is verified. That is the whole of what we ask for: the email and profile scopes and nothing else. Signing in never asks for Gmail, Drive, Calendar, Contacts or any other Google service. The two optional integrations below ask for their own, separate permission, and only when you choose to connect them.

We use that information for one thing: to identify your account. The email is your login and the address we write to; the name and picture appear next to your account in the panel and on invitations you send to teammates. Nothing from Google is used for advertising, profiling, or analytics of any kind, and we never combine it with visitor data from the sites you measure.

The email, name and picture are stored with your account by our authentication provider, Supabase, for as long as the account exists. Signing in leaves us no lasting Google token: once the sign-in completes we cannot read anything from your Google account. The integrations below are different, and say so.

We do not share Google user data with anyone. It is not sold, not passed to advertising networks, and not disclosed to third parties, with the single exception of the processors listed below that run the service itself. You can disconnect Google at any time from your Google account permissions; deleting your TrueStat account deletes the copy we hold. One thing we cannot do for you: Google keeps TrueStat in your list of connected apps until you remove it there, because the sign-in grant is Google’s record, not ours — and once your account is gone, nothing can be read through it.

Our use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.

Two optional integrations read data from your Google account. Neither is on by default; each starts only when you press Connect in a site’s settings and approve Google’s consent screen for that one integration.

What we ask for. Search Console uses the webmasters.readonly scope; Google Analytics uses analytics.readonly. Both are read-only. We cannot change anything in your Google account, and we ask for no other scope.

What we read, and what for. From Search Console: the search terms that brought visitors to your site, the pages they landed on, clicks, impressions and average position — shown in the Keyword tab beside what the site already measures. From Google Analytics: daily and hourly page views, sessions and users, broken down by page, entry page, hostname, channel, source, medium, campaign, campaign term and content, country, region, city, device, browser and operating system, plus new versus returning visitors and Google’s own bounce rate and average session duration — all of it for the period before your site started sending events to us, and shown on your dashboard for those days, each row marked with a Google Analytics icon. That is the only use. We do not use this data for advertising, profiling, training models, or anything you cannot see on your own dashboard, and no person at TrueStat reads it except to investigate a fault you report.

What we store. A refresh token that lets us fetch on your behalf, encrypted at rest with a key held outside the database (the cipher, key size and where the key lives are on our security page); the property you chose; and the rows Google returned. Search Console rows are refreshed daily and kept for your plan’s retention period. Google Analytics history is fetched once and kept until you disconnect that integration or delete the site; disconnecting deletes it. All of it lives with your other site data at Supabase, in the EU.

Sharing. None. This data is not sold, not passed to advertising networks, and not disclosed to anyone but the processors listed below, who host it and nothing more.

Disconnecting. Press Disconnect in the site’s settings and we revoke our access at Google and delete the token. You can also remove TrueStat from your Google account permissions; Google tells us the moment you do, and we remove the connection on our side right then — you do not need to tell us. (If that notice ever fails to reach us, the next time we try to fetch Google refuses, and we remove the connection on our side within the hour.) Search Console data already fetched stays on your dashboard until you delete the site. Imported Google Analytics history is deleted when you disconnect that integration from your settings; a revocation on Google's side removes our access and leaves the history in place until you disconnect or delete the site.

Our use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.

If you turn it on for a site, we search X once a day for public posts that link to that site or mention the brand terms you enter, so the posts appear on your timeline beside the traffic they brought. This connects no account: the search runs under our own application key, you never sign in to X through TrueStat, and we can neither read your private messages nor post anything.

From each post found we keep what any reader of it can see — the text, the author’s handle, display name and profile picture, the follower count, the time it was published and its link. That data is stored with your site’s analytics and follows the same retention period; deleting the site or your account removes it. Turning the integration off stops all further searching.

What X does with the search request itself is governed by X’s privacy policy. We send it a query, never your visitors’ data.

Threads is optional, off until you connect it, and connected per site rather than per account. When you connect it we ask Meta for three permissions and no others: threads_basic, which every call requires and which returns your username, display name and profile picture; threads_keyword_search, which searches Threads for posts containing the brand terms you enter; and threads_manage_mentions, which lists posts that tag your account. We never ask for permission to publish, and nothing in TrueStat can post to Threads on your behalf.

We use it for one thing: to show, on your analytics timeline, the posts that mention your brand next to the traffic they arrived with. From each post we keep its text, its author’s username and profile picture, the time it was published and its permalink — the same information any reader of that post can see. It is never used for advertising or profiling, never combined with the visitor data from the sites you measure to identify a person, and never used to train a model.

The access token is encrypted with AES-256-GCM before it is written and is only ever decrypted on our servers to make a request to Meta; it is never sent to your browser. Posts we have found are stored with your site’s analytics data and follow your plan’s retention period, like everything else on the timeline. Profile pictures are not copied — we keep the address Meta gave us, which expires on Meta’s own schedule.

We do not share Threads data with anyone: not sold, not passed to advertising networks, not disclosed to third parties beyond the processors listed below that run the service itself. You can disconnect Threads at any time from the integration’s settings, which deletes the token and stops all further requests; removing TrueStat from your Threads account settings has the same effect, and Meta notifies us so the token is deleted at our end too. What Meta does with the data on its own side is governed by the Meta Privacy Policy. A data deletion request made through Meta reaches us the same way and erases the token and the connection. Posts already on your timeline stay, because a public post about a customer’s product is that customer’s analytics record in the way a referral from a blog is — they expire with the retention period like the rest of it, and deleting your TrueStat account or the site removes them at once.

Analytics data is kept for the retention period your plan sells: three years on Starter and five years on Pro. When a subscription ends we keep the data for a short grace period so a returning customer does not lose their history, and then delete it.

Account data is deleted when you delete your account. Records we are required to keep for tax and accounting — invoices, chiefly — are kept for as long as the law requires and no longer.

We use four processors, each for one job:

• Vercel — hosting and delivery of the application
• Supabase — accounts, sign-in (including Google sign-in), sites, settings, subscription records, and the encrypted tokens and imported rows from the Google integrations above
• Tinybird — the analytics event store
• Stripe — payments and subscription billing

Two more companies appear above, in the other direction: X and Meta are sources we READ from, not processors we send data to. When an integration is on we ask them for public posts; we never hand them your visitors’ data, and the only thing they learn is that we searched. Their own handling is covered by X’s privacy policy and the Meta Privacy Policy.

We do not sell data, we do not share it with advertising networks, and we run no third-party trackers on our own site.

You can ask for a copy of what we hold about you, ask us to correct it, or ask us to delete it. You can delete your account yourself from Settings, which removes your account data and anything Google sent us at sign-in; or write to privacy@truestat.io and we will answer within 30 days.

If you are a visitor rather than a customer, the site owner who runs the tracker is the controller of that data. We act on their instructions and will pass your request to them. Because we hold no name, email or cross-site identifier for visitors, we usually cannot identify a single person from our records — that limitation is the point of the design, and it means some requests can only be answered by the site owner.

Customers processing personal data on behalf of others should read our Data Processing Addendum.

When this policy changes, the date at the top changes with it. If a change materially affects what we collect, we will tell account holders by email rather than relying on you to notice.

Questions go to privacy@truestat.io.