How to migrate analytics from Matomo to privacy‑first analytics

Why migrate from Matomo

The transition to privacy-first analytics usually starts not with the interface, but with the question: why change Matomo at all. There are three answers. The first is privacy requirements, the second is the desire to simplify data collection, and the third is to reduce dependence on cookies. If you have a website with an audience from the EU, a medical project, or just a team that doesn't want to touch user consents unnecessarily, there is already a reason.

Matomo is often convenient as a familiar system, but its reports and settings gradually accumulate exceptions, plugins, and manual adjustments. At some point, the website owner needs not 'one more field in the consent form', but a simpler scheme where analytics is collected neatly and without unnecessary traces. Hence the request: how to transfer analytics from matomo to privacy-first analytics.

There is also a practical argument. When data collection relies less on cookies, it is easier to explain the logic to marketers, lawyers, and developers. Not to everyone. But most often — yes.

If Matomo is used only for basic events, there is no deep customization, and reports are needed for 5–7 regular decisions, migration usually goes smoothly without dramatic losses. It is more complicated when segments, ecommerce, and long goal chains are tied to Matomo; there a plan is needed, not just enthusiasm.

What to prepare before the transfer

Before the transfer, gather 5 groups of data: goals, events, traffic sources, Matomo reports, integrations, and site access. Without this, migration turns into a guessing game. And yes, guessing is almost always more expensive.

Start with the list of goals. Write down what actions are considered conversions: form submission, phone click, registration, file download, purchase. For each goal, it is useful to specify not only the name but also the page where it triggers and the conditions for triggering. One example is better than ten general phrases.

Then go through the events. In Matomo, they may have been tagged differently: some through JavaScript, some through GTM, some through server calls. A table or at least a document with columns 'event', 'category', 'action', 'label', 'page', 'note' will come in handy here. Such a list saves hours on analyzing old settings.

A separate block is traffic sources. Save which UTM tags are actually used, which channels are tied to advertising accounts, which campaigns come from short links or redirects. Without this, the new system may collect visits, but you won't understand where the user came from. And that is already a problem not for analytics, but for solutions.

Don't forget about integrations. CRM, call tracking, forms, chat, server-side event sending, BI dashboard — all of this needs to be listed before the start. If access to the site, GTM, CMS, or CDN is lacking, it's better to request them in advance. Otherwise, the transfer will stop at the second step.

Mapping Matomo metrics to the new system

Start comparing metrics simply: pages, events, conversions, UTM tags, and user segments. Don't try to match everything at once. First, the basics, then the nuances. This way, there are fewer chances to get confused by the differences in methodologies.

Pages in Matomo and the new system usually match by URL, but not always by normalization rules. Check how slashes, parameters, anchors, and redirects are accounted for. The same path can look like three different strings if the rules differ. This is especially noticeable for an online store on product cards and filters.

Events are better checked in pairs. For example, if there is a click on the 'Submit Application' button in Matomo, the same trigger needs to be created in the new system and not only the number of occurrences should be compared, but also the conditions. Sometimes in Matomo the event was captured on the parent block, while the new system waits for an exact selector. The surprise is simple, the consequences are unpleasant.

Conversions and goals require a separate list. For each old goal, write down: name, event source, page, condition, value. Then compare with the new model. If in Matomo the goal was counted by viewing the 'Thank You' page, while the new system counts the form by submit, the numbers will already differ from the start. This is normal, but only if you documented it in advance.

Check UTM tags at 2 levels: how they come into the system and how they are displayed in reports. Sometimes the difference arises from letter case, sometimes from campaign auto-suggestions, and sometimes from redirects that trim parameters. It's also worth describing internal segments: new users, returning users, traffic from email, users from a specific country. A segment without a description is almost always a future error.

Setting up privacy-first analytics

The basic setup starts with installing the counter. Next, set the cookie-less mode if it is supported by your platform. After that, enable consent-less collection where it is allowed by company policy and the legal framework of the project. It's not magic, but a sequence of 3-4 steps.

Filtering internal visits is necessary right away. If a team of 12 people opens the site 20 times a day, analytics quickly loses its meaning. Exclude the office IP, test devices, staging domains, and, if necessary, individual employee accounts. Otherwise, you will see a 'growth' from people who were just checking the button.

Next, set up the basic events: page view, form submission, click on phone, click on email, file download. Don't try to transfer everything from Matomo in one evening. Start with the core, then the rare events. At this stage, it is especially useful to refer to the documentation and the test environment.

If the chosen privacy-first analytics supports server events, use them where browser events break due to blockers or complex scenarios. This is important for payments, closed accounts, and long forms. But don't drag everything through the server, or you'll lose transparency in debugging.

Sometimes a separate test domain or staging report helps. You can safely click 7-10 key buttons, check filters, and ensure that private analytics is not collecting junk. Yes, it's boring. But then there will be fewer late-night edits.

Transfer of events, goals, and funnels

Prioritize event transfers: start with the 5-10 most valuable actions, then the rest. If you have e-commerce, start with add to cart, begin checkout, purchase, and only then connect filter views and clicks on recommendation blocks. The logic is simple: what affects money is transferred first.

Goals in Matomo were often built around thank you pages or specific URLs. In the new system, this approach is also possible, but it's better to review it along with the technical implementation. Sometimes the form is submitted via AJAX and the user does not land on a separate page — then event tracking is needed, not page tracking. This is more accurate and calmer.

Check funnels step by step. For registration, this can be 4 screens: landing page entry, button click, form filling, email confirmation. For ordering — cart, delivery, payment, confirmation. Each step should have its own trigger and its own test. One missed step breaks the whole picture.

If there were composite goals or segment funnels in Matomo, do not try to copy them literally. It’s better to break down the logic into separate events and rebuild the funnel anew in privacy-first analytics. Sometimes this reassembly is even more useful than the old scheme: unnecessary steps and dead clicks come to light.

For ecommerce scenarios, check amounts, currency, order ID, and cancellations. In practice, the transmission of price and discounts is often confused, and then the report looks nice but does not match the CRM. At this point, an internal document on calculation rules will come in handy.

Data quality check after migration

The first 3–7 days after launch are not for 'observing', but for comparing. Open old and new reports side by side and compare pages, events, conversions, sources. Discrepancies are almost inevitable. The only question is whether you can explain them.

Start the check with manual tests. Go to the site, open 2–3 pages, click a few buttons, submit a form, follow a UTM link. Then check if events appeared in the new system and if the user path is broken. Such a test sounds primitive, but it catches 80% of errors.

Check the referral traffic separately. It often disappears due to redirects, an incorrect exclusion list, or cookie-less mode settings. There are also errors with ad transitions: UTM is read, but the channel goes to 'direct' due to an intermediate page. If this happens, don't rush to blame the platform; first, check the transition chain.

Check the segments after the basic reports. If you had 2 segments by country and 3 by sources in Matomo, verify if the logic and volume match. Small deviations are acceptable, but a sharp drop in one segment usually indicates a filter or rule error.

A good practice is to keep a discrepancy log. It records the date, page, event, old value, new value, and explanation. This is helpful when someone asks a week later why purchases have decreased by 12. You don't have to search for the answer again.

What to do with the old Matomo after the transition

After transitioning to Matomo, it is not necessary to delete it immediately. Often, three options are left: archiving, freezing data collection, or complete shutdown. The choice depends on legal requirements, retention periods, and how often the team returns to old reports.

If an archive is needed, leave access as read-only and record the date of data collection cessation. This is convenient for historical comparisons and internal audits. If the reports are no longer used in work, the main findings can be transferred to documentation: a list of goals, sources, segment rules, important exceptions. The document is short but helps in disputes after 6 months.

Completely shutting down the old installation is not suitable for everyone. Sometimes Matomo remains as a backup for 30–60 days to catch missed events or disputed discrepancies. It can then be removed when the new analytics consistently collects all necessary actions.

Launch checklist and control after transfer

Before the final launch, check 8 things: the counter is set, cookie-less mode is enabled, internal visits are excluded, goals are rebuilt, UTM parameters are read, forms are captured, ecommerce is transmitted, reports are opening. If at least one item is empty, it's better not to rush the launch.

In the first days after the transfer, appoint one person responsible for analytics. Not a team, but one person. They look at the logs, compare reports, collect errors, and answer the question of why the 'Contacts' page suddenly has 0 events. This mode is especially useful when a release and an advertising campaign are happening simultaneously in the project.

Then establish a regular review — every 2 weeks or once a month, depending on traffic. Check new forms, new buttons, new landing pages, new advertising UTM parameters, and changes in the consent banner. Any modification on the site can affect analytics, even if the developer swears that 'we only changed the text'.

And one more small but frequent point: keep a list of all changes in one place. When in 3 months you have to explain why the privacy-first analytics event flow has changed, you will be glad that you are not searching for the history through chats, tickets, and the memory of one tired marketer.