[Перевод] Как правильно запрашивать доступ у пользователей iOS
Автор этой статьи — Бренден Маллиган, один из создателей LaunchKit, пакета инструментов для iOS-разработчиков. Он также работает над мобильным и веб-приложением Cluster, которое позволяет создавать личные соцсети на основе общих интересов и опыта. Также Бренден является автором проектов ArtistData и OneSheet.
Cluster стал моим первым мобильным нативным приложением. Работая над ним, я научился многому, в том числе и не относящемуся к сети. Создавая веб-приложение, вы всего лишь делаете страницу для посетителей. Но когда вы разрабатываете нативное приложение, то не просто предлагаете людям что-то скачать, но и, скорее всего, спрашиваете у них доступ к их местоположению или личным данным. А это отношения уже совсем иного рода.
Главный урок, который я вынес: не запрашивайте у пользователей доступ до тех пор, пока данные вам действительно не понадобится. И предельно ясно дайте им понять, что они получат взамен.
Очень важно получить доступ с самого начала
Для многих приложений отсутствие доступа к нужным данным может испортить всю идею. Например, если работа приложения зависит от местоположения пользователя, то его отказ предоставлять данные геолокации может сделать программу бесполезной. Другой вариант: если push-уведомления играют ключевую роль в формировании привычки использовать вашу программу, то запрет на уведомления может привести к тому, что про ваш продукт забудут.
Хуже всего то, что если пользователь нажимает «Запретить», то очень трудно потом склонить его поменять своё мнение. Чтобы предоставить доступ позднее, пользователь должен осуществить пять шагов, и вы никак не сможете помочь ему в этом, если только не предоставите подробный список всех действий.
Порядок действий для включения разрешений.
Другими словами, если пользователь не дал доступа, то приложение будет работать некорректно, и почти невозможно будет объяснить, как это исправить. Поэтому разработчик должен сделать всё возможное, чтобы пользователь нажал «Разрешить». Есть два распространённых способа.
Способ первый: Начальный Блицкриг (не рекомендуется)
Этот способ всем знаком. Вы запускаете приложение в первый раз, и сразу же всплывает окно «Приложение запрашивает доступ к уведомлениям», потом ещё одно «Приложение запрашивает доступ к камере», а потом «Приложение запрашивает доступ к контактам». И если пользователь ещё не знаком с приложением, то, вероятно, всё запретит. Это как если бы вы подошли к кому-нибудь на улице и потребовали пойти с вами на свидание.
В первой версии Cluster был реализован именно этот способ, и лишь 30-40% пользователей давали доступ.
Способ второй: Объяснение Преимуществ (недостаточно оптимальный)
Данный способ гораздо лучше Первоначального Блицкрига, но всё же он недостаточно эффективен.
На этой иллюстрации видно, как приложение HeyDay объясняет пользователям, почему им следует дать ему доступ к данным. После этого оно их непосредственно запрашивает. Когда мы использовали этот способ в одной из версий Cluster, то доля разрешивших выросла до 66%.
Динамика некоторых приложений позволяет выбрать один из двух описанных способов. В этом случае гораздо правильнее будет сначала объяснить пользователям, зачем вам нужен тот или иной доступ, чем сразу напролом его запрашивать.
Как мы решали эту проблему в Cluster
Со временем мы пришли к убеждению, что запрашивать доступ нужно тогда и только тогда, когда без этих данных ну никак не обойтись. И мы считаем, что в этом случае пользователи ясно понимают, что им это даст.
Мы собрали две версии Cluster, показывающие системные диалоги запроса доступа после того, как пользователь сообщает, что собирается дать доступ.
Диалоги, предшествующие предоставлению доступа
Когда мы через собственный интерфейс запрашивали доступ, прежде чем показать системный диалог, многие пользователи соглашались его дать. Как говорилось выше, нет ничего хуже, чем запрет доступа на системном уровне, поскольку процедура включения разрешений весьма сложна. Но если запросить доступ до того, как это сделает система, и пользователь откажет, то останется ещё одна возможность запросить его в будущем. Может быть, в этот раз пользователь нажмёт «Разрешить».
Согласно нашему опыту, когда мы запрашивали доступ к фотографиями, то 46% из первоначально отказавших в следующий раз проявили благосклонность.
Это гораздо проще, чем кажется на первый взгляд. Вы можете либо создать свой диалог, либо использовать ещё один диалог iOS.
Двойной диалог
В старых версиях Cluster, когда мы запрашивали доступ к фотографиям, то фактически делали это дважды.
Использование системного диалога для предварительного запроса.
Первый запрос (скриншот в центре) ставил флажок отказа пользователя в самом приложении, а не в системе. То есть оставался ещё один, последний патрон.
Только 3% пользователей, нажавших сначала «Дать доступ», потом нажимали «Запретить». То есть 2% от общего количества пользователей запрещали доступ на системном уровне.
Может быть это выглядит назойливо, — спрашивать дважды, — но зато мы почти исключаем возможность оказаться в ситуации, когда пользователь нажмёт «Запретить». Если на то пошло, то в реальных тестах никто из пользователей не колебался и не выразил смущения, когда появлялся второй диалог.
Исходный код
Обучающие сообщения, предшествующие запросу доступа
Запрашивая доступ к контактам, мы хотели дать пользователям немного больше информации. Но стандартный системный диалог не позволял реализовать задуманное в полной мере. Поэтому мы создали свой собственный диалог, который мог содержать изображения.
Сначала мы объясняем, для чего нам нужен доступ, а затем предоставляем выбор: дать доступ ко всей адресной книге или вводить информацию вручную. Естественно, системный диалог отображается только в том случае, если пользователь решает дать доступ ко всем контактам.
Как и в предыдущем случае, были определённые сомнения относительно двойного диалога, но никто не нажал «Запретить». Напротив, в тот момент, когда выбравшие ручной ввод осознавали, во что они ввязались, мы услужливо снова предоставляли возможность дать доступ ко всей адресной книге.
Такой подход позволил практически забыть о проблеме запрета доступа. Крайне редко попадались пользователи, запрещавшие его на системном уровне. Это была наша победа.
Диалоги, инициируемые пользователями (самый успешный вариант)
Тем не менее, оставалось некоторое количество упрямцев, вообще никак не хотевших давать нам доступ. Основной задачей предварительных диалогов было психологически подготовить пользователя к финальному запросу, чтобы он ожидал его и не отказывался из-за внезапности запроса. Но не все в результате нажимали «Разрешить». Нам было к чему стремиться.
Разобрав проблему, мы поняли, что пользователи всё ещё не ожидают, что у них будут запрашивать доступ. И тогда мы придумали, как подтолкнуть их к тому, чтобы они сами инициировали эту процедуру. При тестировании на нескольких десятках человек доля разрешений почти достигла 100%.
Фотографии
В одной из предыдущих версий Cluster нужно было в первую очередь добавить фотографию. Поэтому запрос доступа появлялся сразу после нажатия на кнопку «Создать кластер». Доступ предоставляли 67% пользователей.
Тогда мы решили перенести этап загрузки фотографии на более раннюю стадию, когда пользователь ещё более настороженно относится к приложению. При этом мы попросили его нажимать на иконку камеры и кнопку «Выбрать фото», прежде чем запрашивать доступ.
Количество давших доступ выросло до 89%.
Объясняется это тем, что пользователь собирается загрузить фотографию, которую он только что сделал, потому совершенно логично дать доступ к фотографиям.
Контакты
Мы задались вопросом, что же такого можно предложить пользователю взамен на доступ к адресной книге? В отличие от ситуации с ручным вводом данных, в данном случае трудно было предложить какую-то очевидную выгоду.
В конце концов мы решили просто показать пользователю, как уныло и голо выглядит процедура добавления контакта при запрещённом доступе. И после того, как пользователь обнаруживал, что не может найти в программе своих друзей и близких, мы выводили внизу кнопку «Показать результат из адресной книги». Практически все нажимали на неё.
100% пользователей предоставляли доступ к контактам, поскольку инициатива исходила от них самих.
Push-уведомления
Cluster используется для создания маленьких личных виртуальных пространств для общения с друзьями. Что полезного могли дать пользователям наши уведомления? Естественно, информацию о появлении друзей в созданных «кластерах».
Когда пользователь впервые создаёт «кластер» и приглашает кого-то, мы задаём логичный вопрос: «Вы хотите получить уведомление о том, что ваши друзья приняли приглашение?». Если пользователь соглашается, мы показываем стандартный системный диалог. Если отказывается, то мы его не заставляем.
После нажатия «Уведомить меня» 100% пользователей дали доступ в системном диалоге.
Важность контекста
Приложения бывают разные, но немалая (а иногда подавляющая) доля успеха зависит от правильности выбора момента, когда сто̒ит запрашивать доступ к разным данным, а также от того, подготовите ли вы пользователей к этому.
Полезные ссылки
Представленные ниже ссылки могут оказаться полезны многим iOS-разработчикам.
Review Monitor — бесплатный инструмент, регулярно проверяющий App Store на наличие новых отзывов. Когда он обнаруживает такой отзыв, то публикует его в Slack-канал или отправляет вам в почту.
Screenshot Builder — позволяет легко создавать красивые иллюстрации для вашей страницы в App Store, экспортируя в любое нужное разрешение.
