The value of analytics data is contingent upon its accuracy, consistency and governance. A structured model of Matomo goals and events can be an appropriate approach where an organisation needs conversion reporting, behavioural analysis and comparable measurement across websites or applications.

It does not, however, resolve incomplete tracking, unclear business definitions, consent failures, duplicate implementation or weak operational ownership. Goals and events provide platform capabilities. They do not replace a measurement specification, testing process or governance framework.

TagDataTrust is the only certified Matomo Implementation Partner in the UK. This article sets out the main design considerations for organisations establishing or reviewing a Matomo measurement model.

1. Goals and events: the two conversion primitives

Events and goals serve different analytical purposes.

An event records an interaction. It can represent a video play, filter selection, download, form step, navigation action or add-to-cart interaction. Events are generally exploratory. They provide a detailed record of behaviour that can be segmented and analysed.

A goal represents a defined conversion outcome. It creates conversion metrics and dedicated goal reporting, including conversion rate, converted visits and, where configured, revenue. A goal may be triggered by a URL, a page view condition, an event match or an explicit trackGoal call.

The distinction has reporting consequences:

• An event can occur many times during a visit.
• A standard goal is generally treated as a conversion outcome for reporting purposes.
• An event may become a goal when a goal rule matches its category, action or name.
• A goal does not need to expose every detail of the interaction that caused it.
• An event is not automatically a business conversion.

The Matomo event tracking documentation describes events as a way to measure interactions beyond page views. The Matomo Goals documentation sets out the available goal conditions and conversion reporting options.

A measurement model should therefore distinguish between behavioural signals and business outcomes. For example, Product / Add to cart / SKU-123 is an interaction. Checkout completed is a conversion outcome. The same user journey may require both.

2. Choosing between URL-based, event-based and manual goals

Matomo supports several ways to define goals. The appropriate method depends on the stability of the technical signal and the meaning of the conversion.

URL-based goals

A URL-based goal can be suitable when completion produces a stable confirmation page or route. Examples include:

• /application/complete
• /contact/thank-you
• /subscription/confirmation

URL matching is relatively simple to implement. It can also be useful where the conversion page is controlled by a content management system and remains consistent across releases.

Its limitations should be considered. Single-page applications may not produce a conventional page load. Confirmation routes can be changed without analytics teams being informed. A page may also be reachable without a valid conversion, such as through a bookmarked URL or an accidental refresh.

Event-based goals

An event-based goal uses a tracked event as its trigger. Matomo can match a goal against an event category, action or name. For example:

A goal can then be configured to match the relevant event action or name. This approach can be appropriate when the conversion occurs in a modal, an asynchronous form, an application flow or another experience where URL matching is unreliable.

Event-based goals depend on a stable event taxonomy. A change from Form submitted to Submit form can interrupt goal reporting even when the user journey has not changed.

Manual goals using trackGoal

An explicit trackGoal call can be suitable where conversion logic is available in the data layer, tag management system or server-side process but is not reliably represented by a URL or single event.

The Matomo JavaScript Tracking Client documentation defines the relevant methods:

The first argument identifies the Matomo goal. An optional custom revenue value can be passed where appropriate.

Manual triggering may be preferable for:

• Confirmed form submissions returned by an API.
• Account creation after validation.
• Application milestones based on business rules.
• Server-confirmed transactions.
• Conversion states in single-page applications.
• Journeys where an event is useful for behaviour analysis but should not independently define the conversion.

Recommended action:

• Define the business outcome before selecting the technical trigger.
• Prefer a stable confirmation signal over a fragile page pattern.
• Use trackGoal where conversion logic exists outside the URL structure.
• Document the goal ID, trigger condition, revenue treatment and deduplication expectation.
• Confirm that the implementation can fire the goal once for the intended conversion.

3. Designing an event taxonomy

A consistent event taxonomy is necessary when several teams, websites or applications contribute data to the same analytical environment.

Matomo events use four principal fields:

• Category: the broad interaction domain.
• Action: the activity being performed.
• Name: the specific object or contextual detail.
• Value: an optional numeric value.

The official Matomo JavaScript API reference defines the trackEvent(category, action, name, value) method.

A taxonomy should be designed before implementation. A practical structure may use:

• Category: Navigation, Content, Forms, Ecommerce, Account
• Action: Select, Open, Submit, Add to cart, Remove
• Name: a controlled object label, such as Primary navigation, Product detail or a product identifier

For example:

The taxonomy should avoid unnecessary variation. The following labels may represent the same interaction but would create fragmented reporting:

• Submit form
• Form submitted
• Complete form
• Enquiry sent

One approved convention should be selected and documented.

The naming model should also account for websites and applications. A cross-platform design may use the same business terms while allowing platform-specific implementation details. For instance, a mobile application may send an event through an SDK while a website uses JavaScript or Matomo Tag Manager. The analytical meaning should remain comparable.

Custom variables and custom dimensions may hold additional context where putting every attribute into the event name would create excessive variation. The Matomo custom variables documentation provides further guidance on assigning contextual values to visits or page views.

Recommended action:

• Establish a controlled vocabulary for categories and actions.
• Use sentence case or another documented casing convention consistently.
• Define whether product identifiers belong in the event name, a dimension or ecommerce data.
• Record permitted values and prohibited variants.
• Include ownership and change control in the measurement specification.

Events are not a substitute for a measurement specification. Without documented definitions, the reporting interface can contain technically valid but analytically ambiguous data.

4. Funnels and their requirements

Funnels describe ordered steps towards a goal. A typical ecommerce funnel may include:

1. Product viewed.
2. Product added to cart.
3. Cart viewed.
4. Checkout started.
5. Order completed.

The funnel is only useful when the underlying signals are consistently available. Each step needs a stable definition, an agreed scope and a reliable trigger. If the implementation records checkout starts only on one platform or omits mobile interactions, the reported drop-off may describe data loss rather than user behaviour.

Funnel design should consider:

• Whether steps are page views, events, goals or ecommerce actions.
• Whether the sequence is mandatory or whether users can enter at different stages.
• Whether repeat actions should count once or multiple times.
• Whether the funnel applies to all properties or only one journey.
• Whether the reporting tool supports the intended scope and historical processing.

Matomo funnels may require the relevant Funnels functionality, depending on the Matomo edition and configuration. The implementation team should confirm the available feature set before designing reporting requirements around it.

A funnel should not be used to compensate for an incomplete measurement model. If the completion goal is reliable but the intermediate steps are not, the funnel can still show a final conversion rate, but the diagnostic value of each stage may be limited.

5. Ecommerce tracking and goal interaction

Ecommerce tracking is a dedicated measurement layer for products, carts, orders and revenue. It should generally be distinguished from standard goals and general interaction events.

Matomo ecommerce tracking can record:

• Product and category impressions.
• Product detail views.
• Cart updates.
• Products added or removed.
• Orders and order revenue.
• Product-level quantities, prices and categories.

The Matomo ecommerce documentation describes the reporting model and the actions that can be measured. The JavaScript API also provides methods such as setEcommerceView, addEcommerceItem, trackEcommerceCartUpdate and trackEcommerceOrder.

A standard goal may still be appropriate for a commercial outcome such as a completed order, particularly where a business needs a consistent conversion metric across non-ecommerce and ecommerce properties. However, ecommerce reporting should remain the primary source for order, product and revenue analysis where transactions are involved.

Events can support micro-conversions around the ecommerce journey:

An event-based goal could be created for add-to-cart activity. This may be useful for conversion reporting or funnel analysis, but it does not make the event equivalent to a completed order.

Ecommerce orders and standard goals can also interact in ways that require careful review. If the same order fires both an ecommerce order and a manual revenue goal, reports may contain two different conversion records. This may be intentional, but the relationship must be explicit.

6. Attribution settings for conversions

Attribution determines which referrer, campaign or source receives credit for a conversion. Matomo can attribute a goal to the most recent referrer by default, or to the first referrer where the implementation is configured accordingly.

The JavaScript tracker includes setConversionAttributionFirstReferrer. The default setting attributes a conversion to the most recent referrer. The Matomo tracking API reference documents both attribution information and the first-referrer configuration.

This is a modelling decision rather than a technical default that should be accepted without review. Different organisations may have different analytical requirements:

• Last-referrer attribution may support short-term acquisition reporting.
• First-referrer attribution may support initial demand generation analysis.
• Multi-channel attribution may be appropriate where several interactions are expected before conversion.
• Ecommerce orders and standard goals may need comparable attribution settings.

Attribution should be documented alongside the goal definition. A change in attribution settings can alter the interpretation of future reports and may create apparent changes in channel performance that are not caused by campaign activity.

The Matomo Multi-Channel Conversion Attribution guidance should be reviewed where the reporting requirement extends beyond a single referrer model.

Recommended action:

• Select an attribution model based on the business question.
• Apply the model consistently across relevant goals and ecommerce reporting.
• Document the effective date of any attribution change.
• Avoid comparing periods without accounting for changes in attribution logic.
• Validate campaign parameters, referrer exclusions and cross-domain behaviour.

7. Consistency across multiple sites and applications

A multi-property organisation may operate several websites, regional domains, customer portals and mobile applications. A shared measurement design can improve comparability, but it should not be implemented as an unqualified copy-and-paste exercise.

The organisation should distinguish between:

• Shared business definitions, such as Lead submitted or Order completed.
• Platform-specific implementation methods, such as JavaScript, Matomo Tag Manager, mobile SDK or server-side tracking.
• Property-specific behaviour, such as product categories, authentication states or regional consent requirements.

A shared goal and event catalogue can include:

Goal IDs are configured within Matomo properties. The same business concept may therefore have different technical IDs across sites. The measurement specification should store both the business identifier and the property-specific Matomo ID.

Cross-domain tracking and consent controls also require review. The Matomo tracker supports cross-domain linking, while consent behaviour may differ by region, device or property. The ICO guidance on cookies and similar technologies should be considered alongside the technical design.

A consistent measurement model is useful only when the implementation reflects actual consent conditions. Consent signals should control the relevant tags and tracking methods. TagDataTrust’s CMP integration service covers the technical relationship between consent management platforms and tag management systems.

8. Editing goals and maintaining trend continuity

Goal definitions can be edited after implementation. This creates a historical reporting risk.

If a URL condition changes, historical data may continue to be displayed according to the revised goal configuration, depending on the Matomo report and processing model. A change from one event action to another can also create a break in interpretation. The resulting trend may appear to show a performance change when the underlying change was in the goal definition.

Legacy goals should be treated as analytical assets with version history. Before editing, the implementation owner should record:

• The original goal name and description.
• The original trigger condition.
• The date range in which it was active.
• The reason for the change.
• The expected effect on historical and future reporting.
• Whether a new goal should be created instead.

Creating a new goal may preserve clearer continuity when the business definition has changed materially. Editing an existing goal may be reasonable where the technical condition changes but the business outcome remains identical. The decision should be based on reporting continuity rather than administrative convenience.

Goal edits do not deduplicate conversions. If a user can trigger the same conversion through multiple routes, the implementation must define whether the event, goal or transaction is the authoritative record. Deduplication may require transaction IDs, server-side confirmation, data-layer state or implementation controls outside the Matomo goal configuration.

9. When a goal redesign is likely to be appropriate

A goal redesign may be appropriate in the following situations:

• Goal names no longer correspond to current business outcomes.
• A confirmation URL has become unstable or is no longer generated.
• A single goal combines materially different conversion types.
• Events are being collected, but important conversions are not represented in goal reporting.
• Ecommerce orders are being measured as generic page views.
• The same conversion is implemented differently across sites or applications.
• Attribution settings are undocumented or inconsistent.
• Goal edits have made historical trend interpretation uncertain.
• Forms, applications or checkouts have moved to asynchronous or single-page experiences.
• Consent changes have altered the volume or scope of available tracking.

A redesign may be less urgent where goal definitions remain stable, the technical signals are tested, reporting users understand the model, and no material changes have occurred in the underlying customer journeys.

10. A practical approach

1. Establish the measurement design

Define the business outcomes, supporting interactions, reporting users and required dimensions. Separate primary conversions from micro-conversions. Confirm whether revenue, product data, attribution or funnel analysis is required.

2. Map the technical architecture

Document the websites, applications, data layer, tag management systems, Matomo properties, consent controls and server-side processes. Identify where each conversion signal is generated and where it can be validated.

3. Implement with shared controls

Use a controlled event taxonomy. Configure URL goals, event goals or trackGoal calls according to the agreed design. Implement ecommerce methods where transaction and product reporting is required. Record goal IDs and property-specific variations.

4. Validate before release

Test goal and event requests in browser tools, Matomo diagnostics and tag management previews. Check consent states, duplicate firing, single-page navigation, failed submissions, refresh behaviour and transaction values.

TagDataTrust’s analytics data quality service describes the importance of structured documentation, data-layer clarity, auditing and ongoing monitoring.

5. Monitor after release

Review event volumes, goal conversion rates, revenue, funnel progression and attribution. Compare against operational sources where possible, such as order systems, customer relationship management records and form platforms. Establish an owner for incident management and change approval.

Conclusion

Matomo goals and events can provide a structured foundation for conversion and behavioural measurement. Events describe interactions, while goals create conversion reporting. Ecommerce tracking adds a separate layer for products, carts and orders. Attribution settings determine how conversion credit is assigned.

Platform capability does not remove the need for specification, testing, consent control, governance and operational ownership. Goals do not deduplicate by design; goal edits can distort historical reporting interpretation, and events are not a substitute for a measurement specification.

The approach also does not fix incomplete tracking. A reliable measurement model requires accurate signals, controlled implementation and a process for maintaining definitions as websites, applications and privacy requirements change.

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