Итерации скидок в ТВ-бюджете: как разорвать петлю
Заявленный бюджет выбирает уровень скидки. Скидка меняет бюджет. Надёжный план — это устойчивое состояние обеих величин, а не результат одного прохода.
В любой ТВ-сделке есть круговая зависимость. Бюджет Shop List, который вы заявляете продавцу, определяет уровень скидки. Скидка меняет CPP. Новый CPP меняет бюджет, нужный для тех же TRP. А пересчитанный бюджет может попасть в другой уровень — и расчёт уходит на новый круг.
Это не изъян процесса. Это свойство коммерческой конструкции, в которой цена зависит от объёма, а объём измеряется в деньгах.
Ответ — устойчивое состояние
Расчёт «в одну сторону» исходит из того, что одну величину можно зафиксировать раньше другой. Здесь нельзя зафиксировать ни одну. Полезный ответ — точка, в которой бюджет и уровень скидки перестают двигать друг друга.
- Начинаем с предполагаемого уровня скидки.
- По его скидке пересчитываем CPP и бюджет под целевые TRP.
- Смотрим, какой уровень включает новый бюджет Shop List.
- Уровень изменился — повторяем. Не изменился — пара сошлась.
У последнего шага должно быть явное правило остановки. Иначе расчёт заканчивается там, где остановился человек, макрос или переписка, — а не там, где сходится коммерческая логика.
Арифметика скидок способна сдвинуть всю петлю
Скидки продавца применяются последовательно, поэтому они перемножаются, а не складываются. Скидка 20%, а следом 10%, даёт 28%, а не 30%:
Физика тут простая: вторая скидка действует на то, что осталось после первой. Сложение процентов означало бы, что обе скидки считаются от одной и той же исходной базы.
На одной строке разница выглядит косметической. Внутри итерации она меняет бюджет; бюджет может изменить уровень; новый уровень меняет каждый следующий проход. На плане из десяти позиций небольшое арифметическое расхождение превращается в другой коммерческий результат — при том что обе версии выглядят внутренне непротиворечивыми.
Некоторые границы уровней не сходятся никогда
Сложный случай — колебание между двумя уровнями. Бюджет дотягивает до верхнего порога и включает более глубокую скидку. Эта скидка опускает пересчитанный бюджет ниже порога. Возврат к меньшей скидке снова поднимает бюджет выше него. Формально устойчивой пары в рамках одних лишь правил уровней не существует.
Сделке всё равно нужна цифра, поэтому модели нужна детерминированная политика для границы. Мы берём больший бюджет. Это консервативно для покупателя: лучше защитить сумму до обязательств, чем потом объяснять, почему плану не хватило денег. TV Budgeting применяет то же правило на каждом прогоне.
Это переговорное правило, а не заявление о математической единственности решения. Его ценность в том, что оно явное, воспроизводимое и одинаково работает у разных людей и в разное время.
Автоматизация — про постоянство, а не про изобретательность
Рынки организуют эту петлю по-разному. Она может проходить внутри одной системы или через несколько раундов с продавцом. Меняется рабочий процесс, но не сама зависимость.
Задача движка скромная: повторять одни и те же шаги столько проходов, сколько нужно, каждый раз считать скидки мультипликативно, распознавать и схождение, и колебание, и фиксировать, каким правилом закончился расчёт. Тогда план можно воспроизвести через месяц, а не восстанавливать по памяти.
Частые вопросы
Зачем ТВ-бюджету итерации по уровням скидок?
Потому что бюджет выбирает уровень скидки, а этот уровень меняет бюджет, нужный для целевых TRP. Обе величины приходится решать вместе.
Что считается схождением?
Расчёт сошёлся, когда пересчитанный бюджет Shop List остаётся внутри того уровня, по которому его считали.
Что делать, если результат колеблется между двумя уровнями?
Нужно фиксированное правило для границы. Мы выбираем больший бюджет — консервативный вариант на стороне покупателя.
Ровно эту математику считает за вас TV Budgeting — в обе стороны, TRP → бюджет и бюджет → TRP, с итерацией порогов скидок.
Запросить демо →