📈 Продуктовые и бизнес-метрики

Короткий ответ Без рандомизации точную причинность установить нельзя, но можно получить разумную оценку эффекта с явными допущениями через difference-in-differences (сравнение изменения retention у затронутой группы с похожей незатронутой/рынком-контролем до и после), синтетический контроль или matching — выбор метода и его ограничения нужно явно обсуждать, единственно верного решения здесь нет. Как это работает подробнее diff-in-diff сравнивает изменение метрики "до/после" в группе, где фича была включена, с изменением в контрольной группе (например, другой рынок/платформа, где фичи не было), опираясь на допущение "параллельных трендов" (без фичи обе группы менялись бы одинаково); synthetic control конструирует искусственную контрольную группу как взвешенную комбинацию нескольких непострадавших сегментов, лучше повторяющую довходной тренд. Проверка: убедиться, что тренды retention на iOS и Android были похожи в периодах до раскатки (plot pre-trend) — иначе допущение diff-in-diff нарушено и оценку нельзя счит

Читать полностьюcausal-inference

Короткий ответ Да, но только если retention и churn считаются на одной и той же базе, за один и тот же период и с одинаковым определением активности — тогда retention = 1 − churn. Как это работает подробнее retention и churn — зеркальные метрики: если из базы N пользователей k ушли (churn = k/N), то оставшиеся N−k вернулись (retention = (N−k)/N = 1 − churn). Что использовать на практике Применение. проблема возникает, когда retention считают как rolling retention ("вернулся хотя бы раз после дня N"), а churn — как classic ("не было активности именно в этот период"); такие метрики считаются на разных базах и не обязаны давать в сумме 100%. Проверка или пример. Если бы retention считался как rolling (включая тех, кто вернулся позже месяца), сумма с classic churn уже не дала бы ровно 100%. Подводные камни Частая ошибка. сравнивают retention за один период (например, недельный) с churn за другой (месячный) без пересчёта на общий период; забывают, что если из знаменателя retention исключены удалённые аккаунты, а и

Читать полностьюchurn

Короткий ответ Нет единственно верного горизонта — короткий горизонт (например, 3 месяца) даёт быстрый и менее "модельный" сигнал, но может систематически недооценивать каналы с медленным раскрытием ценности (например, органика/SEO), а длинный горизонт (12-24 месяца) точнее отражает полную ценность, но требует больше допущений об экстраполяции и данных для валидации; выбор должен зависеть от скорости принятия решений бизнесом и характера жизненного цикла пользователей в разных каналах. Как это работает подробнее разные каналы привлечения могут приводить пользователей с принципиально разными кривыми retention — performance-реклама часто приводит пользователей с быстрым, но коротким всплеском активности, тогда как органические/referral-пользователи могут "раскачиваться" медленнее, но оставаться значительно дольше; сравнение каналов по короткому горизонту LTV систематически занижает каналы второго типа. По 3-месячному горизонту канал A выглядит прибыльнее (LTV/CAC=1.2 против 0.86 у B), но по 12-месячному канал B

Читать полностьюforecasting

Короткий ответ Единственно верного ответа нет: эмпирический подход честен относительно наблюдаемых данных, но для молодого продукта почти наверняка недооценивает LTV из-за короткого горизонта наблюдения, тогда как модельный подход (BG/NBD, Pareto/NBD) позволяет экстраполировать на более длинный горизонт, но вносит модельные допущения, которые могут не соответствовать реальному поведению новых пользователей. Как это работает подробнее эмпирический (cohort-based) LTV суммирует фактически накопленную выручку когорты за наблюдаемый период — это нижняя граница истинного LTV, так как "хвост" выручки после конца наблюдения не учтён; вероятностные модели (BG/NBD для частоты повторных покупок, Pareto/NBD с учётом оттока) оценивают параметры распределения активности и оттока по ранним данным и экстраполируют ожидаемую будущую ценность. Проверка: сравнить predicted_purchases для уже "созревших" (12+ мес) исторических когорт с их фактическим числом покупок — если модель систематически завышает/занижает, её параметры или

Читать полностьюbgnbd

Короткий ответ Churn rate = число ушедших пользователей за период, делённое на число активных пользователей на начало периода (не на конец и не на среднее, если иное не оговорено методологией компании). Как это работает подробнее знаменатель — это база, которая "подвергалась риску оттока" в начале периода; числитель — те из этой базы, кто ушёл к концу периода (новые пользователи, пришедшие в периоде, в их число не входят, если они одновременно и пришли, и ушли в рамках того же периода — это отдельный случай "ранний churn"). Пример кода Что использовать на практике Практика. иногда используют среднюю базу (начало+конец)/2 как знаменатель — это тоже валидный подход, но его нужно явно указывать при отчётности, чтобы цифры были сопоставимы между периодами. Подводные камни Частые ошибки. делят ушедших на базу на конец периода — это занижает churn, т.к. конечная база уже не включает ушедших; забывают указать методологию расчёта при сравнении churn между командами/периодами, что ведёт к ложным выводам о "улучшении"

Читать полностьюchurn

Короткий ответ Вместо self-join напрямую к таблице сырых событий стоит сначала агрегировать события до уровня (user_id, день активности) в промежуточную таблицу или материализованное представление, а когортные расчёты строить оконными функциями или агрегатами поверх уже уменьшённого набора данных. Как это работает подробнее self-join на сырых событиях умножает число строк квадратично относительно активности пользователя (каждое событие джойнится с каждым), что на миллиардах строк даёт комбинаторный взрыв; предварительная агрегация до уникальных пар (user_id, day) на порядки уменьшает объём данных до джойна. Пример кода Что использовать на практике Практика. в колоночных СУБД (ClickHouse, BigQuery) эффективнее использовать uniqExact/APPROX_COUNT_DISTINCT и агрегатные функции с условиями (countIf) вместо явных джойнов; также полезно партиционировать/кластеризовать исходную таблицу по дате и user_id, чтобы сканирование затрагивало меньше данных, и строить инкрементальные (daily) агрегаты вместо пересчёта всей ис

Читать полностьюcohorts

Короткий ответ Разделение нужно, чтобы понимать, за счёт чего растёт (или падает) общая активность продукта — за счёт притока новых пользователей или за счёт удержания уже существующих, потому что это разные рычаги роста, требующие разных действий. Как это работает подробнее на каждую дату/период пользователей делят на "новых" (первая активность в этом периоде) и "возвращающихся" (были активны и ранее); сумма даёт общий DAU/MAU, но тренд каждой части может отличаться. Что использовать на практике Применение. если рост общего DAU обеспечен только новыми пользователями, а доля возвращающихся падает — это сигнал проблем с retention, даже если верхнеуровневая метрика выглядит хорошо; обратная ситуация (рост за счёт retention при падающем притоке новых) говорит об ограничении маркетинга/привлечения. Проверка или пример. Общий DAU вырос на 10%, но абсолютное число возвращающихся не изменилось — весь рост обеспечен новыми пользователями, retention не улучшился. Подводные камни Частая ошибка. делают вывод "продукт ра

Читать полностьюdau

Короткий ответ Декомпозиция помогает понять, какой из компонентов (например, число пользователей, конверсия в покупку, средний чек) сильнее всего повлиял на изменение итоговой метрики, и на какой из этих рычагов продуктовая команда реально может воздействовать. Как это работает подробнее итоговую метрику представляют как произведение или сумму более простых и измеримых компонентов; изменение итоговой метрики раскладывают на вклад каждого компонента, сравнивая значения "было" и "стало". Пример кода Что использовать на практике Практика. декомпозиция особенно полезна, когда итоговая метрика осталась почти неизменной, но за этим стоят разнонаправленные изменения компонентов (например, выросло число пользователей, но упала конверсия) — без декомпозиции такая компенсация осталась бы незамеченной. Подводные камни Частые ошибки. считают вклад каждого компонента независимо, складывая проценты изменения (на самом деле при мультипликативной модели это даёт неточный результат из-за взаимодействия компонентов); выбирают

Читать полностьюarpu

Короткий ответ Резкий скачок или провал метрики, совпадающий по дате с релизом/изменением трекинга, нужно проверить сопоставлением с логом релизов (changelog) инженерных команд; если изменение подтвердилось, временной ряд нужно либо скорректировать (пересчитать старые данные по новой логике, если возможно), либо явно разделить анализ на "до" и "после" и не сравнивать периоды напрямую через точку разрыва. Как это работает подробнее разрыв во временном ряду обычно выглядит как резкий ступенчатый скачок (а не постепенный тренд) ровно в дату деплоя; его легко спутать с реальным продуктовым эффектом, если не проверить correlate с датами релизов. Пример кода Что использовать на практике Практика. лучшая защита — вести общий лог значимых изменений трекинга и релизов, доступный аналитикам, и при любом аномальном скачке метрики первым делом сверяться с этим логом; если пересчитать исторические данные по новой логике невозможно, нужно явно аннотировать график и SQL-отчёты пометкой об изменении методологии, чтобы любой

Читать полностьюchange-point