Блог UnionVK

Самое важное число, или о главной метрике продукта

Представь себе продукт, которым ты пользуешься каждый день. Онлайн-магазин, стриминг или игру. Как компании их улучшают? Что добавить, убрать, куда инвестировать больше ресурсов? Для ответа на этот вопрос в enterprise существует главная метрика продукта.
В этой статье поговорим о том, что это, как она связана с KPI, проведением интенсивных A/B-тестов и другими показателями.
Спикер: Павел Запольский, ex-Yandex, ex-Playrix, ML Expert, Co-founder & CEO Stealth Startup.

UnionVK

Материал подготовлен на основе онлайн-встречи UnionVK, неофициального сообщества текущих и бывших сотрудников группы VK. Полная запись встречи доступна всем участникам сообщества в закрытой базе знаний. Смотри тизер с хайлатами встречи на нашем YouTube-канале или VK Video.

Определение главной метрики

Это функция, которая измеряет ключевую ценность продукта. Она воплощает в себе суть продукта и его влияние на бизнес, независимо от сектора – e-com, fintech или gamedev. Чтобы метрика работала, она должна обладать четырьмя важными свойствами:
  1. Качество — показывает, насколько хорош продукт для клиента. Например, сколько времени пользователи проводят на сайте или как часто они возвращаются (всё, из чего складывается retention).
  2. Доходность — не забываем про деньги! Продукт должен зарабатывать, например, с помощью кликов по рекламе. И метрика должна это отражать.
  3. Измеримость — это свойство актуально для больших корпораций, которые стремятся повысить экспертность в дата-категории. Поэтому метрика должна быть легко измеримой, чтобы на её основе можно было проводить A/B-тесты и принимать решения.
  4. Интерпретируемость — важно, чтобы показатель был понятен не только дата-специалистам, но и бизнесу. Поэтому она должна коррелировать с KPI и финансовыми отчетностями. Если метрика сложно объяснима, она может спровоцировать неверные решения.

Проблемы ключевой метрики

Важно понимать: интегральная метрика актуальна прежде всего для enterprise-компаний. В связи с этой спецификой можно ожидать ряд проблем.
  • Множественность тестирования. Когда смотришь одновременно на несколько показателей, растёт шанс ошибки в A/B-тесте.
  • Низкая плотность тестов. Возникает необходимость её повысить, особенно когда простые техники типа CUPED утилизированы.
  • Непонятно, как оценить эффект в спорных ситуациях. Если показатель вовлечённости растёт, а доходность падает. Что делать?
Давай разберём последнюю ситуацию на примере.
У нас есть сайт, на который мы помещаем рекламу. Если мы заспамим его полностью этими рекламными баннерами, метрика дохода может расти: человек просто не сможет не кликнуть на неё. Однако пользователи, которых это бесит, начнут уходить. Из-за этого в долгосрочной перспективе продукт будет проигрывать. Поэтому важно сохранить баланс между выгодой конкретного носителя и его качеством.
Главная метрика полезна и для поддержания баланса продуктового качества и монетизации при мониторинге.

Представим, что мы выкатили патч 14 июля. И он оказался плохим: в его результате мы заспамили пользователей офферами. Так случилось, потому что мы забыли провести A/B-тест. 20 июля мы заметили что-то неладное, увидев, что наша метрика вышла из доверительного интервала.

Но согласись: было бы странно абсолютно все показатели измерять доверительными промежутками и скользящими окнами. Иначе от рандомных алертов в программе не избавиться.

Таким образом, и здесь не хватает интегральной чувствительной метрики.

В поисках метрики | Почему плохо смотреть на GMV?

GMV (Gross Merchandise Value, или валовая стоимость товара) – совокупная стоимость всех товаров, проданных на площадке в единицу времени.
Если мы выбираем GMV в качестве ключевой метрики, то мы без труда сможем придумать решения, которые дадут результаты на коротком промежутке, но станут не выгодным стратегически.

Предположим, у нас есть сайт, который продаёт тапки 🩴. Мы можем накидать на него много беспорядочных офферов – из разных магазинов, с разными сниппетами. Сразу после этого, как мы ожидаем, люди начнут больше покупать. Ведь у нас богаче ассортимент. За первый месяц мы таким образом поднимем GMV. Однако затем окажется, что тапки-то плохого качества. Поэтому вторая конверсия в покупку того же клиента нам не светит 😞

Стратегически целесообразным решением будет уходить в сторону повышения качества продукта: настраивать фильтрацию и прочие показатели. Да, мы понизим GMV. Зато пользователю не попадётся на странице тапок какой-нибудь фалоимитатор. 🔞

В поиске главной метрики | Q&A

  • Какова должна быть чувствительность главной метрики?
0,5-0,8х относительно клика (то есть достаточно чувствительной).

  • Какое необходимо распределение?
Нормальное или логнормальное.

  • Каким образом метрика должна быть связана с ARPU, Retention и DAU (т.е. с финансовыми и продуктовыми показателями)?
Скоррелированы >0,7 на длинных дистанциях, чтобы не было ситуации, когда показатели прибыли или вовлечённости растут, а ключевая метрика падает.

Формулировка и обучение главной метрики

  • Как же найти эту самую главную метрику? Это можно представить как задачу машинного обучения. Мы берем много маленьких метрик — клики, время на сайте, транзакции и так далее — и пытаемся создать из них единую функцию, которая будет чувствительной к изменениям продукта. Для этого используют классический метод — линейную регрессию. Если тебе, как и котику ниже, хочется чуть больше математики, то вот как выглядит формула:
Такую чувствительную метрику мы будем называть NorthStar ✨

Как тестировать и обучать NorthStar?

С помощью датасета экспериментов. Обычно он состоит из 20% АА-тестов, 30% улучшающих и 50% ухудшающих. О последних двух расскажу ниже.

Улучшающий тест – такой, в котором однозначно видно улучшение всех ключевых метрик продукта или ситуация со средними показателями на старте, но высокими в результате релиза (например, если фича фундаментально улучшила продукт).

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

А как проверить, что метрика работает?
1.Использовать кросс-валидацию

Берёшь 80% данных для тренировки и 20% для тестирования. При этом важно, чтобы ухудшающие тесты показывались как красные (плохие), а улучшающие — зелёными (хорошими). Также нужно следить, чтобы значение Z-score было маленьким. Это показатель, который помогает понять, насколько результат отклоняется от среднего.

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

Например, с доходами или ключевыми показатели эффективности (KPI). Представь, что ты протестировал метрику и всё выглядит отлично, но через несколько месяцев выясняется, что тесты на самом деле шли в сторону, противоположную целям компании. 😱 Поэтому важно, чтобы метрика хорошо коррелировала с бизнес-показателями.

3.Исключить риск переобучения

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

4.*Настроить предсказуемость

Это дополнительный показатель – для гениев ML из больших корпораций.

Есть метод, который помогает улучшить точность A/B-тестов с помощью предикторов — это показатели, которые помогают предсказывать результат теста. Важно проверить, насколько хорошо метрика поддаётся предсказанию. Это значит, что при синтетическом тестировании, где нельзя чётко разделить клиентов на разные группы, мы бы использовали технику uplift-моделирование для предсказания влияния изменений.
Но нужно быть готовым: даже после выполнения всех пунктов метрика может плохо поддаваться предсказанию. А это сигнал: нужно что-то улучшить.

Идеальная модель для NorthStar

1.В качестве основы у нас – линейная регрессия:
2.Все компоненты метрики (клики, время, конверсии) должны быть строго положительными или строго отрицательными. Например, если улучшение одной метрики (скажем, рост кликов) улучшает качество продукта, это положительная компонента. Ставим плюсик. Если человек вышел из приложения и не продолжил действие по конверсии – минус.

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

А что в итоге?

Использование главной метрики имеет ряд преимуществ.
  • Во-первых, с её помощью можно проводить интенсивные A/B-тесты за счёт чувствительности. При этом показатель интенсивность увеличивается в 5-7 раз.
  • Во-вторых, она легко интерпретируется, что очень важно для бизнеса. Можно разгрузить команду аналитиков и дать менеджерам возможность самим принимать решения на основе понятных данных. А ещё по ней легко сделать вывод о причинах успеха или провала фичи.
  • В-третьих, мы защищаем себя от неверных решений, выбирая вместо «заспамить ленту баннерами» рабочий вариант на длительный отрезок времени.
Важно! Чтобы настроить NorthStar, в компании должен быть аналитик, знающий ml на продвинутом уровне.
Помешать внедрению NS-метрики может сложно организованный KPI, который не коррелирует с нашим ключевым показателем.

Альтернативы компонентной метрике

  1. GMV – для e-com. Но будь с ней осторожней (об этом мы рассказали выше).
  2. Популярной метрикой, например, в медиа-сервисах является Total View Time – общее время просмотра. Она хороша для понимания, насколько пользователям нравится контент, но слишком подвержена сезонности и не всегда даёт точные результаты при тестах.
🦸Главная метрика продукта – супергерой, который всегда на страже качества и доходности твоего продукта. Она помогает не скатиться в погоню за деньгами в ущерб пользователю и даёт возможность эффективно принимать решения на основе данных. Ищем свою главную метрику, балансируем качество и доходность, и вперед — к успеху!

Двигаться к нему быстрее ты сможешь, если продолжишь изучать материалы Union VK😉

Читай далее

Developer Experience: поиск счастья для технической команды
Как создать copilot
2024-09-04 19:00 ML/AI