Клиент не может скачать ваше приложение: что делать бизнесу

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

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

Мобильные приложения удаляют — и дело не только в санкциях

При этом платформы усиливают контроль не только над своими магазинами, но и над распространением приложений за их пределами. Google вводит обязательную верификацию разработчиков Android: с 30 сентября 2026 года новые требования начнут действовать в ряде магазинов в Бразилии, Индонезии, Сингапуре и Таиланде, а с 2027 года компания планирует распространить систему глобально на приложения для сертифицированных Android‑устройств. Для бизнеса это важный сдвиг: правила Google начинают определять условия установки приложения даже тогда, когда оно распространяется не через Google Play.

Установка приложений от непроверенных разработчиков формально сохранится, но станет заметно сложнее. Пользователю придется включить специальный advanced flow, пройти дополнительные предупреждения и дождаться окончания 24‑часового защитного периода. То есть даже прямое распространение APK уже нельзя считать полностью независимым каналом: возможность доставить приложение до клиента все сильнее зависит от правил самой мобильной платформы.

Почему банки сделали ставку на веб

Российские банки столкнулись с этой проблемой раньше остальных: весной 2022 года из App Store и Google Play исчезли приложения двух десятков крупнейших игроков финансового рынка. Для индустрии это стало серьезным ударом, поскольку мобильное приложение к тому моменту стало привычным способом управлять счетами, переводить деньги и получать ежедневные банковские услуги.

Банки поначалу пытались сохранить привычный мобильный формат, выпуская в App Store приложения с тем же функционалом. Но такие решения оказывались недолговечными: новые версии тоже удаляли, иногда сразу же после публикации. Поэтому постепенно акцент сместился на веб‑сервисы — канал, который не зависит от присутствия приложения в магазине.

Фактически в браузер нужно было перенести все сценарии, которые к тому моменту уже стали привычной частью мобильного банкинга: онбординг новых клиентов, оплату по QR‑коду, считывание реквизитов с платежных документов, номеров телефонов и банковских карт. Именно работа с камерой и автоматическим вводом данных долгое время заметно отличала мобильное приложение от классического интернет‑банка. Поэтому развитие веб‑сервисов потребовало переноса в браузер не только определенного круга привычных услуг и сервисов, но и технологий компьютерного зрения и распознавания, благодаря которым они могли бы быть реализованы.

Именно работа с камерой и автоматическим вводом данных долгое время заметно отличала мобильное приложение от классического интернет‑банка

Этого удалось достичь благодаря сочетанию двух факторов. Сами алгоритмы компьютерного зрения были достаточно компактными и производительными, чтобы выполнять полный цикл распознавания непосредственно на устройстве пользователя: находить документ в кадре, оценивать качество изображения, локализовать поля и извлекать данные. А WebAssembly позволил перенести это алгоритмическое ядро в браузер: нативный код компилируется в WASM‑модуль и запускается внутри веб‑страницы.

В результате веб‑версии банков получили привычный функционал мобильных приложений: онбординг по паспорту, оплату по QR‑коду, считывание реквизитов и другие сценарии с камерой. Для клиента переход в браузер перестал означать заметный компромисс в удобстве, а для банка веб стал полноценным каналом обслуживания, не зависящим от присутствия приложения в магазине.

Что бизнесу стоит переносить в веб в первую очередь

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

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

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

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

Приложение остается — зависимость от него снижается

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

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