Matomo provides organisations with greater control over hosting, governance and privacy configuration. However, accurate reporting is not a consequence of platform selection alone. The value of data is contingent upon its accuracy, and data accuracy depends on implementation quality, testing discipline, and ongoing operational control.
This distinction is significant where analytics data is used to inform marketing investment, product analysis, customer journey assessment and commercial reporting. Certain defects may affect a limited set of reports. Others may affect the dataset’s integrity more broadly, depending on the role of the affected implementation component.
TagDataTrust assesses these matters across tracking, tagging, privacy, and governance, rather than limiting the review to the reporting interface. As the only certified Matomo Implementation Partner in the UK, TagDataTrust is regularly engaged to determine whether discrepancies originate in the platform configuration, the implementation approach or the surrounding operational controls.
This article outlines the most common Matomo implementation errors, along with the corrective controls to consider.
1. Incomplete or incorrectly configured tracking code
The Matomo tracking code is the point of origin for data collection. If it is absent from a template, directed to the wrong Matomo instance or configured with the wrong site ID, the resulting data may be incomplete or attributed to the wrong property.
Common issues include:
- Tracking code missing from landing pages, checkout steps, error pages or campaign-specific templates.
- The wrong Matomo URL or site ID being used in production.
- Development and production environments sending data into the same Matomo site.
- The tracker being loaded more than once.
- Tracking requests that fail due to a mixed HTTP and HTTPS configuration.
- Single-page applications not sending pageview updates when the route changes.
Recommended action:
- Maintain a documented tracking specification covering each website, app, environment and measurable.
- Compare the live implementation against that specification rather than relying solely on the presence of data in the reporting interface.
- Validate pageview behaviour at network level.
A robust implementation should be tested through source-code inspection and browser Network analysis to confirm that:
- The correct Matomo JavaScript file is loaded.
- Requests are sent to the intended matomo.php endpoint.
- The correct site ID is present.
- A pageview is recorded once per page view or virtual route.
- The request returns successfully.
This process can establish whether data loss is occurring at the collection level. It does not, by itself, confirm that the pageview model, channel definitions or downstream reporting logic are appropriate. Matomo’s guidance on addressing unexpected data discrepancies should also be considered where data collection appears active but reported volumes do not align with expectations.
2. Events that do not represent the underlying interaction
Events are frequently implemented as isolated tags without sufficient documentation of firing conditions or business purpose. This can result in a dataset that appears comprehensive yet fails to accurately represent the underlying interaction.
Common risks include:
- The same interaction being tracked under different event categories or actions.
- Events firing on page load rather than on the intended interaction.
- A click event firing through both a hardcoded _paq call and Matomo Tag Manager.
- Events being sent before the required data is available.
- Form events firing when a form is displayed rather than when it is successfully submitted.
- Events not being updated when the front-end implementation changes.
Recommended action:
- Maintain an event catalogue that defines the event name, trigger condition, page or component scope, expected frequency, and required parameters.
- Map each event to a specific business question or reporting use case.
- Validate that the event reflects the underlying application state rather than merely a superficial interaction.
For example, a completed application form should not ordinarily be measured solely through a button click. It is necessary to distinguish between:
- The form being viewed.
- The form being started.
- Validation errors being displayed.
- The form being submitted.
- The application being successfully accepted.
A robust implementation should reflect the difference between intent and completion. A click may indicate interest, but it does not confirm a successful outcome. Equally, a more detailed event model is not a substitute for validating the underlying application behaviour.
3. Ecommerce data being sent at the wrong point in the journey
Ecommerce tracking requires a higher level of implementation control than basic pageview collection. Product views, basket activity, checkout steps, and transactions should align with actual customer behaviour and commercial outcomes.
A common implementation error is transmitting a transaction when the customer reaches the confirmation page without verifying that payment was successful. If that page can be refreshed, revisited or loaded after a failed payment attempt, the same transaction may be recorded more than once.
Other frequent issues include:
- Failed transactions being recorded as successful orders.
- Refunds not being sent or reconciled.
- Product IDs, names or categories being inconsistent.
- Revenue values including or excluding tax and delivery inconsistently.
- Currency being omitted or changed between steps.
- Ecommerce data being pushed before the product or order data is available.
- Transactions being duplicated when a user refreshes the confirmation page.
Recommended action:
- Define the commercial source of truth for each transaction.
- Tie the transaction to a unique order ID where possible.
- Send transaction data only after the order has reached the agreed success state.
Ecommerce QA should test:
- A successful transaction.
- A failed payment.
- A cancelled order.
- A refreshed confirmation page.
- A duplicate order attempt.
- A refund or partial refund.
- Multiple currencies, where applicable.
- Orders using discounts, delivery charges and tax.
This approach can reduce inflation or distortion in reported revenue. It does not, on its own, resolve broader reconciliation issues such as refund timing, tax treatment, cross-device identity or differences in reporting logic across other commercial systems. The principles described in our transaction-tracking and e-commerce case study are equally relevant to Matomo implementations.
4. Campaign parameters being lost or inconsistently applied
Campaign attribution depends on parameters surviving from the campaign link to the first Matomo tracking request.
Campaign data is frequently lost through:
- Redirects that remove query parameters.
- Link shorteners that do not preserve the full URL.
- Inconsistent naming conventions across teams and agencies.
- Email platforms that rewrite links.
- Internal links that overwrite the original campaign source.
- Campaigns using different parameter formats for the same channel.
Recommended action:
- Establish a campaign naming standard supported by a central register.
- Define permitted values for source, medium, campaign, content and keyword fields.
- Apply explicit rules for paid, organic, email, affiliate and offline activity.
Test links should be created for each major channel. The first Matomo request should then be inspected to confirm that the expected campaign information is present. Reports should also be reviewed for unexplained increases in direct traffic, as this may indicate that attribution data is being lost.
This can improve attribution consistency, but it is not a replacement for formal agreement on channel classification across analytics, CRM and media reporting. Matomo’s integration documentation provides additional context for connecting Matomo with other platforms and systems that may affect campaign data collection or use.
5. Consent controls blocking more or less data than intended
Consent implementation is not solely a compliance matter. It also affects the completeness and consistency of analytics data.
A Matomo tracker may be configured to require consent without ever receiving the corresponding signal. Conversely, a consent management platform may release the tracker before the user has made a choice. In both cases, a mismatch arises between the stated privacy configuration and the actual collection behaviour.
The principal issues to assess are:
- Matomo loading before the relevant consent decision.
- Consent being recorded in one domain but not another.
- Consent state not being passed correctly to Matomo Tag Manager.
- Events being sent before consent is granted.
- Consent withdrawal not stopping future tracking.
- Different websites or apps applying different consent rules.
- Anonymous or cookieless measurement being confused with consented measurement.
Recommended action:
- Maintain a consent test matrix.
- Test each relevant consent state across websites, apps and domains.
- Verify both activation and withdrawal behaviour.
At a minimum, the following scenarios should be tested:
- Accepted.
- Rejected.
- Partially accepted.
- Withdrawn.
- Not yet given.
- Reset after a change to the consent configuration.
Matomo’s guidance on consent managers should be considered alongside the organisation’s own privacy requirements and CMP configuration.
The objective is not to maximise the number of hits collected. It is necessary to ensure that the data collected in each consent state is deliberate, documented and technically enforced. This can improve both compliance confidence and reporting consistency, but it does not remove the requirement to define what level of measurement is acceptable by jurisdiction, domain or app context.
6. Server configuration and hosting issues
For self-hosted or on-premise Matomo deployments, server configuration forms part of implementation quality.
A correctly configured browser tracker may still produce unreliable results if the Matomo server is not operating as expected. Relevant issues include:
- Incorrect HTTPS or proxy configuration.
- Web server rules blocking matomo.js or matomo.php.
- PHP errors or insufficient memory limits.
- Database connectivity problems.
- Incorrect file and folder permissions.
- Caching of tracking endpoints or JavaScript files.
- Failed scheduled archiving or maintenance tasks.
- Incomplete monitoring of server and database logs.
Recommended action:
- Maintain an operational runbook covering server status, PHP configuration, database performance, scheduled tasks, backups and upgrades.
- Monitor tracking endpoints separately from the Matomo user interface.
- Incorporate Matomo-specific maintenance requirements into broader service management and change control procedures.
A robust implementation should not assume that a functioning user interface confirms successful processing of new tracking requests. Matomo provides guidance for on-premise installation and maintenance, and that guidance should be reflected in operational processes.
7. Exclusions removing legitimate traffic
Exclusions are necessary in certain circumstances. Internal staff, test traffic and known bots may need to be removed from reporting. Risk arises where exclusions are broad, undocumented or applied without sufficient consideration of traffic routing.
Examples include:
- Excluding a complete corporate IP range that also contains remote users or customer traffic.
- Using a user-agent pattern that matches legitimate browsers.
- Excluding an entire subdomain when only a test environment should be removed.
- Applying different exclusions in different Matomo sites.
- Removing historic data without retaining a record of the change.
Recommended action:
- Maintain an exclusion register.
- Record an owner, rationale, defined scope and review date for each exclusion.
- Test IP ranges and user-agent patterns against real traffic before implementation.
This can reduce reporting noise, but overly broad exclusions may exclude legitimate visits and complicate reconciliation. When comparing Matomo with server logs, CRM data or another analytics platform, it is necessary to account for differences in bot filtering, consent, session definitions and attribution rules. A discrepancy is not necessarily evidence of an implementation defect, but it should be explainable.
8. Duplicate data caused by overlapping implementations
Duplicate data is one of the more damaging Matomo implementation errors because it can cause performance to appear stronger than it is.
Typical causes include:
- A hardcoded Matomo snippet and a Matomo Tag Manager container both sending pageviews.
- A tag manager firing a pageview in addition to the standard tracker.
- Multiple containers installed on the same page.
- A single-page application sending both automatic and manual route changes.
- Ecommerce transactions being sent by both the browser and a server-side process.
- A tag firing more than once because its trigger condition is too broad.
Recommended action:
- Define one authoritative owner for each hit type.
- Document the source of every pageview, event and transaction.
- Validate hit volumes at network level.
A robust implementation should be tested by inspecting requests to the Matomo endpoint and confirming that each expected interaction generates the correct number of requests. This is more reliable than checking whether a tag appears to have fired in a tag management interface.
Removing duplication can materially improve data quality, but it does not guarantee that the remaining data model is complete or aligned with business definitions.
9. When a Matomo data quality review is likely to be appropriate
A focused Matomo data quality review is often appropriate when:
- Reported traffic or revenue no longer reconciles with commercial or operational systems.
- A migration, redesign or tag management change has recently been released.
- Multiple websites, apps, or markets feed into the same reporting environment.
- Consent changes appear to have affected trends, but the impact is not yet clear.
- Self-hosted infrastructure ownership is split across analytics, development and IT teams.
- Senior stakeholders need greater confidence in the implementation before using the data to inform planning or investment decisions.
It may be less urgent where the implementation is small, stable, recently tested and already governed through documented QA and change control. Even then, periodic review can still be useful, particularly if the website changes frequently.
A practical Matomo QA control framework
Matomo data quality is usually best treated as an ongoing control process rather than a one-off implementation task.
Before release
- Review the tracking specification.
- Test implementation in a controlled environment.
- Confirm consent behaviour.
- Validate pageviews, events and ecommerce payloads.
- Check that the correct site ID and endpoint are used.
- Confirm that duplicate trackers are not present.
Immediately after release
- Test the principal website templates and customer journeys.
- Review live visits and recent activity.
- Inspect browser Network requests.
- Compare key volumes with an agreed baseline.
- Check server logs and scheduled processing.
- Confirm campaign attribution using live test links.
On an ongoing basis
- Run automated journeys across important pages and conversion paths.
- Monitor for missing or duplicate requests.
- Review sudden changes in pageviews, events, revenue or direct traffic.
- Re-test consent after CMP or website changes.
- Review exclusions and campaign conventions.
- Keep the implementation documentation current.
Automated monitoring is particularly useful for large organisations with multiple websites, frequent releases or complex customer journeys. It does not replace expert investigation, but it can identify changes before they become embedded in regular reporting.
A practical approach is to combine three elements:
- Clear implementation design
Define what should be collected, why it matters and which system or tag is responsible for sending it. - Release-level validation
Test browser requests, consent behaviour, ecommerce logic and environment separation before and after changes go live. - Ongoing governance
Review anomalies, exclusions, campaign standards, server operations and documentation on a recurring basis.
This approach can improve confidence in Matomo reporting over time. It does not remove every source of discrepancy, particularly where other systems use different definitions, attribution rules or reporting windows.
Conclusion
Matomo can support strong analytics governance and reliable reporting where the implementation is designed, tested and maintained appropriately. However, platform capability does not remove the need for specification, QA, consent control, operational oversight or reconciliation against other business systems.
In practice, Matomo data quality is less a function of any single configuration choice than of whether collection has been implemented as a controlled technical system. A robust implementation should assign a defined purpose, a known source and a practical validation method to each important data point.
This approach will not eliminate every discrepancy, nor is it a replacement for wider reporting governance. It can, however, improve the organisation’s ability to identify where issues originate and which corrective controls are likely to have the greatest effect.
If you’d like to hear more on this topic and set up a 1:1 call with us, please use the contact form. Contact a Consultant
