How Does Promo Analysis Change When It Runs Every Period?
When the promo recap is a living workbook rather than a deck someone rebuilds, every new data drop updates the event table, the lift ladder, the return table, and the cross-account comparison on its own, and the brand's accumulated read on what works becomes a stored asset rather than one person's memory.
Everything in Chapters 1 through 9 has to be right before this is worth doing. Once it is right, doing it by hand every period is the expensive part.
The rebuild ritual
New SPINS, Circana, or Nielsen data lands every 1 to 4 weeks. Someone downloads the file, uploads it, checks that the columns still match, and rebuilds every promo report sitting on top of it: re-isolate the events, re-pull base and incremental at the retailer level, re-join the cost file, recompute lift by tactic on the right denominators, redo the recap. At most brands that is a full day per period, and it is the same day every period.
POI's survey work puts numbers around the feeling. Asked to describe the time the whole process takes, from budgeting through planning, execution, settlement, and post-event analytics, 67% of respondents called it burdensome [2]. In POI's 2026 survey, 57% of manufacturers cited time and people as the top barrier to advancing their trade analytics and 50% cited data cleansing and harmonization [1]. And POI's summary of why promotion calendars do not change is that organizations default to repeating prior-year events because innovation stalls without trusted proof of incremental value [1]. The proof exists in the data. Producing it every period is what nobody has time for.
What changes when the workbook re-runs
In Sous, promo lift analysis is a saved template, and the auto-load and auto-refresh behavior does the ritual. Point it at the folder, drive, or warehouse where the provider's file lands. When a new period arrives, each step of the recap runs without anyone opening the file.
| Step in the recap | By hand, every period | As a re-running workbook |
|---|---|---|
| New file lands | Someone notices, downloads it, uploads it | Detected in the folder, drive, or warehouse Sous was pointed at |
| Column check | Eyeballed against last period's file, if at all | Validated against the prior period; renamed columns or missing measures stop the run and ask first |
| Events | Re-isolated on the new weeks | Re-isolated on the new weeks, one condition per query |
| Base and incremental | Re-pulled at the retailer level | Re-pulled at the retailer level, with the base plus incremental equals total check from Chapter 9 |
| Cost join | Cost file re-attached by hand | Refreshed against the cost file already loaded |
| Lift by tactic | Recomputed, denominators chosen again | Recomputed on the denominators the template fixed the first time |
| Return | Recomputed where someone remembers to | Recomputed where cost exists; marked not computable where it does not |
| Recap narrative | Rewritten the night before the review | Rewritten to describe the new numbers |
| Done | A day gone | One notification: recaps are current |
The demo of that flow is the short video in The Drop Handles Itself, and this chapter will not describe it at greater length than the video does.
What matters for promo work specifically is the validation step. A promo recap is the report most exposed to a quietly changed file, because a renamed condition column or a dropped base measure does not break the arithmetic; it changes what the arithmetic means. Stopping to ask when the file's columns have changed is the same rule as "no return without cost," applied to the data itself.
The ladder becomes memory
Chapter 7's lift ladder only works if it accumulates: one more event in each retailer-tactic-depth row every time a promotion runs. Kept in a spreadsheet, it accumulates until the person who owns it changes roles. Kept as a workbook that re-runs on every drop, it accumulates on its own, and the corrections a team makes along the way (the retailer that reports its display condition oddly, the item group that has to be read as a PPG, the baseline everyone agreed to use for a launch year) are stored as brand context rather than re-explained each quarter.
That is the learning loop applied to promotion: the brand's own history of what worked, at which account, at what depth, gets more useful every period it runs, because every period adds a row and nothing is lost when the analyst is out. The Brand Context Layer guide's chapter on compounding covers the mechanism in general; promo analysis is the sharpest case of it, because the decision it feeds (which event to run next) comes up every few weeks and is otherwise made from last year's deck.
The longer arc
The Agents in CPG guide closes with the autonomous brand: routine data work (loading, checking, rebuilding, summarizing) running itself, and people spending their time on decisions. Promo analysis is where that arc is most concrete, because the routine work is so regular and the decision it serves is so expensive. The four layers in Chapter 1 do not change. What changes is that the event, lift, return, and source reads exist for every event at every account without anyone having built them the night before the review, and the meeting starts from the current ladder instead of the recap someone had time to make.
Start from the guide overview for the definitions, from the Syndicated Data guide for the measures, and from the Agents in CPG guide for the general case of agents on retail data.
Common questions
What is a self-updating promo recap? A promo analysis saved as a workbook template that re-runs when the next period's syndicated file lands: events, lift, return, and narrative recomputed on the new data, validated against the prior period first.
What happens if the new file has different columns? In Sous, the load stops and asks. Renamed columns or missing measures are not silently rebuilt over, because in promo work a changed condition column changes what every number means.
Why does re-running every period matter more for promo than for other reports? Because the decision it feeds, which event to run next, recurs every few weeks, and because the lift ladder only becomes evidence when it accumulates events.
Does automating the recap fix a wrong recap? No. It rebuilds the same recap faster. Chapters 2 through 9 have to be right first.
Where does the accumulated promo knowledge live? In brand context: the retailer-specific ladders, agreed baselines, and corrections the team has made, stored with the workbooks rather than in one person's head.