[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"post-onboarding-friction-pervaya-sessiya":3},{"id":4,"title":5,"slug":6,"description":7,"excerpt":7,"content":8,"body":8,"cover_path":9,"cover_url":10,"cover":10,"inline_path":11,"tags":12,"published_at":13,"published":14,"author_id":15,"author":16,"created_at":17,"updated_at":18},47,"Трение в онбординге: разбор сломанной первой сессии","onboarding-friction-pervaya-sessiya","Сценарий: приложение теряет 71 % пользователей в первой сессии. Пошаговый разбор, как честные тесты вскрыли пять причин трения, которых не было видно в аналитике, и что изменилось после исправлений.","## Сценарий: 71 % уходят и не возвращаются\r\n\r\nПриложение «Полка» — сервис для учёта домашней библиотеки: сканируешь штрихкод книги, она попадает в твою коллекцию, можно отмечать прочитанное и вести список желаний. Идея нравится людям: конверсия из страницы в сторе в установку — 34 %, это очень хорошо.\r\n\r\nПроблема в том, что происходит после установки. Из 100 установивших:\r\n\r\n- 92 открыли приложение,\r\n- 74 прошли регистрацию,\r\n- 41 дошли до экрана сканирования,\r\n- 29 добавили хотя бы одну книгу,\r\n- 12 вернулись на следующий день.\r\n\r\nТо есть **71 % не выполнили ключевое действие** — не добавили ни одной книги. При этом продукт технически работает: сканер исправен, сервер отвечает, крашей почти нет.\r\n\r\nАня, продакт «Полки», три недели пыталась понять причину по аналитике. Она видела, **где** отвал. Она не видела, **почему**. Каждая гипотеза выглядела правдоподобно и ни одна не подтверждалась.\r\n\r\nЭта статья — разбор того, как 45 честных тестов вскрыли пять источников трения за три дня, и почему четыре из них были принципиально невидимы в аналитике.\r\n\r\n## Почему аналитика не находит трение\r\n\r\nАналитика фиксирует события. Трение — это то, что происходит **между** событиями: сомнение, поиск, неправильная интерпретация, ожидание, раздражение.\r\n\r\nПредставьте человека на экране регистрации. В логах: `screen_view: signup` → через 40 секунд → `event: signup_completed`. Сорок секунд. Много это или мало? Аналитика не знает. А в реальности за эти сорок секунд произошло следующее: человек трижды попытался ввести email, получил ошибку «неверный формат» без объяснения (он случайно поставил пробел в конце), решил, что приложение сломано, попробовал войти через Apple ID, не нашёл кнопку сразу, вернулся к email, наконец прошёл.\r\n\r\nОн прошёл. Событие зафиксировано. В воронке он выглядит как успех. А в его голове уже сформировалось «это приложение работает плохо» — и именно это определит, вернётся ли он завтра.\r\n\r\n| Что видит аналитика | Что происходит в реальности |\r\n|---|---|\r\n| Событие выполнено за 40 сек | Три неудачные попытки, потеря доверия |\r\n| Отвал между экранами X и Y | Пять разных причин отвала в равных долях |\r\n| Высокий retention на устройстве А | На устройстве Б кнопка под клавиатурой, но таких устройств мало в выборке |\r\n| Экран просмотрен 1 раз | Человек не понял, что на нём нужно делать, и ждал |\r\n| Разрешение на камеру отклонено | Непонятно, что приложение без камеры бесполезно |\r\n| Событие не произошло | Неизвестно, не захотел или не смог |\r\n\r\nПоследняя строка — самая важная. **Аналитика не различает «не захотел» и «не смог».** А это два совершенно разных продуктовых решения: в первом случае нужно менять ценностное предложение, во втором — починить интерфейс.\r\n\r\n![Разница между тем, что фиксирует аналитика, и тем, что переживает пользователь](inline-mid.jpg)\r\n\r\n## Чек-лист, который Аня отправила на тестирование\r\n\r\nПять шагов, каждый требует факта и доказательства. Ключевой принцип: **шаги воспроизводят первую сессию, а не проверяют функции**.\r\n\r\n**Шаг 1.** Установите приложение и откройте. Не нажимая ничего, 15 секунд смотрите на экран. Напишите своими словами: что это за приложение и что оно предлагает сделать прямо сейчас? Приложите скриншот.\r\n\r\n**Шаг 2.** Пройдите регистрацию. Опишите каждый момент, когда вы сомневались или получили ошибку. Укажите, сколько попыток потребовалось и каким способом вы зарегистрировались.\r\n\r\n**Шаг 3.** Добавьте в приложение любую бумажную книгу, которая есть у вас под рукой. Опишите весь путь: куда нажимали, что происходило, что было непонятно. Приложите скриншот результата.\r\n\r\n**Шаг 4.** Если на шаге 3 что-то не получилось — опишите точно, где остановились и почему. Не переходите к следующему шагу, пока не опишете это.\r\n\r\n**Шаг 5.** Закройте приложение полностью, откройте снова. Опишите, что увидели и понятно ли, что делать дальше.\r\n\r\nОбязательно: модель устройства, версия ОС, версия приложения.\r\n\r\n45 прохождений. Ставка 99 ₽, комиссия 15 %, бюджет 5 123 ₽. Три дня.\r\n\r\n## Что обнаружилось: пять источников трения\r\n\r\n### Трение 1: разрешение на камеру без объяснения\r\n\r\n**Что показали отчёты.** 17 из 45 человек написали, что системный запрос на доступ к камере появился сразу после регистрации, до того как стало понятно, зачем камера нужна. 9 из них отклонили запрос. После отклонения приложение показывало пустой экран сканера с иконкой камеры и без текста.\r\n\r\nЦитата из отчёта: «Спросили камеру на втором экране, я не понял зачем, нажал “Не разрешать”. Потом попал на чёрный экран с непонятной иконкой. Решил, что приложение не работает, и закрыл».\r\n\r\n**Почему аналитика это пропустила.** Событие `camera_permission_denied` логировалось, но никто не связал его с отвалом: 20 % отклонений выглядели как норма. Не было видно, что отклонение — это **тупик без выхода**.\r\n\r\n**Что сделали.** Перенесли запрос на момент первого нажатия «Добавить книгу», добавили экран-объяснение перед системным диалогом, и главное — добавили альтернативный путь «добавить вручную по названию» для тех, кто отклонил.\r\n\r\n### Трение 2: ошибка валидации email без объяснения\r\n\r\n**Что показали отчёты.** 11 человек столкнулись с ошибкой «Неверный формат email». Из них 6 указали, что не понимали, что именно не так. Причина в четырёх случаях — пробел в конце, скопированный при автозаполнении. В двух — заглавная буква, которую приложение почему-то отвергало.\r\n\r\nЦитата: «Писал одно и то же три раза, потом скопировал из заметок — сработало. Так и не понял, в чём была разница».\r\n\r\n**Почему аналитика это пропустила.** Событие ошибки валидации логировалось агрегированно, без причины. В воронке эти люди в итоге прошли регистрацию — то есть выглядели как успех.\r\n\r\n**Что сделали.** Триминг пробелов и приведение к нижнему регистру на клиенте, конкретные тексты ошибок («Похоже, в адресе лишний пробел»), кнопка входа через Apple\u002FGoogle выше поля email.\r\n\r\n### Трение 3: непонятно, что сканировать\r\n\r\n**Что показали отчёты.** 14 человек на шаге 3 описали замешательство на экране сканера. Приложение показывало рамку и текст «Наведите на книгу». Люди наводили камеру на **обложку**, потому что «книга» — это обложка. Сканер ждал штрихкод на задней стороне.\r\n\r\nЦитата: «Держал телефон над обложкой секунд двадцать, ничего не происходило. Подумал, что сканер плохо работает, попробовал ещё раз в другом освещении».\r\n\r\n**Почему аналитика это пропустила.** Это худший тип трения для аналитики: **человек находится на нужном экране, активно что-то делает, никаких событий ошибки не генерируется**. Он просто в конце сдаётся. В логах — длинный `screen_view` и выход.\r\n\r\n**Что сделали.** Изменили текст на «Наведите на штрихкод на обратной стороне книги», добавили схематичную картинку-подсказку и таймер: если через 8 секунд ничего не распознано, появляется подсказка «Не находит? Введите название вручную».\r\n\r\n### Трение 4: успех без подтверждения\r\n\r\n**Что показали отчёты.** 8 человек добавили книгу, но не поняли, что добавили. После распознавания штрихкода приложение возвращало на главный экран, где книга появлялась в списке — но список был внизу, ниже блока «Рекомендации», и на маленьких экранах не попадал в первый экран.\r\n\r\nЦитата: «Просканировал, меня выкинуло назад, ничего не изменилось. Отсканировал ещё раз — потом увидел, что книг стало две».\r\n\r\n**Почему аналитика это пропустила.** Событие `book_added` срабатывало. Человек в воронке — успех. Никто не смотрел, что 3 человека добавили одну и ту же книгу дважды.\r\n\r\n**Что сделали.** Экран подтверждения с обложкой и названием после сканирования, кнопки «Добавить ещё» и «Готово», перенос списка книг наверх для пустой коллекции.\r\n\r\n### Трение 5: пустое состояние при повторном входе\r\n\r\n**Что показали отчёты.** На шаге 5 — 19 человек описали, что при повторном открытии видят главный экран с блоком рекомендаций и не сразу находят свои книги. Ещё 5 сообщили, что приложение показало экран загрузки более 5 секунд.\r\n\r\nЦитата: «Открыл второй раз, увидел те же рекомендации, что и в первый. Как будто мои книги не сохранились».\r\n\r\n**Почему аналитика это пропустила.** Retention D1 считался по факту открытия. Все эти 19 человек — «вернувшиеся». То, что они не нашли свою коллекцию, в метрике не отражалось никак.\r\n\r\n**Что сделали.** Для пользователя с непустой коллекцией главный экран открывается на его книгах, рекомендации ниже. Локальный кеш списка, чтобы не ждать сервер.\r\n\r\n:::chart type=bar title=\"Сколько человек из 45 столкнулись с каждым трением\"\r\nРазрешение камеры без объяснения|17\r\nНепонятно что сканировать|14\r\nПустое состояние при возврате|19\r\nОшибка валидации email|11\r\nУспех без подтверждения|8\r\n:::\r\n\r\n## Что общего у всех пяти находок\r\n\r\nОбратите внимание на закономерность: **четыре из пяти трений происходили в моменты, когда аналитика видела успех или норму**.\r\n\r\n| Трение | Как выглядело в аналитике |\r\n|---|---|\r\n| Камера отклонена → тупик | Нормальный уровень отклонений разрешений |\r\n| Ошибка email | Регистрация в итоге завершена — успех |\r\n| Не понял, что сканировать | Долгая сессия на нужном экране |\r\n| Не увидел результат | Событие book_added сработало |\r\n| Не нашёл коллекцию | Открытие приложения = retention D1 |\r\n\r\nЭто не изъян конкретной аналитической системы. Это принципиальное ограничение событийной модели: она регистрирует **факты**, а трение живёт в **интерпретациях**. Восстановить интерпретацию из логов нельзя — её нужно спросить.\r\n\r\n:::compare\r\nЧто даёт аналитика первой сессии|Что даёт отчёт о первой сессии\r\nГде произошёл отвал|Почему человек остановился\r\nСколько людей затронуто|Как человек понял происходящее\r\nВремя между событиями|Чем он был занят в это время\r\nТехнические ошибки|Ошибки понимания\r\nУстройства в агрегате|Конкретное устройство и конкретный экран\r\nЧто не произошло|Не захотел или не смог\r\n:::\r\n\r\n## Результат после исправлений\r\n\r\nАня внесла все пять исправлений за 9 дней и запустила повторную волну — тот же чек-лист, 30 прохождений, 3 415,50 ₽.\r\n\r\nИз 30 отчётов: разрешение камеры отклонили 4 человека, и все четыре воспользовались ручным вводом. Ошибок валидации email — ноль. Замешательства на сканере — 3 человека вместо 14. Двойных добавлений — ноль. Не нашли коллекцию при повторном входе — 1 человек.\r\n\r\nМетрики продукта через три недели после релиза исправлений:\r\n\r\n| Шаг воронки | До | После |\r\n|---|---|---|\r\n| Открыли приложение | 92 % | 93 % |\r\n| Прошли регистрацию | 74 % | 86 % |\r\n| Дошли до сканера | 41 % | 72 % |\r\n| Добавили книгу | 29 % | 61 % |\r\n| Вернулись на следующий день | 12 % | 34 % |\r\n\r\nКонверсия в ключевое действие выросла более чем в два раза. Общий расход на оба этапа тестирования — 8 539 ₽.\r\n\r\n:::chart type=bar title=\"Конверсия в первое ключевое действие, %\"\r\nДо исправлений|29\r\nПосле волны 1|48\r\nПосле волны 2|61\r\n:::\r\n\r\n## Универсальные точки трения: где искать в своём продукте\r\n\r\nПять трений «Полки» специфичны, но их типы повторяются почти в каждом приложении. Проверьте свой продукт по этому списку.\r\n\r\n**1. Запрос разрешений без контекста.** Камера, геолокация, уведомления, контакты. Вопрос: что увидит человек, если откажет? Если тупик — это блокер.\r\n\r\n**2. Валидация с неинформативными ошибками.** «Неверный формат», «Ошибка», «Что-то пошло не так». Вопрос: может ли человек понять из текста, что именно исправить?\r\n\r\n**3. Неоднозначные инструкции.** Любая формулировка, которую можно понять двумя способами. «Наведите на книгу» — классика. Вопрос: как поймёт человек, который никогда не видел ваш продукт?\r\n\r\n**4. Действие без подтверждения.** Человек что-то сделал — понял ли он, что получилось? Вопрос: есть ли явная визуальная реакция в том месте, куда он смотрит?\r\n\r\n**5. Пустое или неправильное состояние при возврате.** Вопрос: что видит человек во второй раз, и отличается ли это от первого?\r\n\r\n**6. Ожидание без индикации.** Любая операция дольше секунды без спиннера читается как «сломалось».\r\n\r\n**7. Элемент под клавиатурой или под сгибом экрана.** Проверяется только на реальных устройствах с маленькими экранами.\r\n\r\n**8. Недоступный обратный путь.** Человек попал куда-то по ошибке и не может выйти без перезапуска.\r\n\r\n**9. Терминология продукта вместо языка пользователя.** Ваши внутренние названия сущностей на экранах.\r\n\r\n**10. Слишком ранний запрос ценности.** Просьба оплатить, зарегистрироваться или пригласить друзей до того, как человек получил первую пользу.\r\n\r\n| Тип трения | Находится аналитикой | Находится отчётами |\r\n|---|---|---|\r\n| Краш | Да | Да |\r\n| Разрешение → тупик | Частично | Да |\r\n| Неинформативная ошибка | Нет | Да |\r\n| Неоднозначная инструкция | Нет | Да |\r\n| Нет подтверждения действия | Нет | Да |\r\n| Элемент под клавиатурой | Нет | Да |\r\n| Долгая загрузка | Да | Да, с контекстом |\r\n| Непонятная терминология | Нет | Да |\r\n\r\nПоловина строк — «нет» в колонке аналитики. Это и есть аргумент за отчёты: они закрывают слепую зону, а не дублируют то, что вы уже знаете.\r\n\r\n:::quiz\r\nВ аналитике видно: 34 % пользователей отклоняют запрос на геолокацию. Retention этой группы почти нулевой. Что это означает?\r\nA) Аудитория заботится о приватности, изменить нельзя\r\nB) Нужно убрать запрос геолокации из приложения\r\nC) Неизвестно: возможно, после отказа человек попадает в тупик без альтернативного пути — это нужно проверить отчётами\r\nD) Нужно запрашивать геолокацию настойчивее, с повторными диалогами\r\nПравильный: C\r\nПояснение: нулевой retention после отказа обычно означает не принципиальную позицию пользователя, а отсутствие рабочего пути для того, кто отказал. Аналитика показывает корреляцию, но не причину. Отчёты покажут, что именно человек увидел после отказа и почему остановился. Вариант A — преждевременный вывод, B — потеря функциональности без данных, D — агрессивный паттерн, который ухудшает доверие и нарушает рекомендации платформ.\r\n:::\r\n\r\n## Как встроить проверку первой сессии в процесс\r\n\r\nНе разовая акция, а регулярная практика. Минимальный рабочий цикл:\r\n\r\n**1. Перед каждым изменением входного потока — волна на 25–40 прохождений.** Любая правка регистрации, онбординга, первого экрана или запроса разрешений требует внешней проверки. Свои глаза здесь не работают: вы знаете, куда нажимать.\r\n\r\n**2. Чек-лист всегда включает шаг «первое впечатление без действий».** Это самый дешёвый способ проверить, читается ли ценность продукта. Если 20 из 45 описывают приложение не так, как вы его позиционируете — проблема в первом экране, а не в рекламе.\r\n\r\n**3. Обязательный шаг «что произошло при повторном открытии».** Самая недооценённая область: команды тестируют первый запуск и никогда — второй.\r\n\r\n**4. Повторная волна после исправлений тем же чек-листом.** Иначе вы не знаете, помогло ли. Сравнение формулировок людей до и после — самый честный индикатор.\r\n\r\n**5. Требование к разнообразию устройств.** Минимум: один дешёвый Android с маленьким экраном, один средний, один iPhone. Трение вида «кнопка под клавиатурой» существует только на конкретных устройствах.\r\n\r\n**6. Хранение отчётов в одном месте с датами версий.** Через полгода вы захотите понять, когда именно появилось трение.\r\n\r\n## FAQ\r\n\r\n**Сколько тестов нужно, чтобы найти трение в онбординге?**\r\nБлокирующие проблемы обычно проявляются у первых 8–10 человек. 25–30 дают уверенность и оценку частотности. 45 — комфортно, с покрытием разных устройств. Больше на один и тот же билд смысла мало.\r\n\r\n**Можно ли обойтись записями сессий из аналитических инструментов?**\r\nОни полезны и ближе к реальности, чем события, но не отвечают на вопрос «что человек думал». Вы видите, что он двадцать секунд держал телефон над обложкой, но не узнаете, что он считал это правильным действием, пока он не напишет.\r\n\r\n**Почему нельзя просто проверить онбординг самим?**\r\nПотому что вы не можете разучиться знать свой продукт. Вы знаете, что сканировать нужно штрихкод. Это знание невозможно выключить, а именно его отсутствие и создаёт трение у новых людей.\r\n\r\n**Что делать, если трений нашли двадцать?**\r\nПриоритизируйте по двум осям: частотность (сколько человек из N) и блокирующий характер (можно ли продолжить). Сначала блокирующие с высокой частотностью. Мелкие неудобства оставьте на потом — они не влияют на конверсию.\r\n\r\n**Как отличить трение от неподходящей аудитории?**\r\nТрение — когда человек хотел, но не смог: он описывает попытки, ошибки, поиск. Неподходящая аудитория — когда человек смог, но не захотел: он проходит сценарий и говорит «мне это не нужно». Формулировки в отчётах различаются очень явно.\r\n\r\n**Нужно ли исправлять всё до релиза?**\r\nНет. Исправьте блокирующие и то, что затрагивает больше четверти людей. Остальное войдёт в обычный поток работы. Идеального онбординга не бывает, бывает онбординг без тупиков.\r\n\r\n## Итоги\r\n\r\n- Аналитика показывает, где произошёл отвал, но не различает «не смог» и «не захотел». Трение живёт между событиями.\r\n- Четыре из пяти трений в разобранном сценарии выглядели в аналитике как успех или как норма.\r\n- Самые частые типы трения: разрешение без контекста и без альтернативного пути, неинформативные ошибки валидации, неоднозначные инструкции, действие без подтверждения, неправильное состояние при повторном входе.\r\n- Чек-лист первой сессии обязательно включает шаг «первое впечатление без действий» и шаг «что при повторном открытии».\r\n- Повторная волна тем же чек-листом после правок — единственный способ узнать, помогло ли.\r\n- Своими силами трение входа проверить нельзя: команда не может разучиться знать продукт.\r\n\r\n## Заключение\r\n\r\nАня три недели искала причину отвала в дашбордах и не нашла. Затем потратила 8 539 ₽ и двенадцать дней, получила пять конкретных причин с частотностью и цитатами, исправила и удвоила конверсию в ключевое действие.\r\n\r\nСамое поучительное в этой истории: ни одна из пяти причин не была связана с продуктовой идеей, ценой или аудиторией — то есть со всем тем, о чём команда спорила три недели. Все пять были мелкими механическими препятствиями, которые видны только человеку, открывающему приложение впервые. Именно этого взгляда и нельзя получить изнутри.\r\n","\u002Fstorage\u002Farticles\u002F46-onboarding-friction-pervaya-sessiya\u002Fcover.jpg","https:\u002F\u002Fmanica.mrdev.ru\u002Fstorage\u002Farticles\u002F46-onboarding-friction-pervaya-sessiya\u002Fcover.jpg","\u002Fstorage\u002Farticles\u002F46-onboarding-friction-pervaya-sessiya\u002Finline.jpg",[],"2026-09-13T00:00:00+03:00",true,1,"Admin","2026-09-26T01:41:38+03:00","2026-09-26T01:49:01+03:00"]