Govanalytics versus Matomo: where the limit of a good choice lies

At large Dutch implementing organisations running Matomo (https://matomo.org), the same pattern keeps emerging: three legitimate requirements that can no longer all be met simultaneously.

• Leadership teams want up-to-date dashboards.
• Data architects want visitor data in the central warehouse.
• System administrators want fewer cron jobs in the monitoring stack.

Two of the three is manageable; achieving all three becomes structurally difficult once an organisation exceeds around one hundred million events per month.

This is not a privacy question. Unlike with Google Analytics, this isn’t about Schrems II, not about the Data Protection Authority, not about data leaking to the US. Matomo solved those problems four years ago. This is about what happens when a public organisation grows beyond what Matomo was originally designed for — a good privacy-first analytics application, not a warehouse-native data platform.

I’ve been working in privacy-first analytics since 2016, first for eight years at Piwik PRO. Over that period the Matomo question has fundamentally changed. Five years ago, the question was whether public organisations could work with Matomo. That question has been answered; they could, and many have. The question that has replaced it is what you do when you look ahead at the next five years.

What Matomo deserves to be said first

Matomo is not Google Analytics. That sounds obvious, but it sets the tone for this entire comparison. Matomo is one of the most mature privacy-first analytics products in Europe, it has been running in various forms since 2007, and it has successfully moved a serious number of Dutch and European public organisations away from Google dependency.

What Matomo concretely does well: a comprehensive UI with heatmaps, session recordings, A/B testing, form analytics, and funnels that you won’t find as integrated anywhere else in this price range. A plugin ecosystem that, after fifteen years of growth, genuinely answers most niche questions. Strong privacy tooling with cookieless configuration and consent management. WordPress integration that is often relevant in public sector contexts. CNIL recognition, GPL licence, transparent roadmap.

For many public organisations, Matomo remains the right answer. If you run dashboards for one website, your event volume sits well below 2–3 million per month, your marketing team actively uses heatmaps and A/B tests, and your analytics data doesn’t need to coexist with other data sources — then the question I’m about to ask is not your question.

For other organisations, it is.

Where Matomo’s limits become visible

The problem with Matomo in a public sector context is not one thing. It’s four things, each manageable on its own and together the reason for the kind of conversation that opens this article.

The data model itself. Matomo stores data in a normalised MySQL schema spread across tables such as log_visit, log_link_visit_action, log_action, conversion, and archive tables. For dashboard use through Matomo’s own UI, this is invisible. For a data analyst who wants to join visitor data with other sources, for a BI tool wanting to query the database directly, or for an AI agent that needs to find patterns, every useful question requires a series of joins. The schema was built to feed Matomo’s own reports, not to be queried by anyone else.

Scale. Matomo’s reports rely on pre-aggregation via archive cron jobs. Under normal load, this works well. Above around one hundred million events per month, it starts to strain: cron jobs fall behind, dashboards show yesterday’s data instead of this afternoon’s, MySQL tuning becomes a weekly activity, and the IT team starts submitting serious hardware budget requests. Not impossible to manage; but it’s no longer an analytics tool — it’s an infrastructure project.

The operational burden of self-hosting. Running Matomo yourself means PHP, MySQL or MariaDB, archive cron monitoring, plugin updates, GeoIP database updates, security patches, and database tuning. Each component is manageable on its own. Together they form an operational surface that is large for smaller public organisations with limited IT capacity, and that requires a dedicated role for larger organisations. When the person who originally set it up changes jobs, a typical knowledge cliff appears.

The warehouse path. For public organisations developing a broader data strategy — a central data warehouse, dashboards combining multiple sources, AI applications on structured data — Matomo’s positioning is awkward. Matomo Cloud has a warehouse connector and you can configure exports to Looker Studio or BigQuery, but that remains an export workflow out of Matomo. The primary storage sits in Matomo’s own database; everything else is a derivative. For an organisation thinking warehouse-first, that’s the wrong direction.

For some organisations, a fifth consideration comes into play: Matomo Cloud runs on AWS Frankfurt. For public organisations reading “data sovereignty” strictly — no non-EU sub-processors — that’s a consideration. For most it’s not a problem. Matomo is completely clean on this front when you self-host.

What Govanalytics does differently

Govanalytics is built to solve this specific problem for (public) organisations that don’t want to throw away their entire measurement strategy. The technical foundation is D8a.tech, MIT-licensed open source.

Most importantly: Govanalytics accepts Matomo tracking requests. Matomo’s own addTracker API can send the same events to a Govanalytics endpoint, in parallel with Matomo itself. For organisations that have invested years in their Matomo tagging, this means the tagging implementation doesn’t need to change. You add a second receiver, validate that the figures match, and then choose which path to take.

The data arrives in a flat schema. No joins between log tables, no action ID resolution. Session context, campaign data, e-commerce fields, and custom dimensions sit directly on the event row. For BI tools, for data analysts, and for AI agents, that’s the difference between “we can query this” and “we need to build a transformation layer first”.

There are no archive cron jobs. Data is almost real-time queryable. At high volumes, that means no dashboards lagging behind because a batch process has stalled.

To be honest about what Govanalytics does not do compared to Matomo: no heatmaps, no session recordings, no A/B testing, no form analytics. No plugin ecosystem. The built-in dashboard layer is deliberately simpler than Matomo’s UI. If your organisation actively uses Matomo’s richer UI modules, it’s not self-evident that Govanalytics is an upgrade; it’s a different kind of tool.

Four paths out of Matomo

It would be unfair to suggest this is a choice between Matomo and Govanalytics. For public organisations running into Matomo’s limits, there are four paths.

A decision framework that actually works

Four questions that in my experience determine which path fits.

• How close are you to the scale limit? If your event volume is below ten million per month and won’t exceed that in the coming years, Matomo’s scale issue is not your issue. Above the tens of millions it becomes relevant. Above one hundred million it’s usually decisive.

• Do you have a data strategy where visitor data coexists with other sources? If yes, warehouse-native weighs heavily. If no — if analytics can remain an island used only by the communications team — then Matomo’s own UI is often the pragmatic choice.

• How much do you actually use Matomo’s UI modules? Be specific. Heatmaps set up in 2022 and never looked at since don’t count. A/B tests planned but never run don’t count. If the honest usage patterns come down to standard web reports plus the occasional export, you’re giving up less than the tool comparison suggests.

• How much operational burden do you want and can you carry? Self-hosting Matomo at scale is engineering work. Matomo Cloud shifts that to a vendor but adds the AWS sub-processor. Govanalytics managed shifts it too, without that sub-processor. None of these options is free — choose deliberately which form of burden fits your team.

Answer these four honestly, and the right path usually narrows itself.

The switch is less painful than most teams think

The biggest myth around a Matomo-to-warehouse migration is that you need to roll out a new tracker, build a new tagging implementation, and rebuild all your dashboards. In practice, you don’t have to.

Because Govanalytics accepts Matomo’s tracking protocol, you can start by using Matomo’s own addTracker API to send the same events to two endpoints — Matomo itself and Govanalytics. No changes to the website, no new tagging implementation. You let it run for a few weeks, compare figures, validate the schema, and then choose whether Matomo stays for the UI (with Govanalytics as the warehouse pipeline), or whether you gradually switch over entirely.

For public organisations facing upcoming data strategy deadlines, NIS2 trajectories where the entire tool stack is being reviewed, or a central warehouse in the pipeline, that’s the difference between “we can sort this out within a quarter” and “this will become a multi-year project”.

Where this is heading

Matomo itself will move in this direction. The warehouse connector and the Looker Studio integration are already steps on that path; I expect Matomo’s own architecture to evolve further towards warehouse-native storage in the coming years, because that’s where the broader data stack is heading. The bet I’m making at D8a.tech is that organisations that want to go there now don’t have to wait.

The smart move for public organisations evaluating today is to make the choice that fits the current operational reality — with one eye on data portability. Make sure that whatever you choose enables you to extract your raw data and load it into a warehouse. That’s where the next migration will land, one way or another, for everyone.

Matomo remains a good choice for many public organisations. What’s changing is that more and more organisations are running up against the limit of that choice — usually not suddenly, but gradually, in the form of a data architect asking about warehouse access, a leadership team wanting more up-to-date dashboards, or an IT team that wants fewer cron jobs in the monitoring stack. For those who recognise that limit, there is now a path that doesn’t mean starting from scratch.