В дисциплине управления продуктами фраза «принятие решений на основе данных» часто используется там, где каждый руководитель проекта(PM) утверждает, что он или она является истинным евангелистом практики. В то время как компании продолжают повторять свою метрику «Полярная звезда», чтобы команды могли сосредоточиться на ней, иногда PM-ы часто сталкиваются с трудностями, чтобы разбить ее на метрики, которые действительно работают и оптимизируют их.
Многие распространенные инструменты, такие как Google Analytics или Mixpanel, предоставляют инновационные способы фиксировать и анализировать поведение пользователей, хотя их дефолтные или стандартные показатели отслеживания рассказывают только часть истории.
Мы часто можем слишком полагаться на метрики тщеславия, которые по умолчанию отслеживаются в инструментах отслеживания с некоторыми настраиваемыми на базовом уровне отслеживанием событий. Даже самые популярные фреймворки, такие как Pirate Metrics или HEART, нуждаются в настройке контекста, чтобы иметь возможность предоставлять действенные идеи.
Я обнаружил, что они часто определяют то, что происходит в ситуации, но чтобы ответить, добавляет ли наш продукт ценность жизни пользователей, нам нужно копнуть глубже, и, следовательно, мы должны выдвигать гипотезы о том, что за этим стоит.
Этот момент является критическим, потому что вывод «Почему» может быть пронизан различными предубеждениями со стороны РМ. На этом этапе часто можно сразу броситься к решению, если показатели кажутся проблематичными, и это тоже, если у нас даже есть базовый уровень или контрольный показатель для начала или целевые показатели, установленные внутренними заинтересованными сторонами. Часто из-за недостаточной осведомленности об отраслевых стандартах определенных показателей мы часто принимаем наши цифры в качестве ориентира.
Метрики должны отражать не только то, что мы достигли, но и то, что мы заставили достичь наших клиентов. Если у вас контентный веб-сайт, возможно, времени, проведенного на странице, или показателя отказов страницы недостаточно. Возможно, вам нужно знать, нашел ли ваш пользователь контент интересным после 5 минут чтения, смог ли он понять или сохранить то, что он или она прочитал, или же пользователь изучает тему еще глубже.
Если ваше экономическое обоснование требует регулярного взаимодействия с клиентами, например приложения B2B, тогда вам как нельзя больше повезет, когда дело доходит до определения потребностей клиента и на каком этапе вы находитесь на пути к соотношению продукта / рынка. Для массовых потребительских товаров это становится совершенно трудным, потому что объем вашего взаимодействия с клиентами становится ограниченным, и единственный способ измерить успех клиента - это хорошо представленные метрики продукта CPI + KPI, а не только KPI.
Но мы должны проявлять осторожность, потому что каждая точка данных, которую вы собираете, требует дополнительных затрат в системе и только добавляет сложности. Следовательно, для более глубокого анализа нам нужен эффективный план отслеживания, который точно фиксирует эти CPI и KPI.
Задавать правильные вопросы или строить гипотезу
Я обнаружил, что задавая себе основные вопросы об успехе продукта или возможных проблемных точках, я действительно могу найти правильные показатели, на которых можно сосредоточиться. Часто это не может быть выполнено с помощью функций отслеживания по умолчанию распространенных инструментов аналитики, и нам, возможно, придется использовать их расширенные пользовательские функции отслеживания.
Первый шаг к планированию расширенных требований к отслеживанию - вопрос, какие поведенческие аспекты вы считаете жизненно важными и действительно отражающими успех вашего клиента или его проблемные места. Эти поведенческие аспекты представляют собой ваши типичные общие вопросы с простой формулировкой, которые вы задаете себе или своим внутренним заинтересованным сторонам, чтобы получить направление.
На пример:
Какой тип контента заставляет нас казаться заслуживающими доверия?
Достаточно ли интересны изображения наших продуктов, чтобы стимулировать конверсии? А какие типы изображений более эффективны?
Находят ли наши продавцы ценность в заявке продавца?
Вывод объясняющих метрик для каждого вопроса / гипотезы
На каждый из этих вопросов можно ответить с помощью комбинации показателей Focus, L1 или L2, как их называет Mixpanel.
Какой тип контента заставляет нас казаться заслуживающими доверия?
На этот вопрос можно ответить с помощью следующих метрик или методов:
Уровни потребления контента: чтение или участие
Темпы роста трафика
Повторные посещения
Возможность совместного использования
Преобразования
Рост одних типов контента за счет других
Социальные прослушивания
И многое другое.
Достаточно ли интересны изображения наших продуктов, чтобы стимулировать конверсии? И какие типы изображений более эффективны?
На этот вопрос можно ответить с помощью следующих метрик или методов:
Время, затраченное на просмотр каждого типа изображения
Тестирование причинно-следственной связи или корреляции между вовлеченностью изображений и конверсиями
Последствия немедленных преобразований
Шаги перед преобразованием
И многое другое.
Находят ли наши продавцы ценность в приложении продавца?
На этот вопрос можно ответить с помощью следующих метрик или методов:
Заморозка продукта (DAU против MAU или DAU против WAU или WAU против MAU)
Товарооборот
Темпы роста запасов
Темпы роста продаж
Темпы роста маржи
Добавление категорий
И многое другое.
Часто мы можем рисовать частичную картину с помощью легко доступных показателей, таких как пользователи, сеансы, просмотры страниц, DAU, WAU, MAU, отказы, выходы, продолжительность сеанса. Но из приведенных выше примеров ясно, что этих высокоуровневых легко доступных метрик L1 обычно недостаточно для мониторинга состояния вашего продукта. Ваше партнерское приложение продавца может иметь большую заморозку, т.е. продавцы часто заходят в приложение, что может заставить нас думать, что мы делаем отличную работу. Но если он или она не увеличивает уровень запасов и не меняет их часто, то они, вероятно, не смогут ни получить большую ценность, ни получить полномочия делать больше.
Это приводит нас к следующей части проблемы - необходимости более подробных требований к отслеживанию для конкретных продуктов. Многие люди предостерегают от практики чрезмерного отслеживания из-за технических сложностей, дублирования и ограничений инструментов. На мой взгляд, ваши требования к аналитике можно назвать чрезмерно отслеживаемыми только тогда, когда отслеживаемое поведение не связано с основными функциями или функциями продукта, а также когда нет основного вопроса, на который нужно ответить, или гипотезы, которую нужно подтвердить / опровергнуть.
Аудит существующего внедрения и оценка пробелов
Как только мы осознаем, что нам нужно мониторить, чтобы ответить на наши вопросы, нам нужно понять, сможем ли мы использовать стандартные схемы отслеживания инструментов, а также существующие схемы отслеживания. Кроме того, нам нужно будет заполнить пробел между необходимыми требованиями к отслеживанию и существующим отслеживанием. Часто для реализации метрик L1 или L2 нам может потребоваться помощь нашей внутренней технологической группы, поскольку они сложны и специфичны для нашего варианта использования, а автоматическое отслеживание сторонних инструментов может не фиксировать их самостоятельно.
Создание плана отслеживания и выбор правильного инструмента
Есть несколько рекомендаций, которым я следую при составлении требований к аналитике или плану отслеживания:
Я рекомендую использовать инструмент управления тегами для регистрации отслеживания в одном или нескольких инструментах аналитики. В противном случае, например, если мы используем Google Analytics и Mixpanel, оба из которых имеют разные форматы полезной нагрузки, то для команды станет кошмаром реализация и тестирование для каждого инструмента. Следовательно, я рекомендую использовать datalayer (для веб-страниц) или переменные firebase (для мобильного приложения) и использовать Google Tag Manager для запуска этих событий для одного или всех аналитических инструментов непосредственно через менеджер тегов в режиме plug and play.
Разделите разделы или компоненты по отдельности, чтобы отслеживать их собственную подверженность и собственный уровень вовлеченности. Например, если виджет на вашей основной целевой странице значительно опускается вниз по странице, возможно, его уровень взаимодействия не следует сравнивать с количеством посещений на странице, а скорее с количеством пользователей, просматривающих виджет.
Сохраняйте единообразие в своих соглашениях об именах и схемах переменных. Это дает преимущество не только в удобочитаемости, но и в согласованных схемах, а присвоение имен может помочь в автоматизации отчетов. Например, решите, хотите ли вы небольшую схему кейсов: added_to_cart или более читабельную “Добавлено в корзину”, и во всех экземплярах используйте ее.
Я рекомендую явно обозначать имена событий в их истинной форме и форме причастия прошедшего времени. Вовлеченность не всегда определяется «кликами». Для такого приложения, как Bumble, где можно выполнять основные функции, проводя пальцем влево / вправо / вверх / вниз, щелчки не имеют большого значения и, следовательно, также должны отражаться в соглашениях об отслеживании. Поэтому в этом примере важно передавать имена событий в их истинной форме, например, «Смахнуть вправо», «Смахнуть вверх». Точно так же, если пользователь начинает просмотр видео или приостанавливает его, вместо того, чтобы называть его нажатием кнопки, мы должны назвать их «Воспроизведено видео» или «Видео приостановлено». Это связано с тем, что могут быть другие способы воспроизвести или приостановить видео без экранных кнопок, например, с помощью кнопок наушников. В этом случае вы можете фиксировать дополнительную информацию в параметрах события, а не в самом имени события.
Избегайте повторной отправки автоматически собранной информации. Например, URL-адрес страницы или пользовательское устройство автоматически собираются GA при каждом обращении, и их не нужно отправлять в названиях событий. Это важно для Google Analytics, потому что количество уникальных событий показывает количество уникальных комбинаций категорий + действий + меток в сеансе для пользователя. Наличие избыточной информации в любом из трех полей событий увеличивает количество уникальных событий, если какая-либо из добавленных переменных может иметь несколько значений, поэтому вы не сможете отличить общее количество событий от уникальных событий. Помимо этого, рекомендуется оптимизировать количество имен событий таким образом, чтобы они требовали наименьшего количества имен или комбинаций. Это связано с тем, что некоторые инструменты имеют ограничения отдельных событий, например Firebase (500 событий). Также становится проще анализировать данные без необходимости выполнять слишком много агрегирования, поворота или сегрегации данных.
Наш план отслеживания и выбор инструмента идут рука об руку при разработке требований. Вам может понадобиться формат типа Google Analytics, где сверху вниз классифицируется Категория > Действие > Ярлык, чтобы регистрировать одни события или одно событие имени для других. В некоторых случаях вам просто понадобится инструмент тепловой карты, чтобы увидеть самые сильные и слабые места страницы. Следовательно, выбор инструмента зависит от:
Как вы собираетесь читать данные
Уровень сложности в сценариях и сборе данных
Какие возможности визуализации вам нужны
Насколько масштабируемым может быть ваш план отслеживания и какие инструменты имеют ограничения на использование, препятствующие масштабированию
Какие инструменты являются бесплатные, платные или условно бесплатные
Нужны ли вам возможности взаимодействия на основе Journey (CleverTap, Moengage), такие как отправка push-уведомлений, электронных писем или SMS.
Я обнаружил, что описанный выше пятиступенчатый подход действительно эффективен при разработке руководящих принципов на уровне команды для внедрения расширенной аналитики продуктов. Это также помогло в обеспечении согласованности в соглашениях по продуктам и сделало команды более чувствительными к тому, чтобы копать глубже, чтобы обеспечить успех продукта, сохраняя при этом контроль за сложностями.
Статья написана Олегом Мельником в рамках курса «Продуктовая аналитика».
Всех желающих приглашаем на бесплатное demo-занятие «Метрики для жизненного цикла продукта». На занятии мы поговорим о взаимосвязи продуктового термина жизненного цикла с аналитическими метриками. Уже в рамках занятия вы сможете разобраться, какие отличительные черты характерны для каждого жизненного цикла продукта/компании и какие метрики необходимо замерять на каждом этапе, а на какие можно обратить чуть меньше внимания и приложить чуть меньше усилий аналитика.
>> РЕГИСТРАЦИЯ
