Аналитика без цифр. Смотрим на продукт глазами пользователей.

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!

первая версия king of thieves

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

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

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

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

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

 

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

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

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

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

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

 

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

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

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

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

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

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

 

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

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

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

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

 

В заключение

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

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

 

 



Подписка на рассылку новых материалов

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



Запись опубликована в рубрике Аналитика, Без рубрики, Менеджмент. Добавьте в закладки постоянную ссылку.
  • flamingdeth

    1. А к Usertesting/PlaytestCloud ты как относишься?
    2. По опыту с блицом сложилось мнение, что часто чего-то не хватает по ивентам/параметрам, если пытаться понять поведение чисто по логу.
    3. Какие, на твой взгляд, перспективы у применения game-like туториалов (с ментором и т.д.) в “серьезных” веб-сервисах?

    • lohmatyi312

      1. очень хорошо, особенно для отслеживания первых 30-40 минут в приложении
      но для понимания более дальнего горизонта использования они, к сожалению, не подходят

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

      3. вот тут сложно сказать :) думаю, что это принципиально ничего не меняет

      спасибо за вопросы

      • flamingdeth

        1. у них есть долгосрочные тесты, достаточно полезно получается, т.к. юзеры вслух проговаривают “я хочу ____, но забыл, в каком это разделе” и т.п.

        • lohmatyi312

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

  • Victor V. Ukhimenko

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

    • lohmatyi312

      Спасибо!

    • Dmitry Astapkovich

      Поддержу. Но там вообще страно:

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

      – они до сих не умеют подставлять мои места в дропдауны маршруты. Даже не умеют подставлять их в поиск. Так же нельзя выбрать маркер на карте, чтобы он подставился в маршрут

      Можно продолжать, но мой основной посыл – все это лирика про тупых пользователей. Инструменты кривые, вот и пользователи делать не так, как “правильно”.

  • Denis Germanenko

    А есть какой-то рекомендованный разбор сессий/ивентов, если мы трекаем все через Google Analytics? Речь о мобильном приложении.

    • lohmatyi312

      Денис, привет.

      К сожалению, Google Analytics не отдает данные в неагрегированном виде, поэтому достать ивенты конкретного пользователя просто не получится.

      Это возможно сделать через установку пользовательских переменных, но сложно :)

      • Denis Germanenko

        Приветы! Через кастом вары получается передавать юзерские ID и по ним потом фильтровать ивенты/экраны через сегмент по ID?

        • lohmatyi312

          да, все примерно так

  • Елена Первухина

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

    • lohmatyi312

      Я тут не знаю вашей специфики, но инструменты вроде Amplitude, Mixpanel вполне подходят для сбора данных и последующего анализа подобным образом.

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

  • August

    Олег, поясните пожалуйста, каким образом получены 9,8%, 6,9% и тд в определении точности оценки.

    • maxipr

      Он взял 95% confidence, только и всего. Можно взять 99%, будет 1.29/sqrt(n), суть не изменится.

      • Григорий Михолап

        доверительный интервал зависит от среднего значения, например если в бассейне поровну шариков обоих цветов (т.е. среднее равно 0.5) и мы вытащили из 100 попыток 50 белых и 50 черных шариков, то доверительный интервал для среднего 0.3983211 – 0.6016789, т.е. ошибка до 20%. откуда 9,8%?

        • Олег Якубенков

          Привет

          в статье все же не 9,8%, а ±9,8%, что и дает ошибку 20%

          в остальном все верно, но при confidence level 95% и значении 50%, где достигается максимальная погрешность – получаем ±9,8%
          при 99% – ±12,9%

          как у вас получилось 0.3983211 – 0.6016789 я пока не понял :)

          • Григорий Михолап

            Олег, приветствую, спасибо за комментарий. Теперь я понял, что 9,8% это оценка абсолютная и тогда действительно все сходится. И доверительный интервал для среднего 50% получается 40.2%-59.8%. Моя же оценка 39.83211% – 60.16789% немного отличается видимо потому что функция binom.test в языке R через которую я считал интервал, как-то хитро считает. В целом же все похоже на правду ))