The tradeoffs of campaign budget optimisation

Below the campaign there are groups, each of which could carry its own budget. Two arrangements exist.

Budget at the group level. Each group gets a stated amount. You control the split exactly; nothing reallocates on your behalf; every group gets what you said. The cost is that the split is only as good as your information, and your information is a week old.

Budget at the campaign level. The campaign holds one amount and distributes it between the groups on its own reading of which is producing results. The split reacts within the day rather than within the week. The cost is that the split is the system's rather than yours, and it can be wrong in ways you would not have chosen.

Neither is an upgrade. They are different delegations, exactly like daily and lifetime budgets are different delegations of pacing.

Three failure modes, all of which look like something else at first.

Early-reading lock-in. A group that produces results in the first days takes a growing share, which gives it more volume, which makes its numbers look more certain. A group that started slowly never gets the volume to prove otherwise. This is the most common complaint and it is structural rather than a bug — reallocating towards what is working is exactly the job, and the job is done on evidence that was thin when it mattered most.

Starvation of something you needed. A group whose purpose is coverage rather than immediate return will lose to a group optimising for immediate return. If one of your groups exists for a reason the system cannot see, a shared pool will not respect it.

Unreadable aggregates. A campaign whose internal split moved every day produces campaign-level numbers that are an average over a changing mixture. Six weeks later, the question "what did this campaign cost per result" has an answer that describes no particular week.

All three of these, not one of them.

The groups are interchangeable. They are genuinely different ways of reaching the same outcome, and you would be equally happy with the result coming from any of them.

You have no strong prior. If you already know which group should win, you are paying for a reallocation you could have made yourself, and paying in control.

No group needs a floor. Nothing underneath has a job that requires it to keep running regardless of its immediate numbers.

Fail any one and the answer is separation: take the group that needs protecting out of the shared pool and give it its own campaign with its own budget. Where a platform offers floors and caps at the group level, those are a weaker version of the same idea and worth using, but the structural answer is a separate campaign.

The decision has a measurement consequence that outlives it, and it is worth making at the same time.

Lines that share a budget will have their numbers averaged together at the level above. So put things in one pool when you want to read them as one thing, and separate them when you will want to tell them apart. That is the same argument as keeping prospecting and retargeting in separate campaigns — Split prospecting and retargeting is one version of it, and it applies here whenever two groups have different jobs.

Naming carries the rest. A campaign's name is the thing a report groups on, and it is carried from wherever it was typed — a plan item's name goes straight onto the draft and then onto the campaign. Encode what you will want to filter by and nothing else.

Worth saying because it is assumed constantly. Which entity a budget attaches to differs between platforms, and so does what a shared pool is called and what it guarantees.

Every connection in Tempio carries a capabilities object describing what that platform can actually express: which change operations it supports, where budget attaches, which objectives it accepts, what a deletion means there, and whether a change can be dry-run against the platform before it is applied. Read that rather than reasoning from the platform you know best, because the structural advice in this guide is portable and the mechanics are not.

A budget change is a change request whichever entity it attaches to, and the limits are the same. A budget may not move more than a hundred per cent of its current value in one change. The entity's daily figure may not exceed the account's own ceiling, derived from what that account has actually done. An entity with no budget yet is held to a first-budget cap. Applied increases on one connection are summed over a rolling twenty-four hours against the ceiling.

Stated once: your connections read your accounts, a change is written as a draft on the record with the state it would change from and the checks it passed, applying it is gated on approval — by you, or by a rule you wrote — and no platform write reaches a customer account until that platform has granted write access. Applying a cleared change to a platform is in private beta.

Moving the budget level is a substantial change in conditions — it changes the budget on more than one entity and changes what each is competing for — so treat it the way you would treat any large change: deliberately, early in a window, with enough time either side to read what it did. How budget changes restart learning is the argument for that habit.

And read it afterwards from the record rather than from memory. Every applied change is a row with what it moved and from what, which is what lets you answer whether the reallocation you bought was worth the control you gave up.

A shared pool is a bet that the system's reading of which group is working, made daily on thin evidence, beats yours, made weekly on more. Often it does. It reliably does not when one of your groups exists for a reason the system cannot observe, and that case is common enough that the first question to ask is not whether to share a budget but which things belong in the same pool at all.

Daily versus lifetime budgets is the other delegation decision, and Pace a budget without a month-end scramble is what happens when neither delegation is doing the pacing you assumed.