The issue with BI dashboards in marketing reporting

A question I get a lot, from technical buyers in particular, goes roughly like this: "We already have Tableau / Looker / PowerBI. Why would we need anything else for marketing reporting?"

It is a fair question and the answer is nuanced. The problem is not with the BI tool per se. 

The BI dashboarding tool is just a presentation layer. It consumes the data from the warehouse, e.g. Snowflake, Google BigQuery or Amazon Redshift. The warehouse in its turn needs to be populated with the relevant data coming from third party platforms - the channels (Google, Meta etc), MMP data etc etc. This step requires an ETL tool. 

So we are dealing with at least three software solutions (in reality, more - I am simplifying to the absolute key components), none of which were built specifically for marketing data or with marketing context in mind. Each of them separately, and the interplay of all of them, introduce problems which make the overall setup a bad fit for marketing reporting. 

Let’s take a look at why. 

In marketing, granularity is the whole game 

Before getting to cost or compute, it is worth being specific about who horizontal BI tools were designed to serve.

Most BI reporting is built for executives and the C-suite. They care about stable top-line tracking: what is performance by channel, what is the trend versus last quarter, where are we against the plan. They do not need to know whether a specific ad creative in a specific ad group in a specific market is underperforming on Tuesday.

Yet in marketing, the unit of action is granular - so the unit of analysis has to be granular too. Channel-level numbers average winners and losers together. A paid social line that looks fine can contain three campaigns burning money and two carrying everything. At channel level you would never know. At ad-group or ad level you can see it in thirty seconds and may even be able to see why.

So why not use granular data in a BI dashboard? The answer people expect is that it would become slow. It would indeed, but that’s not even the main issue. 

The main issue is cost. Tools and pipelines charge you on volume, and they charge you on every layer of the stack: ingestion, storage and query.

Storage on its own is quite cheap. That is why the warehouse era happened: storage got cheap, so the prevailing logic became "let's move everything into a data warehouse and worry about it later." Sure. 

Ingestion and compute are a different story. 

Let’s start with ingestion. A tool like Fivetran charges on volume, and it is common for marketing alone to account for two thirds of the bill, simply because marketing generates so much more data.

Now, compute. What happens when someone wants to use the data at full granularity?

They write lots of queries. Imagine a simple-sounding ask: group campaigns into Austria and Germany buckets and sum revenue. At channel level, you might be scanning a hundred rows. At campaign level, five hundred. At ad group level, a few thousand. At keyword level, things start to get uncomfortable. The grouping is the same business question, but the underlying group-by operation is doing a lot more work as you go down the hierarchy.

AI makes this problem worse. Warehouses were sized around human behaviour. The assumption underneath the pricing, the indexing strategies, the materialised views, is that humans are going to make maybe twenty queries a day. An AI agent does not behave like a human. It can generate and run many more queries, much faster, and it is happy to keep asking the same question every hour. Instead of three humans doing twenty queries, you can easily end up with one hundred agents doing thousands. 

The problem of meaning 

There is a second problem with the "just let AI query the warehouse" story. Metrics in marketing are context-dependent. Paid social, CRM, brand and search teams each care about different valid metrics. The KPI you look at for a branding campaign is different from the one you look at for a performance campaign. The metrics for Germany may not be the same as the metrics for France. A simplistic warehouse model that picks one definition of "conversion" and applies it everywhere is going to be wrong.

What you need on top of the raw data is metadata and context: who is asking, what they mean by the metric they just named, which team owns it, how it relates to the other definitions that are also valid. Without this, a marketer using AI to query the warehouse will get a nonsense answer or worse, a plausible sounding but completely wrong one. 

… and then there is maintenance

Having a stack of three tools (likely more), each of which requires a change when business realities change, is a problem. And here again marketing is so much worse than most other business areas. 

There is constant change. New campaigns, new product lines, new creative concepts, shifting spend, shifting priorities etc etc - which require changes in what data is needed, in metrics, in dimensions. Every shift in strategy becomes a data engineering project. The reporting layer has to be able to move at the speed of marketing strategy. That is hard to do when there are multiple tools owned by different teams, each with their own priorities and a backlog of work. 

So a BI dashboard is not a tool for marketing reporting? 

It is not. 

The tech stack powering BI dashboards was not built for marketing data and use-cases, maintenance is a huge problem, AI makes things more complicated and then there are costs. Inevitably, companies who go on this path, decide that having super granular data is just not worth the explosion in costs and settle for campaign level data in their dashboards. 

Which means marketers can’t do their job… but marketers are crafty and they find a way. If your organisation’s official tool for marketing reporting is a BI dashboard with campaign level data and you have a half competent marketing team, I promise you there is a whole universe of shadow reporting in spreadsheets that actually informs marketing decisions on how millions of dollars of spend are allocated. But that’s a story for next time.