Matomo and Sentry: how to connect them, what they do, and why use them together

Google Analytics tells you how many people showed up on your site and what they clicked. It won't tell you why a third of them vanish mid-signup — and it definitely won't tell you whether that's a design problem or just a bug that silently failed to submit a form. That's why, alongside GA, I bring two more tools into audits: Matomo and Sentry.

Each covers something different on its own. Together, they answer the question clients ask most often: is this a design problem, or a code problem? Without data, that's just a guess.

Matomo — what it does and how to connect it

Matomo is an analytics tool similar to Google Analytics — it measures visits, behavior, and user journeys. The difference comes down to two things: where the data lives, and how closely you can look at individual sessions.

• Visits and Unique Visitors — how many visits happened, and how many were actually distinct people.
• Bounce rate and Exit rate — where people leave right after arriving, versus where they leave after any number of steps.
• Actions per visit and Average visit duration — how much people actually engage with the site, not just click through.
• Page performance — how long individual pages take to load (under 1 s is great, over 3 s is a problem).
• Session replay / transitions — what happened before a page, during it, and after leaving it.

Connecting it works the same way as Google Analytics: Matomo generates a short tracking snippet that goes into the site's head, right before the closing </head> tag. You can run it as Matomo Cloud (fully managed, nothing to maintain) or self-hosted on your own server — and that's the key difference from GA: the data never leaves your own infrastructure or the EU. For public-sector, healthcare, or financial clients, that's often what decides whether analytics can be used at all.

One thing Matomo doesn't solve any better than GA: cookie banners and ad blockers. If a visitor declines tracking or their browser blocks it, they simply won't show up in the data. That's a limit worth keeping in mind every time you read the numbers — not a reason to distrust them entirely, but a reason not to take them as gospel either.

Sentry — what it does and how to connect it

Sentry watches a completely different layer: not what the user wanted to do, but what technically happened while they tried. It captures errors, exceptions, and performance in real production traffic — exactly what Matomo or GA will never show you.

• Errors / Issues — specific errors and exceptions, grouped by type, with the number of affected users.
• Error rate and crash-free rate — how stable the app is over time, broken down by release, browser, or device.
• Performance (p95 / p99 latency) — how fast the app is for 95% or 99% of users (the average is misleading; the extremes hurt the most).
• Core Web Vitals — LCP (how fast the main content renders), FCP (when the first visible content appears), INP (click responsiveness), and CLS (how much the page "jumps" while loading).
• Session Replay — a recording of what the user was actually doing on screen right before an error happened.

Connecting it is done through an SDK right in the application's code — Next.js has a package with a guided setup, and other frameworks follow a similar path. Once installed, the app reports errors hitting real users on its own, including the browser, page, and action that triggered them. No more waiting for someone to contact support.

Rough benchmarks Core Web Vitals are usually judged against:

• LCP (main content render): under 2.5 s good, 2.5–4 s needs improvement, over 4 s poor.
• INP (interaction responsiveness): under 200 ms good, 200–500 ms needs improvement, over 500 ms users feel the lag.
• CLS (layout stability): under 0.1 good, 0.1–0.25 needs improvement, over 0.25 frustrating — usually caused by images without set dimensions, late-loading fonts, or dynamic content that shifts the rest of the page.

Why have both — and not just one

Matomo and Sentry complement each other exactly where each one is blind on its own. Matomo sees what a user did on the site — but has no idea the app crashed on them at that moment. Sentry sees that the app crashed — but has no idea what the user was doing five minutes before.

Without connecting the two systems, you get either the cause or the context. Never both at once.

The fix is simple to describe and light to implement: Matomo generates a unique visit ID for every session. That same ID is passed to Sentry as a context tag (typically session_id). When Sentry captures an error, it carries a link to that exact session in Matomo — so you can replay precisely what the user did before the app crashed.

In practice, one more layer gets added — tags that describe the context an event happened in, not just that it happened:

• user_id / role — who it happened to and what role they have (admin, customer, a specific agenda).
• screen / action — where in the app it happened and what the user was doing (e.g. submitting a form, approving something).
• module / feature — which part of the system is affected.
• session_id — the link between Sentry and the session replay in Matomo.

Together, that answers the question a client asks first: who did this happen to, where, while doing what, and why did it crash.

A real scenario

An error shows up in Sentry. On its own, it's just one line in a list — you don't know if it's minor or blocking hundreds of people from doing their job. With connected data, the breakdown looks like this:

• Who: a user with an "approver" role in a specific module of the system.
• Where: step 3 of 5 in an approval form (screen: approval_flow).
• What they did: clicked "Submit for approval" (action: submit_approval).
• What happened: the app froze for 5 seconds (p99 latency over 3 s), then went to a blank white screen.
• Evidence: the session replay shows they clicked three times before it crashed — frustration, not a fluke.

Without connected data, this error stays one of many in the backlog. With connected data, it's clear it's blocking a specific step for a specific type of user — and it deserves priority. And because you know who it happened to, you can reach out before they reach out to support.

What this means for a UX audit

Analytics and error tracking aren't a substitute for intuition, but neither layer is enough on its own. Heatmaps and session replay (from Matomo, or Hotjar for that matter) show where users hesitate. Sentry shows whether that hesitation is actually a design problem — or just a bug that no redesign will ever fix.

When I run a UX audit, I read both layers side by side for exactly this reason: behavioral data shows the problem, error data shows whether it's a design issue or a technical one. A recommendation built from both isn't a guess — it's based on what's actually happening on the site.