Privacy policy requirements
Privacy and data-protection laws generally require a clear, accessible privacy notice telling people what data you process, why, on what basis, who receives it, how long you keep it, and what rights they have. This page summarises, educationally, the disclosure elements transparency rules commonly expect and how analytics fits into a notice.
Common disclosure elements
Across regimes like the GDPR's Articles 13–14 and various US state laws, a privacy notice is expected to cover a recurring set of points: who the controller is, the categories of data processed, the purposes and (where relevant) lawful basis, the recipients or categories of recipients, retention periods or criteria, any international transfers and their safeguards, and how individuals exercise their rights.
- Controller identity and contact
- Data categories, purposes, and lawful basis
- Recipients, retention, and international transfers
- How to exercise data-subject rights
Describing analytics honestly
For analytics, the notice should reflect what actually happens: whether measurement is first-party or shares data with third parties, whether identifiers or cookies are used, how long event data is retained, and whether data leaves the region. The notice must match the implementation — a generic template that understates recipients or retention is a transparency problem regardless of how the analytics is configured.
How it appears in analytics and logs
If your analytics collects data not described in your privacy notice — extra recipients, longer retention, undisclosed transfers — the notice is out of step with reality.
Diagnostic use case
Use the common disclosure checklist to confirm your privacy notice accurately describes your analytics processing, recipients, retention, and any transfers.
What WebmasterID can help detect
WebmasterID's clear data model — first-party, purpose-limited, no selling or sharing — makes its role straightforward to describe in a privacy notice.
Common mistakes
- Copying a generic notice that does not match your actual processing.
- Omitting third-party recipients your tags disclose data to.
- Stating retention periods the system does not actually honour.
Privacy and accuracy notes
This page is educational and not legal advice. Exact notice requirements differ by jurisdiction; consult the applicable law and counsel for your situation.
Related pages
- Data retention in analytics
Data retention is the policy for how long an analytics system stores collected data before automatic deletion. Many platforms expose configurable retention windows for user- and event-level records. Shorter windows reduce breach exposure and support data-minimisation principles, while aggregate reports can often outlive the raw data. This is an educational overview, not legal advice.
- Lawful basis for analytics processing
The GDPR requires a lawful basis for processing personal data. For analytics the realistic candidates are consent and legitimate interests, each with conditions: consent must be valid and is often required where ePrivacy applies to cookies, while legitimate interests demands a balancing test and grants the visitor a right to object. Picking and documenting the basis is the operator's job. This is educational, not legal advice.
- Controller vs processor
The GDPR assigns different duties to a controller — who determines the purposes and means of processing — and a processor, who processes personal data on the controller's behalf. Whether your analytics vendor is a processor or a joint controller changes the contracts and liabilities involved. This page explains the distinction and how it applies to analytics.
- Privacy-first analytics
A simple data model that is easy to disclose accurately.
Sources and verification notes
- EUR-Lex — GDPR Articles 13 and 14 (information to be provided)Transparency disclosure requirements under the GDPR.
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.