Регистрация и запросы разрешений съедают пользователей: где сужается воронка

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

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

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

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

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

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

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

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

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

Второе — подтверждение номера или почты. SMS-код может не приходить, письмо — попадать в спам, а пользователь — переключаться между приложениями и терять контекст. Иногда человек несколько раз запрашивает новый код, не понимает, истёк ли предыдущий, или не может исправить ошибку в номере без повторного прохождения формы. Если подтверждение действительно необходимо, интерфейс должен показывать понятный статус, давать исправить данные и объяснять, когда можно запросить код повторно.

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

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

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

Перед тем как сокращать форму, стоит разделить данные на три группы.

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

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

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

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

Для разных продуктов это может выглядеть по-разному:

• Контентные приложения: дать посмотреть доступные материалы до создания аккаунта.
• Сервисы бронирования: позволить выбрать услугу и время, а контактные данные запросить перед подтверждением.
• Фитнес-приложения: показать пример тренировки, а затем предложить сохранить индивидуальный план.
• Сервисы с сохранением данных: разрешить начать работу, но объяснить, когда регистрация понадобится для синхронизации или восстановления доступа.

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

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

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

Перед системным окном можно показать короткий экран-пояснение — его часто называют pre-permission screen. На нём следует объяснить конкретную пользу разрешения и дать пользователю возможность отказаться или выбрать альтернативный способ.

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

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

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

1. Разбейте регистрацию на отдельные события. Зафиксируйте открытие приложения, начало регистрации, отправку формы, запрос и подтверждение кода, завершение анкеты, показ системного разрешения, согласие или отказ и первое полезное действие. Названия событий и условия их фиксации должны быть одинаковыми для всех платформ, если вы сравниваете iOS и Android.
2. Посчитайте конверсию между шагами. Например, если регистрацию начали 1 000 пользователей, а завершили 600, конверсия этого этапа составляет 60%. Это условный пример расчёта, а не ориентир для мобильных продуктов. Анализировать нужно фактические данные вашего приложения. При сравнении этапов учитывайте одинаковые временные окна и то, что часть пользователей может завершить действие с задержкой.
3. Посмотрите записи пользовательских сессий. Они помогают увидеть, где человек возвращается назад, несколько раз нажимает на кнопку, долго ищет нужное поле или не понимает сообщение об ошибке. Записи следует анализировать с соблюдением требований приватности и не собирать лишние персональные данные.
4. Проведите короткие тесты с пользователями. Попросите людей, похожих на вашу целевую аудиторию, выполнить регистрацию и объяснить, что они понимают на каждом шаге. Не подсказывайте, куда нажимать. Даже несколько наблюдаемых прохождений могут выявить проблемы, которые команда не замечает из-за привычки к собственному интерфейсу. Но такой тест помогает находить гипотезы, а не точно оценивать частоту проблемы во всей аудитории.
5. Меняйте по одному значимому фактору и проверяйте результат. Например, сравните обязательную регистрацию в начале с доступом к первой функции без аккаунта. Или проверьте, изменится ли поведение, если объяснение геолокации появляется непосредственно перед системным запросом. По возможности используйте A/B-тестирование, заранее определив основную метрику и ограничения: конверсия не должна расти ценой потери безопасности, качества данных или удержания.

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

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

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

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