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

Короткий ответ Перед расчётом churn стоит проверить дубликаты событий/пользователей, задержку поступления данных (late-arriving events), согласованность определения "активности" во времени и отсутствие тестовых/служебных аккаунтов — любая из этих проблем может существенно исказить churn в ту или иную сторону. Как это работает подробнее дубликаты событий сами по себе не искажают факт наличия активности (достаточно одного события), но могут искажать производные метрики (частоту); гораздо критичнее — задержка доставки данных: если анализ churn за последний период делается до того, как все события успели "доехать" в хранилище, часть реально активных пользователей ошибочно попадёт в "ушедшие". Если число событий для event_date продолжает расти в load_date на несколько дней позже — это подтверждает лаг и обосновывает выбор cutoff-окна для churn-расчёта. Что использовать на практике Практика. стоит выбирать так называемую "дату отсечки" (cutoff) для расчёта churn с запасом на задержку данных (например, не считать ch

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

Короткий ответ Нужно заранее, до запуска кампании, выбрать набор guardrail-метрик на разных горизонтах (мгновенные — доля отписок/жалоб, среднесрочные — D30 retention и рейтинг в сторе, долгосрочные — churn платящих), установить конкретные пороги отката по каждой метрике и зафиксировать, кто и когда принимает решение об остановке — единого универсального набора порогов не существует, они зависят от продукта и риск-аппетита компании. Как это работает подробнее разные guardrails реагируют с разной задержкой — отписки от push и жалобы в поддержку видны почти мгновенно, падение D30 retention видно только через месяц, а эффект на churn платящих пользователей и LTV может проявиться ещё позже; система мониторинга должна учитывать эту разную скорость реакции и не ждать самого медленного сигнала, если быстрые уже бьют тревогу. Такой план позволяет среагировать на быстрые сигналы (отписки) за дни, не дожидаясь месяца, пока станет виден эффект на retention, когда вред уже будет накоплен на большем числе пользователей. Ч

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

Короткий ответ Единственно правильного общего определения "активного пользователя" не существует — финансовая отчётность и продуктовая аналитика законно могут требовать разных определений (например, биллинговая активность против поведенческой вовлечённости); решение — не навязывать одно определение всем, а создать явно задокументированный реестр метрик (metric registry) с именованными, версионированными определениями и единым источником расчёта для каждого. Как это работает подробнее финансовая метрика "активный клиент" часто привязана к факту оплаты/действующей подписки (нужна для отчётности перед инвесторами и регуляторами и должна быть стабильной и аудируемой), а продуктовая метрика "активный пользователь" — к поведенческому вовлечению (нужна для быстрой диагностики здоровья продукта и может чаще меняться вместе с продуктом); попытка свести их к одному числу обычно жертвует полезностью одной из сторон. Metric registry (фрагмент): Любой дашборд или отчёт обязан явно указывать, какое из двух определений испо

Читать полностьюactive-users

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

Читать полностьюanalytics-review

Короткий ответ Нужно найти для каждого пользователя дату первого события (или регистрации), сгруппировать эти даты по месяцу и посчитать число уникальных пользователей в каждом месяце. Как это работает подробнее "новый пользователь" — тот, для кого текущий месяц совпадает с месяцем его самой первой активности; это требует предварительного вычисления MIN(date) по каждому user_id, а не просто фильтрации событий по месяцу. Пример кода Что использовать на практике Применение. если в таблице уже есть отдельное поле registration_date, можно обойтись без вычисления минимума по событиям — но важно убедиться, что registration_date действительно отражает первый визит, а не, например, дату подтверждения email. Проверка или пример. Проверка: сумма new_users по всем месяцам должна равняться общему числу уникальных пользователей в таблице events. Подводные камни Частая ошибка. считают число новых пользователей просто как число уникальных user_id с любой активностью в месяце (это посчитает и старых, вернувшихся пользователе

Читать полностьюdate-trunc

Короткий ответ Нужно посчитать число уникальных пользователей с событием "просмотр" и число уникальных пользователей с событием "покупка" среди тех же пользователей (обычно с ограничением по времени от просмотра до покупки), затем разделить второе на первое. Как это работает подробнее используем условное агрегирование или EXISTS/JOIN, чтобы связать пользователей, совершивших оба события, и ограничить окно (например, покупка в течение 7 дней после просмотра), иначе в конверсию попадут случайные совпадения, не связанные причинно. Пример кода Что использовать на практике Применение. важно договориться, обязательна ли покупка именно того товара, который просматривали, или любая покупка в принципе — это сильно разные по смыслу метрики. Проверка или пример. Проверка: conversion_rate должен быть в (0;1]. Подводные камни Частая ошибка. считают конверсию по количеству событий вместо уникальных пользователей; не ограничивают временное окно, из-за чего в конверсию попадают покупки, произошедшие задолго до просмотра и не

Читать полностьюconversion-rate

Короткий ответ Rolling N-day retention для пользователя — это признак "была ли хотя бы одна активность в день N или позже"; его удобно получить через оконную функцию, находящую минимальную разницу в днях между регистрацией и каждым последующим событием, и сравнивающую её с порогом N. Как это работает подробнее для каждого пользователя вычисляем MAX(event_date) (или проверяем EXISTS событие с day_diff >= N) — если последняя активность наступила не раньше дня N, пользователь считается "rolling retained" на день N. Пример кода Что использовать на практике Практика. в ClickHouse для больших объёмов эффективнее использовать maxIf/minIf агрегатные функции с условием вместо JOIN; в PostgreSQL можно использовать оконную функцию MAX(event_date) OVER (PARTITION BY user_id) для избежания повторного сканирования таблицы. Подводные камни Частые ошибки. вычисляют rolling retention как "была ли активность именно в день N или позже" только для одной конкретной даты в прошлом, забывая, что для свежих когорт день N+ ещё не нас

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

Короткий ответ Нужно для каждой пары (пользователь, событие) вычислить номер периода когорты, сгруппировать по (cohort_month, period_number), посчитать число уникальных пользователей, а затем развернуть результат через pivot_table в матрицу "когорта × период" и нормировать на размер когорты. Как это работает подробнее после группировки получаем длинную (long-format) таблицу с тремя колонками (cohort_month, period_number, active_users); pivot_table разворачивает её в широкий формат, где строки — когорты, столбцы — номер периода, значения — число активных или retention rate. Пример кода Что использовать на практике Практика. в pandas 2.x при работе с Period/Grouper для месячных когорт стоит явно приводить типы (dt.to_period('M')), а после merge/groupby проверять df.shape, чтобы не упустить незаметное дублирование строк; для нормировки на размер когорты удобно делить матрицу на первый столбец (.div(matrix.iloc[:, 0], axis=0)). Подводные камни Частые ошибки. забывают нормировать на размер когорты и путают абсолют

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

Короткий ответ Нужно для каждого пользователя найти дату регистрации и проверить, есть ли у него событие в интересующий день (например, day+7), а затем усреднить этот признак по всем пользователям когорты. Как это работает подробнее объединяем таблицу регистраций с таблицей событий, вычисляем разницу в днях между датой события и датой регистрации, создаём булев признак "был активен на day N" и усредняем по когорте. Пример кода Что использовать на практике Применение. в pandas 2.x при работе с датами важно явно приводить столбцы к datetime64, а при объединении больших таблиц проверять, не дублируются ли строки после merge (это завышает метрику); в pandas 2.x с включённым copy-on-write операции присваивания на срезах ведут себя иначе, чем в pandas 1.x — лучше избегать cepnых chained assignments. Проверка или пример. Проверка: d7_retention должен лежать в [0;1]; пересчитать вручную по небольшому датасету. Подводные камни Частая ошибка. считают retention как долю от общего числа событий, а не от числа уникальных

Читать полностьюcohort-analysis