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