Everyone thinks a BI project takes a year. Here's how we do it in a week.

Ask the person who owns marketing reporting whether the current setup is good, and you'll rarely hear an enthusiastic "Yes!". But ask what the problem is, and you'll almost never hear "the tool". You'll hear about the process: decisions made years ago that made sense at the time, complexity that accumulated over time, workflows the team inherited and never got the chance to rethink. The setup is the problem, not the tooling.

That instinct is fair, and mostly right. But process and tooling are not separate things. The process grew the way it did because the tools defined what was possible: what marketers could self-serve and what needed a ticket, which questions were easy to answer and which took a sprint, what got a proper metric definition and what got a workaround in a spreadsheet. Teams experience the pain as a process, but a lot of that process is downstream of tooling constraints.

When someone suggests a new reporting platform, the reaction is usually fear rather than excitement. The assumption that any new reporting platform means a year-long painful project comes from how these projects are usually done, not from anything inherent to the problem though. For marketing reporting specifically, we deliver a working platform in a week. This piece is about why that's possible, and what causes the year-long version of it for many.

Why BI projects take a year

It feels like technical work: pipelines, warehouses, dashboards. In reality, the technical work is the smaller part. The bigger and harder part is the tribal knowledge.

Before anyone builds anything, someone has to figure out what the organisation actually uses. Which dashboards are alive and which are abandoned? How do people use them? What do the formulas mean, and why was that one metric defined in that particular way in 2021? You can't just walk in and say, let me start from scratch. You need to interview every stakeholder in every department who touches the old system, and reconstruct the logic that went into every dashboard: definitions that were agreed years ago, formulas set in a certain way for reasons nobody wrote down, exceptions that exist because of a deal with finance.

This is why migrations stall. It's an incredible amount of work, most of it invisible. The data team spends months in discovery before anything is built, and the business stakeholders, who just wanted their numbers, started doing everything in spreadsheets long ago.

All of this is valid, but notice what it's a product of: trying to figure everything out from scratch, in every company, every time.

The one-week version

At Clarisights, we tell customers we can go from them sharing their current reports to a working platform which means all data connected, history backfilled, purpose-built reports live, in a week. This sounds like sales talk, but we do actually do it. 

We ask marketers to share the reports they use for daily steering, weekly overviews etc., which in the vast majority of companies live in spreadsheets, for reasons I've written about earlier in this blog. Those spreadsheets are the entire requirements document, if you know how to read it.

Marketing reporting runs on third-party data. If a marketing team uses 100 metrics, roughly 90 of them come from third-party systems: Meta, Google, TikTok, DV360, the app networks. We're not touching your order system, not connecting to user-level data, not tracking individual sessions. The whole category of work that makes internal BI projects slow, mapping messy internal systems, negotiating access, untangling schemas nobody owns, doesn't exist here.

Third-party APIs don't change by customer. Every company is using the same Google and Meta APIs. We've built these connections for dozens of customers across verticals, and with them the semantic layer and the transformation layer on top. What varies is the last 10 metrics - your business logic. What is a conversion for you? Is it an add-to-cart? Or you're a gaming company and it's predicted LTV? Those come from your attribution provider or your internal attribution system, and that's the part we set up together.

The only thing we need to get started is access tokens. Nothing gets deployed in your Snowflake, nobody has to figure out dbt connections, no infrastructure project runs alongside the reporting project. Enter credentials, and the data starts flowing.

And there is one more thing: we speak the language. Hand one of our CSMs a sophisticated marketing report - a daily steering sheet with blended CAC by channel, spend pacing against a quarterly plan, a cohort view from AppsFlyer - and they know what they're looking at. They can rebuild it without a hundred follow-up questions, because they've built this exact report, in slight variations, dozens of times. A data engineer seeing that spreadsheet for the first time doesn't have that context. Not because they lack skill, but because they don't know the specifics of marketing, which means every formula becomes an interview, every tab becomes a discovery meeting, and the tribal-knowledge problem extends the project indefinitely.

This is the real answer to why BI projects take a year. The year isn't spent building, it's spent learning a domain, one stakeholder interview at a time, and this happens over and over in every company.

Which raises the obvious question: these are the same third-party datasets, the same APIs, the same metrics with the same quirks everywhere. Why does every company need to figure out the same logic over and over? There is no good reason for data analysts and engineers to rediscover, from scratch, what a performance marketing team means by ROAS, spending tons of time and money in the process.

The year-long BI project isn't the price of good marketing reporting, it's the price of starting from zero.