Incrementality and event lift

Two different questions live under the word incrementality, and Nexus answers them separately because they carry different weight. One is a test you design and run. The other is a reading of something that already happened. Only the first is causal, and Nexus says which is which on the result itself.

Tests you run

A test begins as a proposal. A specialist states what they expect to happen, what they are changing, and what they will measure. A manager approves it before it runs. When it concludes, the verdict is recorded against the original hypothesis.

That sequence exists for one reason: it is the only way a test that failed stays on the record. In most teams a losing test is quietly dropped and the same idea is proposed again two quarters later by someone who was not in the room. Recording the verdict against the stated hypothesis makes the organisation's accumulated knowledge survive staff turnover.

A proposal captures what the result will be judged against before the result exists, which is the entire discipline. Deciding what counts as success after seeing the numbers is how almost every inconclusive test becomes a win.

Event and promotion lift

The second question is retrospective: Black Friday happened, Christmas happened, you ran a 20% promotion in March — what did each of them actually do?

Nexus estimates this with a pre-period counterfactual. It establishes what performance looked like before the event, projects that forward across the event window, and compares the projection against what happened. The gap is the lift.

This estimate is labelled non-causal, in the data and on the screen. A before-and-after comparison is not a randomised test. Anything else that changed at the same time is inside the number — a competitor's promotion, a seasonal demand shift, a platform algorithm change, a site outage. The estimate is useful for planning and worthless as proof, and conflating the two is the most common way a measurement platform misleads the team using it.

Finding the window

Event windows are detected from the spend data rather than assumed from the calendar date. Spend is compared against a robust baseline — a median with a median-absolute-deviation band, so one unusual day does not move the threshold — and contiguous elevated days are grouped into a window, tolerating a single-day gap.

This matters because the spend window and the calendar date rarely agree. Black Friday spend starts in early November. Christmas spend tails into Boxing Day. Measuring against the calendar date alone attributes the wrong days to the wrong event.

Events that sit next to each other

Some events cannot be separated, and Nexus says so rather than producing a number that implies they can.

Black Friday and Cyber Monday are three days apart every year. Christmas and Boxing Day are one. Where two events are a fixed distance apart, no amount of historical data distinguishes them — the data has never contained an instance of one without the other at that offset. The estimate for the pair is therefore a joint estimate, and the result declares which neighbouring events are inside the baseline and which are inside the carryover window.

The alternative — silently merging them, or silently splitting the lift between them — produces a number that looks like an answer to a question the data cannot answer.

Your calendar, not ours

Nexus ships a built-in calendar of US retail events, and takes your own on top. During onboarding you declare the events and promotions your business actually runs, including whether they recur on the same date or the same weekday each year.

Promotions are additionally read from your campaign, ad set and ad names where your naming convention carries them — a discount in a name is parsed into an offer and matched to the window. Where the convention does not carry them, nothing is inferred. Nexus does not invent a promotion structure you do not have.

What a lift number can and cannot support

Should we repeat this event next year?

Event lift, as one input

How much budget should the event hold?

Event lift plus a saturation estimate

Did this channel cause the revenue?

A designed test

Is this channel undervalued?

A designed test, prompted by the model

Event lift sets the prior. A test settles it. Nexus is built to move findings in that direction — a model result or a lift reading that suggests an opportunity is designed to end as a test proposal, not as a recommendation someone acts on directly.

Baselines are the hard part

The honest difficulty in event measurement is not the arithmetic, it is the baseline. A pre-period that sits on another event's plateau will understate the event being measured, sometimes dramatically — a Christmas window measured against a pre-period sitting on the Black Friday peak can read as a decline while absolute spend and revenue are both at their annual high.

Nexus exposes what the baseline was drawn from, so a reading that looks implausible can be checked against the window it was compared with rather than taken at face value.

Previous
Previous

Data quality and joins

Next
Next

MMM