Migrating from GA4 to Matomo is often framed as a technical task. Which tags to rewrite? Which parameters to keep? How to replicate existing reports?
That framing is wrong.
What you are really migrating is not a tool, but a way of thinking about measurement.
GA4 and Matomo are built on different assumptions about what an event is, what it should represent, and how meaning is created in analytics data.
If you ignore this and aim for a one-to-one migration, you will almost certainly end up with a brittle and confusing setup.
A good Matomo migration starts by accepting that some GA4 habits must be unlearned.
Two event models, two mental models
GA4 is built on a flat event model. Everything is an event. Page views are events. Scrolls are events. Purchases are events. Meaning is constructed later by combining event names with parameters and custom dimensions.
This model is flexible and expressive. It is also easy to abuse. In real-world implementations, it often leads to event names that carry too much meaning, parameters that act as hidden dimensions, and reports that only make sense to the person who implemented them.
Matomo follows a more classical model. Events have a structure by default: category, action, name, and optionally a value. You cannot postpone the meaning to the analysis time. You have to decide upfront what kind of interaction something actually is.
This difference is not cosmetic. It shapes how you design tracking, how you read reports, and how well your data survives organisational and technical change.
Everything discussed in this article applies equally to Piwik PRO Analytics.
Piwik PRO shares the same classical event model as Matomo: page views are their own action type, and events are structured around category, action, and name, with an optional value. The same design principles, therefore, hold.
Page views are not events in Matomo
One of the most important conceptual differences between GA4 and Matomo is also one of the simplest.
In Matomo, a page view is not an event.
It is its own action type.
In GA4, ‘page_view’ lives in the same namespace as ‘clicks’ and’ custom interactions’. In Matomo, page views capture navigation and content consumption, while events capture interactions that occur on top of page views.
This separation is intentional. It keeps event data focused on actual interactions rather than basic navigation. It also eliminates the need for artificial constructs such as virtual page view events, route change events, or navigation events that exist mainly to work around GA4’s flat model.
A practical rule helps here. If something happens when a page loads, it is probably a page view. If it happens after the page has loaded, it is probably an event.
Applying this rule alone usually removes a large number of unnecessary GA4-style events during migration.
Why one-to-one mapping does not work
Many GA4 events only make sense when combined with parameters. The same event name can represent several different user actions depending on context.
Matomo does not allow this ambiguity. An event must have a clear category, a clear action, and a clear identifier. This forces you to answer questions that GA4 allows you to defer or ignore.
- What kind of interaction is this?
- Where does it happen?
- What exactly did the user interact with?
Because of this, a true one-to-one mapping between GA4 and Matomo is not just difficult; it is impossible. It is conceptually impossible.
The right response is not to fight this limitation, but to use it as an opportunity to simplify and clarify your measurement.
Redesign before you migrate
A successful Matomo migration almost always reduces the number of tracked events.
This is not a loss. It is a signal that you are moving from exhaustive data collection towards intentional measurement.
Start by grouping GA4 events by actual user intent, not by event name. You will often discover that several events describe the same interaction with minor technical differences. Many of these can and should be dropped.
If an event does not support analysis or decision-making, it does not belong in your analytics setup.
Category: describe the UI component
In Matomo, the event category should describe what kind of UI component the user interacted with. Not the business outcome. Not your interpretation of the interaction.
Good categories are concrete, visible on the page, and stable over time. Examples include form, video, audio, menu, configurator, and calculator.
This approach has important advantages. Categories remain meaningful even when business logic changes. Reports stay readable without documentation. And similar components can be compared across the site.
A useful test is simple. If you cannot point to the component on the page, the category is probably too abstract.
Action: use verbs consistently
The action answers one question: what did the user do?
Simple verbs work best. Click, submit, play, pause, calculate, filter, download. The exact vocabulary matters less than consistency.
Avoid nouns and internal jargon. Actions should be readable as plain language, even by someone who did not implement the tracking.
Name: be explicit, not clever
The event name identifies what exactly was interacted with. This is where specificity belongs.
Names such as newsletter_footer, product_demo_intro, main_navigation_pricing, or loan_estimate_basic are not elegant, but they are clear. Clarity scales. Cleverness does not.
When in doubt, prefer longer and more explicit names. Storage is cheap. Confusion is not.
Value: only when it truly adds meaning
Event values should be used sparingly. They are useful when there is a natural numeric interpretation, such as video progress, scroll depth, result count, or a calculated value.
Adding numbers without a clear analytical purpose only creates noise. If you cannot explain how the value will be used in analysis, do not track it.
A cleaner result than GA4
When designed this way, Matomo events tend to be fewer but more expressive. The same action, such as a click, becomes meaningful through its category and name rather than through a complex combination of parameters.
Page views describe content consumption. Events describe interaction. Custom dimensions are used only when the data truly does not belong to the event itself.
This separation leads to reports that are easier to read, explain, and trust.
Final thought
GA4 encourages you to collect more data and decide later what it means.
Matomo forces you to decide first and collect less, but better, data.
A successful migration usually results in fewer events, simpler logic, and a setup that continues to make sense long after the original implementation details have been forgotten.
That is not a compromise. It is progress.