За последние несколько лет в лексиконе банковских продуктовых команд прочно закрепилась аббревиатура PWA. То, что еще недавно обсуждалось как веб-эксперимент на периферии мобильной разработки, превратилось в полноценный канал обслуживания клиентов – с миллионами пользователей, собственными релизными циклами и отдельной строкой в бюджете.
В российском банкинге этот переход заметнее, чем на большинстве других рынков: у крупнейших игроков прогрессивные веб-приложения сегодня работают наравне с нативными, а средний сегмент постепенно повторяет этот путь.
Разберемся, что такое PWA на самом деле, зачем банки в него вкладываются, с какими сложностями сталкиваются и действительно ли необходимо внедрять эту технологию.
Что такое PWA и чем оно отличается от обычного приложения
Progressive Web Application – это веб-приложение, которое ведет себя как обычное приложение на смартфоне. Пользователь заходит на сайт банка, соглашается «добавить на главный экран» – и получает иконку рядом со всеми остальными приложениями. При запуске оно открывается на весь экран, без адресной строки и браузерных кнопок, работает даже при плохом соединении и присылает push-уведомления. Внешне отличить его от нативного приложения довольно сложно.
Технически это все еще веб: код исполняется браузерным движком, а не устанавливается в систему как отдельная программа.
Отличия PWA от обычного сайта:
-
Установка на главный экран. Обычный мобильный сайт в лучшем случае остается закладкой в браузере, тогда как PWA ставится иконкой на главный экран и запускается в отдельном окне.
-
Работа без сети. Сайт при потере соединения просто не открывается, а PWA сохраняет доступ к базовым экранам за счет локального кэша.
-
Уведомления. У сайта их нет вовсе, а PWA присылает push-уведомления о списаниях, платежах и событиях по счету.
Отличия PWA от нативного приложения:
-
Прямая дистрибуция. Нативное приложение попадает к клиенту только через App Store и Google Play и проходит ревью при каждом обновлении, а PWA устанавливается прямо с сайта банка и обновляется на стороне сервера.
-
Упрощенная кодовая база. Для натива нужны отдельные сборки под iOS и Android, тогда как PWA живет на одном коде для всех платформ.
-
Ограниченный доступ к устройству. Нативное приложение получает полный доступ к системным возможностям смартфона, а PWA ограничен тем, что разрешает браузер.
Отдельно стоит снять частое возражение: биометрический вход в PWA возможен. Современные браузеры поддерживают стандарты аутентификации, которые опираются на Face ID и сканер отпечатка – клиент может войти в веб-приложение так же, как в нативное, без ввода пароля.
Зачем банкам PWA
Независимость от магазинов приложений
Весной 2022 года приложения российских финансовых организаций начали массово удалять из App Store и Google Play: 11 апреля Apple убрал со своей платформы «Сбербанк Онлайн», за ним последовали приложения ВТБ, Альфа-банка, ПСБ, «Открытия», Т-Банка и десятков банков поменьше.
Ситуация оказалась принципиально разной для двух платформ. Android допускает установку приложений из сторонних источников – банки быстро развернули раздачу APK-файлов со своих сайтов. На iOS такой возможности нет: удаленное из App Store приложение невозможно ни установить заново, ни обновить, а после смены устройства или сброса настроек клиент теряет его безвозвратно. Именно PWA стал для этой аудитории основным решением – Сбер адаптировал веб-версию «Сбербанк Онлайна» под мобильные устройства по технологии прогрессивного веб-приложения, и по этому же пути пошли остальные.
Вывод, который сделал рынок: канал доступа к клиенту, который контролирует третья сторона, – это операционный риск, и закрывать его нужно заранее.
Скорость поставки
Нативный релиз проходит через ревью магазина: от нескольких часов до нескольких дней, иногда с отклонением и повторной подачей. Дальше начинается вторая проблема – часть пользователей не обновляются месяцами, и банк вынужден поддерживать совместимость со старыми версиями клиента.
В PWA этого слоя нет вовсе. Правка выкатывается на сервер и доезжает до всех пользователей при следующем запуске. Для исправления критичного дефекта в платежном сценарии разница между «часы» и «дни» – это разница в объеме ущерба.
Низкий порог входа для клиента
Нативное банковское приложение – это в среднем сотни мегабайт. На бюджетном Android с забитой памятью установка превращается в квест: удалить фотографии, освободить место, дождаться загрузки по нестабильной сети. Часть клиентов на этом шаге просто не доходит до конца.
PWA снимает этот барьер: установка занимает секунды и практически не расходует память устройства. Для банков с массовой и региональной клиентской базой это не про удобство, а про охват – про сегменты, которые нативным приложением не покрываются в принципе.
Конверсия из веб-трафика
Классический путь платного привлечения выглядит так: реклама → лендинг → переход в магазин приложений → установка → регистрация → онбординг. На каждом переходе теряется часть аудитории, а суммарные потери на участке «лендинг → установленное приложение» – самые болезненные во всей воронке.
PWA убирает из этой цепочки два шага. Клиент попадает на страницу и сразу оказывается внутри работающего продукта; предложение установить иконку возникает уже после того, как он совершил первое действие. При заметных бюджетах на веб-трафик это напрямую влияет на стоимость привлечения.
Проблемы и вызовы PWA
Несмотря на это, PWA все еще имеют ограничения, и командам приходится их обходить – но практически все они сегодня решаемы архитектурно, а не блокируют внедрение.
Ограничения iOS. Историческая головная боль отрасли: единый браузерный движок, урезанные фоновые задачи, ограничения на push-уведомления и риск очистки локальных данных, если приложением долго не пользовались. Apple последовательно, хотя и неохотно, снимает часть этих барьеров, но планировать функциональность по-прежнему нужно от возможностей Safari, а не от возможностей Android.
Антифрод и привязка к устройству. В нативном приложении банк получает от системы богатый набор сигналов о целостности устройства и окружения. В браузере эти сигналы беднее, идентификатор устройства менее устойчив, а значит, риск-модель приходится перестраивать: переносить часть логики на бэкенд, усиливать поведенческую аналитику, аккуратнее работать с лимитами операций в веб-канале.
Требования регулятора. Сертифицированная криптография, требования к идентификации и к защите канала в браузерной среде реализуются иначе, чем в нативной сборке. Это решаемая, но отдельная и небыстрая работа, которую нужно закладывать в план с самого начала.
Фишинг. PWA – это в конечном счете сайт, и клонировать его дешевле, чем нативное приложение. Клиента, который привык устанавливать банк «по ссылке», сложнее научить отличать настоящий домен от подделки. Компенсируется коммуникацией, работой с брендом и мониторингом доменов – но это постоянные операционные расходы.
Недоступность части системных сценариев. Прежде всего бесконтактной оплаты и глубокой интеграции с операционной системой. Здесь разрыв с нативом сохраняется и в обозримой перспективе сохранится.
Общая картина, тем не менее, движется в сторону расширения браузерных возможностей, а список того, что «в вебе принципиально невозможно», за последние годы заметно сократился.
Три сценария: как PWA выглядит на практике
У банка есть три траектории
Нативное приложение без PWA. Исходное состояние для большинства банков: одно приложение под iOS, одно под Android, весь мобильный трафик идет через магазины. Пока все работает, конфигурация выглядит оптимальной – команда сфокусирована, стек один, дублирования нет. Проблема в том, что весь канал связи с клиентом держится на решениях двух компаний, на которые банк никак не влияет: правила публикации, требования к содержимому, сам факт присутствия в каталоге. Плюс сохраняются встроенные издержки – ревью при каждом релизе, вес дистрибутива, потери в воронке привлечения. Для небольшого банка это терпимо. По мере роста базы цена этих издержек растет быстрее, чем кажется.
Натив плюс PWA. Целевая конфигурация для банка, который перерос предыдущую стадию. Нативное приложение остается основным продуктом – там самые требовательные сценарии, бесконтактная оплата, глубокая интеграция с устройством и наиболее сильный антифрод. PWA рядом решает три отдельные задачи: страхует канал дистрибуции, забирает клиентов, которым нативное приложение недоступно или неудобно, и служит быстрой точкой входа для платного веб-трафика. Да, это третий стек и постоянные расходы на поддержку. Но именно эта конфигурация дает банку полный контроль хотя бы над одним каналом связи со своими клиентами – а чем крупнее банк, тем выше цена его отсутствия.
Только PWA. Состояние, в котором банк оказывается либо на старте, либо не по своей воле. На старте это осмысленный минимум: небольшой игрок запускает ограниченный набор сценариев – баланс, перевод, поддержка – быстро, дешево и без мобильной команды под каждую платформу. Вынужденный вариант может стать результатом закрытого доступа в магазин – тогда веб-приложение остается единственным способом дотянуться до части аудитории. Конечно, такие ситуации лучше встречать с уже готовым и обкатанным PWA, нежели чем строить его в авральном режиме.
Так must-have или преимущество?
За несколько лет PWA прошел путь, характерный для многих технологий: то, что начиналось как вынужденный обходной маневр, стало частью продуктового ландшафта. Технология перестала восприниматься как компромисс – ее выбирают не только потому, что закрыт App Store, но и потому, что она быстрее выкатывается, дешевле достается клиенту и лучше конвертирует трафик. Претензия «это же просто сайт» сегодня звучит примерно так же, как претензии к облакам десять лет назад.
Ключевая зависимость здесь – от масштаба. Чем больше клиентская база, чем шире каналы привлечения и чем выше цена простоя, тем дороже обходится отсутствие канала, который банк контролирует полностью. Для небольшого игрока отказ от PWA – это упущенная возможность. Для крупного – незакрытый операционный риск, который однажды сработает.
Поэтому формулировка «must-have или конкурентное преимущество» скорее описывает не два разных ответа, а две точки на одной траектории. Преимуществом PWA был на входе, когда его делали единицы. Сейчас, по мере того как банк растет, эта опция перестает быть опцией – и вопрос смещается с «нужно ли нам это» на «сколько мы еще готовы откладывать».
