Tag: Tracking plan
All blog posts with this tag.
- 27 Jul, 2026
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
- 20 Apr, 2026
A minimal analytics tracking plan for SMBs: 12 events are enough to run a website
For years, many teams approached analytics tracking as an endless checklist. Track everything, name everything, enrich everything, and hope that one day someone will actually use the data. In practice, that usually creates the opposite result. The tracking plan grows too wide, the event list becomes messy, parameters get harder to read, and the dashboard stops helping people make decisions. The tool collects more, but the team understands less. For an SMB, a B2B website, a lead generation site, or a small SaaS property, the right logic is usually much simpler: measure less, but measure what helps you act. That is what a minimal tracking plan is for. It does not try to describe every micro-interaction. It tries to answer a few useful questions:where traffic comes from; which pages attract attention; which pieces of content create intent; which actions suggest progress; which actions count as real conversions.This article offers a practical framework with 12 events at most. It is not a universal truth. It is a robust starting point for teams that want analytics to stay readable, governable, and useful. A tracking plan is not a technical inventory, it is a decision framework The first mistake is to start from the tool. You open the documentation, discover dozens of recommended events, and then try to squeeze all of them into the site. That is the wrong direction. A good tracking plan starts with the decisions the team needs to make. For example:Which pages actually support acquisition? Which content drives lead generation? Which calls to action work? Where do visitors drop off? Which signals deserve a monthly review, and which ones are just curiosity?Until those questions are clear, adding more events does not help much. Google Analytics 4 explicitly separates automatically collected events, recommended events, and custom events. The key point is not that many options exist. The key point is that a team does not need all of those options to get useful analytics. The same is true with tools such as Matomo and Plausible. They can track actions beyond pageviews. That capability is valuable. It becomes counterproductive when it pushes teams to document every movement on the site. What a minimal tracking plan should cover For SMBs, a lean tracking plan should cover five areas. 1. Core audience reading Before adding events, you still need the basics:pageviews; landing pages; sources or referrers; campaigns when they are actively used; main conversions.In other words, event tracking should not compensate for a weak audience dashboard. If your reporting does not already explain which pages attract qualified traffic, twenty extra events will not fix that. 2. Intent signals Not every visitor converts right away. You need a few intermediate signals: a strategic CTA click, a file download, internal search, a demo request, the start of signup, and similar actions. These signals help you read progression. They should not become an artificial funnel for its own sake. 3. Real conversions A minimal plan should identify what actually matters for the site:form submissions; booked meetings; trial starts; confirmed purchases; validated signups.If an action does not influence any decision, it probably does not need to exist as an event. 4. Obvious friction points The goal is not to replay every session. The goal is to see where intent gets lost. Repeated internal searches, clicks to pricing with no follow-up action, or checkout starts without completed purchases can already be enough to reveal a problem. 5. Tracking governance A tracking plan without governance drifts quickly. You should know:why the event exists; who asked for it; where it fires; which parameters are actually useful; when it can be removed.This is often the difference between a clean setup and an accumulative one. The 12 events that are enough in most cases Here is a simple model. Not every team will need all 12. Many can start with 6 to 8. 1. form_submit This is the most universal event. It covers contact forms, quote requests, demo forms, and inbound lead forms. Why track it: it captures explicit intent. Useful parameters:form_name page_type2. demo_request If your B2B site offers demos, it is worth distinguishing that action from a generic form. It often reflects stronger intent. Why track it: it separates general contact from more qualified demand. Useful parameter:placement3. newsletter_signup This is usually secondary compared to commercial intent, but it can still be a strong content signal. Why track it: it measures a lighter conversion that is useful for content teams. Useful parameters:placement content_type4. account_signup For SaaS products or member areas, the start of signup nearly always deserves dedicated tracking. Why track it: it shows the move from visit to account creation. Useful parameters:plan_type placement5. trial_start If a trial exists, it should be tracked separately from a simple signup. Volume may be lower, but the signal is much closer to revenue. Why track it: it brings analytics closer to the real pipeline. Useful parameter:plan_type6. purchase_complete For ecommerce sites or SaaS products with direct subscription, this is the most important end-state event. Why track it: it anchors the setup in real conversion rather than vague intent. Useful parameters:plan_type billing_cycle7. phone_click On many local business, consulting, services, and B2B sites, the phone is still a conversion path. Why track it: not every conversion goes through a form. Useful parameter:placement8. email_click The same applies to mailto links. On some sites, this matters more than another decorative click on a product page. Why track it: it shows direct contact intent. Useful parameter:placement9. file_download White papers, brochures, product sheets, or PDF documentation can indicate serious intent, as long as you stay selective. Why track it: it helps identify the assets that generate tangible engagement. Useful parameters:file_name content_type10. outbound_click Not every outbound click deserves tracking. But some external links are strategic: Calendly, payment platforms, partner portals, marketplaces, or core documentation. Why track it: it explains useful exits from your site. Useful parameters:destination_type placement11. search_submit If your site includes internal search, it is often one of the most revealing signals. Visitors are telling you what they are looking for. Why track it: it reveals the gap between site architecture and user intent. Useful parameters:query_group results_stateImportant: avoid sending raw search terms if that creates unnecessarily sensitive collection. Grouping or aggregation is often the better choice. 12. checkout_start or pricing_cta_click The twelfth event depends on the type of website. For ecommerce: track checkout_start. For B2B sites without direct purchase: track pricing_cta_click or another major commercial CTA. Why track it: it captures the shift from interest to active intent. Useful parameters:placement offer_typeThe real discipline: limit parameters A bad tracking plan does not only contain too many events. It also contains too many properties attached to each event. A simple rule works well here: only keep parameters that change how you read performance. For example:placement can help compare a CTA in the header and footer; plan_type can help separate free, starter, and pro; form_name can help if several forms exist.By contrast, many parameters create little value:the exact button text; the full URL when it is already visible elsewhere; casing variations and naming inconsistencies; redundant details that mostly complicate analysis.Plausible, for example, lets you attach custom properties to events. That is useful. But technical possibility is not the same as analytical necessity. The more you enrich, the more you have to read and maintain later. A simple naming convention beats a complex framework For a minimal plan, the following convention is enough:event names in English; clear action verbs; no spaces; no near-duplicates; stable meaning over time.Good examples:form_submit trial_start file_download phone_clickAvoid names like:CTA Final Hero Demo contactFormSuccessNew btn_click_v2 conversion_importantThe rule is simple: the name should still make sense six months later, even to someone who was not part of the original implementation. What not to track first A minimal plan also means accepting what not to measure. Do not start by tracking:every scroll; every navigation click; every accordion open; every hover; every visual button variation; every video interaction if nobody uses that data; every micro-step of a long form unless a proven problem exists.This data can feel reassuring because it looks detailed. In reality, it often creates noise. The recommended implementation order To avoid turning tracking into an endless project, deploy in three waves. Wave 1: main conversions Start with:form_submit demo_request purchase_complete trial_startNot every team will have all four, but every team should start with the events closest to value. Wave 2: intent signals Then add:phone_click email_click file_download checkout_start or pricing_cta_clickThat is often enough to read the useful middle of the journey. Wave 3: orientation signals Only then, add if needed:search_submit newsletter_signup account_signup outbound_clickThis sequence keeps tracking under control. First document what supports decision-making, then what improves interpretation. A simple example of a minimal tracking table This documentation format is enough for most SMBs:Event Trigger Why track it Parametersform_submit successful form submission measure inbound leads form_name, page_typedemo_request demo click or confirmed request isolate strong commercial intent placementnewsletter_signup confirmed signup measure content-driven conversions placement, content_typeaccount_signup signup started or completed read visit → account progression plan_type, placementtrial_start trial activated track the signal closest to revenue plan_typepurchase_complete purchase or subscription confirmed measure the final conversion plan_type, billing_cyclephone_click click on phone link capture non-form conversions placementemail_click click on mailto link follow direct contact intent placementfile_download file download triggered measure interest in key assets file_name, content_typeoutbound_click click to a strategic external domain understand useful exits destination_type, placementsearch_submit internal search submitted read user intent query_group, results_statecheckout_start or pricing_cta_click checkout started or key pricing CTA clicked identify the shift to action placement, offer_typePrivacy matters, even in a minimal setup This point matters. A minimal tracking plan is not automatically a legally simple one. The CNIL makes clear that audience measurement can, under certain conditions, fall within a specific regime, but the analysis still depends on purposes, configuration, and actual data use. Once you move into broader marketing use cases, acquisition logic, or richer reuse, the compliance analysis changes. In practical terms, that means two things:keep the tracking plan proportionate; clearly separate useful audience measurement from broader marketing needs.In other words, a good tracking plan is not just lean. It is also explainable. What to keep in mind For SMBs, a good tracking plan is not trying to impress anyone. It is trying to remain usable. In most cases, 12 events are more than enough, and often 6 to 8 are enough to start well. The key is not to build an ambitious taxonomy. The key is to answer a few simple questions every month:what attracts qualified traffic; what creates clear intent; what actually converts; where progress gets lost; which data the team truly understands and uses.If your tracking plan becomes more complex than your decisions, it is probably already too heavy. FAQ Should we implement all 12 events on day one? No. Most teams should start with the 4 to 8 events closest to real conversions, then expand only when a clear use case appears. Why keep event names in English on a non-English site? Because it often makes maintenance, technical consistency, and future transcreation easier. The important thing is not the language itself, but stable naming. Is a button click enough to count as a conversion? Not always. A click can be a useful intent signal, but it does not replace a real conversion such as a submitted form, an activated trial, or a confirmed purchase. Can campaigns and UTM data fit in a minimal setup? Yes, but acquisition reporting and event tracking are not the same thing. Campaign data can be useful, but it does not justify an inflated event taxonomy on its own. How do we know an event should be removed? If nobody looks at it, if it drives no decision, if it duplicates another signal, or if nobody on the team can explain why it exists, it probably deserves to go. SourcesCNIL, Cookies: solutions for audience measurement tools: https://www.cnil.fr/fr/cookies-solutions-pour-les-outils-de-mesure-daudience CNIL, Recommendation on cookies and other trackers, consolidated 2026 edition: https://www.cnil.fr/sites/default/files/2026-01/recommandation_cookies_consolidee.pdf Google Analytics, Analytics - Recommended events: https://developers.google.com/analytics/devguides/collection/ga4/reference/events Google Analytics, Set up events: https://developers.google.com/analytics/devguides/collection/ga4/events Google Analytics, Set up event parameters: https://developers.google.com/analytics/devguides/collection/ga4/event-parameters Matomo, JavaScript Tracking Client Guide: https://developer.matomo.org/guides/tracking-javascript-guide Matomo, Event Tracking User Guide: https://matomo.org/guide/reports/event-tracking/ Plausible, Custom event goals: https://plausible.io/docs/custom-event-goals Plausible, Custom properties for events: https://plausible.io/docs/custom-props/for-custom-events Plausible, Goal conversions: https://plausible.io/docs/goal-conversions