Максим Кульгин, учредитель компании notissimus, в своем блоге приводит перевод статьи о том, как правильно просить push-уведомления.
Огромное количество публикаций связано с push-уведомлениями (например, здесь или здесь). Это очень мощный инструмент для вашего бизнеса (торгового или сервисного), т.к. с его помощью происходит активное взаимодействие с лояльной аудиторией. Если учесть, что лояльные клиент — основа любого бизнеса, то получается, что push — это весомый механизм повышения эффективности компании. Есть одно «но» в этом инструменте: нужно стимулировать пользователей, кто установил ваше мобильное приложение, включить поддержку получения уведомлений. Мы перевели для вас хорошую статью (с нашими добавлениями из опыта), в которой даются отличные советы как повысить вероятность получить от пользователя разрешение на push и другие функции телефона (например — отслеживание местоположения). Для тех, кто предпочитает оригинал — читайте здесь.
Бренден Маллиган – сооснователь и дизайнер Cluster – веб и мобильного приложения, которое позволяет пользователям создавать частные социальные сети по интересам, обмениваться личными фотографиями с друзьями и близкими. До Cluster Бренден создал и затем продал сервисы ArtistData и OneSheet.
Cluster – это первое мобильное приложение, дизайн которого сделал я (Бренден — прим.ред). Это научило меня многим вещам на которые не нужно обращать специального внимания при работе с веб-приложениями. Когда создаешь веб-приложение (веб-сайт) ты всего лишь разрабатываешь страницу для визитов пользователей. Однако при разработке нативных мобильных приложений вы хотите, чтобы пользователи не только что-то загружали, но также давали доступ к данным об их месторасположении (это очень важно, т.к. позволит делать вам proximity marketing) или к персональным сведениям (это требуется для персонализации, и поверьте — в сочетании с push, персонализация еще более эффективный инструмент взаимодействия с аудиторией). Это совершенно разные задачи. Именно поэтому в Cluster мы потратили много времени на микро-взаимодействия с пользователем, которые повышают его комфорт и лояльность. Одной из таких областей, на которой мы сосредоточились – как запрашивать у пользователей iOS доступ к различным данным на их телефоне.
Наша самая большая задача: не запрашивать доступ к функциям у пользователя до тех пор, пока вы реально не будете в нем нуждаться и точно ему гарантировать то, что он получит взамен.
Получение доступа в первый раз является решающим!
Для многих мобильных приложений не получить доступ к сенсорам телефона или данным может изменить весь пользовательский опыт. Например, если работа приложения зависит от geo- месторасположения пользователя, отказ в доступе к гео-локации может сделать использование приложения абсолютно бесполезным. Более того, если push-уведомление играет решающую роль в формировании у вашего пользователя привычки пользоваться вашим мобильным приложением, отказ в доступе может привести к тому, что вы потеряете его навсегда. Хуже всего, что когда пользователь нажимает «Не разрешать», то уже нет простого способа для того, чтобы он изменил свое решение. Необходимо пройти 5 шагов чтобы получить доступ позже. И нет способа помочь пользователю найти нужный экран, кроме реального движения по этому алгоритму (в настройках телефона). См. ниже последовательность включения push — уведомлений, если пользователь запретил это сделать в вашем мобильном приложении.
Другими словами, если пользователь запрещает доступ, приложение не работает должным образом – и практические невозможно объяснить, как это исправить. Это значит, что разработчикам нужно делать все возможное, чтобы пользователи нажимали «Разрешить» при первом запуске вашего мобильного приложения.
Есть два распространенных метода, которые используют приложения для запроса разрешений.
1. Начальный и простой системный (не рекомендуется)
Все сталкивались с этим. Вы открываете впервые мобильное приложение и затем тут же получаете уведомление «Можем ли мы рассылать вам push-уведомления?» или «Можем ли мы использовать вашу камеру?» или «Можем ли получить доступ к вашим контактам?» Если пользователь уже знаком с приложением, например, таким как WhatsApp, то скорее всего такой проблемы не будет. В противном случае – он нажмет «Не разрешать». Подобные запросы в лоб выглядят примерно так, как если подойти к кому-то на улице и попросить пойти с вами на свидание. В первой версии Cluster был такой подход и только 30-40% пользователей давали разрешение.
2. Объяснение преимуществ (почти оптимально)
Этот метод значительно лучше, чем первоначальный простой, но все еще недостаточно эффективен, насколько это возможно.
Например, HeyDay (приложение для ведения дневника) пытается объяснить пользователям преимущества, которые они получат, дав мобильному приложению доступ к определению местоположения. Затем, когда пользователь уже достаточно узнал, приложение запускает всплывающее сообщение-вопрос. Использование такого сценария работает для нас. Когда пользователь узнает о Cluster перед запросом на доступ, количество положительные ответы на запросы увеличиваются с 40 до 66%.
Такая статистика конкретных мобильных приложений может подтолкнуть к использованию только такого способа. В таком случае, попутное объяснение пользователю почему доступ так важен – гораздо лучше, чем просто делать запрос на доступ.
Подход Cluster к проблеме
Сегодня мы научились запрашивать разрешение на доступ у наших пользователей тогда и только тогда, когда нам это абсолютно необходимо, и мы знаем, что пользователь может ясно видеть, как этот доступ будет ему полезен. Мы переделали Cluster используя эти два способа, чтобы только тогда показывать системное диалоговое окно на разрешение, когда пользователь уже сообщил нам, что он намеревается дать это разрешение.
Диалоги, предваряющие разрешение
У нас было много удачных примеров запросов разрешения при помощи собственного пользовательского интерфейса перед тем как запускать всплывающие диалоговые окна в iOS. Как говорилось выше, худший вариант развития событий – это отклонение пользователем доступа на уровне системы, так как изменить это решение в iOS очень сложно. Но мы спрашиваем их об этом перед тем как это сделает система и, если они ответят нет, у нас еще будет возможность спросить их снова, когда вероятность положительного ответа будет больше. Если говорить о доступе к фото, то 46% людей, которые отклонили доступ в предваряющем диалоге, в итоге предоставляли доступ, когда их просили об этом в подходящее время позже. Это проще, чем вы думаете. Вы можете моделировать собственные диалоги или использовать для этого дополнительные диалоговые окна в iOS.
Двойные системные диалоги
В ранних версиях Cluster, когда мы запрашивали доступ к фото, мы обязательно спрашивали их дважды.
Первое диалоговое окно (в центре сверху) устанавливает флажок в мобильном приложении, что пользователь отклонил запрос, но оно не устанавливает его как «Отклонено» в операционной системе. Это значит, что, если мы захотим делать такой запрос в будущем, мы не похороним свой единственный шанс. Только 3% пользователей, которые разрешили доступ в первом окне, нажимают «Не разрешать» во втором. Таким образом, менее чем 2% от общего количества пользователей запрещают доступ на системном уровне. Несмотря на то, что это кажется навязчивым спрашивать дважды, мы почти полностью устранили возможность для пользователя нажать «Не разрешать», оставляя возможность для нас в будущем. Однако, в живых пользовательских тестах, не один испытуемый колеблется или испытывает растерянность, когда появляется второе диалоговое окно.
Обучающие обзоры перед запросом на доступ
Перед запросом о доступе к контактам, мы хотели немного рассказать пользователю о приложении. Стандартное диалоговое окно системы не дает нам достаточно места и возможностей для полного объяснения того, что происходит, поэтому мы создали свое окно, которое позволяет нам добавлять картинки.
Таким образом, мы сначала показываем им диалоговое окно с причинами зачем нам нужен доступ и предоставляем выбор использовать адресную книгу или ввести контактную информацию вручную. И конечно, мы должны показать системное диалоговое окно с запросом на доступ только тогда, когда они специально выбрали опцию «Использовать адресную книгу».
Нам не нравится спрашивать пользователей дважды, но зато, когда они видят диалоговое окно в iOS никто не нажимает «Не разрешать». Кроме того, люди, которые выбирают авторизацию при помощи ввода контактной информации, осознают, как это на деле неудобно. У нас появляется еще один шанс, чтобы позволить им использовать для этого их адресную книгу.
Использование предварительного окна практически решает проблему «Не разрешать». Исключительно редко пользователь не дает нам доступа на системном уровне, когда его просят. Это была большая победа для нас. Мы были этому сильно рады
3. Диалоговые окна, запускаемые пользователем (наиболее успешный механизм)
Даже если пользователи не закрывают доступы на уровне системы, все равно есть часть людей, которые не добираются до системного диалогового окна, так как они не захотели дать нам доступ на любые действия. Диалоговые окна предварительного разрешения появляются, когда пользователь их не ожидает, нет нужды заставлять большее количество пользователей давать доступ. Можно действовать лучшим образом.
Когда мы подробно разобрали проблему, мы поняли, что пользователи не ждут того, что их будут о чем-то спрашивать, потому мы нашли способ запускать подсказки специально для них. Этот способ был протестирован с реальными потоками из десятков людей, оказалось, что степень предоставления разрешения при такой схеме работы близка к 100%.
Фотографии
В предыдущих версиях, первый шаг создания нового аккаунта в Cluster заключался в добавлении фотографий. Другими словами, мы просили доступ к фото после того, как пользователь создавал аккаунт в Cluster. Это приводило к тому, что только 67% пользователей давало доступ к своим фото. Эту цифру можно увеличить.
Поэтому мы решили переместить этап загрузки фото на несколько шагов дальше – до тех пор, пока пользователи не узнают больше про Cluster, и заставить их нажать на иконку камеры и плашку «Выбрать фото» перед тем как запросить доступ. Такой алгоритм действий повышает долю разрешений на доступ с 67 до 89%. В этот момент пользователь уже хочет загрузить фото, сделанные ранее, поэтому совершенно очевидно, что он даст положительный ответ на доступ мобильного приложениях к его фото.
Контакты
Мы задались вопросом: какую наибольшую выгоду получает пользователь от предоставления доступа к своим контактам. Это чем-то похоже на то с чем сталкивается пользователь, когда он выбирает опцию ручного ввода своих контактных данных в диалоговом окне. Но в данной ситуации, пользователи не испытывают еще дискомфорта, поэтому потенциальный бонус им явно невиден.
В итоге, мы решили позволить увидеть им каким пустым выглядит процесс добавления контакта пользователя без запроса на доступ к данным. Когда пользователи не видят их друзей в поиске, внизу экрана всплывает панель «Показать результаты из контактов iPhone». Обычно люди нажимают эту плашку, когда они не видят своих друзей в списке. Мы обнаружили, что с того момента как пользователи явно пытаются получить доступ к своей адресной книге, 100% из них разрешает доступ к своим контактам в случае запроса на это приложением.
Push-уведомления
Cluster предназначен для создания небольших частных блогов с друзьями. Мы спросили себя: а что ценного получат наши клиенты, получая push-уведомления от нас? Ответ – знание того, что их друзья активны в созданном ими блоге.
Когда пользователь создает блог в первый раз и приглашает туда кого-то, мы задаем ему очень логичный вопрос: «Хотите ли вы получать уведомление, когда ваши друзья, которых вы пригласили присоединятся к проекту?». Если человек кликает «Уведомлять меня», мы показываем ему стандартное диалоговое окно iOS. Если выбирает «Нет, спасибо», мы позволяем ему двигаться дальше. Во время пользовательского тестирования, мы увидели 100% успешность разрешений push-уведомлений в iOS после нажатия «Уведомлять меня».
Что мы узнали: контекст является определяющим фактором
Понятно, что каждое мобильное приложение уникально, но если есть реальное понимание того, когда пользователю действительно нужен доступ к различным данным телефона и есть уверенность пользователя, что у него запросят разрешение на этот доступ, то это значительно увеличивает успех подобных системных диалогов.