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

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

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

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

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

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

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

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

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

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

Рассмотрим на примере: как мы подключали пуши для приложения «Кошелёк ЦУПИС» — сервиса для платежей легальным букмекерским конторам.

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

Коммуникация с клиентами происходила в основном через push-уведомления в веб-браузере и e-mail рассылки. Эти каналы хорошо работали на первичное вовлечение, но для активации повторных продаж их функциональности не хватало. Приложение, как площадка для общения с аудиторией, не использовалось вообще. Было очевидно, что это нужно исправлять.

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

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

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

Push-уведомления от мобильного приложения «Кошелек ЦУПИС»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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