How a $100M+ DTC eCom got to a 9am dashboard the whole org trusts

A 2-month case study in why the data problem you think you have is rarely the data problem you actually have.

They asked me to build dashboards.

After a month inside the stack, I told them their dashboards weren’t the problem.

What I found

Their BigQuery views were stacked two and three levels deep. When a change got made to an intermediate table, nobody knew what would break downstream. So the data engineers had stopped modifying existing tables and started building new ones whenever they thought a change was dangerous. Over time, that produced a graveyard of duplicate tables (old ones left behind because someone, somewhere, might still be reading them). Field changes broke downstream readers. Some dashboards took minutes to load because they were running on several stacked views in a row.

There were scheduled queries materializing tables nobody was tracking. Nobody knew what was feeding what, what was being used, how much data was moving, or how much it was costing.

That was the surface layer. The deeper layer was definitional.

Marketing wanted Gross Revenue when they calculated ROAS (the bigger, faster number, the one that reflected better). Direction, finance, and operations preferred Net Revenue: after discounts, with taxes, without shipping costs. Nobody had ever explicitly disagreed; they had quiet preferences. And the same pattern repeated at a smaller scale across the warehouse: somebody preferred a metric with shipping or without discounts, a report got built that way, and the convention quietly propagated. Reports drifted to align with individual preferences, not departmental ones. Nobody could see the lineage well enough to push back.

What we did not do

The recommendation a $100M+ DTC eCom typically gets at this point is: buy more tools. Snowflake. Fivetran. Adobe Analytics. Amplitude. A new attribution platform. None of them would have addressed the actual problem. They would have added another layer of pipelines on top of the same ungoverned soup underneath.

We didn’t buy a new tool. We didn’t write a six-month framework. We added dbt to the existing BigQuery stack.

What dbt actually did

dbt isn’t magic. What it gave us was visibility:

• A clear lineage map (what feeds what, all the way down)
• The ability to see, before changing a table, exactly what would be impacted downstream
• A view of the multiple ways the same dimension was being calculated across the warehouse, which made deduplication possible
• Production and development environments aligned end-to-end
• An understanding of which tables were worth materializing, how often, and what the cost-versus-freshness tradeoff was for each one

But the most valuable thing dbt did wasn’t technical. It surfaced the questions the company had been quietly avoiding: Which definition of Net Revenue do we actually use? What attribution model do we use for reporting? How do we treat returns and refunds in revenue? The lineage made avoiding them no longer possible.

Once we put marketing, finance, and operations in the same room, the conversations were short. Marketing dropped Gross Revenue for ROAS. Net Revenue (after discounts, with taxes, without shipping) became the company default. Discussions about which metric to use where stopped taking up the meeting time.

What was true at month two

• A clear bird’s-eye view of the data infrastructure, models, and lineage
• Deduplicated mappings and calculations across the warehouse
• Production and development environments aligned, no drift
• A first dashboard (marketing channel performance) built on the new shared models, used immediately
• Then the rest: automated 9am dashboards for marketing, finance, CX, and operations, all on the same shared foundation
• 66% reduction in data processing costs, mostly from retiring the duplicated pipelines and the scheduled queries that were materializing tables nobody was using
• All of it delivered in two months, with no downtime, and without spending a single euro on new tools or subscriptions

A note on documentation: metrics were discussed and written down. But in practice, people don’t go to documentation for reference. The dbt models became the source of truth (readable, lineageable, and the only place a definition couldn’t disagree with itself).

The framework, in one sentence

Most marketing data problems aren’t accuracy problems. They’re governance problems disguised as data-quality problems. Buying a new tool doesn’t fix governance. What provides is visible lineage, smaller iterations, and difficult conversations brought to a foundation everyone can see.

I now run this as a method: DAR loops (Diagnose, Act, Reflect) anchored to the Horizon, a success definition stakeholders sign off on before any code gets written.

How to start

If you’re a Director or VP at a $50M+ DTC eCom and you’re about to sign a contract for the next tool that promises clarity (but you suspect what you actually have is a governance problem), start with The First Loop instead. If you’re not sure yet, the Trusted Number Audit is a free 5-minute read on whether your problem is accuracy or trust between teams.

Four weeks. One trusted artifact shipped end-to-end. Your Horizon defined. It becomes the proposal for an ongoing engagement, or a clean exit with real value in hand.

DM me, or book here: calendar.app.google/FHHGWnbUPzi5EZpJA