{"id":14262,"url":"\/distributions\/14262\/click?bit=1&hash=8ff33b918bfe3f5206b0198c93dd25bdafcdc76b2eaa61d9664863bd76247e56","title":"\u041f\u0440\u0435\u0434\u043b\u043e\u0436\u0438\u0442\u0435 \u041c\u043e\u0441\u043a\u0432\u0435 \u0438\u043d\u043d\u043e\u0432\u0430\u0446\u0438\u044e \u0438 \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u0435 \u0434\u043e 1,5 \u043c\u043b\u043d \u0440\u0443\u0431\u043b\u0435\u0439","buttonText":"\u041f\u043e\u0434\u0440\u043e\u0431\u043d\u0435\u0435","imageUuid":"726c984a-5b07-5c75-81f7-6664571134e6"}

Когортный анализ: метрики роста против метрик продукта

Когортный анализ — эффективный инструмент продуктовой и маркетинговой аналитики. Даже те, кто знают о его существовании, используют крайне редко. В рамках серии статей «Курс аналитики» об эффективности когортного анализа расскажет аналитик компании ZeptoLab Олег Якубенков.

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

  • первый проехал 2 000 км, второй — 12 000 км;
  • первым автомобилем пользуются 5 раз в неделю, вторым — 4 раза;
  • первый автомобиль в последний месяц в среднем проезжал 10 км, второй — 20;
  • в данный конкретный момент первый автомобиль едет на скорости 100 км/ч, а второй автомобиль — на скорости 70км/ч.

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

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

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

В этой деятельности не обойтись без аналитики. Аналитика является обратной связью на действия, глазами в продуктовом мире. Сначала аналитика позволяет понять, где мы находимся, что за продукт сделали, как им пользуются в реальном мире, а затем позволяет увидеть то, как действия, вносимые изменения влияют на продукт. Аналитикой на картинке ниже я называю этапы: Measure, Data, Learn.

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

Почему метрики роста бессмысленны для аналитики продукта

Давайте рассмотрим следующую модельную ситуацию. Есть продукт, который обладает следующими характеристикам:

  • стоимость привлечения пользователя составляет 1$;
  • средний доход с одного пользователя составляет 2$ в течение следующих 4 месяцев;
  • 30% новых пользователей продолжают пользоваться продуктом спустя месяц (далее доля постепенно снижается до 15%);
  • команда продвижения привлечет 10 тыс. новых пользователей в первый месяц после запуска, 15 тыс. во второй, 20 тыс. в третий и так далее;
  • продакт-менеджер, который отвечает за развитие продукта, вносит в него изменения каждый месяц. Изменения неудачные, поэтому после каждого из изменений доход с пользователя падает на 0,1$, а доля пользователей, продолжающих использовать продукт падает на 2%.

В компании, где разрабатывается этот продукт, принято следить за месячной аудиторией (MAU или Monthly Active Users) и прибылью каждого из проектов. На основе этих метрик выставляются KPI и оцениваются успехи команды, работающей над продуктом.

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

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

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

При правильно построенной аналитике мы бы увидели неудачное влияние обновлений продукта еще в первые недели/месяцы.

Суть когортного анализа

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

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

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

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

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

Ключевые метрики продукта — LTV и CAC

Две ключевые метрики, которые в конечном итоге определяют финансовую успешность вашего продукта — это LTV (Life Time Value) и CAC (Customer Acquisition Cost).

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

Почему эти две метрики так важны для вашего продукта и как они влияют на ваши бизнес показатели вы можете прочитать в материале « Аналитика SaaS. Критерии жизнеспособности» и в материале «Убийца стартапов: стоимость привлечения клиентов» или посмотреть на Vimeo. В рамках же этой статьи важность этих метрик будет принята по умолчанию, а более подробно будет освещены способы работы с этими метриками.

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

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

Декомпозиция LTV на метрики продукта

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

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

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

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

Монетизация же описывается следующей последовательностью этапов жизненного цикла пользователя:

  1. активация в приложении;
  2. увидел продающий экран;
  3. совершил 1 покупку;
  4. совершил 2 покупку;
  5. ...

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

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

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

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

Метрики продукта и как они влияют на LTV

Рассмотрим описанные выше метрики продукта и то, как они влияют на LTV, на примере абстрактной игры.

Активация в приложении

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

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

Пользователь «залип» в приложении

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

Обычно метрику для факта залипания определяют опытным путем (примеры подобных метрик для ряда популярных сервисов).

Пользователь увидел предложение о покупке, сделал первую покупку

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

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

Повторные покупки

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

Retention

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

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

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

Далее необходимо сравнивать показатели вашего продукта для когорт пользователей, сформированных на основе недели, когда они пришли в приложение. Для такой аналитики идеально подходят инструменты Mixpanel и Localytics.

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

Будем формировать когорты пользователей на основе недели, когда они пришли в приложение. Для простоты в примере рассмотрены только следующие метрики: CAC, LTV, Ratention, % совершивших первую покупку, % совершивших повторную покупку. Также для простоты когорты не сегментировались ни по каким дополнительным признакам.

Ниже приведена таблица когортного анализа рассматриваемого продукта (можете считать, что это игра или туристическое приложение).

В первую неделю в первую версию нашего приложения пришло 3000 пользователей. На конец «0 недели» 25% из них прошли туториал, но еще никто не заплатил. К концу первой недели еще 5% прошли туториал (то есть всего уже 30%), при этом 1,2% совершили первую покупку. К концу второй недели туториал прошли 34% из рассматриваемой когорты, а первую покупку совершили 1,4%.

Спустя неделю мы выпустили новую версию приложения, где изменили туториал. Как мы видим из таблицы когортного анализа — сработало! К концу четвертой недели уже 47% прошли туториал (ранее лишь 34%). Расширение воронки монетизации на уровне туториала увеличило и долю тех, кто совершил покупку. К сожалению, наши пользователи не совершают повторные покупки, что не позволяет выйти на операционную безубыточность продукта, даже несмотря на то, что команда продвижения смогла существенно снизить CAC (пусть и сократив приток новых пользователей). Тратим на привлечение мы 0,8$, а зарабатываем лишь 0,5$ со среднего пользователя спустя 8 недель.

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

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

В заключении

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

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

Об этом в следующих материалах.

Олег Якубенков, GoPractice

0
14 комментариев
Написать комментарий...
Владимир Ситников

Спасибо, очень полезно, сохранил в избранном.

Ответить
Развернуть ветку
Андрей Журавлев

Как посчитать изменение LTV, не выжидая каждый раз по 8 недель после апдейта, пока все пользователи не отвалятся?

Потому что даже если подождать эти 8 недель, то этот LTV как верхнюю планку для CAC использовать уже будет нельзя, потому что за это время уже выкатили несколько апдейтов продукта и метрика изменилась.

Как решить эту проблему?

Ответить
Развернуть ветку
Олег Якубенков

Обычно соотношение APRU через неделю-две-месяц и ARPU за лайфтайм остается примерно постоянным (если не было каких-то кардинальных эффективных изменений, нацеленных на 2х или 3х месячных пользователей, например). Так что по динамике первых недель часто можно достаточно точно предсказать финальное значение. Этим в частности хвастается система аналитики Upsight - у них называется predictive LTV.

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

Затронутая вами проблема - проблема любых длинных метрик, и простых решений этой проблемы я не знаю.

Ответить
Развернуть ветку
Николай Чеботарёв

Курс Аналитики и Growth Hacking - реально самое полезное что есть на ресурсе. Большое спасибо за отличную инфу!

Ответить
Развернуть ветку
Eugeny Plokhoj

Великолепные статьи, спасибо.

Ответить
Развернуть ветку
Андрей Журавлев

Расскажите как LTV считать

Ответить
Развернуть ветку
Олег Якубенков

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

Ответить
Развернуть ветку
Андрей Журавлев

Ну это херня, а не LTV.

Ответить
Развернуть ветку
Олег Якубенков

Как вам угодно

Ответить
Развернуть ветку
Андрей Журавлев

Не разглядел автора, сорри :)

Вот у вас (zeptolab) нестандартный фримиум. Игрок делает 1-2 разовых платежа, для разблокировки всего контента.

А как считать LTV для чего-то вроде Candy Crush, когда lifetime длинный, игрок может потратить очень много денег, процент платящих маленький и сами по-себе платящие ужасно сегментированы?

Как много данных нужно, чтобы достверно посчитать LTV?

Ответить
Развернуть ветку
Illia Kravchenko

Наверное это ответ:
1) за длительный период существования приложения, вы узнаете среднюю длительность использования вашего приложения пользователями (Х дней).

2) Считаете сумму (Y долларов) заработанного бабла приложением за последние Х дней, от пользователей, привлеченных Х дней назад.

3) Делите Y на кол-во пользователей. Получаете средний среднее бабло от среднего пользователя.

Но "средняя достоверная температура" никому не нужна особо

Ответить
Развернуть ветку
Maxim Shibakov

Сильно! Наконец-то что-то очень полезное

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Vitaliy Myshlaev

Спасибо за материал. А где вы этому учились? :)

Ответить
Развернуть ветку
Олег Якубенков

Учился на работе :)

Ответить
Развернуть ветку
11 комментариев
Раскрывать всегда