The value of analytics data depends on its accuracy, consistency, and governance. Running Matomo Tag Manager (MTM) and Google Tag Manager (GTM) can be an appropriate approach where an organisation operates Matomo alongside marketing, advertising or other vendor technologies managed through GTM.
It does not, however, resolve incomplete measurement specifications, poor data quality, inadequate consent controls or unclear operational ownership. A second container may increase flexibility, but it also increases the number of configurations, release paths and failure points requiring control.
The decision should therefore be treated as an architecture and governance decision rather than a simple platform preference. The appropriate model depends on the role of Matomo, the vendor ecosystem, the consent management platform (CMP), the application architecture and the capabilities of the teams maintaining the implementation.
1. The role of each container system
MTM is designed as a native companion to Matomo Analytics. It provides containers containing tags, triggers and variables, with the container snippet deployed to the website. It can manage the Matomo tracker and other marketing or functional tags through a single interface. Matomo documents these core components in its Tag Manager User Guide.
MTM may be used in two principal ways:
- As the container for the Matomo JavaScript tracker.
- As a wider tag management system for Matomo and selected third-party tags.
- As a container that receives structured events from the website or application.
- As a system extended through custom tag, trigger or variable templates.
GTM has a broader vendor ecosystem and is commonly used for Google Analytics, Google Ads, Floodlight and third-party marketing tags. Google describes a container as a collection of tags, triggers, variables and related configurations installed on a website or application in its Introduction to Tag Manager.
GTM also provides server-side container options. A server container can receive event data from a web container, process it and forward it to selected destinations. This may support more controlled data routing and reduce some browser-side processing, although it introduces infrastructure, security and operational requirements. Google provides further detail in its server-side Tag Manager documentation.
The two systems are therefore similar in their basic operating model, but they are not identical products. MTM is closely aligned with Matomo tracking and its open-source ecosystem. GTM is generally broader in terms of vendor integrations, Google services and server-side deployment options.
TagDataTrust is the only certified Matomo Implementation Partner in the UK. This distinction is particularly relevant where Matomo is being deployed alongside another tag management system and the implementation requires platform-specific technical judgement.
2. Single-container versus dual-container architectures
A single-container architecture places the primary tag management responsibility in either MTM or GTM.
A GTM-led model may be appropriate where:
- Google Analytics and Google Ads are central to the measurement estate.
- Marketing and advertising vendors are managed through GTM.
- Server-side GTM is part of the planned architecture.
- Existing teams have established GTM governance and deployment processes.
An MTM-led model may be appropriate where Matomo is the principal analytics platform and the organisation wishes to minimise the number of client-side containers. MTM can contain the Matomo tracker and may also embed other tags where suitable templates and controls exist. This approach may reduce duplication in the website implementation.
A dual-container model deploys both MTM and GTM. The systems may have distinct responsibilities. For example, GTM may manage Google and advertising technologies while MTM manages Matomo tracking. Alternatively, MTM may manage the Matomo tracker while GTM manages the wider vendor ecosystem.
The main benefits of a dual-container deployment can include:
- Clear separation between analytics and marketing technology responsibilities.
- Greater access to platform-specific templates and features.
- Reduced need to reproduce certain tags in a less suitable system.
- Continuity during a phased migration between platforms.
The main costs can include:
- Two container snippets or an equivalent loading arrangement.
- Duplicate data layer mappings and event triggers.
- Separate consent configuration and testing.
- Independent versioning and release workflows.
- More complex debugging when both systems react to the same event.
Recommended Actions
- Define the primary purpose of each container before implementation begins.
- Assign each tag to one system unless duplication is explicitly required.
- Document which system owns the initial page view and key business events.
- Record the operational cost of maintaining both systems.
- Do not deploy both containers solely on the basis of platform availability. Deployment should be justified by operational requirements and governance considerations.
3. Data layer compatibility considerations
Both systems can consume structured information from a data layer, but their schemas and processing conventions may differ. GTM commonly uses window.dataLayer and dataLayer.push() for events and associated values. MTM commonly uses its own data layer conventions, including the mtm data layer in relevant configurations. Matomo provides specific guidance on its Tag Manager data layer.
This does not necessarily require two independent application data layers. A shared event model may be feasible, but the implementation should distinguish between:
- The business event and its agreed data.
- The syntax used to expose that event to each container.
- The variable definitions used by each system.
- The timing at which each container reads the values.
- The consent state associated with the event.
For example, an ecommerce event might include:
The application team may publish this event once. GTM and MTM may then consume it through separate variable definitions or adapter logic. The event name, field meanings and value formats should remain consistent even where the container-specific implementation differs.
Common compatibility risks include:
- One container reading a value before the application has populated it.
- Different naming conventions for the same business concept.
- Different handling of arrays, nested objects or null values.
- A purchase event being interpreted as both a page view and a conversion.
- User or customer identifiers being exposed without an appropriate privacy assessment.
A formal tagging implementation service can support the separation of measurement design, data layer specification and container configuration. This separation is useful because a container should not become the informal source of truth for the organisation’s measurement model.
4. Consent signal propagation across containers
Consent is a shared dependency. A CMP may be installed independently of both containers, but its state must be communicated consistently to MTM, GTM and any directly embedded tracking code.
For UK-facing services, analytics and marketing technologies should be assessed against PECR and UK GDPR requirements. The ICO states that organisations must provide clear information about cookies and similar technologies and obtain appropriate consent for technologies that are not strictly necessary. The relevant ICO cookies guidance should be considered alongside the organisation’s legal and privacy advice.
GTM has built-in consent controls and supports Google Consent Mode. This commonly involves default consent states, consent updates and tag-level checks. MTM has its own mechanisms for controlling Matomo tracking and can use custom templates or triggers to respond to CMP signals. Matomo also documents consent-related implementation in its tracking consent guide.
A dual-container implementation should establish:
- The canonical consent categories used by the CMP.
- The mapping from CMP categories to GTM consent types.
- The mapping from CMP categories to MTM triggers or variables.
- The default state before a user has made a choice.
- The behaviour when consent is withdrawn or changed.
- The handling of consent across page loads and single-page application routes.
The consent signal should be available before non-essential tags are eligible to fire. Load order is therefore part of the privacy control, not simply a performance consideration. A tag that fires before the CMP state is known may create a compliance and data quality issue even if both containers are correctly configured after the event.
Recommended Actions
- Define one consent taxonomy for the whole estate.
- Test both containers in denied, partially granted and fully granted states.
- Confirm that withdrawal prevents future tracking and applies the required updates.
- Test consent persistence across page views, domains and application routes.
- Include directly coded scripts in the same consent review.
5. Load order, timing and performance
The order in which the CMP, application data layer and containers load can affect the data collected by both systems.
The initial page view is particularly sensitive. If MTM or GTM loads before page-level metadata is available, the initial event may be missing page type, product information, login state or other required values. If the CMP loads too late, a non-essential tag may become eligible before the consent state has been applied.
The organisation should define a controlled sequence, such as:
- Establish the data layer object and required page-level values.
- Load the CMP and establish the default consent state.
- Load the container or containers.
- Process consent updates and subsequent business events.
- Fire destination tags only when the relevant conditions are met.
The precise sequence will depend on the technology stack. Server-side rendering, content delivery networks, consent mode configuration, single-page applications and asynchronous third-party scripts may alter the practical behaviour.
Two client-side containers may also increase browser work. The impact is not necessarily material, but it should be measured rather than assumed. Container size, custom JavaScript, third-party dependencies, request volume and tag firing frequency are likely to be more significant than the container count alone.
The Matomo JavaScript tracker itself is designed to load asynchronously in the standard implementation. Its official JavaScript tracker documentation explains the tracker queue, configuration calls and tracking requests. This does not remove the need to control when the tracker becomes eligible to run.
6. Version control and release governance across two systems
MTM and GTM each have their own workspaces, versions, environments and publishing processes. These mechanisms may be useful within each platform, but they do not automatically provide a shared release history across both systems.
A change to one container can affect the other. For example, an application event may be renamed for GTM but not updated in MTM. A CMP update may change the consent event consumed by both systems. A new page template may alter the data layer structure used by both containers.
A dual-container release should therefore have a single implementation record containing:
- The business requirement and measurement specification.
- The affected application components.
- The affected data layer fields and events.
- The MTM version and GTM version.
- The consent implications.
- The test evidence.
- The release owner and rollback method.
Container previews should be used independently and together. A test that confirms a GTM tag fires does not confirm that MTM receives the correct event, that the Matomo request contains the required parameters or that the two systems have not created duplicate requests.
Release governance should also define whether MTM and GTM changes are:
- Released together as one coordinated deployment.
- Released independently under a documented dependency model.
- Reviewed by one central team.
- Reviewed by separate teams with a shared approval process.
7. Ownership and documentation
The technical owner of each container should be explicit. Ownership may sit with a central analytics team, a digital product team, a marketing operations function, an external agency or a shared model.
Ambiguity is a material risk. A container may remain operational for years while no current team understands why a tag exists, which consent category applies or which downstream report depends on it.
The documentation set should include:
- Container purpose and scope.
- Account, property and website identifiers.
- Tag inventory and vendor ownership.
- Trigger and variable definitions.
- Data layer schema.
- Consent mappings.
- Dependencies on application code and CMP events.
- Testing requirements and expected network requests.
- Publication permissions and approval rules.
- Incident response and rollback procedures.
Documentation should distinguish between configuration and rationale. A tag inventory may show what exists, but it may not explain why a tag is necessary or what decision depends on its output.
The same principle applies to Matomo settings. Site IDs, tracker URLs, custom dimensions, goals and ecommerce mappings should be documented outside the container interface. Matomo’s tracking documentation provides the platform reference, but organisational definitions still require local documentation.
8. What tag managers do not resolve
A tag management system provides deployment capability. It does not, by itself, create a sound measurement design or enforce data quality.
Neither MTM nor GTM resolves:
- Undefined business questions.
- Missing event definitions.
- Inconsistent naming across websites and applications.
- Incorrect revenue or product data.
- Duplicate implementation in application code and containers.
- Incomplete consent requirements.
- Poor attribution decisions.
- Broken downstream imports or reporting logic.
- Lack of ownership after implementation.
A container can publish an incorrect configuration efficiently. It can also conceal an implementation problem when teams focus on whether a tag fired rather than whether the resulting request was accurate, permitted and usable.
Automated QA, browser testing, network inspection and reconciliation against source systems may be necessary. Organisations with multiple websites or applications may also require monitoring for unexpected changes, missing events and discrepancies between analytics platforms.
Tag managers do not enforce data quality by themselves. Dual containers double the governance surface, even where they share one application data layer.
9. When a dual-container deployment is likely to be appropriate
A dual-container deployment is likely to be appropriate in scenarios such as:
- Matomo is a strategic analytics platform while GTM manages Google advertising and marketing vendor tags.
- Existing GTM infrastructure supports a substantial vendor ecosystem that would be costly or impractical to reproduce in MTM.
- Matomo tracking is required through MTM, while GTM is also needed for established Google or server-side workflows.
- A phased migration requires both platforms to operate temporarily.
- Separate teams have legitimate platform ownership, with a defined shared governance model.
- The organisation requires Matomo-specific templates or controls that are not available in the existing GTM setup.
- Different estates or applications have different deployment constraints but need a common measurement model.
A dual-container deployment may be less urgent where Matomo is the only analytics platform, the number of third-party tags is limited and the organisation can meet its requirements through MTM alone. It may also be less appropriate where there is no capacity to maintain two release and testing workflows.
The decision should be based on operational capability as well as technical functionality. A theoretically flexible architecture can be unsuitable if the organisation cannot maintain accurate documentation, consent propagation and regression testing.
10. A practical approach
A controlled planning process can reduce the risks associated with either architecture.
1. Establish the measurement design
Document the business questions, conversion definitions, event taxonomy, data requirements and reporting destinations. Identify which data is required by Matomo, Google platforms and other vendors.
The specification should define ownership of the event model independently of MTM and GTM. This reduces the risk of allowing platform terminology to determine business meaning.
2. Map the technical architecture
Record the website and application entry points, CMP, data layer, containers, analytics endpoints, server-side components and directly coded tags.
Identify the intended role of each container. Include load order, consent dependencies, cross-domain requirements and single-page application behaviour.
3. Implement with shared controls
Use a shared schema where practical. Create platform-specific adapters only where required. Establish common naming, consent mappings, documentation standards and access controls.
Each tag should have a defined purpose, owner, data requirement and consent category. The implementation should avoid unnecessary duplication between MTM, GTM and application code.
4. Validate before release
Test the implementation in controlled environments. Validation should include:
- Container preview and debug modes.
- CMP state changes and consent withdrawal.
- Initial page view timing.
- Key events and ecommerce transactions.
- Matomo and Google network requests.
- Duplicate or missing requests.
- Single-page application navigation.
- Multiple devices, browsers and regional consent states.
The TagDataTrust analytics data quality service provides a relevant reference point for organisations assessing automated validation and discrepancy monitoring requirements.
5. Monitor after release
Post-release monitoring should check whether tags continue to fire correctly, whether data layer values remain available and whether consent behaviour changes after application or CMP releases.
Monitoring may include automated page journeys, request validation, analytics reconciliation and alerts for material changes. A release is not complete when the container is published. Operational ownership is required for the period that follows.
Conclusion
MTM and GTM can coexist where their roles are clearly defined, and the organisation can support the additional governance required. A single-container architecture may reduce complexity, while a dual-container architecture may provide necessary platform coverage or support a controlled transition.
Platform capability does not remove the need for measurement specification, data layer design, testing, consent control, governance and operational ownership. Neither container resolves these issues automatically, and a dual-container deployment does not remove the need to decide what should be measured or how the resulting data should be trusted.
The appropriate architecture is the one that can be maintained, tested and governed across the full implementation lifecycle. It does not, however, resolve incomplete measurement design, poor data quality, inadequate consent controls or unclear ownership.
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
