Гендиректор аналитической компании Spark59 Эш Маурия написал в своем блоге о трех правилах разработки метрик, которым должны следовать создатели проектов.
В рубрике Growth Hacks — перевод заметки.
Прежде всего, давайте разберемся, что такое рабочая метрика? Рабочая метрика — это такая метрика, которая связывает определенное повторяющееся действие с видимыми результатами. Противоположностью рабочих метрик являются статистические метрики (такие как количество посещений страницы или количество загрузок), которые служат только для того, чтобы зафиксировать текущее состояние продукта, но не дают представления о том, как мы к этому пришли или что делать дальше.
Пивот — это обучение, в то время как оптимизация — это увеличение эффективности. Это же различие можно перенести и на метрики. Как мы дальше увидим, некоторые метрики значат больше других на определенных стадиях развития компании, но более важно то, как следует оценивать эти метрики, что делает их рабочими или статистическими.
Я поделюсь тремя своими правилами, применимыми к рабочим метрикам — они были выделены из принципов lean-стартапа. Также уделю особое внимание тому, какие именно метрики я измеряю, и как я это делаю.
Правило 1: Измеряйте «правильное» макро
Эрик Рис рекомендует сосредоточиться на макроэффекте от проводимых экспериментов (например, количество подписок vs кликов на кнопку). Однако крайне важно сфокусироваться на правильном макроэффекте. Например, потратить массу усилий на то, чтобы стимулировать рост подписок на продукт с низким уровнем удержания — это просто потеря времени.
Определите ключевые метрики
Хорошая новость состоит в том, что действительно важных макрометрик не очень много. Аналитик Дейв МакКлюр выделил всего пять. Из этих пяти только две имеют значение перед проверкой соответствия продукта рынку — активация и удержание.
Прежде чем проверять соответствие продукта рынку, ваша цель — убедиться, что вы создали то, что нужно людям. Для того, чтобы изучать, много источников трафика не нужно — ведь люди обычно не ссылаются на продукт, пока не воспользовались сервисом и если он им не понравился. Поэтому на данном этапе привлечение клиентов и реферальная программа могут быть отложены в сторону.
Создание продукта — это работа над тем, чтобы обеспечить прекрасный первый опыт (активация) и, самое главное, заставить пользователей вернуться (удержание).
Некоторые читатели возможно заметили, что я заменил метрику доходности из версии Дейва метрикой реферальной программы. Это потому, что я верю — брать деньги можно с первого дня, что более естественно сближает (но не замещает) доходность с удержанием.
Установите соответствие метрик с действиями
Следующим шагом — установка соответствия между определенными действиями пользователей, активацией и удержанием.
Действия по активации
Действия по активации обычно начинаются с процесса регистрации и должны заканчиваться ключевыми действиями, которые определяют уникальные конкурентные преимущества вашего продукта.
Функция «рассказать друзьям» здесь используется для того, чтобы прорекламировать пользовательскую галерею, и я не отношу это к пункту «реферальная программа». Лично я считаю, что «реферальными» можно называть те действия, которые представляют собой более существенную поддержку продукта, как, например, с помощью партнерской программы.
Действия по удержанию
Существует несколько способов определить удержание. Эндрю Чен проводит различие между удержанием пользователя и его вовлечением. Лично я предпочитаю привязывать действия по удержанию пользователей к ключевой деятельности, которая определяет уникальные конкурентные преимущества.
Правило 2: Создавайте простые отчеты
Отчетами, которые сложно понять, никто пользоваться не будет. Точно также, если отчет растягивается на несколько страниц (да-да, Google Analytics) не будут иметь практическую ценность.
Я обожаю простые отчеты, занимающие не больше одной страницы, и мне кажется, что воронки — это самый подходящий для этого формат.
Отчет-воронка
Воронки — отличный способ суммировать ключевые метрики. Они простые, наглядные и хорошо отражают процесс активации (и метрики AARRR-стартапа Дейва). Вот пример воронки для сервиса, который предлагает пользователям бесплатную пробную версию на 14 дней:
Но у того последовательного анализа, который сегодня используется в аналитических инструментах, существует ряд недостатков.
Отслеживание событий с длинным жизненным циклом
Например, довольно сложно отследить события с длинным жизненным циклом. Почти все инструменты последовательного анализа используют отчетные периоды, где данные по всем событиям за определенный период времени собираются по всем пользователям.
А это, в свою очередь, искажает цифры на границах воронки. Но, что еще более важно, из-за того, что вы постоянно меняете свой продукт, совершенно невозможно привязать полученные результаты к определенным манипуляциям, которые вы производили месяц назад.
Отслеживание сплит-тестов
Более серьезной проблемой является отслеживание результатов сплит-теста таких макро-метрик как доход, у которого тоже длинный жизненный цикл. Приведу в качестве примера эксперимент, который я провожу в настоящее время — сравнение долгосрочных последствий вывода на рынок условно-бесплатной версии и бесплатной пробной версии программы.
Я считаю, что правильно созданная условно-бесплатная версия должна вести себя как бесплатная пробная версия. Единственная разница между ними состоит в том, что у бесплатной пробной версии истечет срок действия, в то время как с условно-бесплатной версией пользователь спустя какое-то время перерастет предлагаемые сервисом бесплатные функции.
C достаточной степенью уверенности я могу предположить, что с условно-бесплатной версией программы я добьюсь большего количества подписок. Но главный вопрос заключается в том, приведет ли это к увеличению уровня удержания и дохода? И если да, то каково среднее время конверсии (временного периода X)?
Ответить на такие вопросы с помощью существующих в настоящее время инструментов я не могу.
Измерение процента удержания
И, наконец, последовательные инструменты не дают возможности отслеживать удержание, которое по определению требует отслеживания пользовательской деятельности в течение длительного периода времени.
Несмотря на то, что воронки являются прекрасными инструментами визуализации, их одних недостаточно. Инструменты аналитики сегодня работают хорошо для микро-экспериментов по оптимизации (например, показатель конверсии посадочных страниц), но не оправдывают ожиданий в случае экспериментов по изменению стратегии. Лучшее решение — объединить воронки с когортами.
Когортный анализ очень популярен в медицине, где он используется для изучения долгосрочного эффекта от лекарств и вакцин:
Когорта — это группа людей, которые обладают общими характеристиками или опытом за определенный период времени (например, рождены в одно время, принимали одинаковые лекарства или прививались одной и той же вакциной). Таким образом, группа людей, которые были рождены в один из дней определенного периода времени, например, в 1948 году, образуют возрастную когорту. Тогда к группе сравнения будет относиться остальное население, из которого была выделена эта группа, или это может быть еще одна когорта людей, которые не подвергались воздействию исследуемого препарата, но в чем-то схожи с первой группой. Или же, подгруппы внутри одной когорты могут сравниваться друг с другом.
— Wikipedia
Мы можем применить тот же принцип когорты или группы к пользователям и отслеживать жизненные циклы использования приложения за определенный период времени. Условно говоря, когорта — это любой связанный с пользователем параметр, который мы хотим отслеживать.
Наиболее часто используемая когорта — «дата присоединения», но, как мы дальше увидим, такими когортами могут быть и «версия программы», «операционная система», «пол пользователя» и так далее. Давайте посмотрим, как можно применять концепт когорт, чтобы преодолеть недостатки воронок, о которых мы говорили выше.
Отслеживание событий с длительным жизненным циклом
Первый отчет, который я рекомендую вам составить, это «Еженедельный когортный отчет по дате присоединения к проекту». Этот отчет выполняет функцию первой ласточки и является отличным инструментом предупреждения, так как позволяет понять, какие из действий оказывают в целом отрицательное или положительное действие на проект.
Вы группируете пользователей по неделям, в которые они подписались на ваш проект, и отслеживаете все их действия за определенный промежуток времени. Этот отчет был собран из тех же данных, которые мы использовали в воронке выше (которую я снова показал, чтобы было проще сравнивать).
Ключевое отличие когортного отчета от последовательного состоит в том, что кроме данных о присоединении, все остальные пользовательские действия необязательно включать в определенный отчетный период. Вы сразу же заметите, что данные по конверсии очень изменятся (особенно по платной конверсии), потому что когортный отчет не имеет таких проблем с границами, как последовательная отчетность.
Что еще более важно, еженедельный когортный отчет более отчетливо выделяет значительные изменения в метриках, что позволяет связать эти изменения с особым видом деятельности, которую вы совершали в определенную неделю.
Отслеживание сплит-тестов
Кроме мониторинга воронок, когорты могут быть использованы для того, чтобы эффективно измерять результаты сплит-тестирования. Вот отчет, в котором «версия продукта» является когортой в эксперименте «условно-бесплатная версия» vs «бесплатная пробная версия», описанном мною выше.
Оговорка: мой эксперимент «условно-бесплатная версия» vs «бесплатная пробная версия» все еще продолжается, и эти результаты выдуманы.
Вы видите, что несмотря на то, что при пользовании условно-бесплатной версией программы уровень активации выше, однако (пока) доход ниже. Со временем это может поменяться и поэтому важно знать среднее время конверсии, чтобы соответственно скорректировать условно-бесплатную версию.
Вы можете создать когорту из любого пользовательского параметра, который вам нужен, и составить отчет, чтобы ответить на такие вопросы как:
- Какие пользователи конвертируются лучше: владельцы Mac или Windows?
- Подтвердится ли, что одни ключевые слова поиска конвертируют лучше, чем другие?
- Пользователи какого пола конвертируются лучше: мужчины или женщины?
Отслеживание удержания
И наконец, самой важной метрикой проверки соответствия продукта рынку является удержание. Этот отчет сгенерирован с помощью еженедельной когорты по дате присоединения, но вместо отслеживания конверсии, он отслеживает ключевую деятельность пользователей за определенный период времени.
Мы отслеживаем только «Подписавшихся» пользователей, вот почему в течение всего первого месяца уровень удержания составляет 100%. Отчет по удержанию может быстро сказать, двигаетесь ли вы в правильном направлении, создаете ли вы продукт, действительно нужный пользователям, или просто завершаете циклы.
Метрики могут сказать вам лишь то, что делали ваши пользователи. Но не могут ответить на вопрос «почему». Ключевым фактором в превращении метрики в рабочую является то, что вы должны быть способны привязать их к реальным людям. Это полезно не только для того, чтобы определить, где находятся самые активные пользователи, но, что более важно, для того, чтобы определить проблемы, когда что-то идет не так.
И эта последняя часть особенно важна для проверки соответствия продукта рынку, поскольку в это время у вас еще не так много пользователей, и вам больше нужно полагаться на подтверждение качеством, а не количеством.
Вот пример, где я создал список людей, которым не удалось завершить стадию загрузки приложения в моей воронке. Вооружившись этим списком, я могу не гадать, что пошло не так. Я могу просто набрать номер пользователя или отправить ему электронное письмо и спросить его об этом лично.
Как я создаю отчеты
Ранее я уже упоминал, что большинство инструментов аналитики лучше всего подходит для микро-экспериментов по оптимизации, а не макро-экспериментов по изменению стратегии проекта в целом. И на самом деле это разумно, потому что (обычно) оптимизация — это то, что следует делать после проверки продукта рынком, здесь уже задействованы деньги. Раньше я пользовался и KISSmetrics, и Mixpanel, и несмотря на то, что оба эти инструмента хороши в последовательных отчетах, они не оправдали моих ожиданий в когортном анализе.
В настоящее время Mixpanel поддерживает когортный отчет по удержанию, но не последовательную когорту. Я знаком с Хитеном из KISSmetrics и знаю наверняка, что они сейчас работают над когортами. Поэтому, надеюсь, что вскоре мы увидим что-нибудь полезное.
C учетом всего вышесказанного, мне пришлось очень постараться, чтобы провести сплит-тестирование «условно-бесплатная версия продукта» vs «бесплатный пробный период», поэтому в качестве эксперимента я решил потратить день и разработать собственный инструмент когортного анализа, основанный на концептуальных моделях «люди — события — параметры», представление о которых я получил пользуясь KISSmetrics.
Все отчеты, которые вы тут видели, были сгенерированы с помощью этого инструмента.
