О жизни продукта после релиза

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

По данным Invesp 44% компаний фокусируются на привлечении пользователей против только 18% компаний, ориентирующихся на возвращаемость. При том, что затраты на привлечение превышают затраты на удержание в пять раз.

Сила метрик

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

Продукт — очень дорогая (в среднем несколько сотен тыс. $) информационная система про медицину. Компаний-заказчиков вообще на рынке — сотни (то есть не очень много). У продукта в данный момент — несколько десятков заказчиков. Конечных пользователей — несколько тысяч. Мой коллега взаимодействует с продактом и разработчиками. У продакта очень хороший научный бекграунд, при этом она хороший коммуникатор и продавец.

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

Коллеге хотелось приносить проекту больше пользы и быть ближе к пользователям. При этом просто взять и сказать “дайте мне респондентов” — не тот случай. Респонденты-заказчики очень труднодоступны даже для продакта, выделяют в лучшем случае несколько минут и тратить их, например на юзабилити-тесты, — бессмысленно. Конечных пользователей на тот момент было не получить технически. Руководство проекта воспринимало аргументы, которые в первую очередь про деньги и бизнес. Что делать?

Тогда я рассказал коллеге про набор метрик HEART framework (рекомендую погуглить).
H — happiness
E — engagement
A — adoption
R — retention
T — task

Им пользуются во многих продуктах Яндекса и пр. По сути этот набор — отличный срез “здоровья продукта”, который прекрасно стыкуется, с одной стороны, с бизнес-метриками наподобие маржинальность и всяких там LTV, с другой стороны — раскладывается на UX-метрики типа “какой % юзеров успешно доходит до второго шага этого визарда и при этом не может загрузить вот этот файл и бросает приложение”.

То есть HEART — отличное звено, через которое можно простроить цепочку от улучшения UX — к росту бизнеса.

Хорошо. Но что делать в данном конкретном продукте?

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

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

Как это сделать? Измерить и при необходимости — повысить engagement и retention пользователей. Чтобы продакт мог придти к заказчику и сказать “вот ваши ребята (25 человек) постоянно на протяжении полугода используют такие-то фичи по нескольку раз каждую неделю. Похоже, вам есть смысл продлять, а ещё посмотрите вот на этот модуль, он хорошо ускорит вас в такого типа задачах.

Для этого нужно поменять механизм авторизации и сделать ряд других фичей. Решить, в каких конкретных “попугаях” измерять engagement и retention и настроить сбор этих данных. А потом выпускать запланированные фичи, смотреть статистику, генерить и проверять гипотезы о том, что может её улучшить.

Кроме того, нам потребуется и метрика task, поскольку фичи сложные и пользователи запросто могут помирать где-то по пути, толком не распробовав функционал. И это тоже нужно измерять, и качественными, и количественными методами.

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

Что и какими метриками анализировать?

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

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

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

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

Путь пользователя в продукте можно отслеживать с точки зрения его вовлеченности
и монетизации.

Вовлеченность для нас первостепенна, так как монетизации пока нет. Она описывается следующими этапами в жизненном цикле пользователя:

1. регистрация в приложении через социальную сеть (Вконтакте или Facebook)
2. залипание в приложении (активность использования доступного функционала)
3. долгосрочный retention (сколько пользователей продолжают использовать продукт спустя месяц, два месяца и т.д. после регистрации)

Сами метрики, соответствующие каждому из этапов, такие:

• регистрация (% тех, зарегистрировался через социальную сеть
  и прошел интро)
• залипание в приложении (% пользователей, совершающих целевые действия, например, добавили N друзей или добавили N рейсов в аккаунт)
• retention (% пользователей, использующих приложение спустя месяц, два и т.д.)
• пользователь порекомендовал приложение (% пригласивших друзей в приложение или оценивших приложение в мобильных сторах)

Метрика, как вектор внимания

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

Регистрация в приложении

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

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

Залипание в приложении

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

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

Retention

Измеряем retention и анализируем, что может помешать пользователям использовать приложение в перспективе, снижая степень их вовлеченности.

Использование когортного анализа

Когорта — сплочённая чем-нибудь группа людей, совокупность людей

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

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

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

Интересный эксперимент провели менеджеры продукта компании Yammer:

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

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

Осмысленность при разработке

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

Эта заметка является частью цикла заметок по разработке проектов
с высокой долей неопределенности в Molinos Studio.