Лого vc.ru

Почему пользователи отказываются от push-уведомлений и как этого избежать — опыт Hopper

Почему пользователи отказываются от push-уведомлений и как этого избежать — опыт Hopper

Разработчики приложения для планирования путешествий Hopper рассказали в своём блоге на Medium о push-уведомлениях — в каких случаях пользователи отключают их и как этого избежать.

В рубрике «Интерфейсы» — перевод заметки, подготовленный командой Faino Interactive для рассылки дизайнеров интерфейсов UX Fox.

Приложение Hopper проводит ежедневный анализ изменения цен на авиабилеты и подсказывает, когда стоит их приобрести.

Основываясь на прогнозах цен, приложение может точно подсказать, следует ли вам сейчас покупать авиабилеты или лучше подождать. Если стоит переждать, вы можете нажать «отслеживать», и приложение будет следить за ценами на авиабилеты на необходимые даты отправления до тех пор, пока они не достигнут «приемлемых» (по сравнению с предыдущими периодами). Как только это произойдёт, вам будет отправлено уведомление о возможности покупки. Опа.

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

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

Проблема с уведомлениями

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

Если пользователь разрешает уведомления, всё в порядке. Если нет, ему будет очень сложно изменить своё решение — необходимо выйти из приложения, зайти в настройки, найти уведомления, отыскать в длинном списке приложений нужное и только потом применить желаемые настройки.

Запрет на уведомления означает, что мы можем потерять пользователя навсегда, поэтому при отправке системного запроса стоит быть очень осторожными, у нас есть всего одна попытка. Это нужно учитывать при добавлении любых «улучшений».

Базовый UI

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

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

На одной из этих страниц были представлены достоинства функции отслеживания, но почти ничего не было явно сказано о её UI и уведомлениях, об их связи между собой и о системных сообщениях iOS. Если пользователь не стал бы читать большой текст или решил, что эта информация ему не нужна, — он бы, скорее всего не понял, как работает функция отслеживания и почему для неё важны уведомления. Таким образом, получив запрос на уведомления, он бы их запретил.

Первое взаимодействие = Уведомления

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

Я набросал несколько скетчей, верхние из которых иллюстрируют наше первоначальное решение.

В UI нашего приложения это выглядит так.

Для вводной страницы об уведомлениях мы решили протестировать только один сценарий: нажатие кнопки «Разрешить уведомления» в приложении приводит к системному запросу iOS на разрешение уведомлений.

Мы предполагали, что, хоть это и весьма агрессивный приём, такая кнопка будет способствовать:

  • большему воздействию на пользователя, чтобы он ознакомился с вводными страницами, прежде чем продолжить работу с приложением, и задался вопросом «На что я соглашаюсь?»;
  • осознанию связи между уведомлениями, функцией отслеживания цен билетов в приложении и экономией денег с помощью Hopper;
  • что более важно, нам было интересно, увеличится ли число разрешений на уведомления, несмотря на то, что могло стать больше пользователей, которые откажутся работать с приложением после вводной части.

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

Мы усвоили урок

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

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

Разветвление

Мы пришли к простому выводу: наши пользователи не уделяли особого внимания вводной части — а даже если они с ней ознакомились и всё поняли, решали подождать и поработать сначала с приложением, прежде чем разрешать нам отправлять уведомления. Чтобы пользователь нажал «разрешить», он должен нам доверять и быть уверен, что мы не станем злоупотреблять его доверием и будем понимать ценность того, что нам позволено.

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

Мы решили оставить вводный экран, посвящённый уведомлениям, но добавить кнопку «отложить решение», которая допускает две ветви развития взаимодействия.

  • Пользователь ещё не доверяет нам и хочет сначала осмотреться, независимо от того, прочёл он вводный текст или нет. Запрос iOS не будет вызван, позволяя нам это сделать позже в контексте.
  • Пользователь нажимает «разрешить» и тем самым вызывает системный запрос.

Текущая версия выглядит так:

Естественное погружение

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

Я пришёл к выводу, что необходимо достичь наиболее естественного погружения в работу с приложением, чтобы вводные страницы не выглядели второстепенными, а были неотъемлемой частью взаимодействия. Наши контекстные подсказки помогли нам приблизиться к цели, положительно повлияв на вовлечённость пользователей и их доверие.

Да, чтобы заслужить доверие, необходимо время. Нам помогло то, что мы позволили пользователям осмотреться, прежде чем решить, стоит нам доверять или нет.

Теги
0

Скажите пожалуйста, какой процент пользователей отказывался от пушей до и после изменений?

0

Сергей, вы же понимаете, что это перевод статьи? У кого вы спрашиваете про статистику? :)

Что уж тут сделать с пользователями если они глупые :)
Мы у себя кстати даем несколько типов уведолмений. И у меня есть подозрение, что некоторые жмут "включить оповещения" потом запрещают их, а потом видя что они не работают скачивает дополнение для хрома - а вот оно уже никаких разрешений не спрашивает и работает :)

Как итог 10% аудитории нативных оповещений против 40% аудитории через дополнение.

Похоже пользователи даже если что то нажали - все равно машинально от греха подальше жмут запретить.

В последнее время много информации про пуш-уведомления.
У нас на Boosta.ru мы уже две статьи посвятили этой теме и собираемся дальше продолжать в этом направлении. Кому интересно, вот две ссылки с зарубежными и российскими кейсами, советами и ошибками:
boosta.ru/various/push-uvedomleniya-novyj-kanal-kommunikacii-s-celevoj-auditoriej/
boosta.ru/various/push-uvedomleniya-kanal-kommunikacii-ili-sploshnoe-razdrazhenie-polzovatelej/

Кстати, мне кажется, что это очень крутой канал коммуникации. Вся проблема лишь в том, как его использует сайт или приложение. Если это не сильно навязчиво и несёт ценность целевой аудитории, то почему нет?
Мне кажется, весь этот негатив связан с тем, что некоторые компании слишком навязчивы в использовании пуш-уведомлений.
E-mail рассылки тоже много кому не нравятся.Но рассылка рассылке рознь. Есть полезные рассылки, а есть бесполезные и продажные, где только одна реклама.

0

По-моему, проблема даже не в навязчивости, а глубже. Навязчивость становится видна потом, из опыта. Первая проблема — в неразвеянном страхе пользователя за то, чем чревато согласие принимать уведомления. Поглядите на первый скриншот в разделе "Проблема с уведомлениями". В нём пугает всё. Для начала, пользователь весьма вероятно не знает, что такое push-уведомления. Тут же его укрепляют в мысли о том, что это что-то потенциально неприятное, т.к. это непонятное явление может включать сигналы тревоги (alerts) и звуки. Третий гвоздь в крышку этого гроба забивает тот факт, что из показанного на экране совершенно непонятно, как в будущем пользователь может изменить своё решение и отключить эти уведомление — нет никакой успокаивающей или поясняющей написи, какие обычно делаются при email-подписках. И, наконец, могильную плиту на эту могилку ставит крупный, бросающийся в глаза, текст "Don't Allow" на кнопке — он таки и просится быть нажать, он почти кричит "Опасно! Не ходи туда! Откажись!"

0

Скомкано написал. :-\ Я, конечно, говорю не о кейсе, изложенном в статье, а о том, как оно получается, когда приложение особо не мудрствуя пытается включить push-уведомления, не приложив усилия для разъяснения происходящего пользователю.

Прямой эфир
Узнавайте первым
о важных новостях
Мы будем присылать вам только срочные уведомления в браузере
Mail.Ru Group получила полный контроль над «ВКонтакте»
Хочу знать!
Не нужно