Product Analytics & Telemetry Privacy
Understanding how people use the product is valuable. But analytics and telemetry quietly collect personal data, often sent to third parties, and that collection follows the same privacy rules as everything else. Measure what you need, with a lawful basis and consent where required. Collect as little as possible. Never let analytics become a hidden path that leaks sensitive data.
Product analytics (usage events, session recording, feature tracking) and operational telemetry can both capture personal data: identifiers, behaviour, sometimes content. It is easy to add a tracking call without thinking about privacy. But doing so creates the same obligations as any other data processing: a lawful basis, data minimisation, retention limits, and, for non-essential tracking, especially via cookies, user consent.
This sits alongside Privacy & Data Protection (the policy), Observability & Logging Hygiene (do not log sensitive data), and Cookie Consent (the web mechanics). The main point: analytics is data processing, so treat it as such.
Collect responsibly
- DoDecide the lawful basis before collecting usage or behaviour data, and get consent for non-essential analytics where the law requires it (see Cookie Consent & Tracking).
- DoMinimise: collect the specific events and fields you will actually use, not everything "just in case".
- DoPseudonymise or aggregate where you can. Measure behaviour without needing to identify the person.
- DoApply retention limits to analytics and telemetry data too, and honour data-subject rights over it (see Data Retention & Erasure).
- AlwaysTreat analytics and telemetry as personal-data processing, under the same privacy rules as the rest of the system. It is not a free-for-all.
Don't leak through analytics
- DoBe careful what gets captured automatically (form contents, URLs with ids, free text), and scrub sensitive fields before they are sent.
- DoVet analytics and telemetry vendors, and where they send data (often outside the EU), as third parties (see Vendor & Third-Party Risk).
- AvoidSession recording or detailed capture on pages with sensitive data (KYC, payments), unless it is carefully masked.
- NeverSend special-category data, full PII, secrets, or financial details into an analytics or telemetry tool (see Data Classification, Observability & Logging Hygiene).
analytics.track("FormSubmitted", { ...allFormFields });
// includes name, DOB, document number; sent to a 3rd-party tool
This tracking call just sent special-category KYC data to an external analytics vendor: a privacy breach hidden inside a metric. There is also no consent and no minimisation.
if (consent.analytics)
analytics.track("KycFormSubmitted", { stepCount, durationMs });
// behaviour only — no personal data in the payload
We learn what we need (how the flow performs) with no personal data sent, and only when the user has consented to analytics.
Self-review checklist
- AskWhat personal data does this analytics or telemetry actually capture, and do I have a basis (and consent if needed) for it?
- AskAm I collecting only what I will use, with retention limits?
- AskCould sensitive data be captured automatically (form fields, URLs, recordings)?
- AskWhere does this data go, and is that vendor and location compliant?