What Must an AI Agent Get Right on Promo Analysis?
An AI agent doing promo analysis must enforce the rules a good analyst enforces by habit: one promo condition per query, decompositions pulled at the level being reported rather than rolled up from parts, ratios recomputed rather than averaged, base plus incremental checked against total, reads at the retailer level, and an explicit refusal to compute a return when the trade cost input is missing. Speed without those rules produces confident wrong numbers faster.
Chapters 1 through 8 describe the work. This chapter describes the standard any tool has to meet to do the work without supervision, and it is written as a standard rather than a product description. Sous is named at the end as one system built to meet it.
Why promo work is where agents fail first
Promo analysis concentrates every property of syndicated data that breaks naive math. The measures are modeled (base and incremental), so they do not survive re-aggregation. The conditions overlap (any promo contains the "only" cuts), so they double count when summed [3]. The key ratios (lift, efficiency) have denominators that change by tactic and by store set [2]. And the most important input, trade cost, is not in the file at all. A general-purpose model asked a promo question will happily do all of the arithmetic that is forbidden, because nothing in the data refuses it. The aggregation trap chapter of the Syndicated Data guide covers the general case; the promo-specific failures are below.
The promo failure list, and what a correct system does instead
| A query that runs fine | Why it is wrong | What a correct system does |
|---|---|---|
| Average promotional lift across Kroger and Sprouts | Lift is a ratio with each retailer's own base as denominator; averaging two ratios is meaningless | Reports lift per retailer. If a combined figure is demanded, recomputes it as combined incremental over combined base and says so |
| Sum incremental units across markets to a national incremental | Each market's incremental was modeled against its own baseline; the sum compounds modeling error | Re-pulls the decomposition at the national level from the provider, or reports by market |
| Add feature-only, display-only, and any-promo dollars | Any promo already contains the "only" conditions | Asks which single condition the question is about; defaults to any promo when the question does not name a tactic |
| Average trade efficiency across events | Efficiency is return per dollar; averaging ignores that events spent different dollars | Recomputes as total return over total dollars invested at the requested level |
| Apply a Nielsen condition name to a Circana extract | The two providers name and nest conditions differently | Uses the rulebook for the provider the data came from; flags a condition that does not exist in that provider |
| Report a display lift on chain-wide base | The display ran in a subset of stores; the denominator must be those stores' base [2] | Uses the condition-specific base for each tactic |
| Invent a baseline where the provider did not model one | Base is the provider's estimate; a substitute average is a different number wearing the same name | States that base is unavailable for that cut and stops |
| Assume a discount-funding rate to produce an ROI | The cost file was missing; the return is fiction | Reports lift, states return is not computable, and asks for the cost input |
Every row in that table is an ordinary spreadsheet operation, and every one is a wrong answer that arrives looking like a right one. None of these queries errors out. That is the problem.
The identities an agent can check mechanically
Two arithmetic identities hold in every syndicated promo extract, and a system can test them on every query without any judgment involved.
Base plus incremental equals total. If the query pulled a base from one set of weeks or one provider and actuals from another, the identity fails and the lift built on it is wrong. Subsidized equals promoted minus incremental. If a narrative describes subsidized volume using base instead of incremental, the identity catches it.
These are the checks Sous encodes in its per-provider rulebooks. The verifier runs the base-plus-incremental-equals-total check on every promo query before a result ships, and the subsidized identity is written into the rulebook so the definition cannot drift between one query and the next. Neither check requires the model to be clever. They require it to be stopped when the numbers do not add.
Provider taxonomies are not interchangeable
Sous's Nielsen rulebook, built from Nielsen's facts guide, recognizes ten promo conditions, including "feature or display," "price reduction," and "subsidized." Its Circana rulebook treats causal conditions as a dimension any measure can be sliced by rather than as part of the measure's name, following Circana's measures guide. SPINS carries its own conventions for the same three tactics. The consequence is that "promo lift" is not one query with three data sources; it is three queries, each written to the provider that produced the file. Sous keeps a separate rulebook for each of SPINS, Circana, and Nielsen for this reason, and the agent architecture chapter of the Agents in CPG guide explains where the rulebook sits in the system.
The accuracy stakes, briefly
The trust and accuracy chapter of the Agents in CPG guide quantifies how often unassisted AI turns a question into the wrong database query on a public benchmark, and why "the answers looked right" is a weak test on syndicated data. The promo-specific point is that the wrong queries above return plausible numbers. A lift of 47% averaged across two retailers looks exactly like a lift of 47% computed correctly. The difference is only visible if the system shows its query and enforces the rule.
The demo question
Bring one question to any promo analysis demo: "Average my promotional lift across Kroger and Sprouts."
A tool that returns one number has told you how it will treat every other ratio in your data. A tool that reframes the question, shows lift per retailer, and offers a correctly recomputed combined figure with the query attached has passed the promo-specific version of the evaluation checklist in the Agents in CPG guide. Follow up with a second question: "What was the ROI on last quarter's Sprouts TPR?" when you know the cost file is not loaded. The right answer is a lift table and a sentence explaining why return is not computable.
Four ways to do the work, compared
| Spreadsheet | TPM or TPO software | Generic AI chatbot | Analytics agent meeting the standard | |
|---|---|---|---|---|
| Condition discipline | Depends entirely on the analyst | Often not connected to syndicated conditions at all | Computes whatever condition sum it is asked for | One condition per query, asked or defaulted |
| Grain discipline | Depends on the analyst; rolling up is one drag away | Event-level by design for cost; syndicated decomposition often imported pre-rolled | Sums and averages on request | Re-pulls decompositions at the reported grain |
| Identity checks | None unless built by hand | Reconciles spend, not base and incremental | None | Base + incremental = total on every query |
| Cost input handling | Manual join, if anyone does it | Its core strength: the cost lives here | Will estimate if asked, without saying so | Joins the cost file; refuses to compute return without it |
| Traceability | The formula bar, until someone pastes values | Audit trail on spend | Usually none | Every number linked to its query |
| Re-run on a new period | Rebuilt by hand, every period | Depends on integration | Start over | Re-runs when the file lands, validated against the prior period |
This table is a standard, and any vendor should be able to point to how it meets each row. Per POI's 2026 survey, 14% of consumer goods organizations still run trade on spreadsheets, and the top barriers to advancing are time and people (57%) and data cleansing and harmonization (50%) [1]. The rows above are where that time goes.
Where Sous stands
Sous is built to the right-hand column. Its per-provider rulebooks for SPINS, Circana, and Nielsen encode the promo conditions each provider actually carries; it asks for one promo condition before a promo query runs and recommends any promo as the default; its verifier checks that base plus incremental equals total on every query; ratio and efficiency measures are recomputed at the level requested rather than averaged; and every number in a workbook stays traceable to the query that produced it. When the cost file is not loaded, the workbook reports lift and says return is not computable. No accuracy or performance figure is attached to any of that here, and none should be attached to any tool's promo claims without the query behind it.
Common questions
Can an AI agent do promo analysis? Yes, if it enforces the rules above: one condition per query, decompositions at the reported grain, ratios recomputed, identities checked, retailer-level reads, and no return without cost. Without those it produces wrong numbers with a confident narrative.
What is the most common AI mistake on promo data? Averaging or summing things that cannot be averaged or summed: lift across retailers, incremental across markets, efficiency across events, or overlapping merchandising conditions.
What should I ask in a demo? "Average my promotional lift across Kroger and Sprouts." A correct tool reframes it. Then ask for ROI on an event whose cost is not loaded; a correct tool declines to compute it.
Why do the provider rulebooks have to be separate? Because Nielsen, Circana, and SPINS name and nest merchandising conditions differently. A promo query written for one does not translate word for word to another.
What are the identities an agent should check? Base plus incremental equals total, and subsidized equals promoted minus incremental. Both fail when a baseline is mismatched or a definition drifts.
Does a chatbot on top of my spreadsheet count as an agent? Not by this standard. The test is whether the system refuses forbidden math and shows its query, not whether it answers in complete sentences.