Category: Governance
All blog posts in this category.
- 06 Jul, 2026
Analytics data retention: what to keep, for how long, and why
“We retain analytics data for twenty-five months.” The statement sounds precise but does not say whether it covers raw events or reports, whether visitor identifiers expire at the same time, whether collector logs follow another period, whether backups are purged, whether CSV exports remain on laptops, whether new activity resets the clock, or whether truly anonymous statistics remain longer. A useful retention policy is not one number. It describes the lifecycle of each data layer and connects every period to a purpose. The CNIL states that personal data cannot be kept indefinitely and that controllers should determine retention from the collection purpose. It distinguishes active use, intermediate archiving and, in particular cases, permanent archiving. Web analytics teams usually need a well-limited active dataset, effective deletion and possibly sufficiently aggregated long-term trends. Begin with purpose, not available settings A platform may offer 2, 14, 25 or 50 months. Those options do not determine the right period. Ask:For how long does this individual-level data remain necessary for the defined decision?Examples:seasonal comparison may require more than twelve months of trends; diagnosing collection failures may require only weeks of logs; a long B2B campaign may need several months; retaining a visitor identifier for years “just in case” is harder to justify; an aggregate monthly total may remain useful longer than detailed events.Retention should be proportionate to granularity and risk. Map seven retention layers 1. Terminal trackers and identifiers This includes cookies, local-storage IDs, session identifiers and other persistent mechanisms. Document initial duration, renewal, domain scope, cross-site use, withdrawal deletion and consent expiry. For certain audience-measurement trackers that may meet the French exemption conditions, the CNIL recommends a lifetime allowing meaningful comparison, such as thirteen months, without automatic extension at every visit. That does not make thirteen months correct for every identifier. It is a benchmark tied to the specific framework and conditions. 2. Raw events Events contain the most detail: timestamp, page, source, device, event properties, identifiers and technical metadata. They support diagnostics, funnels and report reconstruction. Their granularity increases singling-out risk and governance cost. Ask whether raw events are needed beyond the analysis cycle, whether they can be aggregated after 30, 90 or 180 days, which fields can disappear earlier, whether invalid events are stored, and whether schema deletion affects history. 3. Pseudonymised data A replaced, hashed or rotating identifier is not automatically anonymous. If events can still be linked, treat this layer cautiously. Define method, re-identification possibility, table separation, access, rotation, mapping-table deletion and the real need for continuity. Rotation helps only when old periods cannot be reconnected without a justified process. 4. Aggregate statistics Daily or monthly reports can sometimes remain longer, especially when they no longer single out a person. Examples: monthly visits by site monthly conversions by channel weekly page views by content category quarterly conversion rate“Aggregate” is not magic. A cell with one conversion in a small region may still reveal information. Set thresholds, reduce dimensions and test sparsity. If data are truly anonymous, GDPR personal-data rules no longer apply. That conclusion requires evidence. 5. Technical logs Collectors, CDNs, reverse proxies and applications may keep IP addresses, full URLs, user-agents, errors, rejected payloads and request IDs. Logs are frequently missed because they do not appear in the analytics dashboard. They serve separate security, availability and diagnostic purposes. Give them a separate period, restricted access and sensitive-field filtering. 6. Backups A backup is not a permanent deletion exception. Document frequency, rotation, encryption, access, restoration, treatment of previously deleted data, purge timeline and offline snapshots. Immediate editing of every backup may be impractical. In that case, limit access and duration, and prevent restored expired data from returning to active use. 7. Exports and secondary systems Exports create parallel retention:emailed CSV files; spreadsheets; warehouses; BI systems; agency storage; presentations; support tickets; local backups.The vendor's setting does not erase these copies. Every export needs an owner, purpose, approved location, period, access rule and deletion method. Reducing exports is often simpler than governing many copies. Build a retention matrix An illustrative SaaS matrix:Layer Purpose Proposed period Trigger Deletion OwnerLimited visit identifier Trend measurement Up to 13 months under the assessed framework Creation, no automatic renewal Expiry Analytics ownerRaw events Analysis and diagnostics 6 months Event date Automated job DataAggregate monthly reports Historical steering 36 months Month end Aggregate then purge Finance/GrowthCollector logs Security and errors 30 days Receipt Rotation EngineeringBackups Recovery 60 days Snapshot creation Rotation InfrastructureOne-off exports Defined analysis 90 days Export date Owner deletion AnalystConsent evidence Demonstrate choice Defined from risk and limitation periods Choice Dedicated policy PrivacyValues are illustrative unless a specific framework is cited. Another organisation can reach different periods after assessment. Define the trigger. Six months from collection differs from six months after last visit, campaign close or contract termination. Understand platform settings GA4: explorations versus aggregate reports GA4 documentation says retention controls apply to user-level and event-level data. Standard properties document options including 2 or 14 months for user and event data. Google also says the setting does not affect standard aggregate reports and applies to surfaces such as Explorations and funnel reporting. A team can therefore believe it reduced all retention while aggregate reporting remains available. “Reset on new activity” can extend certain user-data expiry with each event. Check whether that matches policy. Other vendors Privacy-first SaaS, self-hosted platforms and cloud tools differ in fixed or configurable periods, raw-event availability, aggregate retention, provider backups, site deletion, APIs and contract-end deletion. Do not copy a period from a comparison article. Verify current documentation and contract terms. The CNIL twenty-five-month recommendation For audience-measurement trackers under the French exemption framework it describes, the CNIL recommends a maximum of twenty-five months for collected information, with periodic review. Three cautions:maximum is not the default: less may be sufficient; the framework is conditional: purpose, anonymous statistics, no combining and other conditions still matter; layers remain separate: logs, exports and identifiers need their own assessment.A policy can therefore keep detailed events for six months and aggregate reports for twenty-four, when justified. It should not copy twenty-five months into every database. Test deletion An untested policy is an intention. Test 1: expired data Use test events or a short-period environment. Verify disappearance from storage, APIs and affected reports. Test 2: identifiers Check cookie or identifier expiry, renewal and withdrawal behaviour. Test 3: exports Track a file from creation to deletion, including copies, attachments and recycle bins. Test 4: restored backups Restore into an isolated environment and verify that deletion rules are reapplied or expired data are blocked from use. Test 5: contract termination Ask the vendor about export windows, deletion date, backups, confirmation, legally retained data and subprocessors. Avoid silent extensions Retention can be prolonged by cookie renewal, user-row updates, warehouse imports, sparse aggregates, never-rotated backups, shared-folder copies, reused test accounts and changes applying only to future data. Document whether a change acts retroactively. Retention across multiple sites One policy may not fit a corporate site, authenticated app and help centre. Purposes, data, risks and countries differ. Use a common baseline with approved exceptions. The multi-site dashboard can show collection health, while administration tracks the retention mode and review date of every property. Do not share a cross-site identifier merely to simplify retention. Who validates the period? Business owners explain need. Analytics describes granularity. Engineering confirms deletion. Security owns logs. Privacy reviews the framework. Infrastructure covers backups. Procurement checks contracts. Name a final owner. “Data team” is not enough. The data collection summary and analytics privacy notice should show consistent periods at different levels of detail. A quarterly ten-question reviewHave purposes changed? Are detailed data still used? Can long-term reports be more aggregated? Do identifiers renew? Did deletion jobs succeed? Are there new exports? Are backups rotating? Did vendor policy change? Are public documents aligned? Can an inactive property be deleted?Removing an unused site, export or event is often the strongest risk reduction. Conclusion Retention is not a number in a policy. It is a system connecting purpose, granularity, access, trigger and deletion. A sound policy:separates identifiers, events, aggregates, logs, backups and exports; justifies each period; avoids silent renewal; tests purge operations; documents exceptions; aligns tools, contracts and public information.Begin with the most detailed data. Ask how long it remains useful, then aggregate or delete. Long-term history should not require indefinite individual-level collection. FAQ Does the CNIL always require twenty-five months? No. It recommends a twenty-five-month maximum for collected information under the conditional framework for certain audience-measurement trackers. A shorter period may be sufficient or necessary. Can aggregate statistics be kept indefinitely? Only when they are truly anonymous or another framework justifies retention. Sparse or highly segmented aggregates can still single out people. Does GA4 retention remove all reports? No. Google states that user and event retention settings do not affect standard aggregate reports. Understand which data and surfaces are covered. Must backup data be deleted immediately? It depends on architecture and risk. Backups need limited rotation, controlled access and procedures preventing expired data from returning to use after restoration. When does the retention clock begin? Define the trigger: collection, last activity, campaign close, aggregation or contract termination. Avoid automatic renewal where the framework or policy does not allow it. SourcesCNIL, Data retention periods CNIL, Audience-measurement cookies and consent conditions Regulation (EU) 2016/679, Article 5(1)(e) Google Analytics, Data retention Plausible, Data policy CNIL, Practical guide to retention periods
- 29 Jun, 2026
How to choose an analytics tool: a 15-question governance scorecard
Analytics comparisons often begin with feature lists and end with an overall score that assumes every team wants the same thing. They do not. A B2B small business measuring three sites, sharing reports with an agency and limiting collection has different constraints from an ecommerce group connected to advertising platforms. A technical team willing to operate self-hosted software makes a different trade-off from a marketing team without systems administration. The best tool is not the one with the most features. It is the one whose capabilities, defaults and governance model fit the need. The existing Google Analytics, Matomo and lightweight analytics comparison explains the main families. This scorecard supports an actual procurement decision without relying on a static ranking or prices that will change. Write the problem before scoring tools A serious selection fits on one page before the first demo. Decisions to support List five to ten decisions:Which channels create qualified requests? Which landing pages contribute to conversion? Which content is used? Which sites are growing or declining? Which product events matter? Where did collection break?“Collect all the data” is not a decision. Users Identify marketing, product, management, agency, analyst, engineering, privacy and external-client roles. The key issue is not only user count. It is rights, skills and usage frequency. Constraints Document site count, expected volume, countries, consent requirements, prohibited data, retention, integrations, budget, operating capacity, migration timeline and contractual requirements. This prevents a polished demo from replacing analysis. The 15-question scorecard Score each tool from 0 to 3:0: unavailable or incompatible; 1: possible with a major workaround; 2: covered with acceptable configuration or limits; 3: naturally supported and documented.Apply a weight from 1 to 3 for your organisation. 1. Can it answer business questions without heavy reconstruction? Test five scenarios, such as campaign landing pages, demo requests, three-site comparison, monthly export and traffic-drop diagnosis. A powerful tool that real users cannot operate is expensive. 2. What granularity is genuinely required? Separate aggregate statistics, events, journeys, cohorts, funnels, user identifiers, advertising data and session replay. Each layer adds capability and governance. A team using only pages, sources and conversions should not select primarily for detailed behavioural analysis. 3. What does the default setup collect? Check cookies or identifiers, IP address, full URL, user-agent, geography, advertising IDs, automatic events, query parameters and cross-site signals. Use the URL parameter audit and inspect a test payload. A default aligned with policy scores better because every option to disable is configuration debt. 4. Are strict and extended modes clearly separated? Some teams want minimal measurement by default where the local framework allows it, with extended capabilities after consent. Assess configuration separation, pre-consent behaviour, signal propagation, accidental activation risk, change history and documentation. A vague privacy switch is not enough. 5. Can you explain the data flow? You should be able to state where requests arrive, which transformations occur, where data are stored, which subprocessors participate, whether the vendor reuses data, which support access exists and which transfers apply. Use the data collection summary as the evaluation format. 6. Do location and transfers fit your constraints? Assess hosting region, contracting entity, subprocessors, remote access, transfer mechanisms and self-hosting options separately. “EU hosted” is one fact, not a complete assessment. Self-hosting provides control while transferring operational duties to the team. 7. Can retention, deletion and backups be governed? Ask about available periods, raw versus aggregate data, automatic deletion, property-level deletion, backup purge, exports, contract-end deletion and operational evidence. Unlimited default retention is not neutral. 8. Do multi-site permissions fit? Test per-site roles, groups, agency access, read-only access, exports, admin logs, SSO where needed, offboarding and portfolio views. The multi-site dashboard model turns these into practical scenarios. 9. How does it handle data quality? Review bots, test environments, duplicates, invalid events, unknown parameters, ingestion delay, definition changes, alerts, time zones and cardinality. A simple report without diagnostics may be too shallow. A rich platform with opaque transformations may be hard to audit. 10. Can events and conversions remain governed? Test event creation, change and deprecation. Can schemas be validated? Can fields be forbidden? Are changes versioned? Do historical goals remain understandable? Can an agency change collection without approval? Easy event creation is not always an advantage. Missing guardrails quickly creates an unreadable taxonomy. 11. Is acquisition readable without excessive setup? Test source and medium, UTM campaigns, referrers, direct, landing pages, conversions, custom channels and only the attribution models you genuinely need. Platforms can classify the same journey differently. Ask how rules are defined and changed. 12. Can history be migrated and compared? Check import availability, format, granularity, supported metrics, cost, duration, definition differences, source-data preservation and break-point labelling. An import does not erase differences in sessions, visitors or conversions. 13. Is cost predictable at your scale? Include subscription by volume, overages, sites, users, modules, storage, hosting, maintenance, support, consent management, configuration time, manual reporting, migration and exit. For self-hosting, include updates, backups, monitoring, security and availability. For SaaS, model traffic growth and plan-gated features. Verify prices at decision time. 14. What operating burden can the team sustain? List installation, configuration, tests, maintenance, access, compliance, alerts, backups, support, training and documentation. A free tool can be expensive to operate. A simple tool can be expensive if every useful question requires manual exports. 15. Can you exit cleanly? Evaluate full export, open formats, API, post-cancellation access, deletion, portable configuration, event recovery, definition history and proprietary identifier dependence. A good fit today can still create future debt through lock-in. A weighting example For a multi-site B2B SaaS company:Criterion WeightBusiness questions 3Granularity 2Default collection 3Strict/extended separation 3Data flow 3Location and transfers 2Retention and deletion 3Multi-site access 3Data quality 2Event governance 2Acquisition 2Migration 2Total cost 3Operating burden 3Reversibility 2Calculate: sum(score × weight) / sum(3 × weight)A percentage is convenient, but a two-point difference is not scientific truth. The criteria discussion matters more than the final rank. Add disqualifying criteria Some conditions cannot be offset:unavailable DPA; no deletion; no export; prohibited data collected without control; incompatible multi-site access; unacceptable transfer; cost beyond budget; impossible operating burden; missing essential capability.A tool can score 85% and still fail one critical requirement. Reading the main tool families Rich analytics and advertising suites GA4 integrates deeply with Google's ecosystem and provides broad dimensions, explorations and advertising connections. This can fit trained teams with real attribution and activation needs. It also requires more event governance, configuration and understanding of scopes. Familiarity alone is not a selection criterion. Controllable and self-hostable platforms Matomo offers cloud and self-hosted options with broad functionality. Umami and other open-source projects take more compact approaches. Self-hosting increases infrastructure control, but the organisation owns operations. Decide who patches, restores backups and monitors access. Privacy-first analytics SaaS Plausible, Fathom, Simple Analytics and related tools prioritise readable reporting and often more limited collection. They can reduce setup for essential needs. Simplicity may limit advanced analysis, complex event schemas or some consolidation patterns. Verify actual capabilities, not only philosophy. Emerging products A beta or launch-stage product may align well with governance, but assess maturity, documentation, support, export, stability and demonstrated roadmap. Never score a roadmap promise as an available feature. Run a two-week pilot Day 1: confirm scenarios Select five questions, three roles and two representative properties. Days 2 to 4: deploy a small scope Install each candidate on a test environment or pilot property with the same pages and events. Days 5 to 7: audit collection Compare network requests, documented storage, consent, URL parameters and access. Days 8 to 10: user tests Ask marketing, product and administration users to complete the same tasks without excessive assistance. Days 11 to 12: test export and deletion Export data, revoke access, change retention and review deletion procedures. Days 13 to 14: score and document Complete the scorecard, list disqualifiers and write down accepted compromises. Common selection mistakes Choosing from a demo A demo shows the best workflow, not routine operations. Choosing on privacy alone Privacy is a major design constraint, but the tool must support decisions. An unused solution does not improve governance. Choosing on features alone A feature that expands collection or requires a dedicated team can be a cost rather than value. Comparing prices without future volume Model twelve- and twenty-four-month scenarios. Forgetting people The theoretical best tool fails when nobody understands its reports or maintains its rules. Conclusion A useful comparison does not ask, “Which tool is best?” It asks, “Which tool creates the best compromise for this organisation?” The scorecard makes visible:expected decisions; default collection; governance; access; retention; multi-site needs; total cost; operating burden; exit capability.The result is not a universal score. It is an explainable, reviewable and documented decision. FAQ How many tools should be tested? Three well-chosen candidates are often enough: a rich reference platform, a more controllable option and a simple privacy-first option. Add a fourth only when it represents a genuinely different model. Is self-hosting always more compliant? No. It increases potential control, but compliance still depends on configuration, security, access, purpose, retention and real operations. Can prices be compared once and reused? No. Plans, limits and prices change. Verify them at decision time and model several volumes. How should a roadmap feature be scored? Treat it as unavailable until it can be used and verified. A roadmap can affect risk, but it cannot satisfy a current requirement. What is the difference between a weighted and disqualifying criterion? A weighted weakness can be offset by other strengths. A disqualifying criterion makes the tool incompatible regardless of its total score. SourcesCNIL, Audience-measurement cookies and consent conditions Regulation (EU) 2016/679, data minimisation, transparency and accountability principles Google Analytics, Analytics account structure Google Analytics, Data retention Matomo, Privacy Plausible, Data policy Fathom Analytics, Data policy Umami, Documentation
- 22 Jun, 2026
Analytics privacy notice: useful wording and claims to avoid
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. SourcesRegulation (EU) 2016/679, Articles 12, 13 and 14 CNIL, Examples of privacy information notices CNIL, Informing individuals CNIL, Audience-measurement cookies and consent conditions EDPB, Guidelines on transparency under Regulation 2016/679
- 18 May, 2026
Data collection summary: document what your analytics actually collects
Installing analytics can take minutes. Explaining exactly what it collects often takes much longer. The problem is not only volume. Information is scattered across the tracking plan, vendor documentation, consent manager, source code and cloud configuration. When somebody asks, “Do we transmit the full URL?”, “Is the IP address stored?” or “How long do we keep raw events?”, no single person may have a complete answer. A data collection summary is a short operational document that brings those answers together. It describes the collection that is actually deployed, not the collection implied by a marketing page. It is not legal advice, a replacement for a record of processing activities, or a privacy notice. It is the technical layer that helps keep those documents accurate. What a data collection summary is for The document answers one question:For every data point or signal, do we know where it comes from, why it is collected, where it goes, how long it remains and who can access it?Product teams can use it to challenge new events. Marketing teams can see which dimensions genuinely exist. Engineering teams gain a reference for filtering and transformations. A DPO or legal adviser can compare technical reality with compliance records. Management can see the operational debt behind audience measurement. GDPR principles include purpose limitation, data minimisation, transparency and storage limitation. The Regulation also requires information for individuals and, where applicable, records of processing activities. A data collection summary does not create or replace these duties. It makes the underlying facts easier to establish. It is not the record of processing activities The distinction matters. A record of processing activities describes processing at a governance level: purposes, categories of people and data, recipients, transfers, retention and security measures. A data collection summary goes closer to implementation. It may state that:the page URL is stored without its query string; an IP address is used briefly for a technical operation and not retained; a user-agent is reduced to a browser family; only utm_source, utm_medium and utm_campaign are retained; a form event is emitted only after validation; raw events and aggregate reports have different retention periods.A privacy notice translates the relevant facts into language for visitors. It should not become a copy of the technical inventory, but it cannot be accurate without one.Document Main audience Detail level PurposeRecord of processing Internal compliance Processing and categories Govern and demonstrate complianceData collection summary Product and engineering Fields, flows and controls Describe the deployed collectionPrivacy notice Visitors and users Clear public information Explain relevant processingTracking plan Product, marketing and engineering Events and rules Define what should be measuredThese documents complement one another. They should not contradict one another. The ten columns that make the document useful A spreadsheet is enough. The value comes from the columns and the update discipline. 1. Data point or signal Use concrete names: page path, referrer domain, device class, form event, site ID, UTM parameter, derived country or temporary IP address. Avoid broad labels such as “technical data”. They hide design choices. 2. Example value An example removes ambiguity: /pricing/, newsletter or demo_requested. Use synthetic examples, never real personal data. 3. Source State where the signal originates: browser, server, form, CMS, CDN, analytics script or imported system. This reveals indirect collection. A platform may receive a URL or HTTP header before your tracking code transforms it. 4. Operational purpose Connect the field to a decision. “Identify entry pages that lead to a demo request” is more useful than “marketing analysis”. If a field supposedly serves every purpose, the need has probably not been defined well enough. 5. Transformation before storage Document what is removed, truncated, aggregated or derived:stripping unapproved query parameters; normalising paths; reducing the user-agent; deriving coarse geography and discarding the IP address; hashing an identifier, while recognising that hashing is not automatically anonymisation; daily or monthly aggregation.This separates what the system receives from what it keeps. 6. Destination and processors List every relevant destination: collection endpoint, raw storage, aggregate database, BI tool, export, cloud provider and analytics vendor. Record hosting regions and relevant transfers when they are documented. Do not infer a legal location from a cloud region label alone. 7. Retention Separate the layers:technical logs; raw events; pseudonymised records; aggregate statistics; backups; manual exports.A single global period is often misleading. The CNIL notes that retention should follow the purpose and remain limited to what is necessary. For audience-measurement trackers that may fall within the French consent-exemption framework, it recommends a tracker lifetime of thirteen months and a maximum of twenty-five months for collected information. Those benchmarks do not replace an assessment of the actual setup. 8. Access Describe roles rather than only names: administrators, analysts, agency, support or hosting provider. Specify whether access covers aggregate reports, raw events or exports. “Marketing has access” is not enough when a shared account can download the entire dataset. 9. Consent or configuration dependency Keep this factual:collected only after a consent signal; disabled in strict measurement mode; enabled for defined campaigns only; subject to local ePrivacy assessment; used for limited audience measurement, provided every applicable condition is met.Do not write “exempt” without documenting scope, conditions and configuration. 10. Deletion and owner Explain how the field disappears: automated deletion, scheduled job, vendor purge, manual procedure, contract termination or export deletion. Add an internal owner and a last-review date. Without ownership, the summary starts ageing at the next deployment. A minimal SaaS exampleSignal Purpose Before storage Retention AccessPage path Understand content usage Query string removed, path normalised 25 months for reports Product, marketingReferrer domain Understand visit sources Origin only when transmitted 25 months Marketingutm_source Identify a declared campaign Values normalised to a taxonomy 25 months Marketingdemo_requested Measure a B2B conversion No form content transmitted 25 months Product, aggregate sales viewIP address Security and coarse geolocation Used temporarily, not stored in the event Documented technical period Restricted operationsUser-agent Technical distribution Reduced to browser and device categories 25 months ProductThe table proves nothing by itself. It must match the observed network traffic, source code and vendor settings. Start with a real tracker audit and compare the results with your minimal tracking plan. A five-step method Step 1: start with network traffic Open browser developer tools, reload representative pages and inspect requests. Test before and after each consent choice, across several journeys and devices. Record domains, payloads, URL parameters and events. The network panel shows what leaves the browser. It may not expose every server-side transformation, but it gives you a verifiable starting point. Step 2: inspect code and configuration Review the collector, tag manager, CMP rules, environment variables and filters. Generic vendor documentation does not tell you which options your site enabled. Check adjacent capabilities too: session replay, advertising enrichment, CRM connections, user identifiers and exports. Step 3: ask vendors closed questions Request testable answers:Is the full URL received and stored? Can query parameters be removed before storage? Is the IP address logged outside the event dataset? Which backups still contain data after deletion? Does the vendor reuse data for its own purposes? Which subprocessors and transfers apply? Do exports follow the same retention policy?“Privacy-friendly” fills no column. Step 4: reconcile the documents Compare the summary with the processing record, data-processing agreement, privacy notice and consent interface. Contradictions matter more than the writing quality of each document in isolation. A common example is a notice saying that only aggregate statistics are collected while the tag manager sends a user identifier to a third party. Step 5: tie review to change Review the summary whenever you add or change:a tool; an event; a collection domain; an export; a retention period; consent behaviour; a processor; a site or property.A light quarterly review can detect silent drift. Mistakes that make the summary unreliable Copying vendor marketing Vendor documents describe a possible product. Your summary must describe your instance and configuration. Treating pseudonymisation as anonymisation A hashed or rotating identifier may still be personal data if it can distinguish or reconnect a person. Use precise terms and document re-identification risk. Forgetting URLs Full URLs can expose email addresses, order IDs, internal search terms or tokens. Even a minimal analytics tool can receive excessive data when the website places it in the address. Documenting only the dashboard The visible report is only one surface. Logs, raw events, backups, exports and integrations count too. Leaving the document ownerless An accurate but unmaintained inventory can become more dangerous than no inventory because it creates misplaced confidence. Validation checklist Before approval, verify that:every field has a specific purpose; received and stored data are distinguished; URL parameters and free-text fields were audited; retention is defined by layer; recipients and access roles are named; consent and configuration dependencies are explicit; deletion can be tested; the summary matches public and contractual documents; an owner and review date are recorded; every anonymisation claim has technical evidence.Conclusion A data collection summary is not another document for a compliance folder. It is a shared interface between product, marketing, engineering and legal work. Its value comes from precision. A team that knows exactly what it collects can remove unnecessary fields, explain the useful ones, configure tools correctly and answer questions faster. Start with one web property and its ten most important signals. Verify them in the network and code, then expand only when the deployed collection justifies it. FAQ Is a data collection summary legally required? This exact format is not prescribed by the GDPR. It can support documents and processes that are required or necessary, including processing records and transparent information for individuals. Should it be public? Not necessarily. It often contains internal technical details. Relevant information for individuals should be expressed clearly in the privacy notice or another appropriate notice. Should a non-stored IP address be listed? Yes, if it is received or used even briefly. Distinguish receipt, temporary processing, transformation and storage. Can one summary cover multiple sites? Only when their flows and configuration are genuinely identical. For multi-site operations, maintain a common baseline and document property-specific differences. How often should it be reviewed? At every material collection or destination change, plus a periodic review. Quarterly review is a practical operating rhythm for a small team, not a universal legal rule. SourcesRegulation (EU) 2016/679, including Articles 5, 13, 25 and 30 CNIL, Record of processing activities CNIL, Audience-measurement cookies and consent conditions EDPB, Guidelines 4/2019 on data protection by design and by default Chrome for Developers, Network features reference OWASP, Information exposure through query strings in URL