The flaws of mighty Matomo and how to tackle them

Published: 22.10.2025
Categories: Analytics, Security
Reading time: 5 min
Uncomprehensible code in the background and laptop with easy to read dashboard in the center of the image

As Matomo grows to be more and more used analytics system for multiple reasons, it does have its flaws and development areas. As many of Wunder’s clients wish to use a highly GDPR compliant and tailorable analytics tool, Matomo has a strong role in our toolbox. In this article, we share insights on the underlying issues the tool has – and reveal our solutions for tackling those issues.

The open-source alternative and the only true challenger to Google Analytics is Matomo (formerly known as Piwik). On top of being way more GDPR compliant than Google Analytics (4), Matomo offers a solid list of ready-made reports. Those reports are usually one-dimensional, only allowing viewing based on page title or page URL, respectively, one at a time (with the exception of Event reports with two dimension levels in each report by default).

Achilles heel of Matomo

But Matomo’s default way to filter data is limited searching with words that are included in the search, so it's not that optimal unless you have a simple URL structure. This leads to people needing to utilize the collected data to be frustrated with questions like “How do I see my pages?” or “How do I filter my pages?”

Matomo has come up with a solution for this – but so have we. Let’s look at the solution Matomo offers and then see how we build upon that to make the data even more accessible and use-worthy.

Matomo's solution

Matomo's Paid Plugin Custom Reports tackles this issue partly by allowing improved filtering options for reports and adding multiple levels of dimensions, such as (page URL, page title), in a single view, filtered by page URL starting with /fi/, for instance. This addition is great, but creating each of these reports is slowish and always requires an archival process to actually create the report, and this can take several hours to have more than yesterday's data available.

The list of Custom Reports tends to grow rather quickly and can work out perfectly when planned early and added to Matomo's dashboard view to glance daily or weekly, but this doesn't solve the need for Ad-hoc or debugging. For Ad-hoc reporting, you still rely on searching with contains rules on Matomo's default reports and the custom reports you’ve created.

So in a nutshell, Matomo’s solution works as long as one does not need debugging or ad hoc reports.

Solution 1, debugging events Wunder way

Our best solution to debugging events (to see if everything works as it should) has been to use the visits log view, which displays the user’s flow and actions. Each of the events and all of the information for page views and events is visible by simply hovering the mouse over the particular element. We often see on React / Next.js front page title and page URL mismatches, and this sometimes is the only way to see the issue without a custom report plugin, also it is quicker. 

Visits log session from demo.matomo.cloud, displaying all of the actions and details in single view
Visits log session from demo.matomo.cloud, displaying all of the actions and details in single view

Solution 2, better dashboards, Wunder way

The Matomo interface has certain limitations, which is why a more future-proof approach is to use the data on another platform rather than relying solely on Matomo. By accessing the data through BigQuery, it can then be processed more quickly and flexibly.”

Our preferred solution with Matomo Cloud Instances for a longer term is to export the data to Google BigQuery with the new beta functionalityOpens in a new tab. We export the data to an external platform because the raw data shows you exactly what it has available. Matomo UI works great, but it does not have the filtering capacity required, basic filtering such as “How many page views this page gets and split by source / medium”. The information is available but not accessible with the UI constraints. Matomo's tables are based on visits, actions, goals, and action types.

Screenshot of BigQuery view of the list of Matomo tables exported via DataWarehouse plugin
Screenshot of BigQuery view of the list of Matomo tables exported via DataWarehouse plugin.

This is how we do it

We aim to

  1. Create a flatter table that has the necessary fields to do in-depth analysis more easilt
  2. Provide more Google Analytics-like experience, for instance, source and medium information is not available for rows/sessions that don’t come from ‘Campaigns’

Matomo’s raw data tables only show ID numbers, not the actual page names or titles. To make the data easier to understand, we build two simplified tables that replace those IDs with real names, page titles, and other useful text. This way, instead of staring at a list of numbers, you can immediately see which pages or actions people interacted with.

This is the default view of log_link_visit_action table
This is the default view of log_link_visit_action table
The picture shows how we turn Matomo’s raw tracking data into clear labels, like where visitors came from (for example: search engine, social media, or direct link). We also add an easy-to-read “channel” field, so you can filter and compare traffic sources just like in Google Analytics.

The picture above shows how we turn Matomo’s raw tracking data into clear labels, like where visitors came from (for example: search engine, social media, or direct link). We also add an easy-to-read “channel” field, so you can filter and compare traffic sources just like in Google Analytics.

Matomo unfortunately, reuses its fields, and it requires quite a lot of playing around to match the fields from the log_action list.

Screenshot of BigQuery query where events are categorised
We take the IDs that Matomo stores for things like page URLs, page titles, and events, and turn them back into meaningful names (so instead of just an ID number, you see “Homepage” or “Download brochure”). Because Matomo sometimes uses the same field for both page views and downloads, we also check the file type to make sure downloads are correctly identified.

Bonus: Why exclude URL parameters in Matomo

One more tip we want to share with the rest of the world on this topic. In Matomo, every new page title, event, or page URL variation is stored with its own ID. This means that even small differences — like tracking tags, session IDs, or search queries — create new entries. The result is a long list of “unique” pages that are actually just versions of the same page.

Screenshot of matomo.log_action table filtered with /search showing all of the unique versions of the same page
Screenshot of matomo.log_action table filtered with /search showing all of the unique versions of the same page

For example, /search, /search?utm_source=newsletter, and /search?sessionid=123 all show up as separate items in reports. This makes the data harder to read and slows down Matomo, since it needs to process and combine all these variations. By default, Matomo doesn’t distinguish between the clean page path and the extra query values.

Screenshot of Matomo with the unique urls displayed in the UI
Screenshot of Matomo with the unique urls displayed in the UI

Our recommendation: Exclude parameters so you only track the base page paths. This keeps reports clear and performance faster.

You can do this in Settings → Websites → Manage → Excluded parameters 
by adding the regex rule /.*/.

In a nutshell

We believe Matomo is a very powerful, trustworthy, and GDPR compliant tool, and with the ways of working mentioned above it can combine the best of all worlds in analytics. If you feel you could perhaps better utilize the data available for your organization or wish to improve how you collect the data in the first place, send us a message. We are more than happy to discuss the possibilities of analytics in operational and strategic steering and development of your digital.

Related content

Loading...