TV budget discount tier iteration: how to solve the loop
The declared budget selects a discount tier. That discount changes the budget. A reliable plan is the stable state of both values—not the output of a single pass.
Every TV deal contains a circular dependency. The Shop List budget declared to the seller determines the discount tier. The discount changes CPP. The new CPP changes the budget required to deliver the same TRP. That revised budget may belong to a different tier, sending the calculation around again.
This is not a process flaw. It is a property of a commercial structure in which price depends on volume and volume is measured in money.
The answer is a stable state
A one-way calculation assumes one input can be fixed before the other. Here, neither can. The useful answer is the point at which budget and tier stop moving each other.
- Start with a candidate discount tier.
- Use its discount to recalculate CPP and the budget for the target TRP.
- Check which tier the new Shop List budget activates.
- If the tier changed, repeat. If it did not, the pair has converged.
That final step needs an explicit stopping rule. Otherwise the process ends wherever a person, macro, or message thread happens to stop—not where the commercial logic resolves.
Discount arithmetic can move the entire loop
Seller discounts are sequential, so they multiply rather than add. A 20% discount followed by 10% gives 28%, not 30%:
The physical logic matters: the second discount acts on what remains after the first. Adding the percentages gives both discounts against the same original base.
On one line the difference may look cosmetic. Inside an iteration it changes the budget; that budget may change the tier; the new tier then changes every next pass. Across a plan with ten positions, a small arithmetic disagreement becomes a different commercial outcome, even though both versions look internally coherent.
Some tier boundaries never converge
The difficult case is a two-tier oscillation. A budget reaches the higher threshold and activates the deeper discount. That discount pulls the recalculated budget below the threshold. Returning to the lower discount pushes the budget above it again. Formally, no stable pair exists under the tier rules alone.
The deal still needs a number, so the model needs a deterministic boundary policy. We use the larger budget. It is conservative for the buyer: protect the amount before commitment rather than explain later why the plan came up short. TV Budgeting applies this same rule on every run.
This is a negotiation rule, not a claim of mathematical uniqueness. Its value lies in being explicit, reproducible, and stable across people and time.
Automation is about consistency, not cleverness
Markets organize the loop differently. It may happen inside one system or through several rounds with the seller. That changes the workflow, not the underlying dependency.
The engine's job is modest: repeat the same steps for as many passes as necessary, use multiplicative discount logic each time, detect both convergence and oscillation, and record which rule ended the calculation. The plan can then be reproduced a month later instead of reconstructed from memory.
FAQ
Why does a TV budget need discount tier iteration?
Because the budget selects the discount tier while that tier changes the budget required for the target TRP. The two values must be solved together.
What counts as convergence?
The calculation has converged when the recalculated Shop List budget remains inside the tier used to calculate it.
What if the result oscillates between two tiers?
A fixed boundary rule is required. We choose the larger budget as the conservative buyer-side outcome.
This is exactly the maths TV Budgeting runs for you — both directions, TRP → budget and budget → TRP, with discount tiers resolved by iteration.
Request a demo →