Сообщить об ошибкеКороткий ответ
Нужно систематически проверять, на каком этапе жизненного цикла данных (сбор события, фильтрация, агрегация, выбор знаменателя метрики) может закладываться систематическое искажение в пользу определённых сегментов пользователей, и явно сверять ключевые метрики с независимыми источниками правды — единого чек-листа для всех продуктов нет, набор рисков зависит от архитектуры трекинга и бизнес-модели.
Как это работает подробнее
системные смещения редко видны в самой формуле метрики — они чаще скрыты в том, что метрика структурно не замечает (например, retention, считающийся только по пользователям, завершившим онбординг, автоматически исключает самых проблемных пользователей, которые отвалились раньше), или в том, как работает сам продукт и трекинг (платящие пользователи с более быстрым интернетом логируются надёжнее, чем пользователи на медленном соединении, которые чаще "теряются" из выборки).
Sanity check: сравнить долю пользователей с сбоями среди ответивших на опрос и среди всех пользователей — заметное расхождение подтверждает структурное смещение в метрике CSAT.
Пример кода
Метрика: "средняя оценка удовлетворённости (CSAT)" считается только по пользователям,
заполнившим опрос в приложении, который показывается только тем, у кого сессия
не завершилась ошибкой.
Скрытое смещение: пользователи, у которых чаще случаются сбои (например, старые устройства,
слабый интернет), структурно недопредставлены — метрика завышает реальную удовлетворённость.Что использовать на практике
- Полезный подход — для каждой ключевой метрики продукта explicitно прописать, какие группы пользователей структурно недопредставлены в знаменателе или числителе, и оценить, насколько это меняет интерпретацию метрики. Также стоит периодически сверять ключевые продуктовые метрики с независимыми источниками (финансовая отчётность для выручки, данные платформы для установок) и целенаправленно исследовать "невидимых" пользователей через альтернативные методы (опросы ушедших, анализ логов ошибок трекинга), а не только тех, кто успешно остался в системе.
Подводные камни
- Считать, что раз формула метрики математически корректна, сама метрика свободна от смещения
- Не учитывать различия в надёжности трекинга между сегментами (устройства, страны, версии приложения) при сравнении метрик между этими сегментами
- Выявлять смещение один раз и не пересматривать его при изменении продукта, хотя архитектура трекинга и состав пользователей со временем меняются.