“Аналитика - как матан. Ты должен решать много задач в день, чтобы набрать опыт и насмотренность” - Дмитрий Тимко, руководитель в Яндекс браузер.
Продолжаю ботать продуктовую аналитику, наткнулся на очень качественную лекцию Дмитрия Титко в Школе менеджеров Яндекса. Автор дает подробные кейсов выбора метрик для разных продуктов вокруг Яндекс Браузера. Объясняет как метрики фичи связаны с метриками всего продукта, как распределять пользователей по выборкам, а так же почему хорошая метрика может оказаться плохой.
Материал оказался очень интересным и практически полезным. Здесь мало простых и правильных ответов, и много кейсов на подумать. Дальше делюсь своей переработкой лекции.
Теория 1. А/В эксперименты
Случайным образом набираем две равных по размеру группы пользователей
Одной группе раздаем экспериментальное улучшение
Сравниваем выбранную метрику по окончанию
Попадание в выборки А/В должны быть случайными. Не должно быть такого признака, по которому пользователь попал в группу А и не может попасть в группу В, как в примере дальше.
Пример 1. Залогиновость браузера
Есть предположение, что у залогиненного пользователя больше вовлеченность. Давайте увеличивать залогининость. Как проверить гипотезу?
Берем 100,000 пользователей, смотрим сколько из них залогинилось, допустим 25,000.
Берем еще 25,000 из этой же выборки, которые не залогинились, и сравниваем
Вторая группа действительно перформит лучше на 10%, все хорошо?
В чем ошибка:
Люди, которые залогинились могли быть изначально более мотивированы, по этому лучше перформили.
То есть в группу B пользователи попали не случайно, а по признаку того, что залогинились в браузер.
Результат нельзя считать достверным.
Теория 2. Правила подбора метрик
Необходимо выбрать одну метрику, на которую вы в конце посмотрите.
Да, могут быть граничные условия, но важно выбрать один пункт. Это может быть комбинация метрик.
Если важно нарастить одно, не просадив другое - отслеживайте сумму (разность) метрик.Проверяем, может ли быть так, что мы улучшили метрику, при этом на самом деле ухудшив продукт.
Определяем список других фич (элементов экосистемы) продукта, которые могут пострадать, от улучшения нашей фичи.
Пример 2. Промо-страница браузера
Улучшаем промо-страницу браузера.
На странице есть УТП и кнопка скачать. На первый взгляд кажется, что задача:
Снизить отказы.
Поднять клики по кнопке загрузки
Почему это плохая метрика? По тому что можно скачать, но не установить. Продукту нужны не скачивания, а установки. Установки тоже не являются хорошей метрикой. Можно установить, но не пользоваться.
Для продукта в целом - Браузера - важно не оптимизировать промо-страницу, а поднять метрики продукта, какие это могут быть метрики:
Из предложенных, Дима выбирает метрику Usage (среднее время) по тому, что:
Usage не подходит по тому, что привлекая пользователей с большим Usage ты можешь терять пользвоателей с меньшим, Возвращаемость снизится, а время Usage. (Чтобы бороться с этим можно сегментировать пользователей и выкатывать улучшение только тем, кому оно нужно. )
DAU плох тем, что падает в низкий сезон, а это не означает что продукт плохо работает. Просто летом люди меньше сидят в интернете.
Время хороший прокси выручки в случае браузера.
В случае Браузера есть метрика еще лучше:
Интересные статьи
Интересные статьи
