Push-нотификации как способ улучшить проект

Каждое приложение стремится захватить внимание пользователей. Особенно это важно для игр, так как приносимый ими value довольно-таки низок: удовлетворение потребностей в развлечениях менее приоритетно чем, например, в еде или в квартплате (вспомним пирамиду Маслоу, где социальные потребности значительно ближе к вершине, чем физиологические). Поэтому при проектировании приложения необходимо рассмотреть различные варианты возврата пользователей. Одним из наиболее важных и эффективных инструментов являются Push-уведомления. Однако, главное не перестараться — огромное количество бесполезных нотификаций может, наоборот, отпугнуть пользователей. 

Данный вопрос встает особенно резко в последнее время — когда производители Google и Apple вводят различные системы контроля нотификаций. Так, например, ни для кого не секрет, что в iOS 12 Siri предлагает пользователям отключать уведомления, на которые он не реагирует, чтобы сократить поток ненужной информации.

Подсказки Siri по отключению Push-уведомлений

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

На основе результатов исследований Google, найдена зависимость DAU return rate (какой процент от DAU вернется на следующий день) и качества PUSH-уведомлений. Чем выше click-rate на нотификации, тем выше DAU return rate. 

Персонализация

Разработчики стараются персонализировать различные функции внутри приложения (например, платежные акции, «умные» ленты, геймплей), но почему-то многие забывают про Push-уведомления. Однако, это один из важнейших способов коммуникации с пользователем: грамотная настройка уведомлений может значительно улучшить ретеншн и вовлечение в игру/количество заказов.

При разработке системы Push-уведомлений рекомендуется учитывать время суток, в которое ваши пользователи привыкли заходить в приложение. Например, если ваш клиент заказывает обычно еду в 12:00, то нет смысла ему присылать уведомление в 16:00 — вероятнее всего, он уже пообедал. Однако, отправив Push в 11:50, вы попадете, скорее всего, в цель. Для развлекательных приложений (например, игр), максимально простым сценарием является отправка сообщений через 24 часа после визита (а лучше — через 23, ведь пользователь его откроет не сразу).

Или, например, ВК посылает уведомления, что у друга день рождения утром. При этом, можно посмотреть, когда пользователь привык поздравлять людей с днем рождения (сделать это довольно-таки легко, ведь фразы или стикеры более-менее стандартны). Если это вечер, то лучше прислать сообщение вечером.

В одном из проектов, над которым я работал, исторически сложилось, что Push-уведомления отправлялись в 16:00 из-за чего на графиках HAU в это время был аномальный пичок, но при этом наиболее популярное время для игры было 20:00. Первое, что было сделано — перенесено время отправки пуша. За счет этого, на 10% пользователей больше переходили по пушу.

Дальше — больше. Мы решили персонализировать уведомления. Наиболее простой способ привязки ко времени — через 23 часа после захода пользователя. Что произошло? Количество открытий PUSH увеличилось в 2 раза. Следующий тест — внедрение системы, которая учитывает не последнее время игры, а типичное, например, за последние 2 недели. Мы разбили промежутки суток по 30 минут и для каждого пользователя нашли оптимальное время отправки уведомления. Результатов пока нет, так как тест еще идет.

В случае, если у вас достаточно большая аудитория, и вы знаете о ней много информации, старайтесь персонализировать и текст уведомления. Например, на основе look-a-like аудиторий или социальных связей, можно предугадать действия пользователей в приложении, и что ему интересно: кто-то заходит в «Кинопоиск» посмотреть трейлер, а кто-то — забронировать билет. Это позволит доставлять только действительно полезные уведомления в приложении.

Решайте проблему, а не спамьте

Одна из самых главных ошибок разработчиков — это бесполезные Push-уведомления, например: «Продолжайте игру вместе с нами». Данное сообщение совершенно не нужно пользователю, а нужно только разработчикам. Найдите моменты, ради которых пользователи будут возвращаться в приложение. Например, «Возвращайся, чтобы получить дейли-бонус», «Время обеда! Закажи еду». 

Кроме этого, представители Google нашли зависимость между количеством отправленных уведомлений в нулевой день и ретеншн первого дня. На удивление, зависимость обратная. Поэтому очень важно не СПАМить игроков PUSH-уведомлениями сразу после установки приложения.

Тестируйте тексты и стратегию уведомлений

Текст для уведомлений также легко поддается AB-тестированию. Развивайте свои проекты, основываясь на статистически значимых различиях в Click Rate. Не забудьте учесть novelty-эффект: следует замерять отличия после некоторого промежутка времени или, например, только среди новых игроков.

Существует несколько типов уведомлений: открыто и ясно дать пользователю информацию, зачем было отправлено сообщение («У нас скидка, заходи быстрее!») или, наоборот, сделать более click-bate заголовок («У нас что-то есть, заходи и посмотри»). Мы думали, что второй вариант увеличит кликрейт, но… нет. Именно поэтому, рекомендуется тестировать различные тексты, они могут работать совершенно по-разному в зависимости от специфики проекта и аудитории.

Проработайте стратегию уведомлений

Система нотификаций — это комплексная задача, которая не только решает множество проблем, но и приносит их. При ее проектировании стоит обратить внимание на все аспекты — начиная от получения разрешения от пользователя и заканчивая всеми ивентами и текстами. Следует учесть, что у нотификации может быть несколько целей: информирование (в том числе и экстренное), активация, ретеншн, увлечение в игру, ре-активация. В зависимости от цели, должны быть и разные тексты, и call-to-action, и, возможно, оформление уведомления. 

Так как iOS требует подтверждения от пользователя, то рекомендуется сделать 2 окна — сначала внутреннее, чтобы получить предварительное разрешение, а следом, при согласии, — системное. Этот подход совместно с AB-тестированием поможет найти лучшее место в приложении для запроса разрешения. Кроме этого, собственное окошко можно поднять несколько раз, а системное — лишь один.

Работаю аналитиком в игровой сфере. Участвую в различных хакатонах. Область интересов - монетизация проектов и применение ML в продуктах и бизнесе.

Leave a Comment

Ваш e-mail не будет опубликован. Обязательные поля помечены *