Метрики продукта: какие показатели смотреть сервису и приложению

Показатели нужны для выбора следующего изменения

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

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

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

Сначала договориться, что считается полезным действием

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

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

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

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

AARRR помогает не потерять часть пути

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

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

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

Активация заканчивается первой полученной пользой

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

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

В учебном примере из ста новых зарегистрированных пользователей тридцать получили подтверждение первой записи в выбранное окно. Доля активации для такой группы равна 30%. Это арифметика примера. Если считать от открывших календарь, показатель отвечал бы на другой вопрос, поэтому для команды полезнее полное название «доля новых регистраций с подтверждённой записью», чем короткое слово «конверсия» без пояснения.

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

DAU и MAU зависят от определения активности

DAU и MAU показывают размер активной аудитории за разные интервалы. Без определения активности эти сокращения остаются слишком широкими.

В руководстве Amplitude DAU относится к уникальным активным пользователям за день, MAU — за месяц, WAU — за неделю. Отношение DAU к MAU используют как показатель частоты использования. В самом сервисе активность по умолчанию связана хотя бы с одним событием, которое не помечено неактивным. Поэтому готовая настройка аналитики не обязательно совпадёт с полезным действием вашей компании.

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

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

Удержание сравнивают на одинаковом сроке

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

Amplitude различает возврат в точный день, Return On, и возврат в этот день либо позже, Return On or After. Это разные расчёты. Команде следует записать выбранное правило и событие возвращения, поскольку вход ради отмены старой записи и новая подтверждённая услуга могут означать разную ценность, хотя технически оба действия показывают, что пользователь снова открыл сервис.

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

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

Дерево связывает результат с доступными действиями

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

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

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

North Star не заменяет экономику и качество

North Star выбирают как главный ориентир получаемой пользователем ценности. Он помогает согласовать приоритеты команды.

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

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

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

Короткое задание на измерение продукта

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

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

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

Такой бриф можно использовать при обсуждении аналитики и развития сервиса в ШТАБ ИТ. Он задаёт вопрос для анализа. Команда получает возможность выбирать изменения по понятному результату, а новые графики появляются там, где действительно помогают объяснить действие пользователя и оценить полученную пользу.