Analytics privacy notice: useful wording and claims to avoid
- 22 Jun, 2026
A privacy notice can be legally dense and technically wrong.
A common example says “we only use anonymous data” while the site sends full URLs, campaign identifiers and IP addresses to several providers. At the other extreme, some notices list twenty abstract categories without helping readers understand what analytics actually does.
Quality comes from alignment between:
- deployed collection;
- purposes;
- roles;
- consent or another applicable framework;
- retention;
- rights;
- the words used.
The GDPR requires information to be concise, transparent, intelligible and easily accessible. Articles 12, 13 and 14 govern much of the content. A useful analytics notice should remain readable while describing important facts with enough precision.
This is an editorial and operational method, not a universal clause or legal opinion.
Start with reality, not a downloaded template
Collect four internal sources before writing:
- the tracker inventory;
- the data collection summary;
- contracts, DPAs and subprocessor lists;
- consent and retention configuration.
The notice is the public view of verified facts. It should not be used to guess how the site works.
A legal template can structure headings. It cannot know whether you collect a full URL, store IP addresses, create a visitor identifier, allow vendor reuse, send free text, activate extended analytics after consent, export to a warehouse, or share identifiers across sites.
Those answers must come from the audit.
Use layered information
One ten-page policy is not always the best entry point.
Layer 1: information at the relevant moment
Near the choice or collection, state the essentials:
- purpose;
- controller;
- required or optional nature;
- link to details;
- means to accept, refuse or withdraw where consent applies.
For strictly limited measurement assessed as not requiring consent, a short notice can link to the analytics section.
Layer 2: dedicated analytics section
Explain:
- what is measured;
- why;
- how data are reduced;
- which provider is involved;
- how long information remains;
- how to exercise rights or ask questions;
- which capabilities depend on consent.
Layer 3: detailed documentation
A technical page or collection sheet can explain fields and transformations. It does not replace GDPR information, but it gives interested readers detail without overloading the first layer.
Every layer must tell the same story.
Sections to cover
1. Controller identity
Name the entity that determines purposes and means, with contact details. In a group, the visible brand is not necessarily the legal controller.
Include DPO details where applicable, or a clearly identifiable privacy contact.
Useful wording:
The controller for audience-measurement data on this site is [entity], available at [address or form]. For data-protection questions, contact [DPO or privacy contact].
Avoid:
We respect your privacy.
It states an intention but identifies nobody.
2. Specific purposes
Separate purposes instead of using “improve your experience” for everything.
Examples include:
- measuring visits and viewed pages;
- detecting navigation errors;
- understanding acquisition sources;
- measuring demo requests;
- producing aggregate statistics;
- personalising content;
- measuring advertising campaigns.
These do not necessarily share one legal framework. If minimal analytics runs by default and extended analytics starts after consent, say so.
Useful wording:
We use limited audience measurement to understand visit volume, viewed pages and main traffic sources. Enriched attribution and [other capability] are enabled only after your choice when consent is required.
Avoid:
We collect data to improve our services and offers.
It is too broad.
3. Data categories and signals
The notice need not reproduce every technical key, but it should be concrete.
Depending on the setup:
- page path;
- visit time;
- referrer domain;
- approved campaign parameters;
- reduced device and browser class;
- approximate country or region;
- conversion event;
- optional pseudonymous identifier;
- temporarily received IP address;
- consent choice.
Distinguish stored data from data used transiently to produce an aggregate result.
Useful wording:
For each visit, we record the page path, time, referrer domain when transmitted, device category and approved campaign parameters. The IP address is [describe exact handling]. Form contents are not sent to analytics.
Avoid:
We collect no personal data.
An IP address, identifier or combination of signals may be personal data depending on the processing.
4. Legal basis and tracker framework
Do not merge:
- storing or accessing information on the terminal under ePrivacy and national law;
- the GDPR legal basis for personal-data processing.
The analytics consent checklist explains the distinction.
Depending on the facts, the notice may refer to consent, legitimate interests after appropriate assessment, limited audience measurement under a conditional national exemption, or strictly necessary functionality.
Do not use a legal basis as a marketing badge. Explain how the choice operates or how the assessment is documented.
Avoid:
Our tool is CNIL compliant, so consent is not needed.
The CNIL states that the conditions depend on setup and context, and that providers cannot claim certification or approval based on its self-assessment.
5. Recipients and providers
Identify recipient categories and, where it improves transparency, key providers.
Explain roles for internal authorised teams, analytics vendor, hosting provider, technical support, agency and data warehouse.
“Trusted partners” is not specific enough.
Assess whether each provider is a processor, independent controller or another role based on the facts and contract.
6. International transfers
Where data are accessible or transferred outside the EEA, explain relevant countries or categories, mechanisms and how to obtain more information.
Do not confuse hosting region, vendor headquarters, support access, subprocessors and legal transfer.
“Hosted in Europe, therefore no transfer” requires verification of the entire chain.
7. Retention
A phrase such as “as long as necessary” needs concrete periods or criteria.
Separate:
- tracker or identifier;
- raw events;
- aggregate reports;
- security logs;
- backups;
- exports.
Useful wording:
Analytics events are retained for [period]. Aggregate statistics remain for [period or criterion]. Technical logs have a separate [period]. Manual exports are deleted under [procedure].
For the French CNIL framework, the thirteen-month tracker-lifetime and twenty-five-month collected-information recommendations are reference points to assess, not values to copy blindly.
8. Rights
Explain applicable rights and provide a simple contact method. Depending on basis and processing, rights may include access, rectification, deletion, restriction, objection or portability.
Truly anonymous analytics may not permit identification for an individual request. Explain this precisely rather than using anonymity as a blanket exception.
Include the right to lodge a complaint with the competent supervisory authority.
9. Withdrawal or objection
Where consent applies, provide an accessible way to withdraw it according to applicable rules.
Where another basis applies and a right to object exists, explain the process.
A “manage cookies” link must work on mobile, remain visible and change actual tag behaviour.
10. Date and changes
Add a last-updated date and a process for material changes.
Review the notice when the team adds a tool, purpose, identifier, retention period, export, provider, country or consent change.
A concise change history can help returning readers.
A short section to adapt
This is an editorial skeleton, not a publication-ready clause.
Audience measurement
We use [tool] to measure visits, viewed pages and main traffic sources. This helps us detect navigation problems and evaluate content usefulness.
Depending on our configuration, processed data include [concrete list]. [Describe IP and identifier handling]. Form contents and unapproved URL parameters are not sent.
[Provider] acts as [role] and processes data in [relevant locations and transfers]. Data are retained for [periods by layer].
[Explain the ePrivacy framework and GDPR legal basis, including consent operation where applicable].
You may exercise your rights or ask a question at [contact]. You may [withdraw consent / object] through [method].
Every bracket requires a verified answer.
Wording that weakens credibility
“Completely anonymous data”
Use this only when the method supports the claim and the information can no longer reasonably identify or single out a person.
Otherwise use precise descriptions such as aggregate data, identifiers removed, pseudonymised data, reduced granularity or IP address not retained in events. These terms are not interchangeable.
“No data are shared”
When a provider hosts or processes collection, it receives data as part of the processing. “Data are not sold” or “not used for advertising” may be accurate, but “no sharing” is often not.
“GDPR compliant”
Compliance depends on the controller, purpose, setup, contract and operations. Describe measures instead of issuing a universal verdict.
“Necessary cookies”
Explain necessary for what. A marketing team finding a tracker useful does not make it technically necessary.
“We may change this policy at any time”
This does not explain material-change handling. Add a date and an appropriate notification process where required.
Align the notice with product delivery
Policies are often reviewed annually while stacks change weekly.
Add a release control:
- every new tag request states purpose, data and provider;
- the privacy or analytics owner assesses impact;
- the collection summary is updated;
- the notice and CMP change where necessary;
- deployment is tested;
- evidence is retained.
For URLs, apply the parameter allowlist before the notice promises reduced collection.
A twelve-question editorial audit
Ask:
- Is the controller identifiable?
- Are purposes separated?
- Are data described concretely?
- Is temporary receipt distinguished from storage?
- Is the GDPR legal basis stated?
- Is the tracker regime explained without shortcuts?
- Are providers and roles clear?
- Were transfers verified?
- Are retention periods concrete?
- Are rights and contact accessible?
- Does withdrawal or objection work?
- Does the text match the current network and configuration?
A negative answer triggers a correction to the stack, the text, or both.
Conclusion
A good analytics privacy notice does not reassure through adjectives. It provides understandable facts.
It explains who measures, why, with which signals, for how long, through which providers, under which framework and with which controls for individuals.
Start from the technical inventory, write in layers, validate necessary legal qualifications and connect every stack change to documentation updates.
Transparency is not separate from the product. It is the public description of its governance.
FAQ
Should the analytics vendor be named?
The GDPR requires information about recipients or recipient categories. Naming the main provider often improves clarity, although the precise form depends on the processing and notice structure.
Can the notice say data are anonymous?
Only when anonymisation is demonstrated. Pseudonymised, aggregated or IP-free data are not automatically anonymous.
Does the notice replace a consent banner?
No. The notice provides detail. Where prior consent is required, a valid choice must occur before covered trackers start.
Must every analytics event be listed?
Not necessarily in the first layer. Use concrete categories and provide deeper documentation where useful. Sensitive or unexpected events require explicit assessment.
What if a vendor changes subprocessors?
Assess recipients, transfers, contracts and risk, then update documentation and information where necessary.
