AB-тест почти всегда живет в плотном контуре принятия решений. Руководителю нужно понимать, не проседают ли ключевые показатели. Команде важно вовремя остановить вариант, который ухудшает метрику, и так же вовремя зафиксировать улучшение, если оно убедительное. Поэтому интерес к проверкам по ходу эксперимента естественен: данные копятся, отчеты обновляются, вопросы возникают каждый день.
Каждый раз, когда в продуктовых чатах заходит речь о проверке гипотез, кто-нибудь обязательно кидает ссылку на калькулятор статзначимости. Мол, «наливаем трафик, ждем p-value < 0.05 и радуемся».
В идеальном мире это работает. В реальности же АБ-тест может стоить компании несколько недель простоя разработки и миллионов недополученной прибыли. Иногда играть в «честный сплит» просто невыгодно.
Длительность. Если вы не Amazon, вам может понадобиться месяц, чтобы добрать выборку. За это время рынок может измениться.
Технический долг.Читать полностью »
В прошлой статье мы разбирали ситуацию, когда есть одна метрика во времени и понятная дата изменения. На практике чаще бывает иначе: изменение затронуло не всех.
Типовые примеры:
релиз раскатан на часть гео,
изменение включено только для определенного сегмента пользователей,
затронуты только отдельные кластеры, каналы, витрины,
контрольной группы в виде AB теста нет, но есть группы, которые не трогали.
У нас есть дата изменения 
. Например, поменяли алгоритм, цены, онбординг, выдачу, лимиты, антифрод, форму оплаты. Есть метрика Читать полностью »
В продуктовой аналитике легко дойти до состояния, когда экспериментов много, а уверенности в решениях мало.
Типовые симптомы:
тест идет «пока не станет понятно»;
MDE забывают зафиксировать (или берут «как обычно»);
p-value проверяют каждый день и закрывают эксперимент на первом же p < 0.05;
ARPU и другие денежные метрики шумят так, что любой вывод спорный;
после релиза эффект не подтверждается, в следствие чего доверие к экспериментам падает.
Всем привет!
Меня зовут Владимир Павлов, я продакт-менеджер. Недавно я проходил кейс-интервью и получил отказ со следующим комментарием: «Правильно выбираешь ключевые метрики, но не хватает измеримости, структуры, прокси‑ и контр‑метрик».
Получив данный фидбек, я решил углубиться в метрики, но не нашел простого инструмента для тренировок их построения и работы с ними. Пришлось создать свой инструмент для этих целей :-)
Оплатив платный доступ к GPT, приступил к Vibe Coding. Весь процесс занял примерно 2 недели, занимаясь по вечерам в будние дни + выходные.
Остановился на следующем объеме функциональности:
За время работы у меня сформировался некий фреймворк, которым я руководствовалась сама и по которому, на мой субъективный взгляд, можно построить здравую, лаконичную систему метрик продукта с понятными взаимосвязями. И вот я дозрела до того, чтобы поделиться им в формате статьи.
Не претендую на абсолютную уникальность, поскольку при его формировании я опиралась и даже во многом переиспользовала существующие фреймворки, адаптируя их под те задачи, которые стояли передо мной. В частности:
Retention - это ключевой метрический показатель для монетизации мобильных и пк-игр. На основе анализа 50+ инди-проектов я выделил три системные ошибки, снижающие Retention на 1-й, 3-й и 7-й день. В статье — практические методы их диагностики и решения без бюджета.
Меня зовут Павел, продуктовый аналитик с опытом в GameDev аналитике, FMCG, Digital и e‑commerce. Помогаю инди‑студиям улучшать метрики через data‑driven решения.
Однажды к новоиспечённому аналитику компании «Линейные уравнения» обратились коллеги из HR-блока с просьбой проверить гипотезу: влияет ли запущенная ими программа обучения на эффективность сотрудников?
Аналитику передали файл с данными [1]Читать полностью »
