I work in marketing, specifically as a full-stack marketer, but data has always been one of the areas I naturally gravitate toward.
I had already built several internal dashboards using Google Sheets and Apps Script. Google Sheets acted as both the reporting layer and, in many cases, the database itself. Sometimes the raw data lived in a separate spreadsheet; sometimes it was simply another tab. It worked.
But as more data was added, the limitations became obvious. Performance slowed down. Every new data source meant another sheet, another integration, and another thing to maintain.
More importantly, I eventually realized that making data accessible was not the same as making it useful.
Reporting Wasn’t Really the Problem
Even with those early dashboards, I wasn’t simply copying numbers into a presentation every week.
The dashboard already showed our important KPIs and historical performance. Instead of presenting screenshots, I could open the actual dashboard during meetings and walk everyone through the numbers.
But then the questions would start. Why did this metric go down? What happened last week? Was it because traffic declined? Which channel caused it? Was there a problem with conversion?
The information was technically there, but answering those questions often meant going through weekly tables and trying to piece together what had happened. And if it was confusing for me to navigate while presenting, it wasn’t going to be any easier for everyone else in the meeting.
That was when my understanding of reporting started to change.
Knowing What Happened Is Only the Beginning
One distinction that became clearer to me through experience — and later through my master’s program — was the difference between reporting and analytics.
Reporting can tell you what happened: revenue increased, conversion rate declined, traffic grew, or average order value went up. That is useful, but it is only the first question.
The next question is usually: Why?
That is where diagnostic analysis starts becoming much more valuable.
If I open the dashboard and see that revenue is down, I rarely stop at revenue. I start asking whether orders or average order value declined. If orders are down, I look at traffic next. If traffic didn’t decline — or perhaps even increased — the question becomes different: what kind of visitors are we attracting?
Are they mostly new customers or returning customers? If we are seeing a significant increase in new visitors, could that be related to a change in our paid acquisition strategy? Are we bringing in more top-of-funnel traffic?
One question leads to another, and that is really how I started thinking about dashboards differently.
The dashboard is not supposed to provide one definitive answer every time. It should help you ask better questions.
Adding More Data Should Add Context, Not Just More Charts
The dashboard itself evolved because of those questions.
Initially, I only had a couple of main reporting areas: overall business health and traffic health. But those views could only take us so far, so I started integrating additional data to understand what was happening underneath the headline metrics.
Channel performance came next, followed by landing-page performance, funnel behavior, and more detailed customer and traffic views.
Each new section wasn’t added because I wanted a bigger dashboard. It was added because there was a question we couldn’t properly answer with what we already had.
That distinction became important.
There is always a temptation when building dashboards to keep adding metrics simply because the data is available. But more metrics do not automatically create more insight.
What matters is whether the additional data gives you more context and helps explain what is happening elsewhere in the business.
The Time Conversion Rate Sent Us in the Wrong Direction
One of the best examples happened not long after we started developing the reporting system.
We had recently gone through a brand relaunch. Around the same time, the company had also changed paid media providers. Then our conversion rate started trending downward.
Naturally, people started wondering whether something was wrong with the website. Did the relaunch introduce friction? Was something broken in checkout? Was there a problem somewhere in the funnel?
Those were completely reasonable questions.
In fact, the investigation eventually led me to build a clearer representation of the conversion funnel so we could see what was happening at each stage. But the funnel didn’t explain the decline.
That made me question something else: What if the conversion rate itself wasn’t telling us the full story?
After digging further into the data, I found that the session numbers being used in the calculation included a significant amount of bot traffic. Those sessions were increasing the denominator without representing actual potential customers.
So instead of immediately trying to fix the funnel, I first had to fix the way we were measuring it.
I created a new data source in BigQuery that filtered the session data to focus on traffic classified as human. From there, I created a derived metric that I internally called Real Conversion Rate — conversion calculated using human sessions rather than the unfiltered session count.
Suddenly, we had a different perspective on what was happening.
It allowed us to go back to the funnel and evaluate its individual stages more objectively instead of assuming that the declining headline conversion rate meant something near checkout was broken.
It also opened another conversation: what about the quality of the traffic we were bringing in?
If traffic is increasing but we are attracting people who are not ready or likely to purchase, then the question is not necessarily about checkout anymore. It might be about acquisition.
That experience reinforced something I have carried into the way I analyze data now:
Sometimes the answer isn’t hidden deeper in the funnel. Sometimes you have to question the metric itself.
A Dashboard Should Create Discussion, Not End It
As the reporting system grew, another problem appeared: weekly meetings have limited time.
Everyone has other responsibilities, and walking through every page of a dashboard is not necessarily the best use of the meeting. So instead of treating the dashboard itself as the presentation, I started focusing the discussion around the metrics and findings that actually deserved attention.
That eventually led to the development of weekly findings.
The dashboard remained the source that people could explore, but the weekly discussion became more focused around a few questions: what changed, what looks unusual, what deserves investigation, what should we continue monitoring, and what might require action from another person or team?
That shift helped move the dashboard from something we simply looked at into something that became part of the team’s regular workflow.
To me, that is an important part of building any system. Creating it is not enough. If it never becomes part of how the business operates, then its value will always be limited.
Scaling the Review Process
As the reporting system grew, so did the amount of information I had to review each week. With more data sources, metrics, and historical context to check, doing everything manually became increasingly time-consuming.
That is where I started using AI as part of the review process.
I built an AI agent with access to the historical data sources behind the reporting system. I also created queries, prompts, and instructions that guide what it should check and how it should present the weekly findings.
But I don’t see it as an automated analyst making decisions for me. I see it as augmentation.
The agent helps me scan more information, identify abnormalities, and surface relationships that may deserve attention. I still validate the findings against the underlying data, especially because I want to be confident that it isn’t hallucinating or presenting figures that don’t exist.
I also decide which findings are important enough to bring into the weekly meeting. And, at least for now, I haven’t given it responsibility for automatically generating recommendations.
Finding a pattern is one thing. Understanding the business context around it and deciding what to do next is another. haven’t given it responsibility for automatically generating recommendations.
Finding a pattern is one thing. Understanding the business context around it and deciding what to do next is another.
AI helps me look. It doesn’t replace the judgment that comes afterward.
A Dashboard Is Never Really Finished
I don’t think there is one perfect dashboard that every company should eventually build.
The needs of the business determine what the reporting system should become. A company that is just starting out might need a much simpler view than a more established organization with multiple acquisition channels, customer segments, and operational questions.
The foundations may be similar — revenue, orders, conversion, average order value, traffic — but the questions surrounding those metrics will change as the business changes.
And when the questions change, the dashboard should probably change with them.
That might mean adding something when a new business question consistently comes up, removing something when it no longer contributes to decisions, changing definitions when you discover that a metric isn’t representing reality properly, or integrating a new data source because the existing one is no longer enough.
The system should evolve with the business, not remain fixed simply because it has already been built.
The Dashboard Isn’t the End Product
I used to think of the dashboard itself as the thing I was building. I don’t anymore.
The dashboard is closer to the starting point.
Its real value comes from what happens after someone sees the number. Do they ask why? Can they investigate it? Can they connect it to something happening somewhere else in the business? Does it challenge an assumption or create a hypothesis? And eventually, does it help someone make a better decision?
I sometimes joke that I know the dashboard is providing value when people start asking a lot of questions and the meeting gets a little heated.
But there is some truth behind the joke.
The goal is not for everyone to quietly look at the same numbers, agree that they went up or down, and move on.
If the data gets people asking better questions, challenging assumptions, forming different hypotheses, and having more informed discussions about what the business should do next, then the dashboard is doing much more than reporting.
And that is where I think its real value begins.