Cookieless & GDPR/ePrivacy
What the tracker stores on the device
Section titled “What the tracker stores on the device”Nothing. In the default configuration the tracker:
- sets no cookie;
- writes nothing to
localStorage,sessionStorageor IndexedDB; - takes no canvas, font, WebGL or audio fingerprint;
- calls no browser geolocation API, so no permission prompt appears.
It reads two localStorage keys if a visitor or a developer has set them —
tracing_disabled and tracing_debug — and it never creates either. See
Opt-out.
Why that matters for ePrivacy
Section titled “Why that matters for ePrivacy”Article 5(3) of the ePrivacy Directive — the “cookie law”, implemented as PECR in the UK — governs storing information on, or gaining access to information stored on, a user’s terminal equipment. Its consent requirement is about that storage and access, not about analytics as such.
A tracker that stores nothing and reads nothing it did not put there is outside the thing that rule regulates. That is the basis on which a cookieless analytics install is commonly run without a consent banner.
It does not follow that the processing has no legal basis requirement. GDPR still applies to the personal data involved, and a lawful basis — typically legitimate interests, with a balancing test you can show — plus transparency in your own privacy notice are still yours to get right.
What the identifier actually is
Section titled “What the identifier actually is”sha256( UTC day | rotating salt | IP address | user agent | site key )Truncated to 16 bytes. The IP address is not stored; it is an input and is discarded.
For the analytics data collected through your site, you are the controller and tracing.tools is the processor. You decide what is collected, how long it is kept, and who sees it. You are responsible for the notice you give your visitors and for the lawful basis you rely on.
For your own account — sign-in, billing, support — tracing.tools is the controller.
What you can turn into a compliance problem yourself
Section titled “What you can turn into a compliance problem yourself”The default install is austere. These are the ways a customer makes it otherwise, and each is your decision:
| Choice | Consequence |
|---|---|
| Personal data in event properties | Stored verbatim, visible to everyone with dashboard access |
Email or name in identify() traits |
Same, and it is directly identifying |
| Identifiers in URLs | Paths are stored; /invoice/ada@acme.com is now in your analytics |
| A public share link | Whatever is on the overview is readable by anyone with the URL |
| The Ask copilot | Aggregate context is sent to a third-party inference provider |
| Order ids or emails in revenue event properties | Stored verbatim, next to the amount |
Claims to be careful with
Section titled “Claims to be careful with”Some things the product’s own marketing says are product claims, not legal conclusions, and should not be repeated as compliance guarantees without your own review:
- “No cookie banner needed” describes the default configuration and the ePrivacy analysis above. It is not a determination about your site.
- “Compliant by design” is a design goal. Compliance is an outcome of your processing, not of a vendor’s architecture.
- No DPA, subprocessor list, security certification, breach-notification SLA or data-residency implementation is asserted here. If you need any of those, ask the operator in writing.
Doing your part
Section titled “Doing your part”- Name tracing.tools in your privacy notice, describe what it collects, and say where it sits in your processing.
- Record your lawful basis, and a legitimate-interests assessment if that is what you rely on.
- Keep personal data out of properties and traits unless you have decided to put it there deliberately.
- Offer an opt-out if that is part of your basis.
- Have a written processing agreement with the operator if one is required for you.