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

Рассказываем, как аналитика и гибкий итерационный подход помогли нам усовершенствовать работу с push-уведомлениями и повысить прибыльность мобильного канала.

Push-уведомления — знакомые всем короткие сообщения от мобильных приложений. Мы привыкли получать их ежедневно. Для бизнеса это эффективный инструмент маркетинга и коммуникации с клиентом. Мобильные push-уведомления используются в разных типах приложений — от мессенджеров до банковских сервисов, и различаются по своим целям. Их можно разделить на две большие группы:

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

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

Еще несколько лет назад для подключения в мобильном приложении push-уведомлений нужно было собрать команду разработчиков, выделить приличную сумму денег (стоимость собственного решения могла доходить до $1 млн!) и потратить на разработку около года. В отдельных случаях все еще нужны сложные самописные или коробочные решения.

Например, за несколько миллионов рублей можно внедрить коробочное решение от Infobip, SMS трафик, MFMs и др. Но чаще всего можно воспользоваться готовыми инструментами — например, платформами Appmetricaили Firebase. Чтобы справиться с задачей внедрения пушей в мобильный продукт, разработчику достаточно стандартной инструкции от конкретной платформы и одной недели на внедрение.

Рассмотрим на примере: как мы подключали пуши для приложения «Кошелёк ЦУПИС». Коммуникация с клиентами происходила в основном через push-уведомления в веб-браузере и e-mail рассылки. Эти каналы хорошо работали на первичное вовлечение, но для активации повторных продаж их функциональности не хватало. Приложение, как площадка для общения с аудиторией, не использовалось вообще. Было очевидно, что это нужно исправлять.

Мы оперативно перешли к следующему шагу — внедрению push-уведомлений. Нам не пришлось разрабатывать сложное решение с нуля или внедрять большую коробку — первым этапом мы настроили Firebase Cloud Messaging и подключили сервисные push-уведомления, на это понадобилось несколько дней. А после — настроили и начали рассылать информационные пуши.

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

Были выбраны два типа push-уведомлений.

Первые, спортивно-событийные сообщения, были привязаны к спортивным инфоповодам. Изначально рассылались именно такие уведомления.

Уже после тестового периода были заметны первые результаты — приложение стали открывать чаще. Соответственно, больше пользоваться услугами сервиса. Выросли продажи и прибыльность.

Поэтому на следующем шаге мы сосредоточились на доработке MVP-инструмента — подключили сообщения другого типа. В дополнение к событийной рассылке добавили когортную — стали рассылать сообщения отдельным группам пользователей в ответ на определенные действия. Например, тем, кто зарегистрировался в системе или установил приложение.

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

Так выглядели сообщения для различных целей:

Однако высокий показатель открываемости push-уведомлений привел не только к росту бизнес метрик. В процессе использования инструмента мы столкнулись с проблемой — высокой нагрузкой в моменте. Мы отправляли уведомления широкой аудитории пользователей. Многие получатели их открывали и сразу же переходили в приложение.

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

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

Результаты и планы на будущее

Аудитория приложения меньше аудитории веб-версии Кошелька. Но несмотря на это, мобильные push-уведомления сработали лучше веб-пушей.

Мобильная аудитория сейчас приносит больше прибыли, чем аудитория сайта. Конверсия в целевое действие — из авторизации в плательщика — в мобильном приложении оказалась в 2 раза выше, чем на сайте.

В среднем переходы с e-mail-рассылки могут затягиваться на неделю. В то время как на пуш в мобильном приложении реагируют быстрее — в течение дня. А их получение разрешено у 76,3% пользователей iOS.

Компания уже планирует осваивать новые инструменты по работе с push-уведомлениями: A/B тесты, автоматизация, капельная цепочка, опросы. Пуши помогут концентрированно раскрывать опыт пользователя — например, упростить процесс онбординга.



И еще несколько рекомендаций

• Не злоупотребляйте отправкой push-уведомлений. Учитывайте коммуникационную политику компании, установите лимит — например, не больше двух сообщений в неделю. Важно удержать пользователя, а не перегрузить его. Получая много пушей, пользователь может запретить их получение в настройках или вовсе удалить приложение.
• Пользователи ценят персональный подход. Клиент скорее обратит внимание на пуш с обращением по имени или поздравление с днем рождения, чем на стандартное уведомление «заходи-посмотри». Степень персонализации инструмента зависит от имеющихся у компании данных пользователей — поэтому эту базу необходимо постоянно обновлять и пополнять.
• На открываемость в мобильных push-уведомлениях влияют изображения в дополнении к текстовому сообщению. Даже если сам пуш не будет открыт, пользователь скорее расширит и посмотрит приложенную к нему картинку.
• Уведомления с эмодзи работают лучше, чем без них. Но нужно знать меру: 2-3 эмодзи лучше, чем 10 эмодзи.
• Push-уведомления начинают работать с определенной версии приложения — с той, к которой подключены Appmetrica или Firebase.Поэтому важно убедить аудиторию обновить приложение — на этом этапе можно использовать инструменты принудительного обновления. Например, вывести на главный экран окно с предложением обновиться, которое будет всплывать при каждом открытии. Более радикальный способ — вместо окна, которое можно закрыть, вывести экран, который не даст приложению работать, пока оно не будет обновлено до последней версии.

Поэтому, после внедрения пушей важно подождать какое-то время, пока аудитория перейдет в новую версию, а уже после этого уже можно считать эффективность канала.