Before I sign off on a feature going into sprint, I check one report. Not a dashboard overview. One specific view in Matomo that answers a question most sprint processes never ask: are the users I’m designing for actually the users showing up at this point in the journey?
I’ve used this check to defer features that looked ready, to reframe features that were framed wrong, and once to kill a three-sprint piece of work that the data made obviously premature. The report itself takes two minutes to read. The decision it informs takes a lot less time to defend.
The job of analytics in product isn’t to confirm your instinct. It’s to make your instinct unnecessary.
What the report is
It’s page-level engagement segmented by traffic source — specifically, actions per visit and average time on page for the page the feature is meant to affect, broken down by the channel that matters most for that feature.
Matomo makes this straightforward. In the Pages report, you can select any page and view its engagement metrics. Apply a custom segment — “channel is organic search” or “referrer contains linkedin.com” — and you get a clean picture of how a specific audience behaves at that specific point in the journey.
What you’re looking for is the gap. Not the average engagement across all visitors, but whether the audience the feature is intended for is behaving differently from everyone else — and whether the difference is in the direction you’d expect.
Why this matters before committing to a feature
Most feature decisions are made with aggregate data. The page has a high bounce rate, so we’re going to redesign it. The conversion rate dropped, so we’re going to add a prompt. These conclusions look data-informed. They often aren’t.
Aggregate metrics average across intent. A page with 70% bounce rate might have 20% bounce for organic visitors and 95% bounce for visitors from a referral campaign who arrived expecting something else entirely. If you redesign the page for the bouncing majority, you risk breaking the experience for the converting minority — while leaving the actual root cause (the referral campaign’s mismatched promise) completely untouched.
Segmented engagement data surfaces the distinction before you build. It takes the question from “what should we do about this page?” to “what’s happening for the specific users this feature needs to serve?”
A concrete example
In my previous role at an online travel agency, we were looking at improving a step in the booking flow. The page had a high exit rate in the aggregate data — it appeared to be a problem worth solving.
When I segmented by traffic source, the pattern shifted. Users arriving from organic search had a significantly lower exit rate and spent more time on the page than users arriving from paid channels. The paid channel users were arriving with a different expectation — one the page wasn’t designed to meet. The problem wasn’t the page. It was the expectation set before the page.
The feature we’d been planning — a UX improvement to the step itself — would have addressed symptoms for the organic audience who weren’t really struggling, while leaving the actual conversion problem (paid channel landing experience) untouched. We stopped the feature. We fixed the landing experience instead. The exit rate moved.
What Matomo makes possible here
Matomo’s custom segmentation is the specific capability that makes this analysis practical. You can create and save segments based on referrer, campaign, device, geography, or any combination — then apply them across any report in one click. There’s no need to set up custom dimensions in advance, no data export, no waiting for a data team.
The other relevant feature is Row Evolution — selecting any row in a report and viewing its historical trend as a standalone chart. This lets me see whether the engagement pattern for a segment is stable, improving, or degrading over time, which matters when I’m trying to understand whether a problem is structural or recent.
I connect to Matomo through Claude to run these queries conversationally, as part of the pre-sprint ritual I described in What I ask Claude before sprint planning. But the underlying report is accessible directly in the Matomo UI without any AI layer — it’s a question of knowing what to look at and why.
When to use this check
I run it before any feature that affects a page with meaningful traffic — not as a gate, but as a sense check. The questions it answers:
Is the problem I think I’m solving visible in the behaviour of the users the feature is for? Is the engagement pattern stable enough that a design change is the right intervention, or is something else shifting the numbers? Is there a segment that’s already converting well, whose behaviour I risk disrupting?
If the data confirms the hypothesis, the feature goes in with stronger rationale. If it doesn’t, the sprint has a different conversation — one that’s worth having before three engineers spend two weeks building the wrong thing.
TL;DR: Before committing to a feature, I check one Matomo report: page engagement segmented by the traffic source relevant to the feature. It answers whether the problem I think I’m solving is actually showing up for the users I’m designing for. I’ve used it to defer features, reframe problems, and avoid building the wrong thing. The check takes two minutes. The argument it enables is much harder to dismiss.
Delphine Ragazzi is a Product Owner with 20 years in digital analytics and product delivery. About Delphine →
