Skip to main content

​
What this lets you do

Delete all event data Traceten holds for a specific visitor or session, or look up and delete what’s stored for a visitor identified by email. Deletion is permanent and cannot be undone.
This page covers data about visitors to your site. To delete your own Traceten account and the personal data we hold about you as our customer, see Deleting your Traceten account.

​
Before you start

  • An API key for your account. Erasing data needs the Delete visitor data permission (privacy:delete); the read-only access endpoint needs Read visitor data (privacy:read) instead. New keys carry neither by default, so tick the one you need when you create the key. They are separate permissions because erasure is irreversible and answering an access request is not.
  • The visitor ID (_traceten_vid cookie value) or session ID (_traceten_sid cookie value) from the visitor’s browser, if you have it. If not, use the email-based lookup below.
  • Your site’s UUID, not its ttid_ snippet key. See below.

​
Which site identifier these endpoints take

Every YOUR_SITE_ID on this page is the site’s UUID, the value in your dashboard URL (app.traceten.com/dashboard/sites/018f0000-…). Two write endpoints outside this page take the UUID as well: POST /v1/ingest/conversions and POST /v1/consortium/fingerprints. Everywhere else, an API key sends and receives the public ttid_ snippet key. That has a consequence worth stating plainly, because it will bite an integration that only ever holds a key: no API endpoint hands you the UUID. You have to copy it out of a dashboard URL once, then keep it wherever your deletion job lives. All three endpoints on this page work this way: DELETE /v1/privacy/data, DELETE /v1/privacy/sites/{siteId}/visitors/{email} and GET /v1/privacy/sites/{siteId}/visitors/{email}. We have not widened any of them to accept both shapes, and we will not do it quietly. Erasure is irreversible, so changing what identifier it accepts is a decision to make deliberately rather than a convenience to slip in. A ttid_ key sent here is rejected with 422, not interpreted.

​
Deleting by visitor or session ID

Pass sid instead of vid to delete a single session’s data:
Supply exactly one of vid or sid. The call returns 204 No Content once deletion is issued; the underlying purge runs asynchronously and typically completes within minutes. Deleting by vid removes the visitor’s full history. Deleting by sid removes only that session. Use vid for a complete erasure. What a per-visitor deletion cannot reach. Every record that carries the visitor identifier is removed. The aggregated daily rollups behind your trend charts do not carry one: they hold counts, and their distinct-visit figures are approximate sketches with no identifier column to match a deletion against. The structure has no remove operation either, so this is a property of the storage, not a gap in the API. Deleting the site or the account clears these sketches completely. For the rollups we keep for the life of the account, that is the only thing that clears them. The three time-limited rollups, the daily visitor count, top pages by country and the daily count of sessions and visitors per outbound link domain, also expire on their own after 730 days. We state this rather than calling the rollups anonymous because below a certain size a sketch retains a hash of each distinct identifier it counted, so someone who already holds a particular visitor identifier can test whether it is present. We do not do that, and no feature depends on it.

​
Looking up or deleting by email

When you only know the customer’s email (for example, a support request), Traceten can resolve it to the visitor(s) it corresponds to and act on all of them:
The email is used only to resolve the matching visitor(s); it is never stored or logged.

​
Linked anonymous activity is included

Deleting by email also removes the visitor’s activity from before they were ever identified. This matters because a visitor is a random anonymous ID until they log in or place an order, at which point they get a new identity-derived ID. Those are two different values. If you have called identify(), or you use the Shopify integration, Traceten holds a record linking them, and an email-based deletion follows that link, so the earlier anonymous records go too. Concretely, deleting by email removes:
  • events, sessions, conversions and revenue records under the identity-derived ID
  • the same records under every anonymous ID linked to it
  • the link records themselves
Known limitation if you identify by account ID. When you call traceten.identify({id}) and supply an account ID, records after that point are filed under an ID derived from the account ID rather than the email. A deletion request made by email currently does not reach those records. If this applies to you, delete by the _traceten_vid value as well, or contact us. We are closing this gap before it can affect a live deletion request.
The access endpoint follows the same links, so a subject access request covers the visitor’s whole journey rather than only the portion after they identified themselves. Its response includes an identity_links array showing which IDs were linked, when, and by what route. Note what the response contains: the linked visitor IDs, a count of matching raw events, the session records themselves (sessions, with session_count and a sessions_truncated flag), the revenue attributions, and the identity links. Each session record holds that session’s entry page, its exit page (the last page measured in the visit), attributed source, the utm_campaign and ref parameters from the entry URL where the link carried them, city and country, device type, operating system and browser, pageview count, foreground time, and the cart token where one applies. The exit page is blank for sessions that started before we began recording it, which means “not recorded” rather than “no exit page”. Raw event rows are still summarised as a count rather than returned, so referrers and raw user-agent strings are not included. If a data subject asks for those under Article 15(3), contact us and we will extract them.
Deleting by a single _traceten_vid value does not follow these links. It removes only the records under that exact ID. When you have the customer’s email, prefer the email-based deletion above; it is the one that reaches everything.

​
AI crawler records

If you have installed AI crawler tracking, the access and deletion endpoints above do not reach your crawl records, and that is a deliberate decision rather than a gap. Why. A crawl record describes a request made by automated software. It carries no visitor ID, no session ID, no cookie and no email, so it holds nothing the endpoints above accept as a lookup key, and nothing joining it to a person’s browsing on your site. That is a statement about the API, not a claim that these records can never be matched to anyone. A crawl record does carry a keyed hash of the requesting address, and that hash is deterministic for a given site, so if a person supplies the address itself, we can recompute the hash and find their rows. What we cannot do is start from an email or a visitor ID, which is what a self-service endpoint would have to do. This is the situation GDPR Article 11(2) describes: we are not required to acquire extra data purely to identify someone, but where the data subject provides information that makes identification possible, their rights apply in full. We handle those by hand rather than pretending an endpoint covers them. The three daily rollups behind your long-term crawl trends are daily counts grouped by crawler, provider, category and verification state, by page path, and by page path and crawler. They carry no address, no hash of one, and no personal identifier, so there is genuinely nothing in them to erase for an individual. What we still do.
  • Every individual crawl record, including any retained address, is deleted after 90 days on every plan. That limit is enforced by the database.
  • Closing your account erases every crawl record and all three rollups, for every site on the account. See Account deletion.
  • An address that we could not verify as crawler infrastructure is never stored raw in the first place. Only the hash exists, from the moment the report reaches us.
If you receive a request you believe reaches crawl data, email privacy@traceten.com with the IP address the person has given you, and the site and date range. That address is what makes the lookup possible. The realistic case is someone whose address appears in the unverifiable share of crawl traffic. We handle these by hand rather than through an endpoint, because an endpoint would have to accept a raw IP address from an unauthenticated caller, which is a worse privacy trade than doing it manually.

​
AI visibility records

If AI visibility is running for your account, the access and deletion endpoints above do not reach your visibility records either, for a simpler reason than the crawl case. A visibility record describes what an answer engine said when Traceten asked it one of your prompts. It carries no visitor ID, no session ID, no cookie, no email and no IP hash (not even a deterministic one), so there is no key of any kind that could be used to look one up for a person. Nothing in it joins to anybody’s browsing on your site. The records are not free of personal data, and it is worth being precise about whose. A stored answer is unredacted prose written by a third party, and it can name people: a competitor’s founder, an author of a cited article, anyone the model chose to mention. So can a citation title. Those people are not your visitors and have no relationship with you or with us, and no lookup key exists for them. What we still do.
  • Every stored answer and citation list is deleted after 90 days, and every mention and resolved citation after 365 days. Both limits are enforced by the database.
  • Deleting a site, or closing your account, erases all of it for the affected sites, including the daily rollups. The rollups have no expiry of their own, so that is the only thing that clears them. See Account deletion.
  • Erasure is confirmed complete before we record it, rather than merely started.
If you receive a request from someone named in a stored answer, email privacy@traceten.com with the name and the site. We handle these by hand. Note that we did not write the text and do not control the engine that did: removing it from our storage does not remove it from the engine, and the person’s more effective route is usually to the engine’s own operator.

​
Handling user deletion requests

When a visitor requests deletion of their data under GDPR or CCPA:
  1. Identify their records. If the visitor is still on your site, read their _traceten_vid cookie value. Otherwise, use the email-based lookup above if they previously called identify().
  2. Submit the deletion request. Use one of the API calls above.
  3. Document the request. Keep a record of deletion requests for compliance purposes. Traceten does not store deletion request logs.

​
Opt-out vs. deletion

Deletion removes historical data. Opt-out reduces, but does not stop, future collection. They are separate operations, and only one of them is complete. Opt-out does not stop collection. Setting the opt-out cookie (or sending DNT: 1) stops the persistent visitor cookie, the higher-entropy device signals, the cart token, and exit, click, and in-app navigation tracking. The initial page view is still sent, and country and city are still derived from it. See Opt-out and Do Not Track. If you need to honor an Article 21 objection, do both of these:
  1. Stop future collection by setting the visitor’s consent state to denied through your consent tool. We enforce this server-side: no event is stored. The opt-out cookie alone will not achieve this.
  2. Remove data already held using the deletion API described on this page.
If your site does not run a consent management platform, there is currently no way to stop collection prospectively for a single visitor. Deletion is the mechanism available to you, and it can be repeated. Tell us if this is blocking a live objection.