ENFR

Blog: Privacy, GDPR & Audience Measurement

Guides and analysis on GDPR compliance, privacy-first analytics, SEO measurement, and audience tracking for modern websites.

Cyber Resilience Act: preparing incident reporting for software, scripts and SDKs

Cyber Resilience Act: preparing incident reporting for software, scripts and SDKs

The Cyber Resilience Act is progressively becoming operational for software publishers. From 11 September 2026, manufacturers in scope will have to report actively exploited vulnerabilities and severe incidents that impact the security of products with digital elements. For a B2B SaaS company, analytics tool, JavaScript script, SDK or component distributed to customers, the topic should be analysed carefully. It would be wrong to assume that every SaaS service is automatically covered in the same way. It would also be risky to wait until December 2027 before organising incident response. This article is not a legal qualification. It gives product, security and engineering teams a practical preparation method when they distribute software or components used by customers. What changes on 11 September 2026 The European Commission states that, as of 11 September 2026, manufacturers must report certain events concerning products with digital elements: actively exploited vulnerabilities and severe incidents affecting product security. The timelines are short:early warning without undue delay and within 24 hours of becoming aware; vulnerability notification within 72 hours; final report within the applicable deadline, including 14 days after a corrective measure or mitigation becomes available for an actively exploited vulnerability, or within one month of the 72-hour notification for certain severe incidents.Notifications go through the CRA Single Reporting Platform, operated by ENISA, and are routed to the competent CSIRTs according to the applicable rules. The important point is that these reporting obligations arrive before the full application of the main product obligations under the Cyber Resilience Act. They should be prepared now, even if other parts of the regime come later. Why scripts and SDKs deserve attention Analytics teams often think first about the security of the main application: authentication, dashboard access, exports and databases. But the product surface can include other elements:a JavaScript script installed on customer sites; a client-side or server-side SDK; an open-source library maintained by the vendor; a connector or plugin; an API used to collect or expose data; an admin interface capable of changing injected code.These elements do not automatically have the same legal qualification. But they belong in the security inventory, because a vulnerability in a distributed component can affect multiple customers at once. For an analytics product, the collection script is especially sensitive. It runs on third-party websites, in visitors’ browsers, and may be updated centrally. A distribution flaw, compromised build or unauthorised modification could have a broader impact than a broken chart in a dashboard. Do not confuse a bug, a vulnerability and a severe incident Not every technical issue is a CRA report. A broken chart, a loading problem or an aggregation error is not necessarily an actively exploited vulnerability or a severe security incident. The first step in the runbook should therefore be qualification.Situation Question to askFunctional bug Does it affect product security or only user experience?Internally found flaw Is it exploitable, exposed, fixed or communicated?Actively exploited vulnerability Is there evidence of real exploitation?Security incident Does it have a severe impact on product security or users?Personal-data incident Does it also require separate GDPR breach assessment?The risk runs both ways. Under-reporting a truly serious issue exposes the organisation. Reporting every unqualified bug creates noise and weakens response discipline. The decision should be documented even when the conclusion is that no report is required. The minimal runbook to prepare A useful runbook must be concrete. It should not merely say “notify legal”. It should allow the team to act in the first hours. 1. Component inventory List products, scripts, SDKs, plugins and connectors distributed or made available to customers. For each one, document the internal owner, repositories, build pipeline, update mechanism, exposed customers, critical dependencies and communication channels. 2. Qualification criteria Define a simple grid: whether security is affected, whether exploitation is observed, potential impact, customer scope, corrective measure availability, technical evidence and possible parallel obligations. 3. Decision team Identify who can qualify the event: engineering, security, product, leadership, legal and the DPO when personal data is involved. Backups should be known. Weekends and holidays should be covered. 4. Timestamping The deadline starts when the organisation becomes aware. The team must record when it had enough information to suspect or qualify the event. A ticket without a reliable timestamp will make compliance harder to demonstrate. 5. Evidence and logging Preserve logs, versions, build hashes, deployed artefacts, exploitation traces, customer messages, internal alerts and qualification decisions. The evidence should be sufficient to reconstruct the timeline. 6. Reporting channel The Single Reporting Platform is operated by ENISA. Teams should know who has the necessary access, which information is needed and what to do if the primary access path is unavailable. ENISA has indicated that there is no API planned at this stage, which makes human procedures even more important. 7. Customer communication Regulatory reporting does not replace customer communication. Prepare concise templates: what is known, what remains uncertain, what customers should do and when the next update will come. Analytics and third-party scripts An analytics script should be treated as a sensitive asset, even when it collects limited data. It may be embedded in public pages, conversion funnels or authenticated environments. The security of the script therefore matters not only to the vendor but also to the sites that install it. Concrete controls include:separation of rights between application code, build pipeline and script publication; dependency review; signing or integrity controls for artefacts where relevant; detection of unexpected changes; fast rollback capability; mitigation or disabling procedure; documentation of versions deployed to customers.These practices are useful beyond the CRA. They reduce operational risk and make crisis communication more reliable. What to decide now Teams that wait for the first incident to organise their response will lose time in the first 24 hours. Those are exactly the most constrained hours. By the end of September, a software team should be able to answer four questions:Which customer-distributed components could be in scope? Who qualifies an actively exploited vulnerability? Who can submit a notification within the deadline? How can the decision timeline be proven?If these answers do not exist, the topic is not yet under control. Conclusion The Cyber Resilience Act should not be reduced to a distant 2027 deadline. Reporting obligations applying from 11 September 2026 already require manufacturers in scope to prepare. For SaaS and analytics vendors, the priority is not to panic or to assume everything is automatically covered. The priority is to inventory components, qualify roles, prepare the runbook and document decisions. A good reporting process is not only a regulatory response. It is evidence of product maturity. FAQ Does the CRA apply to every SaaS dashboard? Not automatically. The qualification depends on the product, the role of the organisation and the way software components are placed on the market or provided. The article is a preparation checklist, not a legal classification of every SaaS case. Should every security bug be reported through the CRA process? No. The reporting duty discussed here concerns actively exploited vulnerabilities and severe incidents with a security impact, according to the CRA framework. Ordinary bugs still need internal handling, but they should not be confused with regulatory reporting triggers. Why should analytics teams care? Analytics stacks often include scripts, SDKs, API keys, client-side configuration and third-party dependencies. Even when the legal obligation falls elsewhere, teams need clear incident routing and supplier contacts. SourcesEuropean Commission - Cyber Resilience Act reporting obligations European Commission - Cyber Resilience Act summary ENISA - CRA Single Reporting Platform FAQ

Read article →
Search Console and generative AI: how to read the new reports without overinterpreting impressions

Search Console and generative AI: how to read the new reports without overinterpreting impressions

Google Search Console is becoming more useful for understanding visibility in generative search experiences. In June 2026, Google announced new reports dedicated to how pages appear in generative AI features in Search, such as AI Overviews and AI Mode, as well as some generative AI features in Discover. For SEO teams, this matters. It does not, however, turn Search Console into an attribution tool. An impression in a generative feature does not mean that someone visited your site, read your content, or identified you as the main source. It is a visibility signal. It becomes useful when it is interpreted carefully, compared with actual clicks, and connected to sessions measured on your site. The goal is not to create a new vanity metric. The goal is to understand what this visibility means, what it does not mean, and how to include it in SEO and analytics reporting without blurring the measurement layers. What changed in Search Console On 3 June 2026, Google announced new Search Console performance reports dedicated to generative AI. The reports are designed to help site owners understand how their pages appear in Google Search generative AI features. Google also states that this data remains included in the overall performance reports, while the new view isolates generative visibility. Google rolled the reports out worldwide on 31 August 2026. Their absence should therefore be investigated as an access, configuration or reporting issue rather than treated as the normal initial rollout state. The reports can show:impressions for URLs appearing in generative AI features; the pages involved; countries; devices, where available for Search; dates, with several time granularities; Search Console dates use Pacific Time.These fields are useful, but they do not replace classic Search Console or analytics metrics. They add a layer: visibility inside an interface where the answer is often summarised before a click happens. AI impression, click and session are different signals A frequent mistake is to merge three separate levels of measurement. An AI impression means that one of your URLs appeared in a generative feature according to Google’s reporting methodology. It is a signal of presence in the search interface. A click means that a user selected a link to your site. It is a potential transition from Google to your site. An analytics session means that a visit was observed on your site by your analytics tool, according to its own collection, filtering and deduplication rules. These signals can move differently. A page can gain impressions in AI Overviews without gaining clicks. A page can receive more clicks from Google while analytics sessions do not increase as expected because referrers, redirects, parameters or filters distort the view. Conversely, a drop in sessions does not automatically mean a drop in search visibility. The useful approach is to keep the three levels separate, then reconcile them only when there is a clear diagnostic question. How Google counts AI Mode and AI Overviews Search Console documentation reminds site owners that counting rules vary by feature. For AI Mode, clicks, impressions and position are recorded using the usual Search Console methodology. If a user asks a follow-up question in AI Mode, that follow-up is counted as a new query. For AI Overviews, standard Search Console impression rules apply. The visibility-after-scrolling or expansion rule applies only to the independent widgets for which Google documents it. Links in the same AI Overview may also share the same position in reporting. These details matter. They explain why average position should not be read like a classic organic ranking. Appearing in a generative block is not the same format as a blue link, a carousel, a featured snippet or a local result. What not to conclude too quickly The first trap is to call every generative impression “AI traffic”. Until there is a click, it is not traffic to your site. It is visibility in a search interface. The second trap is to compare generative impressions and classic web impressions as if they belonged to the same inventory. The spaces are different, the displays are different, and user journeys do not create the same click-through behaviour. The third trap is to isolate a single indicator. More impressions can be good if they involve strategic pages. They are less useful if they relate to low-intent queries, irrelevant countries or pages that do not support the business. The fourth trap is to ignore measurement incidents. Search Console has a data anomalies page. It should be checked before attributing a curve break to an SEO or product change. A simple method for reading the report Start with a reference period. Avoid drawing conclusions from one isolated week, especially if the report has just appeared or volumes are low. A four-to-eight-week window is more useful when enough data is available. Then separate pages into three groups:acquisition pages, such as articles, comparisons and guides; conversion pages, such as product, pricing or demo pages; support or brand pages, which often respond to already-qualified queries.For each group, compare generative impressions, Search Console clicks and organic sessions measured on your site. The diagnostic is useful only if you can state a clear hypothesis. Examples:AI impressions increase, but clicks stay flat: your content is visible in the answer, but not necessarily driving site visits; clicks increase, but sessions do not: check referrers, redirects, parameters and analytics filters; impressions drop on a few pages only: check queries, country, device and content changes; all impressions drop suddenly: check Search Console anomalies first, then investigate SEO hypotheses.How to report it monthly In a monthly report for leadership or marketing teams, avoid a single line called “Google AI traffic”. It mixes too many realities. A clearer structure is:Google generative visibility: Search Console impressions in AI features, when available. Google organic traffic: Search Console clicks and analytics sessions. Traffic from external assistants or conversational engines: sessions with identifiable source or referrer, when your analytics tool observes them. Useful actions: demo requests, signups, email clicks, downloads or key events.This separation reduces overinterpretation. It also helps explain why a brand may be displayed more often without necessarily receiving more visits. Useful content actions Generative reports do not rewrite SEO fundamentals. Google states that SEO best practices remain relevant for appearing in generative AI features. Helpful, original, precise and non-commodity content remains more defensible than pages written only to fill a query pattern. In practice, teams can:strengthen pages that answer a real business question; document sources and update dates; clarify definitions, limits and use cases; avoid generic paragraphs that could be replaced by any competitor; connect Search Console to web analytics without merging the metrics.For a privacy-first analytics team, the key is readability. Measuring visibility in AI interfaces is useful only if it supports a decision: improving a page, correcting a diagnostic, adapting a report, or explaining why sessions do not grow at the same pace as impressions. Checklist before making a claim Before announcing a rise or drop linked to generative AI, check:that the report is available for the site; that the period is long enough; that the pages are strategically relevant; that impressions, clicks and sessions are separated; that countries and devices match the target market; that no known data anomaly explains the variation; that analytics attributes organic sessions correctly; that variations are put in context with content changes, seasonality and demand.Conclusion The new Search Console reports for generative AI are useful. They provide a clearer view into a part of Google Search that was previously difficult to isolate. But they should not be treated as automatic proof of traffic, authority or conversion. The right reading is to treat them as a visibility signal, then carefully connect them to clicks and sessions. As search becomes more fragmented, teams need less slogan-driven reporting and more contextual measurement. FAQ Does the Search Console AI report measure visits? No. It primarily reports search performance signals such as impressions and clicks. A visit should be confirmed in analytics when a user actually lands on the site. Does a drop in AI impressions mean SEO visibility declined? Not always. A change may come from real visibility, interface changes or a logging issue. The August 2026 anomaly is a reminder to check official notes before making a claim. Should AI visibility have a separate monthly report? At first, it is usually better to add a dedicated section to the existing SEO report. A separate report only makes sense when the volume and decisions attached to the signal become material. SourcesGoogle Search Central - Introducing Search Generative AI performance reports in Search Console Google Search Central - What are impressions, position, and clicks? Google Search Central - A new resource for optimizing for generative AI in Google Search Google Search Central - Data anomalies in Search Console

Email tracking pixels: what marketing teams should fix after the CNIL recommendation

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

Analytics migration: a checklist for changing tools without rebuilding tracking debt

Analytics migration: a checklist for changing tools without rebuilding tracking debt

Changing analytics tools can look simple: replace a script, wait a few days and compare the charts. That is rarely enough. A migration changes several layers at once:collected data; metric definitions; consent behaviour; events and conversions; website and workspace structure; access; retention; reports; decision-making habits.The main risk is not losing a chart. It is carrying old tracking debt into a new tool, then reading a methodological change as a business change. This checklist offers a twelve-step migration process for SMEs, B2B SaaS companies and multi-site teams. 1. Define why the migration is happening Write down the reason for the change. Examples include:reducing collection complexity; documenting data more clearly; improving readability across teams; reducing cost; controlling hosting or retention; simplifying consent governance; managing several sites consistently; replacing a discontinued or unsuitable tool.Turn the reason into acceptance criteria.Objective Verifiable criterionSimplify The monthly report uses five stable indicatorsReduce collection Every collected field has a documented purposeGovern multiple sites Access and naming are consistentControl cost Total cost is known for expected volumeClarify consent The actual configuration is documented and testedImprove quality Critical events pass an acceptance testWithout criteria, the project ends when the script runs. With criteria, it ends when the team can make decisions confidently again. Use the analytics governance scorecard to formalise this stage. 2. Inventory the current system before removing anything Create a technical and editorial inventory. Scripts and collection points List:scripts loaded by the site; tag-manager tags; advertising pixels; server-side collection; CMS plugins; mobile SDKs; backend events; CRM, support, payment and email integrations; consent settings; proxies and collection domains.Data and reports List:pageviews; events; conversions; custom dimensions; audiences; segments; funnels; recurring reports; exports; alerts; dashboards; API consumers; report recipients.Responsibilities For each component, record:owner; purpose; destination; collection condition to review; retention; access; dependencies; decision: keep, transform or remove.This inventory becomes the basis of the analytics data collection summary. It often reveals tags that nobody uses. 3. Freeze definitions before rebuilding Two tools may use the same words for different metrics. Visitor, user, session, engagement, bounce, conversion and source can depend on:time windows; identification methods; session rules; filters; consent; bot processing; time zones; attribution; received events.Create a migration dictionary:Business concept Previous definition New definition DecisionVisit Current session rule New tool's rule Compare trendsLead Form event Accepted submission StandardiseSource Calculated channel Referrer/UTM Document gapConversion Historical list Priority goals ReduceInternal traffic IP filter New rule RetestDo not force false equivalence. A documented break in the series is safer than artificially aligned numbers. 4. Reduce the tracking plan A migration is an opportunity to remove, not only copy. Classify existing events into four groups:decision events, required for a KPI or action; diagnostic events, useful for explaining a problem; operational events, required by an integration; orphan events, collected without an identifiable use.Remove orphans. Consolidate variants that describe the same action. Choose stable names and a clear property set. A critical event should specify:name; trigger; page or context; permitted parameters; example; owner; related KPI; success test.A minimal analytics tracking plan provides a practical baseline. 5. Inspect collection and URLs Before installing the new tool, review what it will actually receive. URLs can contain:UTM parameters; campaign IDs; internal search terms; email addresses; tokens; order references; customer IDs; form values; technical fragments.Define an allowlist or removal strategy. Keep acquisition parameters where necessary, but remove sensitive or purely technical values before storage. The guide to privacy-first URL parameter filtering explains this control. Also inspect:referrer; IP handling; headers; user agent; event properties; server-side payloads; infrastructure logs; exports.Cookieless describes only one part of collection. The migration must document the full signal set. 6. Review consent, contracts and governance Changing tools does not automatically make a configuration exempt from consent. Review:purposes; trackers or terminal access; collected data; enrichment; third-party disclosure; provider reuse; transfers outside the EEA; subprocessors; retention; objection mechanisms where relevant; user information; consent-manager configuration.The CNIL describes strict conditions for limited audience-measurement configurations. It also states that a solution should not be presented as officially certified or approved by the authority. Update:the processing register; privacy notice; tracker inventory; data-processing agreement; access and deletion procedures; internal documentation.The assessment follows the real configuration, not the provider name alone. 7. Build a pilot environment Avoid replacing every site at once. Choose:a representative site; one acquisition page; one form; a few critical events; enough traffic to observe behaviour; a period without a major redesign.Install the new tool as a pilot. A short, controlled parallel-measurement period may be useful, but two active systems can mean two scripts, two collections and two consent configurations. The goal is not identical totals. It is to verify that:expected pages appear; events fire once; sources are readable; filters work; conversions correspond to real success; time zones and domains are correct; access is controlled; sensitive data is absent.8. Use an acceptance-test plan A compact matrix is enough.Test Expected result Evidence StatusPageview One occurrence Network debug To validateSuccessful form One event after success Test ID To validateForm error No conversion Test evidence To validateUTM Readable source/campaign Test URL To validateSensitive parameter Value absent Received request To validateConsent declined Behaviour matches configuration CMP test To validateInternal traffic Excluded or identified Controlled session To validateCross-domain Coherent journey Controlled session To validateMobile CTA and form work Device tests To validateTest:normal and private browsing; mobile and desktop; accepted and declined consent; ad blockers where relevant; redirects; subdomains; languages; successful and failed forms; test campaigns.Store evidence with date, version and owner. 9. Decide what to do with history Historical data does not always need to be imported into the new tool. There are three options. Keep the previous tool read-only This is often simplest where contract, security and cost allow it. Restrict access and set a deletion date. Export an aggregate history Keep the indicators needed for future comparison:monthly traffic; top pages; sources; conversions; objectives; campaign notes; measurement incidents.A documented file or controlled warehouse may be sufficient. Import into the new tool Some providers offer imports. Plausible, for example, documents a Google Analytics import. GA4 can export event data to BigQuery when the link has been configured. An import does not guarantee a perfectly comparable series. Verify:imported scope; missing dimensions; granularity; definitions; time period; duplicates; time zones; consent-related restrictions; storage cost; deletion policy.Do not retain everything merely because it exists. Apply the analytics data retention policy to migrated history. 10. Prepare cutover and rollback The cutover should be reversible. Write a runbook containing:date and time; affected sites; technical owner; business owner; scripts to enable; scripts to disable; CMP configuration; immediate checks; alert thresholds; rollback procedure; communication channel; final approval.Avoid cutover:immediately before a major launch; on Friday evening; during a major campaign; without people available to fix issues; at the same time as a redesign and CRM change.Monitor critical events daily during the first week. 11. Rebuild reports around decisions Do not reproduce every dashboard automatically. Start with:objectives; five KPIs; priority pages; sources; conversions; lead quality; incidents; actions.For multiple properties, use shared naming and separate local reporting from consolidated management. The multi-site analytics dashboard guide provides a structure. Update the monthly web report with a migration note:migration date; previous and new tools; changed definitions; non-comparable metrics; stabilisation period; known anomalies.This note protects later analysis. 12. Decommission the old tool properly The migration is not complete while the previous system remains active without a purpose. Confirm that:scripts are removed from code; tags are removed from the manager; server collection is stopped; API keys are revoked; users and access are removed; webhooks are disabled; scheduled exports are stopped; collection domains are removed; contracts are adjusted; data is deleted or archived according to policy; the register and privacy notice are updated; billing is stopped; documentation is closed.Inspect network traffic after removal. An old tag may survive in a template, plugin, unpublished container or forgotten subdomain. Differences you should accept Differences during migration are normal. They can result from:session rules; consent; blockers; bot filtering; time zones; processing delays; duplicated events in the old system; user definitions; attribution; excluded pages; server-side collection.Assess differences by scenario rather than obsessing over totals. For a critical page or conversion, verify that the trend and operational result make sense. Document structural differences and establish a new baseline after stabilisation. Final checklist Before closing the project, confirm that: objectives and acceptance criteria are written; the old system is inventoried; definitions are documented; unnecessary events are removed; URLs and parameters are filtered; consent and contracts are reviewed; the pilot is validated; critical tests are documented; the history strategy is decided; cutover has a rollback path; reports are rebuilt; the old tool is decommissioned; a new baseline is communicated.Conclusion A good analytics migration does not copy every screen. It preserves useful decisions, clarifies definitions and removes collection that no longer has a purpose. The safest sequence is:inventory; define; reduce; document; pilot; test; cut over; decommission.The expected outcome is not merely a new dashboard. It is a measurement system that is easier to understand and govern. FAQ How long should two tools run in parallel? Only long enough to validate critical scenarios and observe normal operation. The right period depends on traffic and conversion cycles. A long overlap increases complexity, cost and collection. Should the new tool show identical figures? No. Definitions, filters, consent and session rules may differ. Compare scenarios, trends and real conversions rather than demanding artificial equality. Should all historical data be imported? Not necessarily. Keep only what supports obligations, comparisons or future decisions. A documented aggregate history is often more useful than a full but poorly comparable import. How can UTM parameters be preserved? Test redirects, forms and domain changes with controlled campaign URLs. Verify that useful parameters are read before they are removed or normalised. When should the old tool be deleted? After the new setup is validated, necessary history is secured, reports are updated and no integration still depends on the previous system. Sources Sources checked on June 21, 2026.CNIL, audience measurement solutions CNIL, defining data retention periods Google Analytics, set up BigQuery Export Google Analytics, account and property structure Plausible, import stats from Google Analytics OWASP, information exposure through query strings

Acquisition pages: seven signals to track without building an analytics maze

Acquisition pages: seven signals to track without building an analytics maze

An acquisition page does not need fifty metrics to be managed well. It needs to answer a short chain of questions:are the right people arriving? do they understand the proposition? do they move toward the intended action? do they complete it? are the resulting leads or sales useful? does the page work properly? is the measurement reliable enough to support a decision?This chain prevents two common mistakes. One is judging a page only by traffic volume. The other is adding behavioural events without connecting them to a business decision. For an SME or B2B SaaS team, seven signals are usually enough for a sound diagnosis. Define the page's job before its metrics Not every acquisition page has the same objective. A page may aim to:generate demo requests; start trials; collect quote requests; sell a product; deliver a resource; register attendees; move visitors to pricing; qualify a need before a sales conversation.Its primary KPI follows from that job. An educational content page should not be judged like a demo page. An awareness campaign should not be read like high-intent search. Document four elements first:Element QuestionAudience Who is the page for?Promise Which specific problem does it solve?Source Which channel or campaign brings visitors?Action What useful action should follow the visit?This short brief becomes the reference point when the numbers change. Signal 1: qualified entries by source The first signal is not raw session volume. It is the distribution of entries by source, campaign and intent. Two hundred visits from a precise query may be more useful than two thousand loosely targeted visits. Conversely, low volume does not prove quality if none of the visitors belong to the intended segment. Review at least:visits or sessions starting on the page; source and medium; campaign; identified ad or link content; organic query where Search Console provides it; country or commercial region when genuinely relevant; direct traffic, interpreted cautiously.GA4's Landing page report associates the first pageview in a session with metrics such as sessions and key events. It can also use Session source / medium as a secondary dimension. Search Console complements this view for Google Search with clicks, impressions, CTR, position, queries and pages. The tools do not measure the same thing. Search Console describes visibility and clicks in Google results. Analytics describes activity observed after arrival, within its collection limits. Their totals should not be expected to match visitor by visitor. For campaigns, a stable UTM convention matters more than a sophisticated dashboard. Our guide to UTMs, referrers and direct traffic explains how inconsistent labels fragment reports. Signal 1: Decision question Is the page attracting the audience its message was designed for? Signal 2: intent-to-message fit A page can receive relevant traffic and still fail because its promise does not match the reason behind the click. Compare:the ad copy; the keyword or query; the newsletter link; the visible headline; the supporting proof; the requested action.Someone clicking “compare analytics tools for multiple websites” should encounter that topic immediately. Opening with generic digital-transformation language creates a gap even when the design is polished. No single rate captures this signal. Use several clues:conversion by source or campaign; primary CTA clicks; movement toward the expected section; very fast exits, interpreted cautiously; feedback from sales or support; focused user tests.Engagement time can flag an anomaly, but it is not proof of interest. A long duration may mean close reading or confusion. A short duration may mean abandonment or an immediate answer. Signal 2: Decision question Does the visitor clearly find the promise that brought them to the page? Signal 3: primary call-to-action activity The primary CTA is the first observable commitment toward the objective. Track an action that matters, such as:clicking Request a demo; opening a form; moving to pricing; adding to cart; starting a trial; confirming a download; scheduling a meeting.Do not label every click as a conversion. Accordion opens, tab clicks and scroll depth can support diagnosis, but they do not carry the same intent as a commercial action. A useful measurement sequence is usually:page entry; primary CTA click; form or flow start; successful completion.This separates a messaging weakness from a form problem. If few visitors click, investigate what happens before the CTA. If many click but few finish, inspect the next step. A minimal analytics tracking plan helps keep those definitions stable. Signal 3: Decision question Does a sufficient share of qualified visitors choose to continue? Signal 4: conversion completion The final conversion is the action the business considers useful. It must be unambiguous. Examples include:an accepted form submission; a confirmed appointment; an account creation; a completed payment; an activated trial; a delivered download.Always name the denominator. “Eight per cent conversion” is meaningless without knowing whether it refers to visitors, sessions, form opens or CTA clicks. For a form, measure at least:opens; starts; errors; abandonment; successful completion.Do not send field values to analytics. Form content may contain names, email addresses, phone numbers, free text and other personal data. The business system needs the content. Analytics usually only needs a technical or functional status. Signal 4: Decision question Where does the journey lose people who already expressed intent? Signal 5: post-conversion quality A page can achieve a strong conversion rate and create poor commercial outcomes. For B2B teams, the decisive signal often appears after the form:fit with the target profile; a request genuinely related to the product; an attended meeting; an opportunity created; continued sales progression; revenue or value created; spam and off-target demand.Connect acquisition to the CRM with proportionate granularity. You do not always need to send personal CRM data back into analytics. An aggregate table by campaign, source or landing page may be enough to answer which entries produce useful demand. Agree on a short sales classification:qualified; unqualified; duplicate; spam; outside market; no next step; opportunity.This prevents marketing from optimizing only for form volume. Signal 5: Decision question Does the page create useful outcomes rather than submissions alone? Signal 6: technical performance and errors A slow or unstable page can damage the experience before the message is evaluated. Core Web Vitals provide three field indicators:LCP for main-content loading; INP for interaction responsiveness; CLS for visual stability.Complement them with operational checks:JavaScript errors; forms that cannot submit; blocked resources; mobile CTAs hidden by layout; incorrect redirects; a 404 after submission; missing or duplicated tracking; consent logic applied incorrectly; abnormal server response time.Do not confuse correlation with causation. A technical improvement may accompany a conversion increase without being its only cause. Use performance data to identify differences by device, release and period. Signal 6: Decision question Is a technical constraint preventing part of the audience from progressing? Signal 7: measurement health The seventh signal concerns the data itself. Before interpreting a change, verify:event volume relative to visits; duplicated tags; consent changes; missing or inconsistent campaign parameters; redirects that lose parameters; sensitive values in URLs; form changes; releases during the period; time-zone differences; internal filters and exclusions.A 30 per cent increase may come from a successful campaign, a duplicated event or a changed definition. Document measurement changes before assigning a business cause. Our guide to privacy-first URL parameter filtering helps prevent identifiers and sensitive values from entering reports. Signal 7: Decision question Does the observed change describe the market, or a change in the measurement system? A minimal dashboard A landing-page dashboard can use this structure:Block Primary measure Useful breakdownAudience Qualified entries Source, campaign, deviceMessage CTA clicks / entries Source, variantJourney Starts and completions Step, deviceOutcome Useful conversions Campaign, segmentQuality Qualified leads Source, pageTechnical Vitals and errors Device, releaseMeasurement Documented anomalies Date, deploymentLimit comparisons to segments that can lead to action. A filter that changes no decision adds complexity without improving control. Review cadence Weekly Check:traffic breaks; form errors; misattributed campaigns; extreme changes; mobile problems; performance incidents.Monthly Review:source quality; conversion trends; lead quality; pages and campaigns to improve; tested hypotheses; decisions made.Put the conclusion into the monthly web report rather than sending a separate export from each tool. Metrics not to over-interpret Bounce rate Its definition varies by tool and context. A short visit to a page that answers a question immediately is not necessarily a failure. Scroll depth It may show how far content was traversed, but not what was understood. It is useful for comparing variants, not for proving intent. Time on page It combines attention, confusion, abandoned tabs and measurement constraints. Heatmaps They can help form a hypothesis, but they do not replace conversion data or user research. They also involve more detailed collection that should be assessed separately. Click volume It only matters when the action matches an explicit objective and the event is not emitted more than once. Conclusion An acquisition page should be managed as a chain, not as a ranking of metrics. The seven useful signals are:qualified entries; intent-to-message fit; CTA activity; conversion completion; post-conversion quality; technical performance; measurement health.Start with this structure. Add a metric only when it answers a question the team is prepared to act on. FAQ What is the primary KPI for a landing page? It is the useful action defined for that page: a qualified request, trial, purchase, meeting or another explicit result. Traffic and engagement mostly explain that result. Should scroll depth be measured? Only when it tests a specific hypothesis, such as whether an important proof point is rarely reached. Scroll should not be treated as a conversion. Why do GA4 and Search Console show different figures? They measure different stages and scopes. Search Console measures appearances and clicks in Google Search. GA4 measures sessions or events observed on the site, according to its setup and consent choices. How can a landing page be connected to revenue? Preserve source, campaign and landing-page context in the CRM or a controlled attribution table, then analyse aggregate cohorts. Avoid sending unnecessary personal CRM data back to analytics. How many events should be tracked? For most B2B pages, four levels are enough: entry, CTA click, journey start and success. Add diagnostic events only when they address a known problem. Sources Sources checked on June 21, 2026.Google Analytics, Landing page report Google Search Console, Performance report web.dev, Web Vitals Google Analytics, collect campaign data with custom URLs CNIL, cookies and other trackers