Почему мобильное приложение не приносит деньги, даже если реклама работает. 5 ошибок
Автор статьи: Юлия Мицкевич, операционный директор KODE.
Эта ситуация довольно типичная. Маркетинг запускает рекламу, получает установки и отчитывается по стоимости привлечения. Продуктовая команда в это время выпускает новые функции, исправляет баги и спорит о том, какой экран переделывать следующим.
Все заняты делом, показатели у каждого свои. Но продажи почему-то не растут.
Пользователь может увидеть рекламу, установить приложение и потеряться уже через несколько минут. Не понять, зачем нужна регистрация. Не найти нужный товар. Столкнуться с ошибкой при оплате. Или просто решить, что разбираться слишком долго, и закрыть приложение.
Вернуть его будет сложно. По данным Mediascope за август 2025 года, на смартфоне российского пользователя в среднем установлено около 120 приложений, но хотя бы раз в месяц открываются только 50. Остальные просто лежат на устройстве.
С удержанием ситуация тоже не особенно радостная. Adjust приводит такие средние показатели: на следующий день после установки возвращаются около 26% пользователей, через неделю примерно 11–13%, а через месяц — 6,5%. Цифры сильно зависят от категории продукта, но общий смысл понятен: сам факт установки почти ничего не гарантирует.
При этом бизнес продолжает много тратить на привлечение. По оценке AppsFlyer, в 2025 году мировые расходы на рекламу, направленную на установки приложений, достигли $78 млрд и выросли на 13% за год. Еще $31 млрд ушел на возвращение тех, кто уже пользовался продуктом.
Приводить людей становится все дороже, но многие компании по-прежнему пытаются решить проблемы продукта дополнительным трафиком.
Ошибка № 1. Сначала выбрать Flutter, а потом думать, что разрабатывать
Обсуждение нового приложения часто начинается примерно так:
— А на Flutter будет дешевле?
— Может, сразу делать нативно?
— А PWA нам подойдет?
Вопросы нормальные, но задаются они слишком рано.
Технология сама по себе не делает продукт прибыльным. Она влияет на скорость разработки, возможности приложения, стоимость поддержки и количество специалистов, которые потребуются в дальнейшем, но выбирать ее нужно под задачу, а не наоборот.
Если компания хочет быстро проверить спрос на новую услугу, ей может быть достаточно кроссплатформенного приложения, мобильной версии сайта или даже прототипа, на котором можно протестировать основной сценарий.
Другая ситуация, когда приложение становится важным каналом продаж, работает с платежами, камерой, геолокацией, Bluetooth, биометрией или сложными внутренними системами. Здесь попытка сэкономить на первой версии может закончиться тем, что через год продукт придется переделывать почти с нуля.
Есть хороший кейс Kijiji, канадской платформы объявлений.
У Kijiji уже были отдельные приложения под iOS и Android. Они развивались несколько лет, кодовая база росла, а выпуск одной и той же функции на двух платформах занимал все больше времени. Компания перешла на Flutter не потому, что это модная или дешевая технология, а потому, что ей нужно было решить конкретную проблему: синхронизировать развитие двух приложений и разобраться с накопленным техническим долгом.
В результате основной функционал пересобрали за девять месяцев, время выпуска крупных функций сократилось вдвое, а кодовую базу Android-приложения удалось уменьшить с более чем 2,5 млн до примерно 900 тыс. строк.
Но у другого бизнеса Flutter может вообще не дать такого эффекта. Например, если продукт сильно зависит от нативных функций устройства или компания уже собрала опытные команды под iOS и Android.
Поэтому первый вопрос должен звучать не «на чем писать приложение», а «что оно должно изменить в бизнесе».
Увеличить число повторных покупок? Снизить нагрузку на кол-центр? Перевести часть клиентов в самообслуживание? Запустить новый источник выручки? Проверить спрос на услугу?
Пока этого ответа нет, сравнивать стоимость технологий почти бессмысленно.
Ошибка № 2. Считать, что после релиза основная работа закончена
Запуск приложения часто воспринимают как финиш. Команда несколько месяцев готовится, проходит модерацию, публикует продукт в магазине и наконец выдыхает.
Выдыхать, конечно, можно. Но ненадолго.
До релиза у команды есть гипотезы о том, как люди будут пользоваться продуктом. После релиза появляются данные о том, как они пользуются им на самом деле. И эти две картины редко полностью совпадают.
Функция, которую внутри компании считали главной, может оказаться никому не нужной. Пользователи могут бросать регистрацию на шаге, который всем казался простым. Или применять продукт совсем не так, как представляли аналитики и дизайнеры.
Иногда заметный результат дает очень небольшое изменение.
Во всем известном Duolingo, например, серия ежедневных занятий раньше была связана с личной целью пользователя. Если человек ставил себе амбициозный план и не выполнял его полностью, серия прерывалась. Команда решила упростить правило: для продолжения серии стало достаточно пройти один урок.
Это не редизайн приложения и не новая большая функция. Просто убрали лишнее препятствие.
В эксперименте удержание на четырнадцатый день выросло на 3,3%, число ежедневно активных пользователей — на 1%, а доля пользователей с непрерывной серией занятий — на 10,5%. Duolingo отдельно уточняет, что это относительные изменения.
То есть продукт вырос не потому, что в него добавили что-то сложное. Команда заметила, где пользователь спотыкается, проверила гипотезу и немного упростила механику.
Так обычно и развивается нормальный цифровой продукт. Не по принципу «раз в год соберем список пожеланий и выпустим большое обновление», а через постоянную работу с поведением пользователей.
Поэтому MVP тоже не стоит понимать как дешевую версию большого приложения, в которую попытались запихнуть все экраны, но сделали их похуже. Первая версия нужна, чтобы проверить один или несколько важных вопросов.
Станут ли клиенты вообще пользоваться мобильным каналом? Готовы ли они оформлять заказ самостоятельно? Нужна ли им персонализация? Вернутся ли они после первого действия?
Срок здесь не может быть универсальным. Иногда гипотезу действительно можно проверить за два месяца. Иногда одна интеграция с корпоративной системой занимает дольше, чем разработка всего интерфейса.
Ошибка № 3. Маркетинг считает установки, а продукт живет своей жизнью
На уровне отчетов все может выглядеть неплохо. Реклама дает клики. Стоимость установки укладывается в план. Количество новых пользователей растет.
Но потом выясняется, что половина из них не закончила регистрацию, еще часть не совершила целевое действие, а до покупки добрались единицы.
Проблема в том, что установка находится примерно в середине пути, а не в конце.
Маркетинговая и продуктовая аналитика должны соединяться в одну цепочку:
реклама → установка → регистрация → первое полезное действие → покупка → повторное использование.
Иначе компания оптимизирует не бизнес, а отдельные красивые цифры.
Показательный российский пример — кампания приложения «Финуслуги» в RuStore. Команда смотрела не только на данные рекламной площадки. Информацию об установках и регистрациях дополняли данными AppMetrica и внутренней CRM, где уже были видны реальные продажи.
Бюджет увеличивали только после того, как формат набирал достаточно целевых событий. Во второй половине 2025 года расходы на кампанию выросли примерно в пять раз. При этом к четвертому кварталу количество целевых действий увеличилось в шесть раз по сравнению со вторым кварталом, а их средняя стоимость оказалась вдвое ниже установленного KPI. Это данные самого опубликованного кейса, поэтому воспринимать их стоит именно как результат конкретной кампании, а не как универсальный прогноз для любого приложения.
Здесь важно не то, что реклама в RuStore всегда дает такой результат. Важно, что команда не масштабировала канал вслепую. Она видела, что происходит с человеком после установки.
До увеличения рекламного бюджета стоит хотя бы проверить:
Где люди чаще всего уходят?
Сколько времени занимает регистрация?
Все ли понимают, что делать на первом экране?
Есть ли различия между пользователями из разных рекламных каналов?
Кто из них возвращается и приносит деньги, а кто просто увеличивает количество установок?
Иногда после такого анализа выясняется неприятная вещь: больше трафика приложению пока не нужно. Сначала нужно починить авторизацию или убрать три поля из формы заказа.
Ошибка № 4. Вспоминать о качестве за неделю до публикации
Перед релизом команда обычно проводит тестирование. Исправляет критичные баги, проверяет основные сценарии и убеждается, что приложение хотя бы не падает сразу после запуска.
Это необходимый минимум. Но качество продукта не сводится к отсутствию явных ошибок.
Приложение может работать технически корректно и все равно раздражать. Медленно открываться. Подвисать на старых устройствах. Не объяснять ошибку оплаты. Заставлять пользователя несколько раз вводить одни и те же данные.
Особенно хорошо это видно в e-commerce. Baymard изучает поведение пользователей интернет-магазинов, поэтому его данные относятся не только к приложениям, но проблема для мобильных продуктов та же. По результатам исследования, 17% американских покупателей бросали заказ из-за слишком длинного или сложного оформления. Столько же уходили из-за ошибок и сбоев.
Пользователь не разделяет UX, разработку и тестирование. Для него это один опыт. Если кнопка не работает, форма непонятна или экран грузится десять секунд, виноватым будет все приложение.
Иногда для улучшения не требуется большая переработка. В 2026 году Android Developers опубликовал кейс британского банка Monzo. Команда полностью включила оптимизацию R8 в Android-приложении. После этого количество случаев, когда приложение переставало отвечать, снизилось на 35%, надежность холодного запуска улучшилась на 30%, а размер приложения уменьшился на 9%.
Большой продуктовый эффект может скрываться в настройке, которую долго никто не трогал. А может, наоборот, потребовать пересмотра архитектуры целого сервиса. Поэтому аудит приложения полезен не только тогда, когда все уже сломалось.
Технический аудит нужен, когда приложение стало медленным, команда боится вносить изменения или стоимость каждой новой функции растет без понятной причины.
UX-аудит помогает найти места, где пользователю приходится слишком долго думать, возвращаться назад или повторять действия.
Проверка безопасности особенно важна для продуктов, которые работают с платежами, документами, медицинскими или персональными данными.
Это не обязательно проводить каждый месяц. Но проверять качество только перед релизом новой версии тоже поздно.
Ошибка № 5. Ждать от приложения только прямых продаж
Приложение не всегда должно само по себе продавать товар или подписку. Иногда оно зарабатывает для бизнеса менее очевидным способом.
Возьмем приложение клиники. Через него пациент записывается на прием, получает результаты анализов и переносит визит без звонка администратору. Часть пользы здесь можно увидеть в оплатах. Но еще приложение снижает нагрузку на кол-центр, уменьшает количество пропущенных визитов и помогает вернуть пациента.
Или приложение ритейлера. Оно может давать доступ к программе лояльности, истории покупок, персональным предложениям и быстрому повторному заказу. В этом случае важна не только выручка внутри приложения. Нужно смотреть, как меняется частота покупок, средний чек и удержание клиента во всех каналах.
Есть и внутренние корпоративные продукты, где прямых продаж вообще нет. Их эффект измеряется тем, сколько времени сотрудники перестали тратить на ручные операции, сколько ошибок удалось убрать и насколько быстрее стал процесс.
Поэтому перед разработкой важно договориться, где именно бизнес ожидает результат.
Иначе через год приложение могут признать неэффективным просто потому, что оценивали его не по тем показателям.
Что нужно понять до начала разработки
Необязательно сразу писать подробное техническое задание на сотни страниц. Для начала достаточно честно ответить на несколько вопросов.
Что сейчас происходит без приложения? Какую проблему оно решит лучше сайта, чат-бота или существующей внутренней системы? Кто будет им пользоваться и как часто? Какое действие пользователя будет считаться успехом? И что компания собирается делать с продуктом после первого релиза?
Последний вопрос особенно важен. Приложение придется поддерживать. Обновлять под новые версии операционных систем. Исправлять ошибки. Развивать аналитику. Добавлять функции и иногда удалять те, которыми никто не пользуется.
Поэтому стоимость запуска не равна стоимости продукта.
Иногда самый разумный первый шаг — вообще не заказывать разработку мобильного приложения, а проверить идею на прототипе. Иногда достаточно доработать мобильную версию сайта. А иногда приложение уже стало настолько важной частью бизнеса, что экономить на архитектуре и исследованиях опаснее, чем вложиться в них сразу.
Часто разумнее начать с аудита: посмотреть аналитику, пройти основные сценарии, проверить производительность и понять, где именно бизнес теряет пользователей и деньги.
После этого хотя бы становится ясно, что нужно исправлять. А главное, что пока можно не трогать.
Мобильный продукт начинает приносить пользу, когда команда понимает, какую задачу он решает, видит весь путь пользователя и продолжает работать после релиза.
______________________________________________
KODE — № 1 в мобильной разработке по версии всех рейтингов России.