Technical Deep Dive: Pricing & Optimization

Demand modeling, elasticity estimation, financial objectives and validation at Thrasio.

← Back to the client-facing case study

This supplement describes the modeling and decision-system approaches behind the pricing case study. It summarizes several related workstreams from my role at Thrasio; they were not one monolithic model. Numerical results come from previously reported résumé/project materials and should be checked against final approved reporting before public release.

1. Modeling the right business question

A demand forecast predicts likely sales under a set of conditions. A pricing system asks which action produces the best expected outcome given uncertainty, inventory position and financial constraints. That distinction drove the architecture: demand forecasts, price response, business objective and guardrails were treated as separate concerns.

Inputs included historical sales, price and promotion history, product information, inventory position, unit economics, and other operational signals. Data preparation also needed to account for stockouts and situations in which observed sales were a constrained view of underlying demand.

2. Demand forecasting and separation of price effects

Forecasting work drew on time-series and machine-learning ensembles with relevant demand, product and seasonal signals. In the pricing context, a deliberate design choice was to avoid letting the baseline demand model simply absorb the same price effect later estimated by the elasticity layer.

Conceptually, the pipeline separates:

1. Baseline demand: what volume is expected given history and non-price conditions?
2. Price response: how should volume change when the candidate price changes?
3. Decision model: which candidate action best satisfies margin, inventory and cash-flow objectives?

This decomposition makes assumptions easier to scrutinize and helps avoid double-counting price effects. It is a modeling design principle, not a claim that a single closed-form equation perfectly described all product demand.

3. Estimating elasticity from observational data

Thrasio’s price history was observational: prices and marketing spend were not randomly assigned, and product-level demand was heterogeneous. Naively regressing units sold on price can confuse genuine price response with promotions, seasonality, inventory availability and other confounders.

I developed the company’s first double machine learning (DML) price-elasticity approach for 10,000+ products. The work used log-log elasticity reasoning and nuisance-model controls to isolate a more interpretable price-response estimate from noisy data.

Key technical considerations included:

• defining the treatment, outcome and adjustment signals carefully;
• recognizing stockouts and censored observed sales;
• separating covariates available at decision time from leakage-prone variables;
• evaluating heterogeneous product/category behavior;
• checking robustness and stability rather than treating one coefficient as ground truth.

DML can reduce some confounding-related bias under its assumptions. It does not automatically make observational elasticity estimates causal; identifying assumptions and validation still matter.

4. Inventory-aware optimization and NPV

Price decisions were evaluated over the economic life of inventory rather than only against a short-term revenue or margin target. I designed an NPV-oriented inventory-aware objective connecting candidate price, expected demand, margin, sales velocity, cash recovery, excess stock and capital costs.

The pricing research considered an infinite-horizon formulation alongside inventory and demand tradeoffs. The point of such an objective is to capture that cash earned now, inventory carried for later and the risk of overstock or stockout have different economic values.

In practice, optimization is bounded by business constraints and operational guardrails. The existence of an optimizer should not be taken to imply unconstrained automatic price changes or perfect future knowledge.

5. Simulations, experiments and decision validation

The engineering and analytical workflow included scenario simulation, holdout/backtesting logic, robustness checks, and commercial experiments including PPC spend measurement. This was important because a plausible modeled optimum is not the same thing as a validated business improvement.

Typical questions included: What changes when volume is lower than forecast? What happens under inventory shortages or excess stock? Are price-response estimates stable over time? Do proposed actions violate commercial guardrails? How should the business interpret model uncertainty?

The model outputs were intended to inform operational decisions and explain tradeoffs to commercial, supply-chain and finance stakeholders.

6. Reported results — keep workstreams distinct

Do not sum percentages across these initiatives. The documents support reported outcomes, not a publicly audited causal estimate.

7. What this work demonstrates

The technical strength was not any single algorithm. It was the ability to turn a commercial problem into a chain of testable components: data preparation, forecasting, elasticity inference, economic objective design, constraints, simulation, code and stakeholder validation.

Technical themes: Python · SQL · forecasting ensembles · DML and econometrics · log-log elasticity · optimization / simulation · cash-flow modeling · holdout testing · production guardrails.

← Main case study · Discuss an optimization project