Why “we need another report” is often not really about the report.
A pattern I keep seeing while working on analytics products is that someone asks for a new report. Usually it’s a perfectly reasonable request: “Can we see purchases by campaign?”, “Can we add this breakdown?” or “Can I export this somewhere?”
The easiest thing to do is immediately start scoping it. Which dimensions do we need? What should the table look like? Which filters should we add? Which attribution model are we talking about? Sometimes that really is exactly what needs to happen. But quite often, if you keep asking questions for a few more minutes, the report turns out not to be the actual problem.
The real problem is that the person doesn’t quite trust the answer they already have.
Let’s say someone asks for a separate report showing campaign revenue. Instead of going straight into what the report should contain, I’ve started asking a much simpler question first: what are you trying to decide with it?
Maybe they say, “I want to understand which campaigns are actually making us money.”
Fair enough. Then the more interesting question is why they can’t do that today.
This is usually where the request starts changing shape. Maybe Google Ads says one thing and the analytics platform says another. Maybe the attribution logic isn’t obvious. Maybe some purchases seem to be missing. Maybe the numbers are technically correct, but there’s no easy way to understand where they came from or why a particular campaign received credit. Sometimes the user simply has a bad feeling about the data and wants another screen to compare it against.
A new report might still be useful. But at least now you know you’re not really solving “we don’t have this table.” You’re solving something closer to “I’m not confident enough in the data I have to make a decision.”
Those are pretty different product problems.
More data doesn’t always help
Analytics products have a slightly strange failure mode: when somebody is unsure about the numbers, it’s very easy to respond by giving them more numbers.
You add another dashboard, another attribution view or another breakdown. On paper, the product becomes more capable. But if those views answer the same question slightly differently and there isn’t a clear reason why, you may have made the original problem worse. Now the user has three answers they don’t fully understand instead of one.
I think this is why explainability matters so much in analytics products. It’s not enough to display a number. At some point, people are going to want to understand where it came from.
Was this event client-side or server-side? What was included in the calculation? What wasn’t? How fresh is the data? Why did this campaign receive attribution? What happens if the same person appears across different sessions or devices? What does “direct” actually mean in this report?
These questions can sound like implementation details, but they become product questions very quickly when somebody is deciding where to move budget, how to report performance or whether they can rely on the product at all.
A dashboard is useful because it reduces uncertainty. If every answer creates two new questions, the product may be doing a perfectly good job of reporting data while doing a much worse job of helping someone make a decision.
Trust is part of the product
For a long time, I think I treated trust as something slightly outside the core product. If users didn’t understand something, maybe the documentation needed to be better. If two numbers were confusing, Customer Success could explain the difference. Maybe we needed a tooltip, a guide or a better onboarding step.
And sometimes that is the right solution.
But the more time I spend around measurement products, the more I think trust itself is part of the product. Reliable collection is part of it. Clear definitions are part of it. Consistent filtering is part of it. Being able to debug an event or understand where a value came from is part of it. Even fairly boring things like showing processing state or data freshness can make a big difference.
Users obviously don’t describe the problem that way. Nobody opens a ticket saying, “I would like more trust infrastructure.”
They say the numbers look wrong. They ask to compare the data with Ads Manager. They want raw events. They want another breakdown, another export, another report.
Those requests are still useful. They may contain perfectly good feature ideas. But I’ve started looking at them as signals as well. Sometimes the feature is missing. Sometimes the product simply hasn’t done enough to make its current answer understandable and believable.
This has probably been one of the bigger changes in how I approach requests since moving deeper into Product. I care less about immediately turning the first thing somebody asks for into scope.
Not because users are wrong. Quite the opposite: they understand their own work much better than I do. But people naturally describe problems through the solution that makes sense to them in that moment. If I’m struggling to understand campaign performance, asking for a campaign report is a completely sensible thing to do.
The useful part for Product is figuring out what happened before that request.
What are you trying to decide? How are you doing that today? Where does the current flow stop being useful? Is information actually missing, or is the issue that you don’t trust what’s already there? And one question I’ve become particularly fond of: what would make you confident enough to act on this?
The answer may still be “a new report.” Great. Build the report.
But it might also be a data quality issue. It might be attribution. It might be that the user needs to inspect the underlying events. It might be a confusing definition. Or the feature may already exist, but we’ve made it too hard to understand what it’s actually telling them.
Same request, completely different product work.
Analytics products are also confidence products
I used to think about analytics mostly as a fairly straightforward chain: collect data, process it and show it back to someone in a useful way.
I still think that’s true, but I’d add one more step now: make the result trustworthy enough that somebody is comfortable using it.
A technically correct number that nobody feels safe acting on isn’t especially useful.
That’s why I’ve become a little suspicious whenever a conversation starts with “Can we just add a report for this?”
Maybe we should.
I just want to understand why the current answer isn’t enough first.
Sometimes people really do need more analytics. Sometimes they need a clearer explanation of the analytics they already have. And sometimes what looks like a feature request is really a request for confidence.
