The most common reason a first causal analysis goes nowhere is not a shortage of data. It is that the data is the wrong shape, or that a column everyone assumed was fine turns out to have been recorded after the fact. Both are easy to fix once you know to look.
The shape: one row per thing you are studying
Whatever you are analysing — a customer, a deal, a campaign week — each one gets exactly one row, and every column describes that same thing. This sounds obvious and is the step people most often get wrong, usually by joining two tables at different levels of detail and ending up with customers duplicated once per order.
A quick test: count your rows and count your distinct IDs. If those two numbers differ, the file is not ready.
The four things every analysis needs
- —An ID column — the customer, deal or account each row describes
- —The outcome you care about — churned or not, revenue, converted or not
- —The thing you changed — the discount, the campaign, the onboarding call. Either yes/no or an amount
- —The context that influenced both — segment, size, channel, tenure, region, time period
That fourth group is where the real work is, and it is worth being generous. It is far better to include a column that turns out not to matter than to leave out one that did.
How much is enough?
Fewer rows than people expect. A few hundred gets you a directional answer with honest uncertainty attached. A thousand or more lets you look at differences between segments rather than one overall number.
What matters more than volume is variation. If ninety-five percent of your deals got a discount, there is almost nothing to compare against, and no amount of extra rows will fix that. You need a reasonable number of cases on both sides of whatever you are testing.
Ten thousand rows where everyone got the same treatment is worth less than four hundred rows with a genuine mix.
Mistake 1: columns recorded after the outcome
This is the one that silently ruins the most analyses. If a column was written or updated after the outcome happened, it contains information from the future.
Classic examples: a churn reason field, filled in when the account cancelled. A final deal stage, which is "Closed Won" for every deal that closed. An account health score recalculated last night rather than as it stood at the time of the decision.
Any of these will produce a beautifully confident result that means nothing. The test is simple: for each column, ask whether you would have known this value before the outcome occurred. If not, drop it or reconstruct its historical value.
Mistake 2: the treatment is not one thing
A column called "discount_given" that mixes a 5% goodwill gesture with a 40% end-of-quarter rescue is not measuring one action. Neither is "onboarding_completed" when that means a full two-week programme for some accounts and a single email for others.
Either split these into separate things, or record the intensity — the percentage, the number of sessions — so the analysis can find where the effect changes.
Mistake 3: no time information
Timing resolves a large share of the ambiguity in a causal diagram, because something that happened later cannot have caused something earlier. Include dates wherever you have them: when the account started, when the intervention happened, when the outcome was measured.
Without dates, the software has to guess at direction and you have to correct more of the diagram by hand.
A five-minute pre-flight check
- —One row per customer, deal or period — row count matches distinct ID count
- —The outcome column has a genuine mix of values, not 99% one way
- —The thing you changed has a reasonable number of cases on both sides
- —Every column would have been known before the outcome happened
- —Dates are included wherever they exist
- —Anything unusual about the period — a campaign, a price change, a reorg — is represented as a column
If your data does not look like this yet and getting it there is the blocker, that shaping work is exactly what our Enterprise data-readiness consulting covers.