A privacy friendly tracking plan lists every event with its purpose, its allowed properties and the data class of each, and rejects anything not on the list. Never send emails, names or free text as event properties. Use a pseudonymous user ID and decide up front what consent you need before any event fires.
The problem with ad hoc events
Analytics grows by accretion. A developer adds a property to debug a funnel, such as the search query or the user's email, and it flows to a vendor forever. Free text fields are the worst, because people type names, addresses and health details into search boxes.
Under Article 5(1)(b) data must be collected for specified, explicit and legitimate purposes, and Article 5(1)(c) says limited to what is necessary. A tracking plan is how you show both.
What to write for each event
A short table per event:
- Name and trigger, such as
checkout_startedwhen the cart page opens. - Purpose, in a sentence: "measure drop off between cart and payment."
- Properties, each with type, example and data class.
- Identifier used, anonymous session ID or pseudonymous user ID.
- Consent needed, yes or no, as agreed with whoever owns that decision.
- Retention in the analytics tool.
- Owner, by team.
If you cannot write the purpose, do not ship the event.
Property rules
- No direct identifiers: no email, name, phone or address.
- No free text: send a category or a length, not the content. Record that a search happened and the result count, not the query.
- Generalise: send an age band, a country or region, not exact values.
- Hash is not anonymisation: see hashing emails is not anonymization.
- Avoid URLs with personal data in paths or query strings. Strip them before sending.
Enforce in code
Put one wrapper around the analytics SDK. It accepts only events defined in a schema file, validates properties against the allowlist, and drops or flags unknown ones. Developers cannot call the vendor SDK directly, enforced by a lint rule.
Make the schema file reviewed like code, so adding a property is a visible, discussed change.
Consent and loading
Where your rules require consent for analytics, gate the SDK load and event sending on the consent state, checked at the point of use. Tie this to your consent log so you can show what applied when.
Audit regularly
Every quarter, export the properties actually received by your analytics tool and compare them with the plan. Extra or surprising properties point to a bug or a bypass. Delete what should not be there.
Quick check
Can I send a user ID instead of an email?
Yes, an internal pseudonymous ID is better. It is still personal data if you can link it to a person, so keep the mapping protected.
What about session replay tools?
They capture screens and can record sensitive fields. Mask inputs by default and review them as high risk.
Sources
Last reviewed: 19 October 2026.
