Trade promotion optimisation & promotion uplift planning (CPG / retail)

Consumer-goods manufacturers spend a large share of revenue on trade promotions, yet many events never pay back because most of the sales lift is pulled forward, cannibalised from sister SKUs or would have happened anyway. Causal ML separates baseline from true incremental volume per retailer and SKU; an optimiser then plans calendar, mechanics, depth and spend within budget and feeds the joint business plan with the retailer.

Problem & value

• Today: Key-account managers plan promotions in spreadsheets or a legacy TPM (trade promotion management) system, mostly by repeating last year's calendar and negotiating depth and slots with each retailer. Post-event analysis is slow, relies on simple baseline-subtraction, and ignores cannibalisation, halo and post-promo dips. Settlement and deduction disputes consume finance capacity.
• AI value: (1) credible per-event ROI via causal estimates instead of naive lift; (2) a spend plan that shifts budget from loss-making to profitable mechanics, retailers and weeks; (3) what-if simulation before negotiation; (4) automated learning loop from every executed event.
• Evidence: industry vendors and consultancies repeatedly report that a substantial fraction of promotions fail to break even, but published figures vary by study and category; treat any vendor-quoted figure as a hypothesis to verify with your own back-test, not a planning number [1][2].

Variants

• CPG manufacturer TPM/RGM (core case): manufacturer-to-retailer budgeting on sell-out and trade-spend data, often as part of Revenue Growth Management (RGM) together with price-pack architecture and assortment.
• Retailer-side promotion planning: retailer plans flyers, loyalty offers and vendor-funded promotions across categories, optimising category margin and traffic rather than one brand.
• Joint business planning (JBP): shared fact base and scenario model between manufacturer and retailer; competition-law limits on information exchange apply (see Risks).
• Markdown and clearance optimisation is price-setting under inventory decay and is treated as a variant of OPT-004; everyday list-price setting also belongs there.
• Private use: none.

How it works

1. sell-in / sell-out / POS + promo calendar + trade-spend ledger + panel data
2. data harmonisation (SKU/EAN hierarchy, retailer calendars, promo mechanic taxonomy)
3. baseline forecast (counterfactual "no promo" demand)
4. causal uplift model per mechanic, retailer, SKU (cannibalisation, halo, pull-forward, post-dip)
5. optimiser (MIP / heuristic / bandit): calendar, depth, mechanic, funding under budget, margin, capacity, retailer rules
6. scenario simulation + KAM review and negotiation with retailer
7. execution, settlement, post-event evaluation
8. retrain

• Baseline and uplift: gradient-boosted or hierarchical time-series models plus causal methods (synthetic control, difference-in-differences, double ML, uplift trees) to avoid confounding: retailers promote what already sells well.
• Optimiser: mixed-integer programme selecting event-by-week choices under budget, minimum gap, funding-share, price-ladder and supply constraints. Response curves are learned, the plan is solved.
• LLM layer (optional): natural-language questions over results ("why was event X unprofitable?"), drafting JBP summaries; numbers always come from the model, not the LLM.
• Human-in-the-loop: key-account managers own plans and retailer negotiations; finance approves budget; every recommendation shows its causal estimate and uncertainty range.

Data preparation

Data needed: shipments and sell-in from the ERP, retailer sell-out and panel data (POS, Nielsen, Circana), the promotion calendar with mechanics, depth and funding, trade-spend contracts and deductions, prices, distribution and competitor activity. It lives in the ERP and TPM system, Excel promotion plans owned by key-account managers, retailer portals, e-mail attachments, and external panel exports. Typical gaps: promotions recorded inconsistently or only as free text, no history of what actually ran, different product hierarchies per retailer, missing baseline periods, deductions not matched to events, and cannibalisation effects hidden by aggregation.

Preparation steps: 1. Build one promotion event table with start, end, mechanic, depth, funding and retailer (PREP-011, PREP-020). 2. Harmonise SKU and customer hierarchies and KPI definitions (PREP-012). 3. Pull sell-out and ERP data through connectors or exports (PREP-005). 4. Match deductions and settlements to events. 5. Document test and control stores for calibration (PREP-018).

Tools: SQL or DuckDB, dbt, Python, retailer data-sharing portals. Rough share of effort: 50-60 percent; two to three years of event history is the realistic minimum. Readiness check via GUIDE-003.

Implementation paths

Which path for whom

• Enterprise (manufacturers, retail partners): B, because promotion planning is a core commercial process that depends on own sell-in, sell-out and retailer data; a causal model on cloud APIs and a warehouse integrates with ERP and TPM tools and avoids high platform seat costs. Path A remains valid for manufacturers that already run SAP or a TPM suite and want a packaged module.
• Developer: C, because open-source causal and time-series libraries (CausalML, DoWhy, PyMC, Prophet) run on HW1 and give full control over assumptions.

Path A — Buy

• TPM/RGM platforms: Visualfabriq (NL, EU) [3], Blue Yonder [4], Exceedra, SAP (Trade Promotion Management / Revenue Growth Management in SAP S/4HANA ecosystem) [5], Oracle, Salesforce Consumer Goods Cloud, Accenture/Kantar/Circana/NielsenIQ analytics services; for retailers: o9 Solutions, Relex (FI, EU), Blue Yonder, Antuit.ai/Zebra-class promo planning.
• Check: EU data hosting, retailer data-feed connectors, ERP integration (SAP, deductions), explainability of uplift, ability to export models and data, price per user/brand.
• Choose A when: more than a handful of key accounts, an SAP landscape, no in-house data-science team.

Path B — Build on cloud APIs

• Data platform (Snowflake, Databricks, BigQuery, Azure Fabric; EU regions) for sell-out data plus managed forecasting (e.g. Vertex AI forecasting, Amazon Forecast successors, Azure ML) for baselines.
• Causal and optimisation layer coded by in-house team (see Path C libraries) deployed on managed compute; LLM API (Claude, Gemini, GPT, Mistral in EU region) for the analyst copilot only.
• Choose B when: you need custom mechanics or a proprietary retailer-specific model but have a data platform and data scientists.

Path C — Self-host (open source)

• Forecasting: Nixtla StatsForecast/NeuralForecast, LightGBM, Darts, Prophet; foundation time-series models (Chronos, TimesFM, TimeGPT-class) for cold-start baselines [6].
• Causal: Microsoft EconML, DoWhy, CausalML (Uber), pyfixest for DiD; Bayesian structural models with PyMC [7].
• Optimisation: Google OR-Tools, HiGHS, Pyomo, PuLP; commercial Gurobi or FICO Xpress for large MIPs [8].
• Hardware: HW1 (CPU server) suffices for most workloads; a GPU only if training deep forecasters at scale.

Path D — Custom training

Worth it for large manufacturers with deep retailer data: hierarchical Bayesian or deep-learning response models per category, bandit-based exploration of depth/mechanic tests, and reinforcement-style planning. Requires 2-3 years of event-level history; run controlled in-market tests (matched stores, geo experiments) to calibrate causal estimates (see DATA-027).

State of the art (2026)

• Causal over naive lift: the move from baseline-subtraction to causal uplift with explicit cannibalisation and pull-forward is the main differentiator; synthetic control and double-ML are common in new builds.
• Foundation time-series models improve baselines for sparse SKUs and new products; they do not fix confounding.
• Optimisation plus simulation: vendors market "what-if" and prescriptive planning; practical solvers (HiGHS, Gurobi) handle thousands of events, with constraint management the harder part.
• Agentic/LLM copilots summarise performance and draft JBP decks; keep calculations deterministic.
• Limits: sell-out data sharing is partial (retailer-dependent); few price points per SKU give weak elasticity identification; promotion decisions are endogenous; competitor promotions and retailer pricing are only partly observed; new products and one-off events lack history. Recommendations can be gamed by retailers who see the model's logic, so keep retailer-facing outputs aggregated.

Shared resources & combinations

• Same stack (time-series + tabular-ml + optimization-solver): OPT-004 (pricing, markdown), OPT-005 (inventory), OPT-008 (S&OP), OPT-017 (assortment and space), PRED-001 (demand forecasting provides the baseline).
• Marketing measurement: REC-005 (MMM) shares causal models and Bayesian tooling; DATA-027 supplies experiment design for calibrating uplift.
• Downstream: promotion plans feed supply planning (OPT-002, OPT-008) and demand sensing; deduction management links to finance automation.

Effort, cost & KPIs

• Path A: 3-9 months for rollout across key accounts; subscription plus integration and data-feed costs.
• Path B/C: 6-12 months with a small team (data scientist, data engineer, KAM champion); cost is mainly people and data acquisition.
• KPIs: promotion ROI (incremental margin per euro of trade spend), share of events above break-even, forecast bias/WAPE of baseline and uplift, trade-spend as percent of gross sales, plan adoption by KAMs, deduction cycle time.

People & change

Involve management for the budget logic and trade-off between volume and margin, the head of sales or revenue management as process owner, and key-account managers as end users from the first workshop; their experience defines which mechanics are realistic. Finance approves budgets and validates ROI, IT and data owners provide ERP and sell-out data, and legal or compliance should review retailer data-sharing terms and competition-law limits when exchanging price and promotion data. Works council: normally no, because the system analyses promotions, not employees; if account-manager performance is tracked per person or usage is logged, §87(1) no. 6 BetrVG applies, and the council should be informed under §90(1) no. 3 when work processes change. Data protection: mostly no personal data; involve the DPO only if customer-level loyalty data is used.

AI literacy: support planners with training on causal versus naive uplift and on reading uncertainty ranges (AI Act Art. 4). Pilot with one category and one or two retailers for one promotion cycle, comparing against the manual plan. Typical concern: "the model overrules my retailer relationship". Address it by showing the causal estimate and range for each recommendation, letting managers override with a reason, and learning from those overrides.

See GUIDE-009, GUIDE-008 and GUIDE-003.

Risks, regulation & compliance

• EU AI Act: minimal risk; no Annex III category. AI literacy (Art. 4) applies to staff using the tools [9].
• GDPR: works on aggregated sell-in/sell-out data, so normally no personal data; loyalty-card or basket-level retailer data must be aggregated or processed under retailer controls and a data processing agreement [10].
• Competition law: Art. 101 TFEU limits exchange of competitively sensitive information (future prices, promotion plans across competitors); shared models must not leak competitor or retailer-specific terms; resale-price maintenance is prohibited. Use clean-team processes and legal review [11].
• Unfair trading practices: for agri-food, Directive (EU) 2019/633 restricts certain retailer demands (e.g. late payment, unilateral changes, payments for promotion not agreed in advance), relevant to promotion funding terms [12].
• Other risks: confounded models overstating uplift, retailer data quality, model drift when mechanics change; mitigate with holdout tests, uncertainty ranges and periodic back-tests.

Getting started

1. Pull 2-3 years of event history for one category and two retailers; define a common promo-mechanic taxonomy.
2. Measure current ROI with a transparent baseline method and mark events where data is too thin.
3. Build or buy a causal uplift pilot; back-test against held-out events and compare with naive lift.
4. Run a small constrained optimisation for one quarter's calendar and review with KAMs; test selected events in matched stores.
5. Institutionalise: post-event scorecards, monthly retraining, JBP template with agreed data-sharing rules.

Sources

1. McKinsey - Revenue growth management and trade promotion insights - https://www.mckinsey.com/
2. Gartner - Revenue growth management and TPM research - https://www.gartner.com/
3. Visualfabriq - Trade promotion management and RGM - https://www.visualfabriq.com
4. Blue Yonder - Retail and CPG planning solutions - https://blueyonder.com
5. SAP - Trade promotion management / revenue growth management - https://www.sap.com/products/scm.html
6. Nixtla StatsForecast / Chronos time-series tooling - https://github.com/Nixtla/statsforecast
7. Microsoft EconML - https://github.com/py-why/EconML
8. HiGHS open-source solver and Google OR-Tools - https://highs.dev and https://developers.google.com/optimization
9. Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj
10. Regulation (EU) 2016/679 (GDPR) - https://eur-lex.europa.eu/eli/reg/2016/679/oj
11. Treaty on the Functioning of the EU, Art. 101 - https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:12016E101
12. Directive (EU) 2019/633 on unfair trading practices in agricultural and food supply chain - https://eur-lex.europa.eu/eli/dir/2019/633/oj