Бюджет первого теста: как рассчитать сумму, которой хватит для решения

Редакция mevrica

Аналитика8 мин чтения

Обновлено 3 августа 2026 г.

Тестовый бюджет — это стоимость информации, достаточной для заранее определённого решения. Он не равен сумме, которую не жалко потерять, и не выводится из универсального правила «несколько выплат на одну связку». Для расчёта нужно знать единицу анализа, базовую частоту результата, минимально полезное отличие, желаемую вероятность обнаружения, цену наблюдения, лаг созревания и максимальный допустимый убыток. Если эти элементы не согласованы, большой бюджет лишь делает ошибочный вывод дороже.

Прямой ответ

Сначала рассчитайте требуемый объём наблюдений, затем переведите его в показы, клики и деньги по диапазонам CPM/CTR/CR. После этого ограничьте план финансовым loss limit и оборотным капиталом. Если лимит ниже требуемого бюджета, дизайн нужно менять до запуска.

1. Какое решение покупает бюджет

Вы хотите проверить техническую доставку, CTR концепции, конверсию лендинга, CPA подтверждённого события или зрелую маржу? Для каждого ответа нужны разные объёмы и задержка. Нельзя рассчитать деньги, пока неизвестен основной результат.

Запишите действие после теста и минимальную разницу, которая это действие оправдывает.

Полезно разделить бюджет на четыре конверта: техническая проверка, discovery, confirmation и резерв инцидента. Деньги не обязаны быть физически разнесены, но в плане у каждого конверта своя цель и stop-rule. Технический этап нельзя незаметно расширять в бизнес-тест, а discovery — объявлять подтверждением только потому, что один вариант оказался лидером.

2. Определите единицу анализа

Показ, клик, сессия, пользователь или когорта имеют разную зависимость. Если один пользователь создаёт несколько кликов, считать их независимыми нельзя. Единица должна совпадать с рандомизацией и бизнес-решением.

Ошибочная единица искусственно увеличивает sample size на бумаге, но не добавляет информации.

3. Найдите базовую частоту

Baseline берут из сопоставимых зрелых данных, а не из лучшего кейса. Если истории нет, задают широкий сценарный диапазон и проводят пилот на оценку порядка величины.

Маленькая ошибка baseline особенно сильно меняет выборку для редкого события.

4. Выберите MDE

Minimum Detectable Effect — минимальное отличие, которое дизайн должен уметь обнаружить с выбранными ошибками. Оно может быть относительным или абсолютным, но в расчёте нужно ясно указать единицу.

Слишком маленький MDE делает тест дорогим; слишком большой позволяет пропустить полезное улучшение. Выбор связывают с экономикой.

Экономический перевод MDE начинается с разницы ценности на единицу. Если изменение CR на 0,1 процентного пункта даёт эффект меньше стоимости поддержки нового лендинга, проектировать тест на его обнаружение неразумно. И наоборот, крупный MDE может пропустить улучшение, которое на годовом объёме существенно. Поэтому продукт, финансы и аналитика выбирают порог вместе.

5. Задайте alpha и power

Alpha ограничивает риск ложной победы в выбранной процедуре, power — вероятность обнаружить заданный эффект при допущениях. Значения выбирают до данных и не меняют ради удобного результата.

Для бизнеса важно также посчитать стоимость каждого типа ошибки, а не только использовать привычные настройки.

Практичный вариант — держать отдельный лимит на разведку, подтверждение и масштабирование. Деньги из следующего слоя становятся доступны только после прохождения заранее заданного условия. Так один удачный час или единичная конверсия не превращаются в основание резко увеличить расход.

Резерв не следует заранее распределять по объявлениям. Его назначение — профинансировать повторную проверку перспективного сегмента или пережить задержку данных. Если резерв расходуется просто потому, что основной лимит закончился, бюджетная дисциплина фактически отсутствует.

6. Переведите выборку в клики

Если primary metric измеряется на сессии, sample size даёт число зрелых сессий. Добавьте ожидаемые технические потери, но не завышайте их скрыто: каждая поправка должна иметь источник.

Используйте нижнюю и верхнюю границу baseline, чтобы получить диапазон.

7. Переведите клики в показы

CTR зависит от концепции, placement и аукциона. Один прогноз не подходит; используйте консервативный диапазон и пересчитывайте бюджет после canary.

Низкий фактический CTR увеличивает стоимость набора, но сам может быть причиной остановки по отдельному правилу.

8. Переведите объём в деньги

Для CPM-источника расходы зависят от показов и фактического CPM; для CPC — от кликов и CPC. Комиссии, валютная конвертация и минимальные пополнения учитываются отдельно.

Средний CPC из интерфейса не гарантирует цену после изменения bid и аудитории.

Для аукциона полезно моделировать цену как функцию объёма. Увеличение bid или бюджета может открыть более дорогой инвентарь, поэтому стоимость последней тысячи показов отличается от средней первой. Постройте ступени spend и ожидаемого CPM/CPC по историческим кривым, если они есть. При отсутствии истории используйте широкий верхний сценарий и canary для обновления только рыночной части предпосылок.

9. Учтите лаг созревания

Бюджет может быть потрачен до появления FTD или approval. План включает календарную длительность и cash exposure, а не только итоговую сумму.

Незрелые результаты нельзя считать нулём; их отделяют в pending.

10. Добавьте технический этап

До статистического теста нужен небольшой canary на маршрут, события и списание. Его бюджет не доказывает бизнес-эффект, но защищает основную сумму от грубой поломки.

Порог canary основан на достаточности для технических инвариантов.

11. Задайте loss limit

Даже корректный sample size может требовать убытка, который команда не готова принять. Loss limit включает spend минус консервативно признанный доход и фиксируется до запуска.

Достижение лимита завершает тест как финансово недоступный, а не автоматически доказывает отсутствие эффекта.

Loss limit полезно задавать на нескольких уровнях: общий тест, день, источник и критический технический сценарий. Дневной предел защищает от внезапного роста цены до того, как общий лимит исчерпан; технический — останавливает spend при потере click IDs или событий независимо от текущего дохода. Все уровни должны иметь ясный приоритет и владельца возобновления.

Постройте распределение времени от клика до целевого статуса хотя бы по исторически похожему потоку. Полезны медиана и несколько квантилей: они показывают, какая доля результата появляется в первые часы, сутки и более поздний период. Это надёжнее, чем ориентироваться на среднее, которое может быть искажено длинным хвостом.

12. Проверьте оборотный капитал

Hold, задержка платежа и RevShare создают кассовый разрыв. Прибыльный ожидаемый тест может остановить работу из-за отсутствия ликвидности.

Сценарий показывает ежедневный cash balance до консервативной даты поступления.

13. Не используйте правило N конверсий

Ожидание ровно десяти конверсий выбирает длительность в зависимости от наблюдаемого успеха: слабая кампания тратит больше, сильная заканчивается раньше. Такая выборка искажает сравнение.

Фиксируйте знаменатель, время или корректный последовательный дизайн.

14. Разделите discovery и confirmation

Discovery быстро отсеивает грубые проблемы и формирует гипотезу. Confirmation проверяет заранее выбранный эффект на новой выборке. Использование одного и того же шума для поиска и подтверждения переоценивает победителя.

Бюджет распределяют между этапами, сохраняя независимость финальной проверки.

15. Учтите множество вариантов

Чем больше креативов и аудиторий, тем меньше объём на каждый и выше риск случайного лидера. Сократите число самостоятельных сравнений или скорректируйте дизайн.

Пятнадцать слабых вариантов не дают больше информации, чем три осмысленных.

16. Планируйте диапазон, а не точку

Составьте low/base/high по CPM, CTR, CR и approval. Для каждого покажите время, spend и вероятность достичь решения.

Если кампания жизнеспособна только в лучшем сценарии, запуск является ставкой на удачу, а не контролируемым тестом.

Monte Carlo или простая сценарная сетка помогает увидеть не только итоговую сумму, но и вероятность не завершить тест в срок. В модель вводят диапазоны CPM, CTR, conversion delay и approval, сохраняя корреляции там, где они известны. Даже грубая симуляция полезнее умножения четырёх средних, потому что показывает тяжёлые кассовые хвосты.

17. Пересчёт после canary

Canary обновляет технические потери и рыночную цену, но не позволяет выбрать удобный MDE задним числом. Если предпосылки резко отличаются, первоначальный тест закрывают и утверждают новую версию плана.

Изменение сохраняется с датой и причиной.

Итог теста может быть не только «масштабировать» или «закрыть». Третий корректный исход — признать неопределённость и назначить повтор с одним исправленным ограничением. Например, если экономика выглядит перспективно, но половина событий потеряна из-за технической ошибки, новый тест проверяет восстановленный трекинг, а не меняет одновременно аудиторию и креатив.

18. Пример логики расчёта

Допустим, дизайн требует определённого числа зрелых сессий. Умножьте их на диапазон CPC, добавьте наблюдаемую долю недоставленных сессий и операционные затраты, затем сравните с loss limit. Если полученная сумма выше лимита, не округляйте вниз: выберите более крупный MDE или другой результат.

Числа проекта должны приходить из его данных; универсальный пример не является рекомендацией ставки.

19. Вывод

Хороший тестовый бюджет начинается с решения и заканчивается финансовым ограничением. Sample size отвечает, сколько информации нужно; аукцион — сколько она стоит; зрелость — когда она появится; loss limit — можете ли вы её купить.

Если эти четыре ответа не сходятся, правильное действие — изменить дизайн, а не надеяться на раннюю удачу.

Финальный документ бюджета должен быть понятен без статистического калькулятора. В нём есть вопрос, единица, baseline, MDE, требуемый объём, диапазон стоимости, календарь зрелости, loss limit и триггеры остановки. Отдельная строка показывает, какая часть расходов является невозвратной даже при техническом провале. Такой документ позволяет владельцу денег согласиться именно с риском, а не с одной итоговой цифрой.

Не финансируйте тест за пределами допустимого риска

Статистическая потребность не обязывает тратить сумму, которую команда не может потерять или заморозить. Финансовая устойчивость имеет приоритет над завершением эксперимента.