We Rebuilt a Client’s GA4 Dashboard in Two Hours. Here’s How We Did It.

Our Head of Ecom Strategy rebuilt a client's GA4 dashboard from scratch in roughly two hours, working inside Claude. The equivalent build in Google's own Looker Studio would have taken the best part of a day, and by his own assessment the result would have looked "half as good," with some of what the Claude version now does not achievable there at all.

That gap between two hours and a day, for a better result, is the concrete number behind a bigger question our leadership team spent the following days working through: is this a personal productivity win, or the outline of something we should be building properly for clients.

The problem: not too little data, too much of it

The brand in question has spent years building a striking, internationally recognised presence. That international attention is mostly good news. It also makes the brand's own GA4 data harder to read, not easier. Our Head of Ecom Strategy recently chased down what looked like a real anomaly in one of the brand's products, before tracing it back to a spike in US traffic, a market the brand doesn't actively serve. The number was real. It meant nothing.

Telling the two apart is the actual job, and it's one most growing brands aren't resourced to do well. Most e-commerce managers don't have data structured this cleanly available to them, and when a CRO session runs off the back of it, both junior and experienced client contacts notice the difference immediately. The constraint was never a shortage of numbers. Plenty of brands, including some with clear internal growth targets, aren't tracking those targets properly in the first place, which is a knowledge gap as much as a tooling one. A dashboard detailed enough to explain why something happened is usually too dense to glance at, and one simple enough to glance at rarely explains why. Most brands end up with one or the other, never both.

This is where a lot of growing consumer brands sit. They have more analytics tooling than they did two years ago, and less clarity from it than they'd like. Adding another chart doesn't fix that. Someone still has to look at the chart and decide whether it means anything, and that's a different skill from building the chart in the first place. It's also a skill most in-house marketing teams aren't hired specifically to have, because the job spec usually asks for someone who can run campaigns, not someone who can sit inside GA4 for an afternoon chasing down why one number moved.

What we built

Instead of extending another Looker Studio build, our Head of Ecom Strategy connected Claude directly to the client's GA4 property through a Google Cloud project, using his own existing credentials, and built the dashboard as a live Claude artifact. It updates on a schedule that currently depends on his own machine to trigger it, something our infrastructure specialists could tighten up considerably. The basics sit on the dashboard exactly as they would anywhere else: the numbers he would otherwise go looking for by hand. What mattered more to him was the layer above that, being served findings rather than digging for them himself.

Because the setup runs on his own account access, duplicating it for any other GA4 property he can reach is, by his estimate, a job measured in minutes rather than days. That replicability, more than the dashboard itself, is what turned an afternoon's personal build into a wider conversation inside the business. The method isn't specific to GA4 either. Our performance dashboard lead pointed out that pulling in other Google performance data, Chrome UX Report or Lighthouse, needs exactly the same setup: a Google Cloud project and a set of keys. He's now adding that same approach to a separate, broader performance dashboard he maintains for a wider set of clients, rather than treating this build as a one-off specific to a single GA4 property.

Where judgment still sits with a person

Claude's first pass at findings was generic, effectively restating what the underlying numbers already showed, which is exactly the failure mode a dashboard is supposed to fix. Our Head of Ecom Strategy wrote his own rules to change that, on one condition: "I'd prefer it didn't show anything over something not valuable." That line is the actual shift in this build: a person deciding what counts as worth surfacing, and holding the tool to that bar, rather than the automation doing it alone.

The dashboard doesn't yet cross-reference the GA4 data against anything else, and he hasn't gone back to open GA4 itself to double check the numbers, relying instead on his own long-running Looker Studio dashboard showing the same figures as a sense check. That caution runs through the whole build. It's a personal workflow right now: the tool our Head of Ecom Strategy uses in his own daily work with this client, not a finished service, and the team is treating it that way rather than selling it before anyone has defined what problem it actually solves for a client.

What it produced

Set against a Looker Studio rebuild, the comparison is straightforward. Both are free to run: Looker Studio directly, Claude through a Google Cloud project. The time cost isn't equal. A day of effort produced a result rated as worse, against two hours for something that extends to a new page or data source with a single prompt. Our Head of Ecom Strategy is already planning to add Google Search Console for page health and Shopify for more current, cross-referenced data, and neither addition meaningfully changes the two-hour economics of the original build.

Our CEO called the time difference a quantifiable cost we can point to, and a real basis for a differentiation argument. His pushback to the wider team was fair too: clients already have, in his words, "a zillion dashboards," and a faster build process is an advantage to us internally well before it's automatically a reason for a client to choose one more dashboard over the several they already have open in other tabs.

What this could become

Our client strategy lead's read is that this sits closer to a genuine differentiator than a nice internal efficiency. Most e-commerce managers a client could hire directly won't arrive with this kind of structured insight already built, and a lot of the value in these CRO sessions currently depends on one person's own capacity to run them one client at a time. Turning that into something less dependent on one person's calendar looks like a strong candidate for a client portal, though the functional detail, and how and when to offer it, is still being worked out properly rather than shipped as a quick win this month.

A few commercial shapes have been raised. Base findings could sit inside the existing fractional relationship. A paid CRO session could be built around what the dashboard surfaces. An ongoing subscription to the findings themselves is a third option. Whichever shape it takes, an AI-driven diagnostic layer like this is a genuine candidate for our own AI-led differentiation, distinct from the fractional resourcing we already sell.

The wider takeaway

What actually answers the question our leadership team was debating is what our Head of Ecom Strategy does with the dashboard now it exists, more than how quickly it was built. A classic report tells a brand what happened. What he wanted, and largely has, is something he can interrogate: ask Claude why a number moved, and get a genuine first pass at an answer instead of a chart that leaves the why to him.

It's the same execution gap that shows up everywhere else AI meets a real team. The technology is more than capable, and the value gets left on the table because nobody has done the unglamorous work of deciding what's actually worth showing. Growing brands aren't usually short on data or short on ambition. They're short on the specific, structured attention needed to turn a graph into a decision, and most don't have anyone on staff who knows how to build that structure themselves. Hiring for it properly means another salary. Buying another dashboard tool means another login nobody has time to check. Neither actually closes the gap, and both are slower and more expensive than the two hours this took.

Our performance dashboard lead put the process we're now following well: build a proof of concept fast and cheap inside Claude for one client, refine it against real use, formalise it into a proper specification once it's clear what's genuinely valuable, and only then build it into the shared performance dashboard our wider team maintains, on existing infrastructure rather than as a one-off. Two hours with one client's GA4 data turned out to be the cheapest possible stage for deciding whether a finished product should exist, a stage we can now run in an afternoon instead of a quarter.