How to Track Website Visitors in Mautic

To track website visitors in Mautic, install the JavaScript tracking script on every page, confirm that pageview requests are reaching Mautic, and add separate handling for known contacts, Smart URLs, and single-page applications. In practice, the tracking script is only the starting point – the real value comes from connecting visits to contact records so page activity can drive segmentation, scoring, campaigns, and follow-up.

How Mautic website tracking works in practice

Mautic website visitor tracking records pageview activity and associates it with a visitor or contact where possible. Anonymous visitors can still generate activity, but the data becomes much more useful when Mautic can connect that activity to a known contact through a form submission, tracked email click, known identifier, or another recognized interaction.

This is different from using a general analytics platform. Mautic tracking is primarily contact-centric. The goal is not only to count visits, but to understand which contacts viewed which pages and use that behavior in marketing automation.

What typically happens in a real implementation:

• A visitor lands on a tracked page.
• The Mautic tracking script loads in the browser.
• A pageview is sent back to Mautic.
• Mautic records the visit against an anonymous visitor or known contact.
• Later, that behavior can be used in campaigns, segments, scoring, or contact activity history.

A common issue is assuming that installing the script once automatically solves every tracking case. It does not. Traditional websites, single-page applications, consent-managed sites, and campaign redirect links all behave differently.

Install the Mautic tracking script on every page

The standard way to track website visitors in Mautic is to place the Mautic JavaScript tracking snippet across the site. The default implementation loads `mtc.js` and sends a pageview using `mt(‘send’, ‘pageview’)` as part of Mautic’s JavaScript tracking script configuration.

A typical implementation looks like this:

<script>
 (function(w,d,t,u,n,a,m){
 w['MauticTrackingObject']=n;
 w[n]=w[n]||function(){
 (w[n].q=w[n].q||[]).push(arguments)
 },
 a=d.createElement(t),
 m=d.getElementsByTagName(t)[0];
 a.async=1;
 a.src=u;
 m.parentNode.insertBefore(a,m)
 })(window,document,'script','https://mautic.example.com/mtc.js','mt');

 mt('send', 'pageview');
</script>

Replace `https://mautic.example.com` with the public URL of the Mautic instance.

Where to place the tracking script

Place the script in the global site template so it loads on every public page that should be tracked. In most real projects, this means one of these locations:

• The main layout file in a custom website
• A theme header or footer template in a CMS
• A custom HTML tag in a tag manager
• A shared layout component in a server-rendered application

The important part is consistency. If the script is only added to a landing page template but not to product pages, blog pages, documentation pages, or pricing pages, Mautic will only see part of the visitor journey.

In practice, missing templates are one of the most common tracking gaps. A visitor may appear to land on one page and disappear, when the real problem is that later pages never loaded the Mautic script.

Use the correct Mautic URL

The tracking script must point to the public Mautic instance that browsers can access. If Mautic is behind a firewall, on an internal hostname, or configured with the wrong base URL, the script may load for administrators but fail for real visitors.

Pay close attention to protocol and domain consistency:

<a href="https://mautic.example.com/mtc.js" target="_blank" rel="noopener noreferrer">https://mautic.example.com/mtc.js</a>

is not the same as:

<a href="http://mautic.example.com/mtc.js" target="_blank" rel="noopener noreferrer">http://mautic.example.com/mtc.js</a>

On HTTPS websites, loading the tracking script over HTTP can cause browser blocking or mixed-content issues. In practice, the tracking URL should use HTTPS in production.

Verify that Mautic is receiving website visits

After installing the script, verify tracking before building campaigns around it. Do not assume that the presence of the snippet means Mautic is receiving usable visitor data.

Check the browser network request

Open the website in a private browser window and use developer tools to inspect network activity. Filter requests by the Mautic domain.

You should see the browser request the Mautic tracking script and send a tracking request after the page loads. If nothing appears, the script may not be present, may be blocked, or may be loading from the wrong URL.

Useful checks:

• Is `mtc.js` loading successfully?
• Is the request returning a successful response?
• Is the browser blocking the request?
• Is a consent tool preventing the script from firing?
• Is the tag manager trigger actually publishing on that page?

A common issue is testing while logged into a CMS or behind a cache bypass. Always test as a normal visitor, preferably in a clean browser session.

Check the contact activity timeline

If the visitor is already known to Mautic, check the contact activity timeline after visiting a tracked page. Page visits should appear as activity once Mautic associates the browser session with that contact.

If no known contact exists, the visit may still be tracked anonymously, but it will not be useful for contact-level personalization until Mautic can identify the visitor.

In practice, this distinction matters. Anonymous traffic can show that tracking works, but known contact tracking is what makes behavior-based automation useful.

Track known website visitors in Mautic

Basic pageview tracking records visits, but known visitor tracking is where Mautic becomes valuable. A known visitor is someone Mautic can associate with a contact record.

Common ways a visitor becomes known include:

• Submitting a Mautic form
• Clicking a tracked Mautic email link
• Visiting with an existing recognized browser session
• Being identified through data passed into the tracking call

Pass contact data carefully

Mautic tracking can be extended by passing contact fields with the pageview call. A simplified example looks like this:

<script>
 mt('send', 'pageview', {
 email: 'alex@example.com',
 firstname: 'Alex'
 });
</script>

This pattern is useful on authenticated areas, portals, ecommerce accounts, or gated content where the application already knows the visitor’s identity.

Use this carefully. Do not expose sensitive personal data in frontend JavaScript unless there is a clear reason and the implementation complies with privacy requirements. In most cases, passing an email address or a stable known identifier is enough.

Avoid identifying the wrong person

A common issue on shared devices is identity contamination. If one person logs in, then another person uses the same browser, tracking can continue under the previously recognized session until the identity changes or cookies are cleared.

For authenticated applications, the safer pattern is:

• Send identifying data only after login.
• Avoid sending stale user data after logout.
• Clear application-level user state before firing new tracking calls.
• Do not hard-code test contact details in templates.

In practice, incorrect identification is harder to fix than missing tracking. Missing visits are inconvenient; visits attached to the wrong person can corrupt scoring, segmentation, and campaign logic.

Track website visitors in single-page applications

Single-page applications need extra handling because the browser does not perform a full page reload on every route change. The initial page load may be tracked, but later client-side navigation can be missed unless the application explicitly sends another pageview. This is the exact type of behavior behind a common single-page application tracking issue, where route changes are not captured like normal page loads.

Why SPA tracking behaves differently

Traditional websites load a new document for each page. The Mautic tracking snippet runs again when the new page loads.

Single-page applications work differently. React, Vue, Angular, and similar frameworks often update the route and page content without loading a new document. Since the tracking snippet may only run once, Mautic may only receive the first pageview.

What typically happens:

• Visitor opens `/pricing`.
• Mautic records the initial pageview.
• Visitor navigates to `/demo` inside the SPA.
• The browser URL changes, but the document does not reload.
• Mautic receives nothing unless the app sends a new pageview.

Send a pageview after route changes

The practical fix is to call Mautic tracking after the route changes.

A generic example:

function trackMauticPageView() {
 if (typeof window.mt === 'function') {
 window.mt('send', 'pageview');
 }
}

In a router-based application, call that function after navigation completes.

Example pattern:

router.afterEach(function () {
 setTimeout(function () {
 if (typeof window.mt === 'function') {
 window.mt('send', 'pageview');
 }
 }, 0);
});

The small delay helps ensure the browser URL and page title have already updated before the pageview is sent.

Avoid duplicate SPA pageviews

A common SPA mistake is sending two pageviews for the first screen:

• The original Mautic snippet sends `mt(‘send’, ‘pageview’)`.
• The router hook also sends a pageview on initial load.

That can create duplicate first-page activity.

A cleaner pattern is to decide which part of the application owns pageview tracking:

let firstRouteTracked = false;

router.afterEach(function () {
 if (!firstRouteTracked) {
 firstRouteTracked = true;
 return;
 }

 if (typeof window.mt === 'function') {
 window.mt('send', 'pageview');
 }
});

Another option is to remove the automatic pageview call from the initial snippet and let the router handle every pageview consistently.

<script>
 (function(w,d,t,u,n,a,m){
 w['MauticTrackingObject']=n;
 w[n]=w[n]||function(){
 (w[n].q=w[n].q||[]).push(arguments)
 },
 a=d.createElement(t),
 m=d.getElementsByTagName(t)[0];
 a.async=1;
 a.src=u;
 m.parentNode.insertBefore(a,m)
 })(window,document,'script','https://mautic.example.com/mtc.js','mt');
</script>

Then send pageviews from the application router.

This approach gives better control in SPAs, but it requires discipline. Every route that represents a meaningful page should trigger tracking once.

Use Smart URLs when the first interaction happens outside the website

Mautic website tracking is pageview-based once the visitor reaches a tracked page. Smart URLs are useful when the measurable action starts before the website visit, such as a link in a social post, SMS, partner campaign, or another channel where the user clicks a link before landing on the site. Mautic supports visitor tracking through Smart URLs for scenarios where the tracked interaction is the URL click itself.

In practice, Smart URLs are best treated as campaign-entry tracking, not as a replacement for the website tracking script.

When Smart URLs make sense

Smart URLs are useful when the click matters as an event:

• A link in an SMS campaign
• A QR code on printed material
• A social media campaign link
• A partner or affiliate landing link
• A redirect link used in an offline-to-online campaign

For example, a campaign might send users through a Mautic Smart URL before redirecting them to:

<a href="https://example.com/demo" target="_blank" rel="noopener noreferrer">https://example.com/demo</a>

That gives Mautic a trackable click event before the visitor reaches the destination.

Smart URL limitations

A Smart URL can track the click into the destination, but it does not automatically track every later pageview unless the destination site also has the Mautic tracking script installed.

A realistic setup often uses both:

• Smart URL to track the campaign click
• Mautic tracking script to track on-site browsing after arrival
• Forms or known identifiers to connect the visit to a contact

This matters because a campaign click and a website session are not the same thing. A visitor can click a tracked link and then browse multiple pages. Without the website tracking script, Mautic may miss that downstream behavior.

Track Mautic landing pages and external websites differently

Mautic-controlled pages and external websites are often implemented differently.

Mautic landing pages

Mautic landing pages are managed inside Mautic, so they are usually closer to Mautic’s native tracking model. They are useful for campaign-specific experiences where forms, assets, and contact activity are all managed in one place.

In practice, Mautic landing pages reduce implementation friction because the marketing automation platform controls the page environment.

External websites

External websites require the tracking script to be installed manually or through a tag manager. This gives more flexibility, but also introduces more failure points.

Common external website issues include:

• The tracking script is missing from some templates.
• A consent banner prevents the script from loading.
• A tag manager rule only fires on selected pages.
• A JavaScript error stops later scripts from running.
• The Mautic URL is blocked by browser privacy tools.
• The site is a single-page application and route changes are not tracked.

External sites usually need more testing because Mautic does not control the frontend environment.

Use a tag manager when governance matters

A tag manager can be a practical way to deploy Mautic tracking across a larger website, especially when developers do not release template changes frequently.

The advantage is speed. Marketing or operations teams can publish the Mautic tracking tag without waiting for a full deployment cycle.

The trade-off is reliability. Tag managers add another layer where tracking can fail:

• The container may not be published.
• The trigger may exclude important pages.
• Consent rules may suppress the tag.
• Multiple versions of the same tag may fire.
• Preview mode may behave differently from production.

In practice, tag-manager deployments should still be validated in the browser network panel and in Mautic contact activity. Publishing the tag is not the same as confirming tracking works.

Handle consent and privacy requirements

Mautic tracking may involve cookies, identifiers, and behavioral data. The correct consent model depends on jurisdiction, business policy, and how tracking is configured.

A common implementation pattern is:

• Load essential site functionality immediately.
• Wait for analytics or marketing consent before loading Mautic tracking.
• Fire the Mautic pageview only after consent is granted.
• Avoid passing unnecessary personal data into frontend tracking calls.

If consent is required and the visitor declines, Mautic should not track that session for marketing purposes. This can reduce visible visitor activity in Mautic, but that is expected behavior, not a tracking defect.

Debug common Mautic visitor tracking problems

No pageviews appear in Mautic

Start with the browser, not Mautic.

Check whether the tracking script loads. If the browser never requests the Mautic tracking file, the issue is usually on the website side:

• Script not installed
• Script installed in the wrong template
• Tag manager not firing
• Consent blocking execution
• JavaScript error before the tracking call
• Wrong Mautic URL

If the request is sent but Mautic does not show activity, check the Mautic instance URL, SSL configuration, caching, and whether the visitor is known or anonymous.

Only the first page is tracked

This usually happens in single-page applications or websites that change content dynamically without reloading the document.

The fix is to send pageviews manually after meaningful route changes. Avoid firing on every tiny UI state change. Track page-level navigation, not every tab switch or modal open unless those interactions have campaign value.

Pageviews appear under the wrong contact

This is usually an identity issue, not a tracking-script issue.

Common causes include:

• Shared browsers
• Testing with multiple contacts in the same browser
• Hard-coded email values in tracking snippets
• Login/logout flows that do not reset user state
• Passing contact data before the application knows the current user

For testing, use separate private windows or separate browser profiles for each contact.

Visits are delayed or campaigns do not trigger immediately

Pageview tracking and campaign execution are not always experienced as the same thing. A visit may be recorded, while downstream campaign actions depend on how the Mautic environment processes scheduled tasks and campaign logic.

In practice, troubleshoot in layers:

• Confirm the browser sent the tracking request.
• Confirm Mautic recorded the visit.
• Confirm the contact qualifies for the campaign or segment.
• Confirm the campaign action is allowed to run.
• Confirm any scheduled processing is working.

This avoids blaming the tracking script for a campaign configuration or processing issue.

Build a practical Mautic visitor tracking setup

A reliable Mautic visitor tracking implementation usually combines several patterns.

Standard marketing website

For a traditional marketing site, install the tracking script globally and test key pages:

• Home page
• Pricing page
• Product pages
• Landing pages
• Contact page
• Thank-you pages

Use Mautic forms where possible so anonymous visitors can become known contacts naturally.

Gated content website

For gated content, track both the pre-conversion and post-conversion journey:

• Anonymous visits to the content landing page
• Form submission or login event
• Known contact visits to gated content
• Follow-up visits after email nurturing

The important part is making sure the same visitor can be associated with the contact after conversion.

Logged-in customer portal

For a portal or application, send identifying data only after authentication. Do not rely only on anonymous cookies if the application already knows the user.

A practical pattern:

if (window.currentUser && window.currentUser.email && typeof window.mt === 'function') {
 window.mt('send', 'pageview', {
 email: window.currentUser.email
 });
}

Keep the payload minimal. Passing too much user data into browser-side tracking creates unnecessary exposure.

Single-page application

For an SPA, use router-level tracking:

router.afterEach(function () {
 if (typeof window.mt === 'function') {
 window.mt('send', 'pageview');
 }
});

Then test navigation without refreshing the browser. If Mautic only records the first URL, the router hook is not firing correctly or the tracking function is not available when the route changes.

Campaign links and offline channels

For SMS, social posts, QR codes, and partner campaigns, use Smart URLs where the click itself needs to be measured. Then make sure the destination page also has the Mautic tracking script so downstream browsing is not lost.

This gives Mautic both the entry event and the on-site behavior after the click.

Please leave this field empty

Oh hi there
I have a SSJS skill for you.

Sign up now to get an SSJS skill that can be used with your AI companion

We don’t spam! Read our privacy policy for more info.

Check your inbox or spam folder to confirm your subscription.

Share With Others