Какие метрики выберем?

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

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

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

С метриками существует интересное противоречие — мы хотели бы иметь одну универсальную метрику (некоторые утверждают, что для web-продукта достаточно MAU или retention, не верьте им), но у вас всегда будет набор метрик, каждая из которых освещает только часть успеха продукта.

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

Примеры метрик web-продукта: количество активных пользователей за месяц (MAU), возврат пользователей, число новых пользователей, удовлетворённость пользователей, доходы от продажи услуг.

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

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

Мы можем: измерять всё подряд, измерять цели, измерять изменения.

Измеряем всё подряд

Несмотря на то, что задача может, на первый взгляд, показаться нерешаемой — она уже давно и успешно решается программными продуктами, многие их которых ещё и бесплатные. Конечно, речь идёт о Google Analytics, Яндекс Метрика и других подобных системах (например, Alexa, Piwik, SimilarWeb, MixPanel).

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

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

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

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

Измеряем (пользовательские) цели

Естественно, с этого следует начать. Даже, точнее, следует начать с выделения целей, потому что:

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

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

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

Собрав все метрики сценариев мы можем сформировать множество метрик целей:

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

Измеряем бизнес-цели

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

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

Если ваши бизнес-цели не укладываются в пользовательские сценарии, то что-то здесь не так: или пользовательские цели или бизнес-цели.

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

Измеряем изменения

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

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

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

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

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

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

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

“Здравый смысл”

Хочу отдельно обговорить изменения в соответствии со здравым смыслом, вроде как не подразумевающие использование метрик. Такие задачи могут быть сформулированы по-разному, например “давайте сделаем кнопки с закруглёнными углами, а то с прямыми смотрятся не эстетично”, а то вовсе и без объяснения причин.

Однако, я настаиваю, часто такие небольшие изменения ведут к значительным изменениям в CTR, которые никто и не думает замечать.

Есть мнение, что “баги” можно исправлять как раз такими задачами, но и это далеко не всегда так. Одно дело, если у вас ошибка вида “500 Server Not Responding”, когда исправление ошибки приводит к восстановлению работоспособности ресурса, и совсем другое дело, если какой-то поисковый параметр неправильно применяется, но это ведёт к лучшей конверсии.