Category: Gdpr
All blog posts in this category.
- 24 Aug, 2026
Email tracking pixels: what marketing teams should fix after the CNIL recommendation
An email tracking pixel often looks harmless. It is tiny, invisible, enabled by default in many email platforms, and it feeds a familiar metric: the open rate. But that simple metric can hide a compliance decision. A pixel may reveal that a specific address loaded a message, when it happened, and sometimes technical context associated with that request. The event can then feed a CRM profile, a campaign report, a lead score or an automation workflow. This is not always just campaign statistics. In many setups, it is tracking. In April 2026, the French data protection authority, CNIL, published its final recommendation on tracking pixels in emails. For marketing, CRM, growth and communications teams, the useful question is no longer: “Should we keep open rates?” The useful question is: what purpose does the pixel serve, what data does it collect, for which recipients, and on what basis? This article gives teams a practical way to review email measurement without abandoning useful reporting altogether. Why this changed in 2026 CNIL published its final recommendation on tracking pixels in emails on 14 April 2026, after a public consultation. The recommendation applies to private and public organisations using such pixels, and to the technical providers involved in that ecosystem. It clarifies three areas:the role of each actor, especially senders and providers; when consent is required; when a pixel may be exempt, under strict conditions.CNIL also introduced a progressive approach for email addresses collected before publication. Senders could continue using certain pixels if recipients received clear information within a period that should not, in principle, exceed three months from 14 April 2026, and if no objection was received after recipients had an easy way to object. At the time of publication of this article, that period has passed. For teams that have not reviewed their emails, this is no longer a theoretical issue. Tool settings, email templates and real purposes should be checked. What an email tracking pixel actually measures A tracking pixel is usually a tiny image loaded from a remote server when an email is opened. The image URL may contain an identifier tied to a recipient, campaign, message or variant. When the email client loads the image, it sends a request. Depending on the platform configuration, that request may reveal or record:that a message was opened or loaded; the date or time of the opening; a recipient or message identifier; the campaign or segment; technical data transmitted with the request; sometimes approximate location or email-client-related information, depending on the processing performed.The important point is that the pixel is not automatically an abstract performance metric. In many configurations, it first creates an individual signal, and that signal is later aggregated into a report. Teams should also be careful with the business interpretation. An “open” does not necessarily mean a person read the message. Images may be blocked, preloaded, proxied or loaded in ways specific to the email client. Open rate can still help with broad trends, but it should not be treated as a reliable measure of individual attention. The starting point: define the purpose The risky shortcut is to classify pixels by platform: “our email tool does this, so it must be standard.” CNIL’s framework pushes teams to start with purpose instead. The same technical mechanism can serve several goals:measuring campaign audience; personalising future messages; scoring a prospect; triggering a sales alert; cleaning an inactive list; improving deliverability; authenticating the user for a requested service.Those goals do not all lead to the same analysis. Article 82 of the French Data Protection Act governs operations that access information stored in terminal equipment or store information there. It is built around consent, with exceptions where the operation exclusively enables or facilitates electronic communication, or where it is strictly necessary to provide an online communication service expressly requested by the user. In practice, two questions must be separated:Does the pixel require consent under tracker rules? Does the related personal data processing also comply with the GDPR, including legal basis, information, retention and rights?Tracker consent and the GDPR legal basis are connected, but they are not the same thing. A sender may be allowed to send a commercial email in certain situations, yet that does not automatically permit the use of a tracking pixel under the rules for trackers. Uses that usually require consent Individualised marketing uses are the most sensitive. This is the case when the pixel reveals that a person opened a message and that signal changes the profile, score, segment or next step in the journey. Typical examples include:showing in the CRM that a contact opened an email; triggering a follow-up after an open; prioritising a lead because they opened several messages; personalising a newsletter based on previous opens; measuring a recipient’s interest in a category of offers; producing contact-level or account-level reporting.These uses go beyond deliverability. They aim to understand, influence or personalise the relationship with a person. They should be treated as tracking purposes in their own right. Mixed-purpose pixels deserve particular attention. One pixel can pursue both an exempt purpose and a purpose subject to consent. But the purpose that requires consent can only be activated after valid consent has been collected. It is not healthy to place a pixel “just in case” and decide later how it will be used. Deliverability may be exempt, but only narrowly The recommendation recognises a possible exemption for certain individual deliverability measurements. The operational idea is to identify recipients who no longer open emails so the sender can reduce frequency, stop sending or clean the list. This can protect sender reputation and avoid repeatedly contacting people who appear inactive. But the exemption is narrow. It does not make open rate a freely available metric. To stay within this framework, the pixel must be limited to the deliverability purpose and linked to a service requested by the recipient. CNIL also stresses data minimisation. In principle, the central data point for that goal is the date of the last opening. Collecting IP address, user-agent or other additional data, then deleting or anonymising it quickly, does not bring the use into the exemption if that data was not necessary from the start. For marketing teams, the lesson is simple: excessive data does not become necessary because it is deleted quickly. Not all newsletters are the same The word “newsletter” covers very different situations. A newsletter expressly requested by the user may, in some cases, be linked to a service requested by that user. A pixel used only for deliverability may then benefit from the exemption, if all other conditions are met. By contrast, a communication sent under the exception for similar products or services does not automatically become a service requested by the user. In that situation, a deliverability pixel should not be treated as automatically exempt. Teams should examine the source of the list, the subscription method, the promise made at sign-up, and the actual purposes of the pixel. A personalised newsletter raises another issue. If the pixel directly contributes to personalising content or frequency, consent may be linked to the subscription when the information is clear and the purposes are sufficiently connected. This should not become a vague formula such as “we improve your experience.” The recipient must understand what they accept. Transactional emails, cart reminders and regulatory messages Transactional emails often have a more favourable analysis, but not without limits. An order confirmation, subscription confirmation, invoice, password reset or legal notice may be linked to a service requested by the user. A pixel limited to a compatible purpose, such as deliverability or user authentication, can therefore be analysed within the exemption framework. But the message content matters. If an email presents itself as transactional while including a strong promotional element, the analysis changes. CNIL gives cart reminders as an example: their purpose is essentially promotional, since they encourage the recipient to complete a purchase, so they cannot benefit from the transactional-email exemption. The right approach is to classify templates one by one: confirmation, invoice, onboarding, newsletter, prospecting, reminder, support, security, product notification. A single global rule for “all emails” will almost always be too rough. Tracking links should not be ignored The recommendation directly addresses pixels in emails. Tracking links are not directly covered by that specific recommendation, but CNIL notes that similar principles should be considered. A tracking link may contain a recipient, campaign or segment identifier. When clicked, it can associate an action with a person. Depending on the technique, it may also involve operations covered by Article 82. For acquisition teams, the practical distinction is useful:UTM parameters describe a campaign or channel; person-level identifiers in links track a recipient.Pomelo’s guide to UTM tags, referrers and direct traffic explains how to tag campaigns without confusing attribution with individual tracking. The guide to privacy-first URL parameter filtering completes the picture: an email address, customer ID or token should not flow through URLs measured by web analytics. How to audit your email platform The audit should start with real emails, not only global platform settings. List your message categories: newsletter, nurturing, prospecting, transactional, support, security, product, events. For each category, record whether open tracking is enabled, whether clicks are tracked, whether data syncs to the CRM, and whether automations use those signals. Then ask five questions. 1. What purpose is being pursued? Write one understandable sentence: “reduce sending frequency for inactive recipients,” “measure overall newsletter performance,” “trigger a sales follow-up,” or “personalise content.” If the purpose is vague, the configuration is probably vague too. 2. What data is collected? Do not stop at “opened or not opened.” Check identifiers, timestamps, IP address, user-agent, campaign data, CRM tags, exports and provider logs. 3. Is the data necessary? For deliverability, CNIL indicates that the date of the last opening is, in principle, the central data point. If the tool collects more, the sender should justify that need or disable excessive collection. 4. Is the choice understandable and easy to withdraw? When consent is required, the recipient must understand the scope of their choice. They must also be able to withdraw consent as easily as they gave it. A preference centre may group several choices, but it must not make rights harder to exercise. 5. What happens after withdrawal? Because an email already sent cannot be removed from the recipient’s inbox, the sender must have a mechanism to ignore pixel requests associated with withdrawn consent. Previously collected data should also be deleted if no other legal basis justifies keeping it. A simple decision matrixUse case Conservative reading Recommended actionGlobal open rate for a newsletter Possible only if the initial collection is lawful and the data is effectively anonymised or aggregated Check the source collection, then report only aggregated metricsInactive-list cleaning for an expressly requested newsletter Deliverability exemption may be possible Limit data, document the purpose, provide information and objection mechanismsCRM scoring based on opens Individual tracking Collect valid consent and document the processingSales alert after an open Sensitive individual tracking Avoid by default or collect explicit and clear consentOrder confirmation with no promotion Requested service Assess a deliverability or user-authentication exemption, without marketing reuseCart reminder Promotional communication Do not treat as an exempt transactional emailSecure unsubscribe link May be strictly necessary Keep the link limited to that purposeThis matrix is not legal advice, but it helps teams remove the most common grey areas. What if you did not inform existing lists before 14 July 2026? For addresses collected before 14 April 2026, CNIL provided a transition period. In principle, clear information enabling objection had to be sent within three months, meaning before 14 July 2026. CNIL’s FAQ notes that a longer period may be justified in certain situations, such as database size or deliverability issues, but those difficulties must be objectively documented. If no information was sent and there is no strong documented justification, the sender should apply the recommendation. That means collecting consent where the pixel requires it, or stopping the use of pixels that require consent. The safest operational response is often progressive: disable unnecessary pixels, keep only strictly justified measurements, and rebuild preferences cleanly at the next collection or subscription point. Keep useful reporting without tracking every open Reducing pixels does not mean giving up email marketing measurement. Post-click measurement is often more useful than open tracking. A click to an acquisition page, a qualified visit, a demo request, a registration or a download usually says more about intent than an image load. To do this well, tag links with non-identifying campaign parameters and read results in web analytics. UTM values should describe the campaign, channel and possibly variant, not the person. A URL such as utm_source=newsletter&utm_medium=email&utm_campaign=product_update is useful. A URL containing an email address or customer ID creates privacy debt. This is also where a clean separation between tools helps. The email platform manages sending, preferences and channel-specific obligations. Web analytics measures what happens after the click with limited and documented collection. Pomelo’s data collection summary can help explain what the analytics tool receives and what it does not receive. Pomelo follows that logic: measure useful web signals without turning every marketing interaction into person-level tracking. But no analytics tool can, by itself, make an email platform configuration compliant. The two scopes should be audited separately. Correction checklist for marketing teams Before the next campaign, review these points:identify all email templates containing a pixel; separate opens, clicks, personalisation, scoring, deliverability and security; disable pixels with no clear purpose; check whether the emails were actually requested by the recipient; limit data collected for deliverability; avoid IP address, user-agent and other additional data when unnecessary; separate aggregate statistics from individual signals; provide a simple withdrawal or objection mechanism; ensure pixels already sent are no longer exploited after withdrawal; update the privacy notice and, where needed, the preference centre; document platform settings and retained choices; check contracts and roles with providers.The analytics privacy notice offers a useful method for avoiding overly broad wording. The same principle applies here: do not promise “anonymous” or “purely statistical” measurement if the tool first processes signals tied to a person. Conclusion CNIL’s recommendation does not say that all email measurement is forbidden. It imposes clearer discipline: name the purposes, limit the data, separate deliverability from individualised marketing, and give people real control where consent is required. Open rate can still exist in some reports. But it should be placed where it belongs: a fragile metric, sometimes useful in aggregate, rarely sufficient to steer a campaign alone, and legally sensitive when it relies on individual tracking. For marketing teams, the fix is not only to change one checkbox in Mailchimp, Brevo, HubSpot or another platform. It is to rebuild email measurement so it is more limited, more explicit and more coherent with the rest of the analytics stack. FAQ Are email tracking pixels always subject to consent? No. Some pixels may be exempt, especially for tightly defined deliverability or user-authentication purposes. But individualised marketing, scoring, personalisation and sales alerts usually require a consent analysis. Can a global open rate be calculated from aggregated data? It can be calculated from lawfully collected data that is then effectively anonymised or aggregated. This does not remove the need to analyse the initial pixel collection. Downstream aggregation does not fix excessive or unauthorised collection. Can an expressly requested newsletter use a deliverability pixel? Yes, it may be possible if the newsletter is a service requested by the user and the pixel is limited to deliverability. The sender should limit the data and avoid reusing that signal for scoring or uncovered personalisation. Are tracking links covered? The recommendation directly covers pixels in emails. Tracking links are not directly covered by that text, but they should be analysed using the same principles: purpose, transparency, possible consent and minimisation. What should we do first if pixels are enabled everywhere? Start by disabling uses with no clear purpose, then separate deliverability, aggregate measurement and individual tracking. After that, update information, preferences, consent evidence and tool settings. SourcesCNIL, Tracking pixels in emails: CNIL publishes recommendations to better protect privacy, 14 April 2026 CNIL, Q&A - recommendation on tracking pixels in emails, 22 July 2026 Légifrance, Article 82 of the French Data Protection Act EDPB, Guidelines 2/2023 on Technical Scope of Art. 5(3) of ePrivacy Directive, final version, 16 October 2024 CNIL, Cookies and other trackers topic page
- 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
- 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
Analytics consent: what to verify before promising “no cookie banner”
“Cookieless analytics” is often shortened to “consent-free analytics” and then to “no cookie banner”. Those statements are not equivalent. A tool can avoid HTTP cookies while reading or writing information on a device through another mechanism. A product may offer a limited audience-measurement configuration while other modules require a different assessment. And even when analytics fits a strict framework, videos, support widgets, advertising pixels or embedded forms elsewhere on the site may still require consent. The right question is not, “Is the tool cookieless?” It is:Which trackers and processing operations are actually deployed on this site, in this configuration, for which purposes and under which conditions?This is an assessment framework, not legal advice. It must be adapted to the countries, uses and setup involved. Do not confuse three layers 1. Storage or access technology A cookie is one technique. The ePrivacy framework more broadly addresses storing information on a user's terminal or accessing information already stored there, as transposed in national law. Local storage, SDKs, pixels, fingerprinting mechanisms and other terminal access can therefore raise consent questions without a traditional HTTP cookie. Cookieless is a technical characteristic, not a complete legal classification. 2. The ePrivacy tracker regime In France, Article 82 of the Data Protection Act implements the tracker rules. The general principle is prior information and consent for covered operations, with exceptions including operations strictly necessary for a service expressly requested. The CNIL also describes conditions under which certain audience-measurement trackers may fall within an exemption. This is a narrow framework, not a general exemption for all analytics. 3. Personal-data processing under the GDPR Even when a terminal operation does not require ePrivacy consent in a particular configuration, GDPR duties can still apply if personal data are processed. Purposes, legal basis, transparency, minimisation, retention, recipients, transfers, security and rights may still need to be documented. No banner does not mean no processing or no information. The French limited audience-measurement conditions The CNIL states that, to remain strictly necessary for the service and potentially fall within the described exemption, trackers must in particular:be strictly limited to measuring the audience of the site or app; operate exclusively on behalf of the publisher; produce anonymous statistics only; avoid combining the data with other processing; avoid transmitting non-anonymous data to third parties; avoid global tracking across websites or apps.The CNIL also recommends informing users, limiting tracker lifetime, for example to thirteen months without automatic extension, retaining collected information for no more than twenty-five months, and reviewing those periods. Each condition matters. Strictly limited purpose Technical performance, viewed content and navigation problems may fit the described logic. Advertising audiences, CRM enrichment, ad personalisation and cross-service tracking do not share the same purpose. One product interface may offer both. Audit the enabled feature, not only the vendor name. Exclusively for the publisher The provider should not turn the collection into data for its own targeting, profiling or incompatible cross-client measurement. Review the contract, product documentation and subprocessors. A marketing statement is not enough. Anonymous statistics “Anonymous” is a demanding word. Removing a name, truncating an IP address or hashing an identifier does not automatically create anonymity. If a signal still distinguishes or connects a person, use cautious terminology. Ask the vendor to explain transformations and re-identification risk. No global cross-site tracking A shared identifier used to deduplicate people across properties changes the scope. This matters for groups and agencies consolidating audiences. A multi-site dashboard can aggregate indicators without requiring a cross-site person identifier. The checklist before any no-banner promise 1. Inventory the whole site Do not begin and end with analytics. Include:analytics; tag managers; embedded video and maps; support chat; forms; fraud prevention; experimentation; session replay; advertising; social widgets; security and CDN tooling; partner scripts; mobile SDKs where relevant.Run a tracker audit before and after each consent choice, across several pages and journeys. Strict analytics does not neutralise an advertising pixel elsewhere. 2. State real purposes For every component, state what it enables:aggregate audience statistics; campaign analysis; personalisation; advertising; security; interaction recording; support; product experimentation.“Improve the service” is too broad to govern a configuration. 3. Identify terminal operations Document cookies, local storage, session storage, cache identifiers, SDKs, pixels, device characteristics, consent signals and withdrawal. A scanner showing no cookies does not close the assessment. 4. Inspect collected data and transformations The data collection summary should answer:Is the IP address received, used and stored? Is the full URL transmitted? Is the user-agent raw or reduced? Is a visitor identifier created? Is it stable across days or sites? Are UTM parameters retained? Can free-form events contain text? Which data are aggregated? At what point can a record no longer single someone out?An “anonymous mode” that nobody can explain is not evidence. 5. Review vendor use Ask whether the vendor:acts only as a processor for this collection; reuses data for its own purposes; combines data between customers; produces benchmarks from individual-level data; trains another product; sends data to subprocessors; makes international transfers.Benchmarking can sometimes be designed on separated aggregate data. It still needs to be understood. 6. Verify the exact configuration Documentation may say “can be configured to meet the criteria”. That does not mean your default account does. Keep evidence of:configuration export or screenshots; script version; collection parameters; disabled modules; allowed domains; retention; sharing options; verification date; owner.The CNIL tells publishers to request documentation and operating instructions from providers. 7. Review retention Separate tracker or identifier lifetime, raw events, statistics, technical logs, backups and exports. Test automated deletion. A dashboard retention setting may not cover files exported by your team. 8. Inform visitors Even when consent is not required for a strictly framed measurement setup, the CNIL recommends informing users, for example in the privacy notice. Depending on context, explain purpose, relevant data, general operation, duration, provider, recipients, rights, contact and relevant transfers. “We use privacy-friendly analytics” is not enough. 9. Test refusal and withdrawal Where part of the stack relies on consent:covered trackers must not start before the choice; refusal must follow applicable interface requirements; withdrawal must have an effect; the signal must reach all relevant tags; new pages and components must respect the choice.Test behaviour, not only the CMP appearance. 10. Validate and retain the assessment The controller makes the final decision, with DPO or legal support where appropriate. Record:countries; purposes; inventory; criteria reviewed; vendor evidence; configuration; tests; residual risks; date and owners; review triggers.The answer may differ for a French corporate site, an authenticated app and an international property group. Cookieless, consent mode and no banner Cookieless The term can mean no persistent cookie, no cookie in one mode, alternative storage, identifier-free events, server-derived identifiers or simply no advertising cookie. Ask for the technical definition. Consent mode A consent mode communicates user choices to tags and can change their behaviour. Depending on the product and setup, signals may still be sent without advertising cookies. It helps implement a decision. It does not decide whether no-consent collection is legally permitted, and it does not turn advertising into strictly necessary measurement. No banner This statement can only be assessed across the complete site. It may be reasonable when no non-essential component runs before consent and the audience measurement genuinely meets the applicable framework. It is misleading when based only on the absence of an analytics cookie. Claims to avoidabsolute GDPR or legal-compliance claims; blanket consent-exemption claims; claims that cookie-free analytics automatically remove every banner; claims of official CNIL certification; claims of official CNIL approval; “No personal data” “No legal assessment required”The CNIL explicitly states that a solution cannot present itself as certified or approved by the authority merely because of the audience-measurement self-assessment. More accurate wording includes:“cookieless by default”; “designed for minimal collection”; “can be configured for limited audience measurement”; “exemption depends on purposes, configuration and context”; “users remain informed”; “the complete site stack must be audited”.Precision protects credibility as well as compliance. When a banner remains necessary Depending on applicable law and configuration, consent is generally still relevant for:personalised advertising; retargeting; ad-network sharing; cross-site tracking; profile enrichment; some session-replay uses; non-essential personalisation; third-party embeds with non-essential trackers; analytics beyond a limited measurement purpose.The existing guide to session replay and the CNIL consultation explains why detailed behavioural recording should not be treated like aggregate audience statistics. A simple decision process Case A: strictly limited measurement Minimal collection, no cross-site tracking, no vendor reuse, anonymous statistics, controlled retention, information and documentation. Action: assess and document the local framework, then inspect the rest of the site. Case B: enriched analytics after consent The team wants detailed events, advanced attribution or more persistent identifiers. Action: block the relevant capabilities until consent, transmit the choice correctly and document the processing. Case C: mixed stack Minimal measurement runs by default, with extended modules enabled after consent. Action: separate the modes technically, prevent reporting changes from silently expanding collection, and test every transition. Clear separation is more credible than one setting claimed to fit every use. Conclusion A no-banner promise cannot be inferred from “cookieless”. It follows from an assessment of the complete site, purposes, terminal operations and configuration. Before communicating, verify:every component; purposes; terminal access; data and identifiers; vendor use; configuration; retention; transparency; consent behaviour where applicable; the documented decision.The result may be a no-banner strict stack, a consent-based extended stack, or a clearly separated combination. Quality comes from the distinction, not the slogan. FAQ Is cookieless analytics automatically exempt from consent? No. Assess other terminal operations, purposes, data, identifiers and applicable national law. Cookieless is a technical feature, not a legal conclusion. Does the CNIL certify exempt analytics tools? No. The CNIL provides criteria and a self-assessment tool but says providers cannot present that self-assessment as official certification or approval. Can visitors be informed without a banner? Yes, when consent is not required for the relevant collection, information can be provided in a privacy notice or another appropriate location. It must remain clear and accurate. Do UTM tags prevent an exemption? Not automatically, but their use and combination must remain compatible with the limited purpose, minimisation and absence of cross-site tracking. They must never contain personal data. Who decides whether the site can operate without a banner? The controller makes and documents the decision, supported by a DPO or legal adviser where needed. A vendor alone cannot guarantee the answer for every site. SourcesCNIL, Audience-measurement cookies and consent conditions CNIL, What does the law say about cookies and trackers? Directive 2002/58/EC on privacy and electronic communications EDPB, Guidelines 05/2020 on consent EDPB, Guidelines 2/2023 on the technical scope of Article 5(3) ePrivacy
- 04 May, 2026
Session replay and CNIL: what teams should verify after the 2026 consultation
On February 25, 2026, the CNIL opened a public consultation on a draft recommendation for session replay tools. The consultation period ended on April 22, 2026. As of this article's publication date, teams should treat the draft as a strong warning signal while monitoring the final recommendation. Session replay tools are not ordinary audience-measurement tools. They can record detailed interactions: scrolling, clicks, form behavior, interface hesitations and sometimes typed content if masking is incomplete. That level of detail creates a different risk profile from aggregated traffic statistics. The practical consequence is simple: product, marketing and support teams should not activate session replay as a casual dashboard add-on. It needs a documented purpose, minimization settings, masking, access control, retention limits and a clear decision on when recording is allowed. What makes session replay sensitive Session replay can help diagnose UX issues, broken forms or confusing flows. But the same recording can reveal personal data, sensitive fields, account context or unexpected behavior. A misconfigured tool can collect more than the team intended. That is why the CNIL draft focuses on proportionality and safeguards. The useful question is not whether a vendor is popular. It is whether your configuration actually limits what is captured, who can view it and how long it remains available. A launch checklist for teams Before enabling session replay, review these points:define the exact purpose: UX debugging, support investigation, quality assurance or another documented need; disable recording by default on sensitive pages and authenticated areas unless there is a validated reason; mask form fields, free-text inputs, account data and any field that can contain personal or sensitive information; limit the share of sessions recorded instead of recording every visit; restrict access to named roles and audit who can view recordings; set a short retention period and delete recordings after the operational need ends; document the tool, provider, transfers and retention in your privacy materials; verify that the recording state follows your consent and preference-management setup; keep a rollback procedure to disable recording quickly if a leak or spike is detected.How this differs from Pomelo's core analytics Pomelo's launch positioning is deliberately different. The default analytics model is cookieless, minimal and report-oriented. It is designed to answer operational questions with aggregate data, not to replay individual user journeys. That distinction matters. Session replay can be useful in a narrow debugging workflow, but it should not be confused with privacy-first audience measurement. For most SME, SaaS and multi-site teams, the baseline analytics stack should remain lighter than a recording tool. What to do now If you already use Hotjar, Microsoft Clarity, FullStory or a similar tool, run a short audit before launch:list every page where recording is active; inspect the last 20 recordings for accidental personal data capture; review masking rules with a non-technical stakeholder; confirm retention and access controls; decide whether the tool is still needed permanently or only during limited research windows.If the team cannot explain why recordings are necessary, it is safer to disable them until the purpose and safeguards are documented. Sources Sources checked on May 9, 2026.CNIL, Session replay consultation, February 25, 2026 CNIL, Cookies and audience measurement solutions Hotjar, Privacy and security Microsoft Clarity, Privacy overview
- 30 Mar, 2026
CNIL sanctions: what analytics teams should learn before launch
CNIL sanction decisions are useful because they show patterns, not just headline amounts. For analytics teams, the lesson is clear: risk rarely comes from measuring traffic in itself. It comes from unclear purposes, tracking before a valid choice, excessive collection, weak information, poor retention and provider relationships that nobody has reviewed. This article does not try to predict a fine. It gives product, marketing and legal teams a launch checklist grounded in the CNIL's public sanction list and cookie guidance. The recurring analytics risks 1. Tracking starts too early If advertising, personalization or advanced tracking fires before the visitor's valid choice is recorded, the compliance issue is immediate. Teams should verify scripts in the browser, not only in a tag manager diagram. 2. The purpose is too broad "Analytics" can hide several purposes: audience measurement, ad attribution, retargeting, product analytics, support, personalization and CRM enrichment. These purposes do not carry the same risk or consent analysis. They must be separated in configuration and documentation. 3. Data is kept too long Retention is a recurring sanction theme across CNIL decisions. Analytics teams should define retention for raw events, derived reports, exports and backups. The answer cannot be "as long as the tool allows". 4. Provider roles are unclear The site publisher remains responsible for understanding what the provider does. Review data-processing terms, hosting, transfers, sub-processors and reuse clauses before launch. 5. The public explanation is vague A privacy policy that only says "we use cookies to improve the experience" is not enough for a modern analytics stack. Explain the tool, purpose, data categories, retention and choice mechanism in concrete terms. How to reduce risk before launch Run this practical check:open a clean browser profile and inspect which scripts fire before any choice; map each tag to a purpose and owner; remove tags nobody can justify; separate minimal audience reporting from richer marketing tracking; document retention and export rules; review provider terms and transfer mechanisms; update privacy copy with actual tool names; keep evidence of the test in the release checklist.For Pomelo, this means keeping the public promise conservative: cookieless by default, minimal collection, clear documentation, Strict first and Extended by explicit configuration. Why this matters for SMEs SMEs often assume enforcement only targets large platforms. The CNIL sanction list shows that smaller organizations can also be sanctioned, including through simplified procedures. The amounts differ, but the operational lesson is the same: a small team still needs traceability, minimization and a clean release process. Good analytics governance is not bureaucracy. It prevents last-minute launches from becoming privacy incidents. Sources Sources checked on May 9, 2026.CNIL, public list of sanctions, updated April 14, 2026 CNIL, Cookies and other trackers CNIL, Cookies and audience measurement solutions
- 23 Mar, 2026
GDPR analytics checklist: 10 checks before installing a tracking tool
Installing analytics is easy. Governing analytics is harder. A script can be live in five minutes, but the team still needs to know what it collects, why it collects it, how long the data stays available and which choices are presented to visitors. Use this checklist before adding or changing a measurement tool. It is not legal advice. It is a practical review framework for product, marketing, engineering and privacy stakeholders. 1. Define the purpose Write the purpose in one sentence. "Understand audience and site performance" is not the same as advertising attribution, retargeting, product behavior analysis or CRM enrichment. Separate the purposes before discussing tools. 2. Split baseline and enriched collection Define what belongs in minimal audience reporting and what belongs in enriched tracking. Campaign parameters, detailed events, goals, technical context and multi-site segmentation should be deliberate configuration choices. 3. List the fields collected Review the payload, not only the dashboard. Check URL, referrer, user agent, language, screen data, campaign parameters, identifiers, events and custom properties. Remove fields that do not serve the stated purpose. 4. Check tracker timing Use a clean browser profile and inspect which scripts fire before any visitor choice is recorded. Do this on the homepage, landing pages, forms, checkout or signup flows and authenticated areas. 5. Set retention rules Define retention for raw events, aggregated reports, exports and backups. Long retention should be justified by a real operational need, not by a vendor default. 6. Review provider terms Confirm the provider role, hosting location, sub-processors, transfers, support access and reuse clauses. Keep the current data-processing agreement with the launch record. 7. Update public information Your privacy policy should name the tool, describe the purpose, list the main data categories, explain retention and point to the relevant choice or objection mechanism. 8. Test Strict and Extended behavior If your product separates Strict and Extended collection, verify both modes in the browser and in storage. Strict should not persist enriched fields. Extended should be explicit and documented. 9. Control access and exports Analytics data often spreads through CSV exports, screenshots and shared dashboards. Restrict access to people who need it and define how exports are handled. 10. Keep evidence Save the browser test, payload review, provider links, privacy-policy update and release owner in your launch checklist. Evidence matters when decisions are challenged later. Pomelo launch reading For Pomelo, this checklist translates into a simple doctrine: Strict by default, Extended by configuration, no profile mutation from reports, and clear dashboard explanations when data availability changes with collection mode. SourcesCNIL, Cookies and other trackers: https://www.cnil.fr/fr/cookies-et-autres-traceurs CNIL, Cookies and audience measurement solutions: https://www.cnil.fr/fr/cookies-solutions-pour-les-outils-de-mesure-daudience EDPB, Guidelines 05/2020 on consent under Regulation 2016/679: https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-052020-consent-under-regulation-2016679_en EDPB, Guidelines 07/2020 on controller and processor concepts: https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-072020-concepts-controller-and-processor-gdpr_en