Methodology & Assumptions

01What this model is, and isn't

This is a seasonality-and-efficiency allocation model. Given a fixed annual media pool and a month-by-month revenue (TTV) target, it phases that pool across the 12 months so the months historically best at converting spend into TTV carry more of the load, adjusted for how current market demand compares to history.

The tool labels itself Pre-MMM. This is important because it is not a marketing mix model, and it does not model:

• Marginal returns. It reasons entirely in terms of average historical efficiency (TTV divided by spend for the whole month), never the return on the next dollar. Moving money into a month assumes that month's next dollar performs like its average dollar, which this model never actually tests.
• Channel or creative-level detail. Everything is a single blended monthly efficiency number. There is no breakdown by channel, campaign, or creative.
• Booking lag or attribution windows. Every dollar of spend and every dollar of TTV is bucketed into the calendar month it fell in, with no adjustment for the delay between media exposure and a booking landing.

What it does do with real rigour: take three years of actual month-by-month efficiency, blend them with adjustable recency weighting, correct that blend for an independent read of current market demand, and use a single slider to set how much weight that efficiency read gets against simply mirroring the revenue target's own shape.

02The building block: MER and the seasonality index

Everything starts from Media Efficiency Ratio (MER), TTV divided by spend, calculated per month and per fiscal year for three years of TripADeal history (FY23/24, FY24/25, FY25/26).

The annual baseline for each year is spend-weighted, not a simple average of the 12 monthly MERs:

Each month is then indexed against its own year's baseline. This is the number used everywhere downstream:

An idx of 1.20 means that month ran 20% more efficiently than its year's average month. An idx of 0.80 means the opposite. This is a relative read: it strips out year-on-year growth or decline in overall efficiency, so the three years become comparable regardless of whether one year was simply a better year overall.

Best-ever and the Proven/Stretch split

For every calendar month, the tool takes the single best MER any of the three years achieved:

The Recommendation table's Proven/Stretch tag compares the model's required MER for that month (TTV target divided by recommended spend) against this ceiling. Proven means the plan asks for no more efficiency than history has already delivered at least once. Stretch means it asks for something no year has ever actually achieved in that month.

Spread and signal confidence

For each month, the tool also measures how much the three years' seasonality indices disagree with each other:

A small spread means the three years broadly agree that a month is seasonally strong or weak, so the pattern is probably real. A large spread means the years disagree, which usually points to one-off campaign timing or a single unusual year masquerading as seasonality.

03Blending three years of history

The three years' seasonality indices combine into a single blended index per month using adjustable recency weights, the numbers in the "Weighting & seasonality" grid, one weight per year per month:

Because the formula divides by the sum of the three weights, they don't need to add to 100%. The result is driven by the ratio between them, not their absolute size, and the tool renormalises automatically. If all three weights for a month are 0, the formula falls back to a blend of exactly 1: perfectly average, no seasonality signal at all. That default is silent, so it's easy to miss if a month's weights are ever cleared entirely.

The default starting weights

The tool doesn't open on flat 20/30/50 recency weighting (FY23/24 / FY24/25 / FY25/26) for every month. The default "Current" preset applies 20/30/50 as a baseline, then overrides five specific months to 30/50/20 instead (Jul, Dec, Feb, Mar, Apr), and further overrides July uniquely to 30/70/0. That means zero weight on FY25/26 for July specifically.

The tool's own interface requires an explanation for any non-default weight, logged in the "Event & dates" row, and flags a month if one is missing.

04The Google demand signal

Historical seasonality alone can't distinguish "this month is efficient because of something structural about the calendar" from "this month was efficient three years running by coincidence, and market conditions have since changed." The demand signal is the model's attempt to correct for the second case, using external data TripADeal's own spend doesn't directly control.

Seven possible sources, each independently switchable:

How the sources are blended

For every active source, both its available years of data get pulled in and pooled, weighted by the same recency weights (W) used for the historical MER blend above, into one running numerator and denominator per month:

The pooled result is then indexed so the 12-month average sits at exactly 1.0:

05The demand correction strength slider

This is the "Demand correction strength" slider on the main screen. It controls how hard the demand index above is allowed to bend the historical seasonality blend:

At 0%, demand.idx is raised to the power of 0, which equals 1 for any number, so the division does nothing. adj equals the pure historical blend from Section 2, completely unadjusted for current demand.

At 100%, the full demand index divides straight into the historical blend.

Mechanically: a month where current demand runs above its own annual average (demand.idx greater than 1) gets divided down. Its adjusted index falls, and that later translates into more budget for that month, not less. A month where demand is currently depressed gets pushed the other way.

The default sits at 50%, a halfway point between ignoring demand entirely and fully deferring to it.

06The efficiency vs. effectiveness dial

Once adj is computed above, it's renormalised so the TTV-weighted average sits at 1 across the year:

The dial then blends this fully-adjusted index against a flat baseline of 1, meaning no adjustment at all:

What each end of the dial means, precisely:

• 0% (pure "Effectiveness"): applied = 1 for every month, regardless of everything computed above. Required spend per month becomes exactly proportional to that month's share of the TTV target. The budget shape simply mirrors the revenue target's shape, with no efficiency or demand reasoning applied at all.
• 100% (pure "Efficiency"): applied = norm exactly. The full three-year, demand-corrected efficiency read determines the shape of the plan, even where that pulls budget away from the months carrying the largest revenue targets.

The required spend per month, and the raw (pre-lock, pre-override) allocation, follow directly:

The default sits at 25%, closer to the "chase the revenue target's shape" end than the "chase historical efficiency" end.

07Locking months, actuals, and reforecasting

Once a month has actually happened, locking it freezes its number and treats it as effectively spent. The model doesn't re-optimise history, only what's still open:

The remaining, still-open months are then scaled so they exactly consume whatever's left in the pool. This is a proportional redistribution of the raw model shape, not a fresh re-optimisation of the open months in isolation:

The reforecast panel's numbers follow mechanically from this. TTV banked and spend committed sum the locked months (using actual TTV where entered, else the original target). MER to date divides one by the other. Budget remaining and TTV still to find are the pool and target totals minus what's already banked. MER required from here divides the two.

08Manual overrides

A manual override on a month not yet locked pins that month's spend to an exact dollar figure, removed from the "open" pool that gets proportionally scaled. Every other open month absorbs the effect of that override through the scale factor above. The tool ships with one override already set by default: December is pre-set to $1.5m, independent of anything a user has entered.

09Known limitations

Six of these are stated directly in the tool's own "Known gaps" tab. The last three come from reading the underlying code closely.

1. Several months require efficiency above the best any year has ever delivered. True of the current live plan too. This reflects the level of the FY27 target itself, not how the model phases the budget.
2. Average returns, not marginal returns. Moving money into a month assumes its next dollar performs like its average dollar, a claim this model never tests. A proper marketing mix model is the only way to answer that.
3. Booking lag is unmeasured. Every dollar and every TTV figure is bucketed into the calendar month it fell in, with no decay curve for the gap between exposure and booking.
4. Five months carry non-default weights as shipped (see the blending section). Each should reflect a specific, documented event logged in the "Event & dates" row.
5. Demand isn't cleanly separated from media-driven effects unless the toggles are deliberately kept to the non-risky sources.
6. Historical spend reflects earlier planning decisions, not a controlled experiment. A month that was deliberately underspent in the past shows inflated efficiency for that reason alone, so the seasonality index is directional, not a precise physical constant.
7. Only Google Trends is on by default. Any demand-adjustment number quoted from an unmodified session reflects one data source, not the full suite the tool supports.
8. The demand-correction direction is an interpretation, not a documented design choice. It should not be presented as settled reasoning without further verification.

10Sensitivity checks worth running

None of these change any saved data. They're safe to try and revert, or just skip "Save checkpoint" while exploring.