Tag: Cookies
All blog posts with this tag.
Website tracker audit: a practical checklist for small teams
A tracker audit is not a cookie-counting exercise followed by a screenshot. Its purpose is more practical: to understand which components communicate with which services, when they do so, why they exist and what data they transmit. That distinction matters. A site can set no HTTP cookie and still send information to third parties. Conversely, a cookie may be strictly necessary to deliver a feature requested by the visitor. The word “cookie” does not determine purpose, risk or the applicable legal rule. For a small business, B2B SaaS team or multi-site operator, the useful output is not a fifty-page report. It is a reproducible inventory connected to owners, decisions and remediation work. Keep one boundary clear from the start: a technical audit is not a legal opinion. It provides the facts needed to document the setup and support a qualified assessment. What the audit should answer By the end of the exercise, the team should be able to answer eight questions:Which scripts, pixels, SDKs and third-party resources load? Which cookies, local storage entries or identifiers are created? Which requests fire before the visitor makes a choice? What data appears in URLs, headers and request bodies? Which provider receives each data point? Which operational purpose justifies each component? How long are identifiers and collected data retained? Who can access, export or reconfigure the data?This prevents a common failure mode: reviewing the banner while never testing what the website actually does. European regulators use a technology-neutral understanding of trackers. It can include cookies, pixels, local storage and fingerprinting techniques. An empty cookie list is therefore not sufficient evidence that no tracking occurs. Build a representative test scope Testing the home page alone rarely gives a useful result. Components differ by template, journey and consent state. Your sample should cover at least:the home page; a content page; a product or service page; a pricing page; a form; a confirmation page; an authenticated area, where applicable; a page embedding video, maps, chat or booking tools; a campaign URL with UTM parameters; major language versions or domains in a multi-site setup.Test several states as well:first visit with no stored choice; reject all optional trackers; selective acceptance; accept all; returning visit with a saved choice; private browsing or a clean browser profile.Add a dedicated scenario for sensitive areas. A customer portal, healthcare form, HR page or admin interface should not be treated like an ordinary editorial page. A seven-step tracker audit 1. Start with a clean browser Use a fresh browser profile without extensions that block or rewrite requests. Open developer tools before loading the page and preserve the network log. Record:tested URL; date; browser and version; consent scenario; production or staging environment; person running the test.This makes the audit reproducible and allows a reliable before-and-after comparison. 2. Inventory loaded components In the Network panel, inspect scripts, images, fetch calls, XHR and documents. Record third-party domains and first-party-hosted files supplied by external vendors. A script served from your domain is not necessarily operated by your team. Proxies, tag managers and CDNs can obscure the functional source. For every component, capture:Field QuestionComponent Which script or service loads?Owner Which team requested it?Provider Who operates it?Purpose Measurement, support, security, advertising or media?Trigger Before choice, after acceptance or after an action?Observed data URL, referrer, IP, identifier or event?Destination Which domain and known processing region?Decision Keep, configure, defer or remove?Do not stop at the vendor name. The same company may provide products with very different data practices. 3. Inspect browser storage Review:first-party and third-party cookies; localStorage; sessionStorage; IndexedDB; service workers; application caches where relevant.For every entry, record its name, domain, lifetime, attributes and creation time. Secure, HttpOnly and SameSite are valuable security attributes, but they do not determine purpose or consent requirements by themselves. Clear site data between scenarios. Otherwise, an identifier created during the “accept” test can contaminate the “reject” test. 4. Compare behaviour before and after a choice Reload the same page in each state and compare:contacted domains; request count; created cookies; sent events; deferred scripts; calls triggered by interaction.A tag may stay silent at first load and fire after scrolling, clicking or opening a widget. Test the important interactions, not only the initial page request. For session replay, chat and personalisation tools, review masking and excluded areas. A minimal tracking plan is a useful reference point: collection should remain tied to a decision rather than the technical ability to record everything. 5. Inspect the transmitted payload Open representative requests and examine:full URL; query parameters; request body; headers; referrer; persistent identifiers; event properties.Look specifically for data that should not enter an analytics URL:email address; telephone number; name; customer ID; password-reset token; session token; free-form text; sensitive search query; case or account reference.URLs are routinely copied into logs, browser history, observability systems and support tools. Data placed in a query string can spread far beyond the analytics product. 6. Connect technical findings to governance The Network panel cannot answer every question. Review the vendor documentation and account settings:retention; hosting and subprocessors; international transfers; vendor reuse of data; sharing options; roles and access; exports; deletion; audit logs; multi-site configuration.Where a team is considering a limited audience-measurement exemption, the actual configuration matters. Under the CNIL framework, the purpose must be strictly limited to audience measurement for the publisher, and the result must be anonymous statistics without cross-site tracking or data combination. The national rules and implementation need to be assessed for the relevant country. 7. Turn the inventory into work Use four simple severity levels:Critical: sensitive data or tokens exposed, marketing tags firing after refusal, session identifiers in URLs. High: unknown provider, no internal owner, session replay on sensitive areas, uncontrolled retention. Medium: excessive lifetime, duplicate tags, unnecessary parameters, incomplete documentation. Low: naming cleanup, stale test tags, missing comments or weak evidence.Every action needs an owner, due date and validation test. “Review later” is not a workable remediation item. A 90-minute first pass A small site can complete an effective initial review in one short workshop. 20 minutes: map the scope List critical templates, expected tools and consent states. 30 minutes: observe Inspect network and storage on three to five pages in the initial, reject and accept states. 20 minutes: reconcile Compare observed domains with the consent interface, privacy notice, tag manager and vendor contracts. 20 minutes: decide Remove ownerless components, open high-priority tickets and schedule deeper tests. This does not replace a full assessment, but it often finds the most expensive issues: forgotten scripts, duplicate tags, personal data in URLs and premature firing. Common audit mistakes Treating a scanner as a conclusion Automated tools help discover domains and cookies. They cannot always determine purpose, event context or contractual configuration. Their findings need manual verification. Testing only “accept all” The reject state is often the most informative test because it shows whether the visitor’s choice is actually enforced. Ignoring first-party requests A request sent to your own domain may still be proxied elsewhere or contain data that should not be collected. Auditing production once A new tag-manager rule, CMS plugin or marketing integration can change collection without a visible interface change. Lightweight quarterly reviews and pre-launch checks are more useful than one large annual exercise. Producing a table with no owner An inventory without decisions, owners or dates becomes stale quickly. Governance turns the audit into actual risk reduction. The minimum evidence package Keep four items:the component inventory; key evidence, such as screenshots or network exports; a decision log with rationale; remediation tasks and retest results.Version the document. For multi-site teams, add a “web property” column and distinguish global components from local exceptions. Conclusion The goal is not to declare the site perfect. It is to explain what was observed at a given date, why each component exists and how gaps are being resolved. FAQ Does a cookieless site still need a tracker audit? Yes. Pixels, network calls, local storage and identification techniques can operate without HTTP cookies. The audit must focus on data flows and purposes, not only cookies. Are automated scanning tools enough? No. They accelerate discovery but do not replace manual checks of trigger conditions, payloads, account settings and internal ownership. Must every page be tested? Not necessarily. Select a representative sample of templates, integrations, journeys and consent states, then test sensitive areas more deeply. How often should the audit be repeated? After material stack changes, before sensitive launches and on a cadence that matches the rate of change. For a small team, a lightweight quarterly review is often more realistic than a large yearly audit. Does a technical audit prove GDPR compliance? No. It documents technical facts. Compliance also depends on purposes, legal bases, contracts, transparency, individual rights and applicable national ePrivacy rules. Sources Sources checked on June 21, 2026.CNIL, Cookies and trackers: what does the law say? CNIL, Cookies and audience measurement solutions CNIL, public consultation on session replay, February 25, 2026 EDPB, Guidelines 2/2023 on the technical scope of Article 5(3) of the ePrivacy Directive Chrome for Developers, Network panel reference OWASP, Information exposure through query strings in URL
- 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