Scenarios

A scenario is a plan with a parent. Duplicating a plan as a scenario copies its items, phases, envelopes and goals into a variant of the same family, and the plan's Scenarios tab then draws every live variant on one axis with what each of them adds up to underneath. Promoting one materializes it and archives its siblings.

Nothing new is materialized by a scenario, and nothing about a variant is a different kind of object: it is a plan, it is free to edit, and it becomes drafts by the same route any plan does.

Duplicating

Duplicate as scenario is in the … menu of the plan's header, and on the Scenarios tab while the plan has none:

A variant of this plan: the same window, its own items and budgets. Both render on one axis, and promoting one archives the rest.

Each variant carries a label — "Base", "Aggressive", "Search-heavy" — which is its name beside the plan's own, and a label already used in the family is refused rather than duplicated. A family holds at most eight live variants; past that, archive one or duplicate the plan as a root of its own.

Once one variant of a family has been materialized the window is settled: the choice has been made, and a variant added afterwards could never be promoted, because a promotion cannot archive a plan that already became drafts. The scenario button steps aside there and a plain Duplicate plan takes its place — a plan of its own, carrying this plan's items, phases, envelopes and goals, and nothing it drafted.

The stack

A plan with variants renders them as stacked timelines, one per variant, on one axis:

Variants of one window, on one axis. Promote the one you want and the rest are archived — frozen, not deleted.

The default axis is the union of the variants' windows. Comparing two variants on an axis that cut one of them short would be comparing two different questions, so the axis widens to hold every variant whole; naming a window in the link still wins over it. Each row is the same timeline component the Planner draws, so a bar, a phase band and a pacing fill mean exactly what they mean everywhere else.

An empty variant beside a full one is drawn too. That is the comparison.

The totals strip

Under each variant, three answers to the question a stack is opened with — which of these do I want:

Every figure is derived from the same planned-per-day arithmetic pacing uses, and nothing is stored. Each number is written out as text beside its bar: a bar whose value nobody can read is decoration.

The goal lines are estimates and say so, in the app's own words — "an estimate, not a forecast". They multiply a variant's planned spend by a ratio measured over the account's recent window, so only cpa and roas goals carry one — a spend goal is already the number in hand, and neither ctr nor cpm says anything about what a spend buys. Where there is no estimate, the line says which of the two reasons applies: the account has no recent baseline yet, or the item's account bills in another currency and money never crosses currencies here. A ratio whose denominator was zero has no value, so the line is absent rather than zero.

Promoting

Promote sits on each variant's row, not on the header — the header's Materialize steps aside on a stacked plan, because on a stack the question is always which one.

Promoting is materializing that variant. In one transaction it writes the create-campaign drafts for that variant's items and archives its live siblings, each with an audit row saying it was archived because another variant was promoted, and naming the one that was. Archived is frozen, not deleted: the plans and their items stay readable, and the family keeps the record of what was considered.

The variant that was promoted is materialized, so it freezes the way any materialized plan does, and the drafts it produced are at the gate from there. Promoting a plan with no variants is simply materializing it.

A worked example

A plan window of 1–31 October in NZD, duplicated twice:

The stack draws all three over 1–31 October. The by-month strip reads NZ$30,000.00, NZ$45,000.00 and NZ$30,000.00; the by-platform strips show where each one puts the money. A CPA goal of NZ$40.00 on an account whose recent measured CPA is NZ$45.00 turns each total into an estimated conversion count — about 667, 1,000 and 667 — clearly labelled as an estimate at the account's recent rate, and absent entirely on an account nothing has been measured on yet.

Promote Aggressive and its items become drafts, one batch per connection, while Base and Search-heavy are archived in the same transaction.

Over MCP

list_media_plans carries each plan's scenarioOfPlanId and its label, so a family is visible in the list. get_media_plan returns the plan's variants — the root first, each variant by its label — alongside its items and their goal verdicts. materialize_plan takes promote, which is what archives the siblings; without it, it materializes a plan that has none.

Duplicating a plan as a scenario is an action in the app rather than a capability on the surface. The MCP reference lists what is there.