Как оценить окупаемость мобильного приложения до начала разработки

08.10.2026 19 мин чтения

---

Расчёт окупаемости мобильного приложения опирается на пять величин, которые у торговой компании обычно уже есть: средний чек, доля валовой прибыли в чеке, число активных покупателей, частота повторных заказов и расходы на привлечение покупателя. Формулы при этом простые — сложность в том, что до старта разработки часть величин приходится брать как допущение. Разбираем, какие показатели запросить у бизнеса, как собрать модель затрат и доходов и как проверить её тремя сценариями чувствительности.

Что показывает расчёт окупаемости приложения

Расчёт окупаемости отвечает на один вопрос: за какой срок дополнительная валовая прибыль от мобильного канала перекроет затраты на его создание и содержание. Главное слово здесь — «дополнительная». Заказы, которые покупатель и так сделал бы на сайте, в расчёт не идут: они лишь переезжают из одного канала в другой и не создают нового дохода.

Отсюда следует практическое ограничение жанра. Модель до старта разработки показывает не прибыль, а условия, при которых она появляется: какой прирост частоты заказов и какая доля валовой прибыли в чеке нужны, чтобы вложение вернулось за понятный срок. Если нужный прирост выглядит недостижимым на текущей базе покупателей, это сигнал пересобрать объём первой версии, а не отказываться от расчёта.

Второе ограничение — горизонт. Разработка оплачивается один раз, а работает несколько лет, поэтому отрицательный результат первого года сам по себе ещё ничего не означает. Рабочий горизонт расчёта — два-три года с отдельной строкой затрат на каждый год.

Какие показатели запросить у бизнеса до начала расчёта

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

Показатели для расчёта окупаемости и их источники в компании

Данные из системы учёта и аналитики

Четыре показателя — активные покупатели, частота заказов, средний чек и доля повторных покупателей — выгружают за полные 12 месяцев, а не за квартал. Годовой период сглаживает сезонность: в категориях с выраженным сезоном квартальная выгрузка заметно завышает или занижает частоту.

Данные из финансового блока

Доля валовой прибыли в чеке (её же называют маржинальностью) — это разница между ценой и себестоимостью товара, отнесённая к цене. Её запрашивают отдельно по категориям: в ассортименте с разной наценкой средняя по компании величина даёт заметную ошибку. Если приложение целится в конкретные категории, в расчёт идёт их доля прибыли, а не общая по магазину.

Величины, которых в данных нет

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

Модель затрат: из чего складывается первый год владения

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

Разовые затраты на запуск

В эту группу входят работы и платежи, которые проходят один раз до релиза:

• Техническое задание и проектирование. Описание сценариев, состава функций и требований к интеграциям.
• UX/UI-дизайн. Макеты ключевых экранов и дизайн-система под бренд.
• Разработка приложения. Клиентская часть под iOS и Android, серверная часть, интеграции с учётной системой, оплатой и доставкой.
• Тестирование и подготовка к публикации. Проверка сценариев на реальных устройствах, материалы для модерации в сторах.
• Регистрационные взносы в программы разработчика. Разовый и ежегодный платежи за аккаунты в сторах — величина небольшая, но в смете она должна быть названа.

Регулярные затраты первого года

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

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

Стоимость поддержки и развития после запуска

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

Поддержка и развитие: разделение бюджетов

Разделение двух бюджетов снимает большую часть споров с финансовым блоком:

• Поддержка. Обновления под новые версии iOS и Android, продление аккаунтов разработчика, серверная инфраструктура, исправления после обновлений внешних сервисов, сопровождение интеграций.
• Развитие. Новые сценарии, новые разделы, доработки под маркетинговые механики. Это инвестиция следующего периода, и в расчёт окупаемости первой версии она не входит.

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

Расчёт бюджета поддержки в модели

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

Доходная часть: повторные заказы и маржинальность

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

Прирост частоты повторных заказов

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

В модель прирост заходит одной величиной — дополнительные заказы на одного покупателя за год. Задавать её лучше в абсолютных единицах, а не в процентах: «плюс 0,5 заказа в год» проверяемо, «плюс 25% к удержанию» требует уточнения, к чему именно эти проценты. Как устроены механики возвратов в мобильном канале, разобрано в материалах об удержании клиентов и программах лояльности и о метриках геймификации в e-commerce.

Валовая прибыль как единица измерения эффекта

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

Отдельная строка дохода — рост доли успешно оплаченных заказов. Сохранённые платёжные данные и оплата в один шаг уменьшают долю брошенных корзин на этапе оплаты; механика описана в разборе встроенного платёжного чекаута. В базовую модель этот эффект можно не включать — он работает как запас прочности расчёта.

Условные исходные данные для примера расчёта

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

Условные исходные данные примера. Фактические данные берут из собственной аналитики

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

Формулы расчёта: пять шагов

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

Шаг 1. Дополнительные заказы за год

Дополнительные заказы = покупатели в приложении × прирост заказов на покупателя. На базовых допущениях: 12 000 × 0,50 = 6 000 дополнительных заказов за год.

Шаг 2. Валовая прибыль с одного заказа

Валовая прибыль с заказа = средний чек × доля валовой прибыли в чеке. На базовых допущениях: 4 500 ₽ × 24% = 1 080 ₽. Если доля возвратов в категории заметная, эту величину дополнительно уменьшают на долю возвратов.

Шаг 3. Дополнительная валовая прибыль за год

Дополнительная валовая прибыль = дополнительные заказы × валовая прибыль с заказа. На базовых допущениях: 6 000 × 1 080 ₽ = 6 480 000 ₽ за год.

Шаг 4. Затраты первого года

Затраты первого года = разработка + поддержка за год + привлечение установок за год. На базовых допущениях: 3 000 000 ₽ + 600 000 ₽ + 1 000 000 ₽ = 4 600 000 ₽. Поддержка посчитана как 20% от стоимости разработки.

Шаг 5. Возврат вложений и срок окупаемости

Возврат вложений за первый год = (дополнительная валовая прибыль − затраты первого года) ÷ затраты первого года × 100. На базовых допущениях: (6 480 000 − 4 600 000) ÷ 4 600 000 × 100 = +41%.

Срок окупаемости в месяцах = стоимость разработки ÷ ((дополнительная валовая прибыль − поддержка − привлечение) ÷ 12). На базовых допущениях: 3 000 000 ÷ ((6 480 000 − 600 000 − 1 000 000) ÷ 12) = 3 000 000 ÷ 406 667 = 7,4 месяца.

Три сценария чувствительности

Одна цифра окупаемости до старта разработки вводит в заблуждение: она скрывает, насколько результат зависит от допущений. Поэтому расчёт прогоняют трижды, меняя четыре самые неопределённые величины: прирост частоты заказов, долю валовой прибыли в чеке, бюджет поддержки и бюджет привлечения установок. Стоимость разработки и средний чек во всех трёх сценариях одинаковы — 3,00 млн ₽ и 4 500 ₽.

Расчёт по трём сценариям на условных данных примера

Разброс в результатах — главный вывод этого раздела. При одной и той же стоимости разработки срок окупаемости меняется от 3,6 месяца до 48 месяцев, то есть более чем в тринадцать раз. При этом ни один из трёх наборов допущений не выглядит фантастическим: прирост 0,25 заказа в год и доля прибыли 20% — осторожная, но достижимая комбинация.

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

Критерии решения по результатам расчёта

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

Результат расчёта и подходящий формат старта

Расчёт, который упирается в качество данных

Частый случай: модель не сходится не потому, что канал не работает, а потому что прирост частоты заказов задан наугад и завышать его не хочется. Здесь помогает прогноз поведения покупателей на существующих данных — подход описан в материале о предиктивной аналитике в e-commerce. Сегментация базы по частоте покупок уже даёт более обоснованную величину, чем оценка «по ощущению».

Способы сократить срок окупаемости

Две управляемые величины в расчёте — стоимость разработки и объём первой версии. Сокращение набора сценариев до одной измеримой задачи — подход разработки MVP, который уменьшает и смету, и срок окупаемости одновременно. Какой минимальный состав функций при этом остаётся рабочим, видно на примере архитектуры и функций приложения розничной сети. Выбор технологической основы влияет на обе величины: единая кодовая база под iOS и Android снижает затраты и на разработку, и на последующую поддержку. Разбор этого выбора на примере небольшого формата — в материале о мобильном приложении для кофейни и выборе платформы.

Ограничения модели и частые ошибки расчёта

Модель из пяти шагов закрывает финансовую сторону решения и не закрывает всё остальное. Границы применимости стоит назвать прямо.

Границы применимости модели

• Эффект на удержание в деньгах за пределами горизонта. Покупатель с установленным приложением остаётся в базе дольше, и на трёхлетнем горизонте это видно слабо.
• Стоимость отсутствия канала. Если конкуренты в категории уже работают в мобильном канале, часть повторных покупок уходит к ним, и эта потеря в модели не отражается.
• Операционную нагрузку на команду. Приложению нужны контент, товарные данные и обработка обращений — это рабочее время сотрудников магазина. Часть нагрузки снимает встроенная в продукт поддержка клиентов.
• Неравномерность эффекта по категориям. В ассортименте с разной частотой покупок прирост распределяется неравномерно, средняя величина это скрывает.

Пять ошибок, которые ломают расчёт

• Считать эффект в выручке. Завышает результат на величину себестоимости товара — в торговле это основная часть чека.
• Записывать в эффект перенесённые заказы. Покупка, которая раньше шла через сайт, нового дохода не создаёт.
• Пропускать затраты на привлечение установок. Самая частая пропущенная строка, и она сопоставима с бюджетом поддержки.
• Занижать поддержку. Без обновлений приложение теряет работоспособность на новых версиях операционных систем, поэтому эта строка не опциональна.
• Считать один сценарий вместо трёх. Единственная цифра выглядит убедительно и не показывает, насколько она хрупкая.

Итог: окупаемость приложения на одной странице

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

Порядок работы с моделью:

1. Запросить девять показателей из учёта, аналитики и финансового блока за полные 12 месяцев.
2. Собрать модель затрат отдельно по разовым и регулярным строкам, не пропуская привлечение установок.
3. Перевести эффект в валовую прибыль с заказа и задать прирост частоты в абсолютных единицах.
4. Прогнать расчёт по трём сценариям, вынеся все допущения в отдельный блок.
5. Принять решение по пессимистичному сценарию и выбрать объём первой версии под полученный срок.

Дальше имеет смысл проверить модель вместе с командой разработки: смета, объём первой версии и перечень интеграций уточняют две самые весомые строки расчёта — стоимость запуска и бюджет поддержки. Уточнить требования и границы первой версии помогает бизнес-аналитика для IT-проектов FITTIN.

Материал носит информационно-аналитический характер. Все числовые значения в примерах — условные и приведены для демонстрации механики расчёта.