Математика бюджета: 99 ₽ × N плюс комиссия 15 % на реальных примерах

Сценарий: таблица, которую нужно показать в пятницу

Денис — технический директор небольшой студии. В пятницу у него встреча с основателем, и вопрос будет один: «Сколько нам нужно на тестирование перед релизом и что мы за это получим?»

Денис знает, что честное тестирование дешевле рекламы для поиска проблем. Но «дешевле» на встрече не работает. Работают цифры: сколько прохождений, по какой ставке, с какой комиссией, в сколько волн, какой итог.

Разберём эти расчёты полностью — так, чтобы их можно было перенести в свою таблицу и защитить перед любым скептиком. Все формулы простые, но именно в простых расчётах чаще всего допускают ошибку на 15 %.

Базовая формула и главная ошибка

Ставка за одно принятое прохождение — 99 ₽. Комиссия платформы — 15 %, её платит автор кампании.

Правильная формула:

> Бюджет = Ставка × N × 1,15

Неправильная (частая) формула:

> Бюджет = Ставка × N, а комиссию «посчитаем потом»

Разница на 50 прохождениях — 742,50 ₽. На 200 — почти 3 000 ₽. Не катастрофа, но если бюджет утверждён по заниженной цифре, приходится идти за дополнением — а это всегда неприятный разговор.

Второй способ ошибиться — считать комиссию как вычет из ставки. Если 15 % удерживается с автора сверху, то за один отчёт автор тратит 113,85 ₽. Это цена результата, и планировать нужно от неё.

Держите эту таблицу под рукой: 90 % планирования сводится к выбору строки.

Обратный расчёт: сколько тестов на заданный бюджет

Чаще бюджет приходит сверху: «есть 15 000 ₽, уложись». Тогда формула переворачивается:

> N = Бюджет ÷ (Ставка × 1,15) = Бюджет ÷ 113,85

Зачем резерв 10 %? Не на комиссию — она уже учтена. Резерв нужен на две реальные вещи: бонусы за особо ценные находки, если вы их объявили, и добор нескольких прохождений, если часть отчётов пришлось отклонить и покрытие устройств получилось неполным.

Почему нельзя тратить весь бюджет на одну волну

Ключевая ошибка планирования: Денис берёт 15 000 ₽ и заказывает 118 прохождений сразу.

Что произойдёт: он получит 118 отчётов, в которых первые 20 расскажут про блокирующую проблему онбординга, а остальные 98 расскажут про ту же проблему. Потому что все тестировали одну и ту же версию сборки. Он заплатил 11 000 ₽ за подтверждение того, что уже знал после первых 2 000 ₽.

Правильная структура — волны с правками между ними.

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

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

Сравнение с альтернативными способами получить обратную связь

Денису на встрече неизбежно возразят: «а если дешевле по-другому?» Разберём варианты честно.

Важно: это не конкуренты, а инструменты для разных задач. QA-инженер нужен для системного покрытия и регрессии. Глубинные интервью нужны для понимания мотивации. Честные тесты закрывают конкретную нишу: много разных людей и устройств проходят конкретный сценарий и пишут, что произошло. Дешёвый способ получить широту и первую реакцию.

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

Стоимость одной находки: главная метрика для защиты бюджета

На встрече с основателем сильнее всего работает не «сколько стоит», а «сколько стоит одна найденная проблема».

Возьмём волну на 40 прохождений за 4 554 ₽. Типичный результат: 34 принятых отчёта, из них содержательных 22, найдено 6 отдельных проблем (после группировки по причинам), из которых 2 блокирующие.

• Стоимость одной найденной проблемы: 4 554 ÷ 6 = 759 ₽
• Стоимость одной блокирующей проблемы: 4 554 ÷ 2 = 2 277 ₽

Теперь оцените обратную сторону. Блокирующая проблема онбординга, из-за которой треть новых пользователей не доходит до первого действия. Если вы позже потратите на рекламу 50 000 ₽ при CPI 30 ₽, это 1 666 установок, из которых треть — 555 человек — уйдут из-за этой проблемы. Потерянный бюджет: 16 650 ₽ за одну кампанию.

То есть 2 277 ₽ на обнаружение проблемы предотвращают потерю 16 650 ₽ только в одной рекламной кампании. Дальше эффект накапливается на каждой следующей.

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

Три готовых сценария бюджета

Сценарий А: инди-разработчик, бюджет 5 000 ₽

Задача — найти блокеры перед первым релизом. Всё в одну волну нельзя, но и дробить на четыре части при таком бюджете бессмысленно.

Итого 5 000 ₽. Ожидаемый результат: 3–5 существенных проблем входа найдены и проверены после исправления.

Сценарий Б: команда перед платным привлечением, бюджет 15 000 ₽

Задача — довести продукт до состояния, когда можно тратить на рекламу.

Итого 15 000 ₽, 115 прохождений. Это та структура, которую Денис понесёт на встречу.

Сценарий В: студия с несколькими продуктами, 40 000 ₽ в квартал

Задача — регулярный процесс, а не разовая акция.

Итого 40 000 ₽, 265 прохождений за квартал. Заметьте крупный резерв: при регулярном процессе всегда возникают внеплановые проверки после срочных хотфиксов.

Как считать возврат от вложений в тестирование

Прямой ROI посчитать сложно, потому что вы измеряете предотвращённые потери. Но есть три подхода, каждый защитим цифрами.

Подход 1: через сохранённый рекламный бюджет.

Формула: Экономия = Планируемый бюджет UA × Доля потерь из-за найденных проблем

Если вы собираетесь тратить 50 000 ₽ в месяц, а тесты показали, что 28 % новых пользователей не проходят онбординг из-за исправимых причин, то экономия 14 000 ₽ в месяц против разовых 5 693 ₽ на тестирование.

Подход 2: через конверсию в ключевое действие.

Считайте до и после. Если конверсия в первый заказ выросла с 8,7 % до 16,1 %, а LTV клиента 800 ₽, то на 1 000 установок вы получаете дополнительно 74 клиента и 59 200 ₽ выручки. Вложено — 13 000 ₽.

Подход 3: через стоимость исправления на поздней стадии.

Проблема, найденная до релиза, стоит часа работы разработчика. Та же проблема, обнаруженная через два месяца по низкому рейтингу, стоит: срочный хотфикс + релиз вне плана + работа поддержки + восстановление рейтинга. Разница на порядок.

Чего в бюджете обычно забывают

Время на модерацию. 50 отчётов при чек-листе из 5 шагов — это 3–4 часа работы продакта или разработчика. При ставке специалиста 2 000 ₽/час это ещё 6 000–8 000 ₽ внутренних издержек. Формально их не платят на платформе, но при планировании нужно закладывать.

Время на исправления между волнами. Волна 2 бессмысленна, если правки из волны 1 не внесены. Планируйте 3–7 дней между волнами, иначе вы просто повторно покупаете те же находки.

Подготовку сборок. TestFlight-сборка, трек тестирования, тестовые аккаунты, sandbox для платежей — это работа, которую нужно сделать до кампании.

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

Добор прохождений. Если из 40 отчётов отклонили 8, а вам нужно покрытие по устройствам, придётся добрать 8–10. Это ещё 1 000 ₽.

Итоговая честная формула для планирования:

> Полный бюджет волны = Ставка × N × 1,15 + Резерв 10 % + Внутренние часы на модерацию

FAQ

Комиссия 15 % — это много или мало?

Сравнивайте не с нулём, а с альтернативой: самостоятельно найти 50 подходящих людей, договориться, проверить работу, разрулить споры и провести выплаты. Комиссия покрывает инфраструктуру процесса. В расчёте это 14,85 ₽ на отчёт — меньше стоимости одной чашки кофе за организацию работы одного человека.

Можно ли ставить ставку выше 99 ₽?

Обычно да, и это оправдано для сложных сценариев: длинный чек-лист, запись экрана, редкое устройство, узкая аудитория. Повышенная ставка ускоряет набор исполнителей и повышает качество отчётов. Считайте так же: Ставка × N × 1,15.

А если снизить ставку, чтобы взять больше прохождений?

Рискованно. Вы получите отчёты от людей, для которых экономически рационально минимальное усилие. Лучше меньше прохождений по нормальной ставке, чем много поверхностных.

Сколько всего стоит подготовка к платному привлечению?

В сценарии Б — около 15 000 ₽ на платформе плюс 10–15 часов внутренней работы. По сравнению с 50 000 ₽ месячного рекламного бюджета это 30 % от одного месяца рекламы — и эти 30 % защищают все последующие месяцы.

Как объяснить основателю, что тесты не дают роста метрик?

Они не дают роста напрямую — они убирают причины, по которым рост не происходит. Формулировка для встречи: «это не канал привлечения, это снижение потерь в воронке; вот три проблемы, вот сколько людей на них теряется, вот сколько это стоит в рекламном бюджете».

Что если бюджет совсем нулевой?

Начните с 10–15 прохождений (1 138–1 708 ₽). Этого хватит, чтобы найти блокеры входа. Это меньше, чем стоимость одного дня слабой рекламной кампании.

Итоги

• Базовая формула: Ставка × N × 1,15. За один принятый отчёт при ставке 99 ₽ автор тратит 113,85 ₽.
• Обратный расчёт: N = Бюджет ÷ 113,85, минус 10 % резерв на бонусы и добор.
• Нельзя тратить весь бюджет на одну волну: после первых 20–30 отчётов по одной сборке новизна находок резко падает.
• Правильная структура — 3–4 волны с исправлениями между ними; между волнами нужно 3–7 дней на правки.
• Главная метрика для защиты бюджета — стоимость одной найденной проблемы, а не стоимость прохождения.
• В планирование нужно включать внутренние часы на модерацию: 50 отчётов — это 3–4 часа работы.
• Проблема, найденная до релиза, стоит на порядок дешевле той же проблемы, найденной через квартал по падению рейтинга.

Заключение

Денис пришёл на встречу с одной таблицей: четыре волны, 115 прохождений, 13 093 ₽ на платформе, 1 907 ₽ резерв, итого 15 000 ₽. Рядом — вторая строка: планируемый рекламный бюджет 50 000 ₽ в месяц и оценка потерь 28 % на онбординге, то есть 14 000 ₽ ежемесячно.

Разговор занял четыре минуты. Не потому, что Денис хорошо убеждал, а потому что цифры были посчитаны до встречи и в них была учтена комиссия.