Продакту, кейсы по аналитике из Яндекса. (Отличаем хорошие метрики от плохих)

“Аналитика — как матан. Ты должен решать много задач в день, чтобы набрать опыт и насмотренность” — Дмитрий Тимко, руководитель в Яндекс браузер.

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

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

Теория 1. А/В эксперименты

• Случайным образом набираем две равных по размеру группы пользователей

• Одной группе раздаем экспериментальное улучшение

• Сравниваем выбранную метрику по окончанию

Попадание в выборки А/В должны быть случайными. Не должно быть такого признака, по которому пользователь попал в группу А и не может попасть в группу В, как в примере дальше.

Пример 1. Залогиненность браузера

Есть предположение, что у залогиненного пользователя больше вовлеченность. Давайте увеличивать залогиненность. Как проверить гипотезу?

• Берем 100,000 пользователей, смотрим сколько из них залогинилось, допустим 25,000.

• Берем еще 25,000 из этой же выборки, которые не залогинились, и сравниваем

• Вторая группа действительно перформит лучше на 10%, все хорошо?

В чем ошибка:

• Люди, которые залогинились могли быть изначально более мотивированы, по этому лучше перформили.

• То есть в группу B пользователи попали не случайно, а по признаку того, что залогинились в браузер.

Результат нельзя считать достверным.

Теория 2. Правила подбора метрик

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

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

• Определяем список других фич (элементов экосистемы) продукта, которые могут пострадать, от улучшения нашей фичи.

Пример 2. Промо-страница браузера

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

• Снизить отказы.

• Поднять клики по кнопке загрузки

Почему это плохая метрика? По тому что можно скачать, но не установить. Продукту нужны не скачивания, а установки. Установки тоже не являются хорошей метрикой. Можно установить, но не пользоваться.

Для продукта в целом — Браузера — важно не оптимизировать промо-страницу, а поднять метрики продукта, какие это могут быть метрики:

Из предложенных, Дима выбирает метрику Usage (среднее время) по тому, что:

• Usage не подходит по тому, что привлекая пользователей с большим Usage ты можешь терять пользвоателей с меньшим, Возвращаемость снизится, а время Usage. (Чтобы бороться с этим можно сегментировать пользователей и выкатывать улучшение только тем, кому оно нужно. )

• DAU плох тем, что падает в низкий сезон, а это не означает что продукт плохо работает. Просто летом люди меньше сидят в интернете.

• Время хороший прокси выручки в случае браузера.

В случае Браузера есть метрика еще лучше:

• ? Суммарные переходы на сайты из Яндекс Браузера.
  Это доля всех страниц в интернете открытых Яндекс браузером, по сравнению с другими браузерами — есть сервис Радар, он показывает.
  (я отметил метрику значком для удобства, по тому что мы будем возвращаться к ней далее в статье)

Возвращаясь к промо-странице

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

(NB) Привязывать фичу к высокоуровневым метрикам продукта не всегда получается. Метрики могут не “прокрашиваться” в течении долгого времени (не показывать стат. значимых изменений).

В таком случае придется придумать более узкую метрику самой фичи. Если более узкую метрику придумать супер сложно, а общие метрики не прокрашиваются, возможно придется отказаться от фичи совсем ?

Заметка Про возвращаемость.

Есть разные retention — rolling retention, churn, x-day retention. В рамках лекции мы будем использовать возвращаемости 2й недели. Сколько и тех людей, которые поставили продукт 2 недели назад им пользовались.

Пример 3. Пуш с погодой

В яндексе есть крутая погода. Решили попробовать показывать пуш с текущей погодой пользователю на экране заставки. Как измерить эффективности фичи и почему retention в данном случае плохая метрика?

• Идея пуша, нанести пользу, и вырастить retention за счет любви пользователя, а не из-за случайного/импульсивного нажатия на push.

• Пуш с инфо о погоде такой продукт, на который не обязательно нажимать. Все данные видны сразу.

Ввели уточненный retention.
Стали считать только тех пользователей, которые видели пуш, но:

• Не нажимали на него вообще.

• Нажимали, но не ограничивались просмотром погоды, а делали другие свои дела. (пользователь и так собирался поработать в браузере, пуш просто ускорил начало сессии)

Если такой retention растет, значит пуш наносит пользу и растит лояльность. Как видите, с retention приходится танцевать с бубном, по этому общие метрики лучше:

• ? Суммарные переходы на сайты

Пример 4. Работа с фонами

• Может быть измерять сколько людей пришло на галерею? Хорошая метрика для начала, но хочется что-то ближе к целевому действию (просмотры сайтов через браузер)

• Может быть опять общие метрики продукта (usage, retention?) они долго не прокрашивались. Нужно выбрать метрику самой фичи.

• Может быть число смен фонов в день?
  Может быть что пользователи меняют фон, который им не нравился, метрика растет. Хорошо это или плохо?

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

• Решили вернуться к общему retention. Да, прокрашиваться будет долго, а может вообще не прокрасится. Но раз фича такая сложная, мы попробуем оценить ее влияние на retention.

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

Пример 5. Дзен в браузере

Добавили новости и погоду на главную страницу в браузере, как измерить эффективность?

• ? Суммарные переходы на сайты.

• Retention

Суммарные переходы и возвращаемость выросли, но в чем здесь проблема?
В Яндексе есть другие продукты, которые пострадали.

• Люди стали потреблять новости и погоду на главной странице браузера, и, возможно перестали приходить за этим на главную страницу Яндекса.

• Но на главной странице Яндекса есть другие фичи, например оповещения о ЧП и другая соц. ответственность.
  Общие метрики продукта могли вырасти, но команда главной страницы недовольна. Улучшив свою фичу, мы сильно сократили использование другого сервиса в экосистеме.

В итоге, добавили на главную страницу браузера несколько виджетов, ведущих на главную страницу Яндекса и все довольны.

Пример 6. Оффлайн копии страниц

Если вы читали какую-то страницу (на мобильных ос), потом свернули и через какое-то время открываете — страница грузится заново. А если это лонгрид — вы потеряли скролл, на котором вы были. А если это случилось на эскалаторе, а если в самолете? Решили сохранять любую открытую страницу на устройстве. Как измерить улучшение?

? Суммарные переходы на сайты?

• Проблема в том, что меняется паттерн поведения. Пользователь осознав эту фичу может по-наоткрывать себе закладок перед входом в метро, чтобы почитать потом. Для доли пользователей суммарные переходы вырастут.

• С другой стороны, раньше, некоторые страницы приходилось открывать дважды. А с этой фичей повторных загрузок не требуется, суммарные переходы упадут.

• Еще проблема — оффлайн просмотры не генерят показы рекламы, что наказывает создателей контента. Улучшая продукт надо думать о пользе всей экосистемы. Стараясь улучшить опыт с помощью офф-лайн просмотров, надо улучшать еще и онлайн использование.

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

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

• e Usage — Среднее время использования

• DAU — Активных пользователей в день

• Retention — Возвращаемость

• Возвращаемость 90го дня