7 min read
A marketing director walks into a meeting with an updated dashboard. He knows how many customers converted last month, which channel they came from and how much they spent on average. He has precise answers to questions that point backwards — and he has no answer to what he needs for Thursday's planning meeting: which segment will convert most next month, and how much it is worth investing in each one before the campaign starts. That question cannot be answered with a better dashboard. It requires a predictive model, and the reason is one of temporal direction — not tooling or budget.
The distinction that matters is not in the software
BI and Data Science use much of the same input data. The month's transaction table feeds both the consolidated sales report and the repurchase propensity model. The data is the same; the question is different. BI answers "what happened?" and "how much?". Data Science answers "what is going to happen?" and "with whom?".
The historical conversion analysis for last month shows what happened: which channel brought the most leads, what the close rate was, where most opportunities dropped out of the funnel. That analysis lives in a dashboard. The forecast of which segment will convert most next month already requires a model. The input data can be the same; the temporal direction is opposite.
A good stock dashboard shows SKU rotation over the past six months, the best-selling lines, the weeks with spikes. A demand forecasting model uses that same history to estimate what to order next month by SKU, adjusting for seasonality, trend and point-of-sale signals. These are two answers built on the same data, for questions that point in opposite directions.
This is the point that tends to get lost when a company decides to "invest in data". The question it wants to answer determines the infrastructure it needs, and the two infrastructures are different.
Two different infrastructures
BI needs clean, structured, accessible data. It needs visualisation that the team can interpret without technical help. Maintenance is predictable: if the input data changes, the report changes; if the business adds a new dimension, it is added to the data model.
Data Science needs something different from the outset. Before writing a single line of code, someone has to define the prediction window: how many days ahead does the model predict? What is defined exactly as conversion? Over which population is it trained? These are business decisions disguised as parameters — not technical decisions — and getting them wrong contaminates everything that follows.
After training, the model needs degradation monitoring. Behaviour patterns change over time. The model trained six months ago may be producing predictions that no longer reflect current reality. That doesn't happen with a dashboard. If today's data is correct, today's dashboard is correct. With a model, the data can be perfect and the model still deteriorate because the world changed. The maintenance of a Data Science system is more active by design; it answers a harder question.
The prediction window is where the project is won or lost
Predicting requires making a decision before modelling. You have to decide what is being predicted and over what time horizon. If a company wants to know which customers have the highest probability of repurchasing in the next 30 days, that problem is different from predicting the next 90. The window changes which customers appear as positives in training, which signals from their behaviour are predictive, and how the model is validated. Changing the window is, in practice, changing the problem.
When someone arrives with the question "do we want to build a propensity model?", the first response is another question. Over what time horizon does the model operate, and what action will the team take with the result? Without a clear answer to those two questions, the model is built on assumptions nobody validated, and when the results arrive nobody quite knows how to use them.
Two questions before deciding which to invest in
Before choosing between BI and Data Science, there are two questions to ask.
Is the decision you want to make retrospective or prospective?
If the decision is to understand what happened, identify what worked, report results or detect past trends, the problem is BI. If the decision is to allocate budget, prioritise segments, anticipate demand or personalise an action before the customer does something, the problem is Data Science.
Is there a process that will consume the model's output?
A predictive model without a process to consume its output is useless. If the model delivers the prediction and the marketing team knows exactly which campaign to activate for each probability segment, the process is defined. If the prediction arrives in a file folder and stays there, the project has a design problem that no model resolves. BI also produces outputs that need processes to consume them, but the friction is lower. The dashboard tends to already be the process, or a step before a familiar process.
Both can coexist, and one tends to be the foundation of the other
A business with well-built BI has better chances of doing Data Science well. The data is clean, structured and has history. Business definitions are already agreed. The team has practice in making decisions based on quantitative information.
There is an additional dependency in the other direction — less obvious and more practical. BI is also what makes it possible to verify in production whether a predictive model is working. When the model predicted that a segment would convert at 15% and the following month's report shows it converted at 8%, that comparison between prediction and observed reality is what makes it possible to exhaustively analyse model degradation and make the necessary adjustments. BI closes the Data Science project loop, validating in production what training proposed.
This does not mean BI is a mandatory prior step. There are companies that go directly to predictive models because the use case justifies the investment from the start. When BI is well built, Data Science does not start from scratch; when it is not, the first work of the project tends to be cleaning up what BI should have left clean.
There is a more frequent pattern than it seems. The company that jumps to predictive models before having BI well established ends up doing both things halfway. The Data Science project stops to clean data that should have been ready beforehand. The model arrives, but on fragile foundations. Confusion between the two generates projects that solve the right question very well. A company that needed to understand what happened with its conversions last quarter hires a "data science" project, builds a propensity model that nobody knows how to operate, and concludes that "the data was not ready". The problem, in many cases, was that the project solved the wrong question.
The highest-value project before building anything
Defining which question you want to answer is the highest-value project that can be done without data yet. A data diagnostic takes two days and produces a document: what can be done with the current data, what cannot, what would be needed to go further, and what type of project resolves the real question. Sometimes the conclusion is that what the team needs is a better dashboard. Sometimes there is enough history to build a forecasting model. Sometimes the question is not yet defined enough to do either.
All three answers are valuable. The third one especially, because it avoids months of work in the wrong direction. The right question, before any data budget, is the highest-return investment that exists.