1. Для сокращения полной неопределенности требуется очень много данных.

2. Люди, работающие над продуктами, хорошо понимают и знают своих пользователей.

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

Первое заблуждение

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

Если вы возьмете 100 случайных шариков и посчитаете долю белых, то вы будете знать ответ с точностью ±9,8%. Еще 100 шариков повысят точность вашего ответа до ±6,9%. Еще 200 шариков — до ±4,9%. Еще 600 шариков — до ±3,1%. Еще 9000 шариков — до ±1%.

Заметили, что первые 100 шариков дали нам намного больше знания, чем следующие 100? А шарики с 100 до 200 уточнили картину реальности больше, чем шарики с 1000 до 10000?

Давайте запомним это и перейдем ко второму заблуждению.

Второе заблуждение

Второе заблуждение заключается в том, что мы думаем, что понимаем продукты, над которыми работаем. На самом деле, не понимаем.

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

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

Смотрим на продукт глазами пользователей

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

Возьмите несколько ваших пользователей и наблюдайте за тем, как они используют продукт.

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

Как это сделать? Если у вас грамотно настроена аналитика в продукте, то очень просто:

1. Выберите группу пользователей, которых вы хотите изучить (для получения ответов на разные вопросы вам потребуются разные пользователи).

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

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

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

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

А теперь вернемся к первому заблуждению. Вам достаточно изучить подобным образом небольшое количество пользователей (50-100), чтобы сформировать понимание того:

1. Как и для чего люди используют ваш продукт?

2. С какими проблемами они сталкиваются?

3. Где реальное использование отличается от того, которое вы проектировали?

4. Какие пользователи остаются, а какие уходят? Чем они отличаются?

Реальные примеры использования

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

Редизайн Яндекс Карт

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

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

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

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

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

В реальности оказалось, что так делает лишь малая часть пользователей. Большинство копировали адрес организации, открывали вкладку маршруты и строили маршрут оттуда (обозначено зеленым цветом на скриншоте).

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

Поиск проблем в первых версиях King of Thieves

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

Удивительно, но «глупые» пользователи, всегда делают всё по-своему, а не так, как планировали мы. В King of Thieves в первых версиях всё вышло именно так.

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

Чтобы понять причины, мы выгрузили сессии и стали изучать, что же идет не так. Основой игры был мультиплеер. При создании обучения в игре наше предположение состояло в том, что мы покажем на первых уровнях синглплеера суть механики игры, а дальше люди уже сами пойдут в мультиплеер, когда будут готовы. Не зря же мы сделали огромную красную кнопку Multiplayer!

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

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

После разбора сессий нескольких сотен пользователей (сессии были очень короткие, поэтому времени ушло немного), мы прикинули, что меньше 10% пользователей за первые несколько сессий имели шанс понять, в чем состоит суть игры.

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

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

Оптимизация воронки добавления полета в App in the Air

Вот замечательный пример, которым Байрам Аннаков поделился в своем блоге.

30% пользователей приложения App in the Air не добавляли полет после перехода на соответствующий экран. Как это всегда кажется уже постфактум — все оказалось просто. Пользователи искали названия авиакомпании/аэропорта на ... родном языке, а поиск работал только на английском.

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

После добавления поддержки всех языков, на которые было локализовано приложение, дроп на этом шаге воронки сократился с 30% до 5%.

Первые ручные продажи

Вот интересный пост Аркадия Морейниса о том, что первых пользователей надо находить и вести по продукту вручную, в каком-то смысле, заменяя для них туториал. Почему? Потому что это дает возможность посмотреть на ваш продукт их глазами, вы очень быстро находите моменты непонятные вашим пользователям.

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

Разбор сессий — это усовершенствование этого способа. Теперь вы можете выбрать нужных вам пользователей и детально изучить именно их. Например, как в примере с App in the Air, тех, кто зашел на экран добавления рейса, но по какой-то причине его не добавил.

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

Кстати, если вы не читали эссе Пола Грема «Do Things that Don’t Scale», то очень рекомендую.

Плюсы и минусы ручного разбора сессий

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

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

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

В заключение

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

PS Разберите сессии 50 ваших пользователей. Если вы не найдете ничего интересного, ну и ладно. Вы потеряете лишь пару часов вашего времени. Но я уверен, что найдете.

Оригинал: http://gopractice.ru/sessions-yo/