Image by Author
We have all heard the mantra “Correlation does not imply causation.” You have likely seen the classic (and hilarious) examples, such as the strong correlation between per capita cheese consumption and the number of people who died by becoming tangled in their bedsheets.
As a data scientist, you know that finding a correlation is usually just the starting line. The real race begins when your stakeholder asks the dreaded “why” question or, worse, “what will happen if we change this?” To answer those questions, you need causality.
If you have ever built a model with fantastic feature importance scores, only to have it fail miserably in production because the underlying relationships shifted, you have felt the pain of confusing correlation with causation. Moving from “X and Y move together” to “X causes Y to change” is the holy grail of analytics.
Here are five practical ways to bridge that gap.
1. Granger Causality: “Does the Past Predict the Future?”
If you work with time series data like stock prices, website traffic, or sensor readings, you have probably struggled with causation. Did a spike in social media mentions cause a rise in sales, or did they both rise because of a holiday weekend?
This is where Granger causality (1969) comes in. Despite its bold name, it does not prove philosophical causation. Instead, it answers a specific question: “Does one time series help predict another?”
The logic is straightforward. You build two models:
- A model that predicts future values of Y using only the past values of Y
- A second model that predicts future values of Y using the past values of Y plus the past values of X
If the second model is significantly better, then X is said to “Granger-cause” Y.
The Technical Use Case
Imagine you are building a forecasting model for server CPU load. You have two features: the current number of active users and the current network latency. You suspect latency helps predict CPU load, but you are not sure.
By running a Granger test, you might find that past values of network latency help predict future CPU load, even after accounting for past CPU load data. This gives you statistical evidence to prioritize fixing network issues to reduce server strain.
Limitation: It only works for prediction. If the relationship is driven by a third factor, such as a new software update that affects both latency and CPU load, Granger causality can be fooled.
Fig 1: Predicting CPU Usage
2. Randomized Controlled Trials (A/B Testing): The Gold Standard
If you work in tech, you call them A/B tests. If you come from a scientific background, you call them randomized controlled trials (RCTs). Either way, this is the cleanest method for establishing causality.
The magic is in the randomization. By randomly splitting your users (or subjects) into a control group and a treatment group, you make sure that, on average, the only difference between the two groups is the treatment itself.
The Technical Use Case
You have a new recommendation algorithm that you believe will increase user “Add to Cart” clicks. If you simply rolled it out to everyone and sales went up, you would not know whether the increase came from the algorithm or a seasonal trend.
By running an A/B test:
- Control: Gets the old algorithm
- Treatment: Gets the new algorithm
Because you randomized the users, you can directly attribute the difference in “Add to Cart” rates between the two groups to the new algorithm. You have broken the correlation cycle by design.
The Challenge: RCTs are not always possible. You cannot randomly assign different salaries to employees to see if it makes them happier, and you cannot randomly drop your prices to see if it crashes the market.
Fig 2: Randomized Controlled Trials A B Testing
3. Instrumental Variables: Using Nature’s Randomizer
What happens when you cannot run an A/B test? You need to find a natural experiment. This is where instrumental variables (IV) shine. The concept is a bit mind-bending at first, but it is incredibly powerful.
An instrumental variable (Z) is something that causes your treatment (X) but has no other way of affecting your outcome (Y) except through that treatment. Think of it like a “clean” push. It forces a change in X without touching anything else.
The Technical Use Case
Suppose you want to know whether adding a feature to your app (X) causes users to remain active longer (Y). The problem is that users who enable the feature are probably more engaged to begin with, which creates a confounding variable.
You need an instrument (Z). Perhaps you ran a limited-time “Early Access” campaign that randomly showed a notification to only 10% of users. The notification (Z) caused users to turn on the feature (X), but the notification itself, assuming it was just a button, should not directly cause long-term retention.
By comparing users who got the notification and were therefore pushed to use the feature against those who did not, you can isolate the causal impact of the feature on retention, removing the bias of “naturally engaged users.”
The Difficulty: Finding a valid instrument is hard. You have to argue convincingly that your instrument affects the outcome only through the treatment.
Fig 3: Instrumental Variables
4. Difference-in-Differences: Tracking the Trend
Difference-in-differences (DiD) is a useful method when you have observational data and a specific event or intervention. It is best understood visually: you look at the trend in a treatment group and a control group before and after an event.
The logic is that the control group shows you what would have happened to the treatment group if the event had not occurred. This is the counterfactual. The causal effect is the difference between where the treatment group ended up and where the control group trend says it should have been.
The Technical Use Case
Imagine your data science team finally convinces the product team to redesign a complicated onboarding flow to reduce feature drop-off. The new flow launches on July 1.
You cannot just compare users before July with users after July because user behavior changes over time anyway.
With DiD, you compare:
- The change in drop-off for users who experienced the new flow
- Minus the change in drop-off for users who were on the old flow during the same period
If the new flow group improved by 10%, but the old flow group (the control) only improved by 2%, perhaps due to a holiday week, your causal impact is the 8% difference. This controls for the background trends that you could not otherwise see.
Fig 4: Retention Rates Comparison Chart
5. Regression Discontinuity Design: The Sharp Edge
Regression discontinuity design (RDD) is useful when a treatment is applied based on a threshold or cutoff. It leverages the idea that units just above the threshold and just below the threshold are essentially identical, except that one got the treatment.
The Technical Use Case
Suppose your customer support team only offers a “premium onboarding call” to users who have a subscription score above 80, based on their usage. You want to know whether that call actually improves customer retention.
You cannot compare all users above 80 with those below 80 because the high scorers are obviously better customers. However, if you look at the users who scored a 79 (no call) and those who scored an 81 (got the call), these users are practically identical in behavior.
If you see a sudden “jump” in retention rates right at the 80-point threshold, you can confidently attribute that jump to the premium onboarding call, not to the user’s underlying quality.
Fig 5: Impact of Onboarding Calls on Retention
Moving Beyond the Toolkit
Moving from correlation to causation is not just about running a different statistical test. It is about changing the way you frame problems. Instead of asking, “What features correlate with customer retention?” start asking, “If I intervened and changed this feature, would customer retention improve?”
To solidify these concepts, the best thing you can do is get your hands dirty with code.
Conclusion
These five methods offer practical ways to move beyond surface-level correlation and start reasoning about causality. They help you answer the dreaded “why” question and the even harder question: “What will happen if we change this?” Try taking a dataset you already work with, preferably one where you suspect a causal relationship but lack proof, and applying one of these methods.
To make this easier, I recommend trying the DoWhy library from Microsoft. It is a Python library designed specifically to codify causal inference. It forces you to state your assumptions explicitly, making them easier to test, and then allows you to estimate causal effects using multiple methods.
Load a dataset, state your treatment and outcome, and see whether the causal direction you suspect holds up under scrutiny. It is the quickest way to stop just spotting patterns and start understanding the forces that drive your business.
