Association, intervention, and counterfactual are three fundamentally different questions. The counterintuitive part: no amount of lower-rung data can answer a higher-rung question — that's a ceiling in the data itself, not a shortage of samples. You can compute "how likely is Y when I see X" from observation, but never "what happens to Y if I reach in and change X." To climb a rung, you must inject something the data does not contain: a causal-assumption graph.
Three rungs, each harder than the last. Rung one, association (seeing): pure-observational P(Y|X), the home turf of today's machine learning. Rung two, intervention (doing): P(Y|do(X)) — I actively change X rather than passively watch it vary. Rung three, counterfactual (imagining): what would have happened had I not done it — a parallel world for the same individual. The catch: each rung up demands an extra "who-causes-whom" assumption; more observed samples alone will never carry you there.
The barometer and the storm. Barometer readings are highly correlated with storms (rung one), yet if you push the needle down by hand (do), no storm arrives — the real cause is atmospheric pressure, and the barometer is just another of its displays. The very same data yields opposite action-conclusions on rung one versus rung two. And the data never tells you which rung it belongs to; only the causal graph in your head can.
Today's machine learning lives almost entirely on rung one — predicting the next token, the next click, all on correlation. This explains a recurring faceplant: a model that predicts beautifully on historical data collapses the moment you use it to "intervene" (change the recommendation, change the price), because it learned association while you wanted intervention — a full rung apart. A/B testing is precious precisely because it is the elevator from rung one to rung two: randomization means you are truly doing do(X).
Almost all your monitoring metrics are stuck on rung one. "Error rate and latency rose together" is association; "will scaling up push errors down" is intervention — and no amount of scrolling back through dashboards answers the second. Only a real experiment, or a causal graph you dare to commit to paper, can. Before your next capacity or architecture call, separate the two: is this conclusion something you saw, or something you verified by acting?
Your last technical judgment based on production data — if pressed with "is this correlation or causation?", did you verify it with a real intervention, or quietly treat rung-one association as if it were rung-two causation?
When two variables move together, it need not be that either causes the other — very likely a hidden third party is pushing both at once. This "common cause" (a confounder) manufactures a purely spurious correlation out of nothing. The danger: it looks identical to real causation, and unless you go looking for it deliberately, you will never notice it is there.
On a causal graph, confounding is a "back-door path": X ← Z → Y. Z causes both X and Y, so even with zero direct causal link between X and Y, the two rise and fall in step. The fix is to "control / stratify": hold Z fixed (compare only within the same value of Z), and the back door is shut, leaving only genuine causation behind. So against a confounder, controlling for one more variable is the right move.
Hormone replacement therapy. Last century, many observational studies showed that menopausal women on HRT had markedly less heart disease, and the field broadly recommended it. But a large randomized controlled trial in 2002 found the opposite — it raised heart risk. Where's the gap? Women willing and able to take HRT tended to be wealthier, more health-conscious, more active — a healthy lifestyle was the common cause, lifting both "takes the drug" and "healthy heart." Once randomization cut the back door, the causal sign flipped outright.
A machine-learning "spurious feature" is exactly confounding: the model sees grass in the image and calls it a cow, because in the training set cows always stand on grass — grass is the common cause of cow and label, and the model breaks on a new background. Distributed systems are the same: a strong correlation between two metrics is often just both being driven by the hidden variable "traffic," and optimizing one alone leaves the other unmoved.
When you compare the results of two designs or two user groups, ask first: besides the one difference you care about, do the groups differ systematically in some other way (returning vs new users, high-spec vs low-spec machines)? That "other difference" is the confounder. Fail to control it, and the gap you measured may be entirely its doing.
In your last "group A beat group B" conclusion, were the groups split randomly, or were they already different for some reason (self-selection, filtering)? If the latter, what you actually measured — was it the design, or the hidden common cause that sorted people into the two groups?
Confounding teaches "control for more variables"; the collider hurls back a chilling opposite: some variables, the moment you control for them, conjure a correlation that never existed. More controls is emphatically not better — control in the wrong place, and you are manufacturing bias with your own hands.
A collider is the mirror of a confounder: X → C ← Y, where C is the "common effect" of X and Y. X and Y start out unrelated, yet once you stratify on C (look only at samples where C takes a fixed value), the two get dragged into a spurious negative correlation — since the outcome C is already fixed, if one cause is weak the other must be strong to make up for it. And the act of "selecting a sample" is itself a covert "stratifying on a common effect."
College admissions. Suppose admission weighs only two things — grades and a special talent — and being high on either gets you in. Across all high-schoolers, grades and talent are unrelated; yet the moment you look only at those admitted, you find the higher the grades the weaker the talent, and vice versa — a negative correlation out of thin air. Not because they are truly related, but because you fixed the common effect "admission" (you study only admits). The same mechanism explains why two diseases look negatively correlated among hospital patients, and why the "the better-looking someone is, the worse they behave" illusion lingers — your sample was pre-filtered by some common effect.
The WWII story of armoring planes is the same thing: tallying bullet-hole patterns only on returning aircraft stratifies on the common effect "made it back" — the spots most needing reinforcement are exactly where returning planes have the fewest holes (the planes hit there never came back). In machine learning, training only on "successful / clicked" samples is a selection on a collider, and the correlations the model learns are systematically distorted.
Your logs, your datasets, are almost always survivors filtered through some gate — only requests that went through leave a record, only retained users make it into the analysis. A correlation found in such pre-filtered data should trigger a reflex of suspicion: is it real, or did my own filter (a common effect) conjure it from nothing?
The dataset you're analyzing — is it "everyone," or "the survivors who passed some gate"? If the latter, of the correlations you're seeing, how many might the gate itself have manufactured?
The good news: getting causation does not always require running an experiment. A rigorous method (do-calculus) can tell you — given a causal graph — which causal questions are answerable from observation alone, and exactly whom to control and whom to leave untouched; and when an experiment is truly impossible, you can go pick up "the randomized experiment nature ran for you." Causation is not mysticism — it has an algorithm.
do-calculus is a set of mathematical rules that, where the causal graph permits, rewrite an intervention query containing do(X) into an expression of ordinary observational probabilities only — and along the way it decides for you: control the confounder, do not control the collider (or your answer drifts ever further off). When you truly cannot experiment, use a "natural experiment": some near-random force in the real world (a policy's effective date, a geographic border, a lottery draw) happens to split people as randomization would, and you borrow it to estimate causation.
The Vietnam draft lottery. To ask "what is the effect of military service on later earnings," comparing veterans to non-veterans directly is doomed to confounding — who goes to serve is itself non-random. But the U.S. drew lots by date of birth to set draft order, and birthdays are random — nature ran a randomized assignment for the researchers. Using that lottery as a lever, people cleanly estimated the causal effect of service on earnings — never running a single day of experiment, yet obtaining an experiment-grade answer.
An A/B test is randomization engineers build by hand; feature rollouts and canary releases are, at heart, small intervention experiments. When A/B isn't possible, engineering also leans on natural experiments: a config change that took effect in just one region, a single data-center outage — each can be a heaven-sent break point for estimating causation. Economics, epidemiology, and machine learning now share one causal language.
Next time you hit "did this change actually help, and yet an A/B is inconvenient" — don't rush to scrape a correlation out of historical data. First hunt for a near-random break point: a release that touched only some users, a hard cutover in time. That is often the closest-to-causal, first-hand evidence you can get.
In the system you own, was there recently a change or outage that hit "only some, not all"? If so, was it a natural experiment you let go to waste — one you could have used to estimate a causal effect cleanly?