I used to think elasticity was a regression problem. You have price, you have quantity, you fit a curve, you write a memo.
Then I had to price a catalog.
The first thing a catalog teaches you is that price is not a feature you found in nature. Someone set it. They set it because of inventory, because of a vendor conversation, because last December was bad, because a title looks like another title. If you put that price into a model and call the coefficient "elasticity," you have mostly recovered the merchandising policy.
The sentence I want
The useful sentence is not "sales fell when we raised the price." The useful sentence is "after we account for the things that jointly drive price and demand, this title still looks elastic."
That is a causal sentence. It is also an engineering sentence, because you only get to say it if the features you used were known before the price was set.
What I actually do
Double machine learning is the tool I reach for when I need to partial out confounders from both the treatment and the outcome. Causal forests when I need the effect to vary by cluster. A dumb baseline always, because a fancy estimator that loses to last year's rule is not an upgrade — it is a research note.
I will not publish the feature list. The discipline is the public part:
- Draw the DAG, even badly.
- Refuse post-treatment features.
- Carry uncertainty into the optimizer.
- Watch the slices where the sign flips. That is usually data, not a market epiphany.
Production is the identification strategy
Notebooks hide leakage. Pipelines can be written so a leaked column fails a test. That is the unromantic core of causal ML in a company: you are not only estimating an effect. You are defending an identification strategy against next week's well-meaning pull request.
If you want the longer case, I wrote it up as Dynamic Pricing Across a 60K+ SKU Catalog. The causal layer itself is private; the logic walkthrough on that page is what I can show.