Метрики, которые врут: ошибка выжившего, p-hacking и другие ловушки данных

Когда метрика наконец пошла вверх, хочется сразу найти причину: что сработало, какую гипотезу закрепить, куда теперь докинуть ресурсов. Но сначала стоит понять, из каких пользователей и событий собран показатель.

Например, retention растёт — звучит хорошо. Но если в расчёт попали только те, кто уже вернулся хотя бы раз, то из картины выпали все, кто открыл продукт один раз и ушёл. А без них нельзя сказать, что продукт стал лучше удерживать новую аудиторию.

В продуктовых отчётах таких ловушек много: не хватает части пользователей, общий показатель смешивает разные группы, A/B-тест смотрели по ходу, а график построили на слишком коротком периоде.

Дальше разберём, что влияет на выводы и какие вопросы стоит задать к метрикам до того, как менять продукт, бюджет или приоритеты команды.

Помогала со статьёй:

Варвара Бутковская

Кандидат физико-математических наук, выпускница курса «Аналитик данных» в Нетологии, эксперт образовательных проектов. Более 20 лет занимается статистическим анализом данных, а последние три года — анализом данных в сфере онлайн-образования.

Когда метрика может врать, даже если посчитана правильно

У метрики есть две проверки: данные и вывод.

1. Данные

Сначала — базовая гигиена: события собрались, пользователи не задвоились, фильтры не съехали, расчёт совпадает с тем, что написано в документации.

В Microsoft Research отдельно разбирали проблему потери телеметрии в онлайн-экспериментах: если часть событий не дошла до системы или потерялась при обработке, результаты могут смещаться и приводить к неверным выводам. Иногда метрика плохая уже на уровне данных: событие не отправилось, часть платформ не покрыли, после релиза сломался трекинг.

2. Вывод

Даже когда с данными всё нормально, остаётся вопрос: можно ли по этой метрике делать тот вывод, который мы хотим сделать?

Допустим, команда поменяла первый экран и видит, что пользователи стали чаще нажимать на кнопку «Продолжить». Клики действительно выросли. Если цель была сделать кнопку заметнее, метрика подходит. Если цель была улучшить онбординг, этого мало: нужно смотреть, дошёл ли пользователь до первого полезного действия, понял ли продукт, вернулся ли позже.

В теории измерений есть близкая мысль: важно не только получить показатель, но и правильно его использовать. Сэмюэл Мессик в работе Validity of Test Interpretation and Use писал, что валидность связана со смыслом, релевантностью и полезностью результата как основания для действия. Для продуктовой аналитики вывод такой: метрика должна подходить под решение, которое команда собирается на неё опереть.

В A/B-тестировании для этого используют понятие Overall Evaluation Criterion, или OEC. Мы бы не переводили его просто как «главная метрика», потому что теряется часть смысла. В книге Trustworthy Online Controlled Experiments Кохави, Танг и Сюй объясняют OEC как общий критерий оценки эксперимента, который должен быть связан с долгосрочными целями продукта. То есть команда заранее договаривается, по каким показателям будет понятно, что изменение действительно сработало, а не просто сдвинуло ближайшее значение в отчёте.

В Microsoft Research в материале Patterns of Trustworthy Experimentation: During-Experiment Stage предлагают разделять метрики по ролям: одни проверяют качество данных, другие оценивают результат эксперимента, третьи помогают разобраться в конкретном сценарии, а последние — guardrail metrics, или защитные метрики, — показывают, что не должно ухудшиться.

Например, команда упростила регистрацию, и новых аккаунтов стало больше. Но рост регистраций говорит только о входе в продукт. Чтобы понять, помогло ли изменение, нужно посмотреть, что было дальше:

Последние пункты — это логика защитных метрик. В Trustworthy Online Controlled Experiments guardrail metrics описаны как показатели, которые помогают заметить нарушенные предположения и осторожнее относиться к результатам эксперимента. Проще говоря, они нужны, чтобы не принять локальный рост за общее улучшение.

Перед решением достаточно задать три вопроса:

Дальше будут конкретные случаи, где нужна такая проверка.

Ошибка выжившего: почему опасно смотреть только на тех, кто дошёл до нужного этапа

Ошибка выжившего (survivorship bias) — это разновидность ошибки отбора, когда в анализ попадают только те объекты или люди, которые прошли предыдущий фильтр. Из-за этого выборка кажется полной, хотя важная часть данных уже потерялась.

Самый известный пример — история Абрахама Вальда, венгерского математика, и самолётов во время Второй мировой войны. Военные изучали машины, которые вернулись с боевых вылетов, и отмечали, где на них больше всего пробоин. Казалось логичным укреплять именно эти места.

Вальд предложил другой подход. Если самолёт вернулся с такими повреждениями, значит, они не помешали ему долететь обратно. Опаснее могли быть участки, где на вернувшихся машинах почти не было следов попаданий. Самолёты с такими повреждениями, скорее всего, не возвращались. Оригинальная работа Вальда называлась A Method of Estimating Plane Vulnerability Based on Damage of Survivors, позже этот кейс разобрали Марк Мангел и Франсиско Дж. Саманьего в статье Abraham Wald’s Work on Aircraft Survivability.

Продуктовый пример:

Онлайн-школа по правильному питанию решила оценить качество сопровождения студентов через NPS.

NPS, или Net Promoter Score, показывает, готовы ли люди рекомендовать продукт.

После окончания курса выпускникам отправили опрос. По ответам всё выглядело замечательно: NPS составил 78, большинство выпускников высоко оценили поддержку кураторов. Команда решила, что формат сопровождения работает и менять его не нужно.

Позже результаты опроса сопоставили с данными о прохождении курса. Выяснилось, что до финала дошли только 43% студентов. Остальные прекратили обучение раньше и в опрос просто не попали.

Когда стали разбирать отток и обращения в поддержку, оказалось, что именно среди этих студентов чаще встречались жалобы на шаблонное общение с кураторами, нехватку персональных рекомендаций и слабую пользу от сопровождения.

Получается, в анализ попали только те студенты, которые дошли до конца. А рядом были две метрики с разным смыслом:

NPS = 78 — те, кто дошёл, довольны;

Completion Rate = 43% — но дошли далеко не все.

Это и есть ошибка выжившего: если оценивать качество курса только по отзывам тех, кто его завершил, можно не заметить проблемы, из-за которых часть студентов ушла раньше.

Главный вопрос к такой метрике: кто не попал в отчёт, хотя важен для вывода?

Selection bias: как смещённая выборка искажает выводы

Если ошибка выжившего возникает потому, что из анализа «исчезают» пользователи, не дошедшие до конца процесса, то selection bias связан с тем, что выборка изначально не отражает всю аудиторию. Иными словами, проблема не в том, кто выбыл, а в том, кого мы вообще включили в исследование.

В Catalogue of Bias selection bias описывают как ситуацию, когда участники анализа системно отличаются от тех, на кого потом распространяют результат.

В продуктовой аналитике selection bias часто возникает при сборе данных — например, в опросах, пользовательских интервью, A/B-тестах или при анализе поведения отдельных сегментов аудитории.

Кейс 1. «Нам не нужна мобильная версия»

Компания хочет понять, стоит ли и дальше вкладываться в разработку мобильного приложения, и размещает опрос прямо в веб-версии сервиса.

На вопрос, насколько им нужен доступ со смартфона, большинство ответило, что мобильная версия им не нужна. На основании этих результатов проект с мобильной версией решили свернуть.

Однако спустя несколько месяцев заметили, что значительная часть новых пользователей заходила в сервис только с мобильных устройств и быстро уходила. Выяснилось, что люди, которым мобильная версия была нужна больше всего, практически не пользовались веб-интерфейсом и просто не увидели опрос.

Проблема была не в ответах пользователей, а в самой выборке. Команда спросила мнение только тех, кто уже комфортно работал в веб-версии, и распространила их мнение на всю аудиторию. Это классический пример selection bias.

Кейс 2. «Почему люди не регистрируются?»

Команда заметила, что многие посетители сайта уходят, не завершив регистрацию. Чтобы понять причины, решили провести серию пользовательских интервью.

Проблема была в том, что приглашения отправили через личный кабинет сервиса. В итоге на интервью пришли только зарегистрированные пользователи — те, кто успешно прошёл регистрацию.

Во время исследования участники рассказывали, что процесс регистрации простой и понятный. Команда уже была готова закрыть гипотезу о проблемах в онбординге.

Но главный вопрос так и остался без ответа: исследование вообще не затронуло людей, которые не смогли зарегистрироваться или отказались делать это. Именно их мнение и было нужно, но в выборку они не попали.

Команда хочет понять, почему люди не регистрируются.

И проводит интервью…

…с зарегистрированными пользователями.

Это почти анекдот среди UX-исследователей, но такое действительно случается.

Это тоже selection bias: выводы сделали на основе группы, которая изначально не представляла интересующую аудиторию.

Парадокс Симпсона: почему общий показатель может противоречить срезам

Представьте: после релиза конверсия выросла и на десктопе, и на мобильных устройствах. Казалось бы, отличный результат. Но в общем отчёте она… упала. Ошибка в расчётах? Нет. Это парадокс Симпсона. Иногда общий показатель ухудшается, хотя в каждом отдельном сегменте ситуация улучшается.

Есть академический пример — исследование приёма в аспирантуру Калифорнийского университета в Беркли. В агрегированных данных за 1973 год казалось, что женщин принимали заметно реже мужчин. Но когда исследователи разобрали данные по факультетам, картина изменилась: женщины чаще подавались на направления с более высоким конкурсом, поэтому общий показатель вводил в заблуждение. Этот кейс опубликован в статье Sex Bias in Graduate Admissions: Data from Berkeley.

Вернёмся к продуктовой аналитике. Команда обновила форму регистрации и ждёт роста конверсии. Но в общем отчёте показатель падает: с 26,7% до 23,3%. Если смотреть только на итоговую строку, можно решить, что релиз навредил.

Но по каждому сегменту конверсия заметно выросла: на десктопе с 30% до 40%, на мобильных — с 10% до 20%.

Причина оказалась в том, что после релиза основная часть трафика неожиданно стала приходить с мобильных устройств, где конверсия традиционно ниже.

Общий показатель не всегда отражает реальные изменения в продукте. Иногда он меняется только потому, что изменилась структура аудитории. Поэтому, прежде чем делать выводы, стоит проверить ключевые срезы. Если общий показатель идёт в одну сторону, а все сегменты — в другую, вероятно, вы столкнулись с парадоксом Симпсона.

Ошибки A/B-тестирования: p-hacking, подглядывание и множественные сравнения

Главная ошибка в A/B-тестировании часто возникает ещё до анализа данных — когда команда заранее не определяет правила эксперимента.

Какую гипотезу проверяем, какая метрика главная, сколько длится эксперимент, какой эффект считаем заметным для продукта, какие сегменты смотрим отдельно — всё это лучше зафиксировать до запуска.

Иначе после старта легко начать подстраивать анализ под данные.

Например, команда тестирует новый экран оплаты и каждый день открывает отчёт. В понедельник различие между вариантами ещё незначимое. Во вторник почти значимое. В среду p-value становится меньше 0,05 — и тест останавливают. На уровне здравого смысла это выглядит нормально: дождались сильного результата и приняли решение.

Но в статистике такая логика не работает. Каждый новый просмотр результатов — это ещё одна проверка гипотезы. Чем чаще команда заглядывает в отчёт и ждёт момента, когда различие станет значимым, тем выше вероятность, что этот момент наступит просто из-за случайных колебаний данных, а не из-за реального эффекта.

Это называют peeking, или подглядыванием. Эван Миллер разбирает эту ошибку в статье How Not To Run an A/B Test.

С p-value вообще нужно быть аккуратнее. P-value не отвечает на вопрос «насколько хорош новый вариант». Он показывает, насколько необычным был бы наблюдаемый результат, если бы на самом деле между вариантами не было различий.

P-hacking появляется, когда команда начинает перебирать способы анализа уже после просмотра данных. Сначала смотрит всех пользователей, потом только новых, потом только мобильных, потом убирает «странный» день, потом переключается с основной метрики на соседнюю. Каждый шаг можно объяснить отдельно, но вместе это уже не проверка исходной гипотезы, а поиск разреза, где эффект выглядит убедительно.

Похожая история — множественные сравнения. В одном тесте можно смотреть конверсию в оплату, клики по нескольким кнопкам, глубину просмотра, удержание, отписки, ошибки, а потом ещё разрезать всё это по устройствам, каналам и новым пользователям. Чем больше проверок, тем выше вероятность, что где-то появится значимость просто из-за случайности.

Пример:

Команда проверяет десять метрик, а потом ещё смотрит каждую отдельно для мобильных пользователей, десктопа, новых клиентов и постоянных. Так быстро набираются десятки статистических проверок. Даже если новый экран на самом деле ни на что не влияет, в одной из них может появиться значимый результат просто из-за случайности.

Дополнительные метрики и сегменты смотреть полезно: они помогают понять, где именно изменилось поведение пользователей. Но важно, когда команда решила смотреть этот сегмент — до запуска теста или уже после отчёта. Если интересный эффект нашли постфактум, его лучше считать новой гипотезой, а не основанием для релиза.

Поэтому правила A/B-теста фиксируют заранее: какую гипотезу проверяем, какая метрика основная, сколько длится эксперимент и по каким критериям принимаем решение. Тогда команда после завершения теста оценивает тот эффект, ради которого его запускала, а не ищет удачное объяснение уже после просмотра данных.

Среднее против медианы: почему одна «средняя» цифра может обмануть

Когда в отчёте есть среднее по времени, деньгам или количеству действий, его лучше смотреть вместе с медианой. Иначе несколько редких случаев могут выглядеть как нормальное поведение пользователей.

Например, руководитель службы поддержки открывает отчёт и видит: среднее время ожидания ответа — 18 минут. Кажется, пользователи ждут слишком долго. Но медиана составляет всего 4 минуты.

Значит, половина обращений получает ответ быстрее четырёх минут. Среднее растянули несколько сложных тикетов, которые разбирали несколько часов или даже дней.

Если смотреть только на среднее, можно решить, что вся поддержка работает медленно. Медиана показывает другую картину: типичный пользователь получает ответ гораздо быстрее.

То же бывает с деньгами.

Интернет-магазин смотрит средний чек и видит 12 000 рублей. Кажется, большинство покупателей тратит примерно столько. Но медиана — 3 500 рублей. Несколько крупных заказов подняли среднее, хотя обычная покупка намного меньше.

Среднее хорошо отвечает на вопросы про общий объём: сколько выручки получили, сколько нагрузки пришло в поддержку, сколько времени суммарно ушло на сценарий. Медиана лучше помогает понять пользовательский опыт: сколько ждёт типичный пользователь, сколько тратит обычный покупатель, как быстро большинство проходит нужный шаг.

Рядом с медианой полезно смотреть перцентили. Например, p90 показывает значение, в которое уложились 90% пользователей, а остальные 10% оказались выше. Для поддержки, онбординга, оплаты и других чувствительных сценариев это часто важнее среднего: так видно, кто ждёт дольше всех, где пользователи застревают и какая часть создаёт основную нагрузку.

В справочнике NIST по measures of location медиану описывают как более устойчивую меру для данных с экстремальными значениями. Для продуктового отчёта вывод простой: если среднее и медиана сильно расходятся, сначала смотрим распределение, а уже потом делаем вывод по метрике.

Регрессия к среднему: почему метрика могла улучшиться сама

Представьте студента, который обычно учится на четыре-пять, но на одном экзамене сильно нервничает и получает двойку. Родители нанимают репетитора, следующий экзамен он сдаёт на четвёрку.

Связать эти события легко: были занятия — оценка выросла. Но часть улучшения могла произойти и без репетитора. Двойка была необычно плохим результатом для этого студента, а следующий экзамен просто оказался ближе к его обычному уровню.

Так работает регрессия к среднему. После резкого отклонения следующий замер часто выглядит спокойнее, потому что экстремальные значения редко повторяются подряд.

В продуктовой аналитике это часто видно после провалов.

У продукта обычно 5–6% пользователей из рекламного трафика доходят до оплаты. Потом случается неудачная неделя: конверсия падает до 2,8%. Команда быстро переписывает офер на платёжном экране, меняет порядок блоков, добавляет подсказки.

Через неделю конверсия возвращается к 5,1%. Правки могли помочь, но это не единственное объяснение. В ту плохую неделю мог измениться состав трафика, просесть один канал, накопиться меньше данных или сломаться часть оплат. Следующая неделя могла просто вернуться к привычному диапазону.

Из-за этого легко переоценить свои действия. Просели оплаты — после правок восстановились. Выросли жалобы — после разбора стало меньше. Во всех этих случаях команда могла правда повлиять на результат, но само восстановление метрики ещё не доказывает, что причина именно в её действиях.

Поэтому резкие провалы и всплески лучше смотреть не только через «до» и «после». Нужна история метрики: как она вела себя раньше, часто ли уходила в такой диапазон, сколько данных было в плохой точке и не менялись ли трафик, сезонность, каналы или трекинг.

Корреляция и причинность: почему похожие графики не доказывают связь

Корреляция показывает, что два события часто происходят вместе. Но она не отвечает на вопрос, что на что повлияло. Иногда за обоими событиями стоит общий фактор.

Есть каноничный пример с мороженым и акулами. Летом растут и продажи мороженого, и число нападений акул. Связь между показателями есть, но мороженое не привлекает акул. Просто в жару люди чаще идут на пляж, покупают мороженое и заходят в море.

В продуктовой аналитике такие ситуации встречаются гораздо чаще, чем кажется.

Команда анализирует аккаунты, которые перешли на платный тариф, и смотрит, что они делали в первые дни. Самая заметная связь — приглашение коллег: если пользователь позвал команду, аккаунт чаще становится платным.

Из этого легко сделать продуктовую задачу: вести больше пользователей к приглашению команды. Вынести кнопку выше, добавить подсказку, отправить письмо после регистрации.

Но отчёт не доказывает, что приглашение коллег привело к оплате. Он показывает только, что у платящих аккаунтов это действие встречается чаще.

Коллег обычно зовут не случайные пользователи, а команды, которые уже пришли с рабочей задачей. У них есть несколько участников, понятный процесс и внутренняя потребность в инструменте. В такой ситуации смешивающей переменной может быть готовность команды к внедрению продукта: она одновременно повышает и вероятность приглашения коллег, и вероятность перехода на платный тариф.

Тогда приглашение коллег — не причина оплаты, а признак более зрелого аккаунта. Вывод стоит формулировать осторожнее: не «приглашение коллег повышает оплату», а «платящие аккаунты чаще приглашают коллег в первые дни».

Такой отчёт полезен как гипотеза. Дальше её можно проверить на похожих аккаунтах: одного размера, из одного канала, на близкой стадии внедрения. Или запустить A/B-тест: одной группе заметнее показать приглашение коллег, другую оставить на обычном сценарии.

Так станет понятнее, само действие влияет на оплату или просто чаще встречается у клиентов, которые и так были ближе к платному тарифу.

Закон Гудхарта: почему метрика портится, когда становится целью

Закон Гудхарта обычно формулируют так: когда показатель становится целью, он перестаёт быть хорошим показателем (формулировка Мэрилин Стратерн, 1997 год, источник).

Например, служба поддержки отвечает пользователям слишком медленно, и команде ставят KPI — сократить время первого ответа до пяти минут. Через месяц цель выполнена, и сообщения больше не висят без ответа по 40 минут.

Но если открыть диалоги, окажется, что часть быстрых ответов — это шаблонные фразы вроде «Сейчас посмотрим» или «Передали вопрос специалисту». Формально сотрудник ответил вовремя, но пользователь быстрее помощь не получил.

То же самое происходит с продуктовыми метриками. Например, команда хочет увеличить DAU и начинает чаще отправлять пуши и письма. Пользователи переходят по уведомлениям, число ежедневных входов растёт. Но вместе с ним могут вырасти отписки, отключения уведомлений и удаления приложения. Люди стали чаще открывать сервис просто потому, что их настойчивее туда звали.

В обоих случаях команда улучшает сам показатель, а не то, что за ним стоит. Поэтому KPI нельзя оценивать отдельно от последствий. Для времени первого ответа важно также смотреть на скорость решения вопроса и удовлетворённость пользователей. Для DAU — на полезные действия после входа, удержание и отписки от уведомлений.

Визуальные искажения: как ось графика и выбранный период меняют вывод

Один и тот же результат на двух графиках может выглядеть совершенно по-разному.

После запуска нового онбординга конверсия в оплату выросла с 4,8 до 5,1%. На графике с осью от 4,8 до 5,1% это будет резкий подъём. Если начать ось с нуля, линия окажется почти горизонтальной.

Обрезанная ось здесь нужна, чтобы разглядеть небольшие изменения. Но по такому графику легко переоценить рост: 0,3 процентного пункта выглядят как большой скачок. Чтобы понять, насколько результат действительно значим, нужны сами значения и бизнес-контекст.

Ещё один способ получить неверный вывод — взять слишком короткий период. Например, за две недели после релиза число регистраций выросло. Команда связывает это с новой механикой. Но на графике за три месяца видно, что похожие всплески бывают после каждой рекламной кампании. Значит, регистраций могло стать больше просто из-за притока трафика.

Поэтому при работе с графиком важно смотреть на шкалу и период. Где начинается ось? Что было с метрикой до релиза? Повторялись ли такие скачки раньше?

Чек-лист: как проверить метрику перед решением

Перед тем как менять продукт, бюджет или приоритеты по одной метрике, проверьте, на какой вопрос она правда отвечает и что могло исказить вывод.

Что почитать дальше

Вот несколько полезных книг по теме от эксперта статьи.

Статистика

Даррелл Хафф, «Как лгать при помощи статистики» — классическая книга о том, как цифры и графики могут вводить в заблуждение. Несмотря на возраст, многие примеры до сих пор актуальны.

Дэвид Шпигельхалтер, «Искусство статистики. Как находить ответы в данных» — современная книга о статистическом мышлении без сложной математики. Хорошо объясняет неопределённость, интерпретацию данных и типичные ошибки.

NIST/SEMATECH, e-Handbook of Statistical Methods — бесплатный справочник по статистике с разделами о средних, медиане, доверительных интервалах, распределениях и проверке гипотез. Подойдёт тем, кто хочет разобраться глубже.

Аналитика

Evan Miller, How Not To Run an A/B Test — одна из самых известных статей о распространённых ошибках в A/B-тестировании: преждевременной остановке экспериментов, интерпретации p-value и принятии решений. Не новая, но классика.

Ron Kohavi, Diane Tang, Ya Xu, Trustworthy Online Controlled Experiments — одна из лучших современных книг по A/B-тестированию в цифровых продуктах. Написана авторами, которые много лет строили культуру экспериментов в Microsoft, Google и LinkedIn.

Alistair Croll, Benjamin Yoskovitz, Lean Analytics: Use Data to Build a Better Startup Faster. O’Reilly Media, 2013 — о том, какие метрики действительно помогают принимать продуктовые решения и почему важно правильно интерпретировать данные.

Чтобы оставаться востребованным специалистом, нужно выходить из зоны комфорта и пробовать новое. Если всё ещё сомневаетесь, начните с чего-то небольшого и БЕСПЛАТНОГО:

• практического курса «Аналитика и ИИ: как принимают решения в реальном бизнесе», где вас ждут 6 мини-проектов, разбор задач и общение с ИИ-инженерами;

• программы «ИТ в действии: как создаются и живут цифровые продукты», где можно разобраться в разных языках программирования и получить навыки использования нейросетей в разработке;

• вводного курса «Специалист по искусственному интеллекту», где сможете обучить свою первую модель в реальных инструментах;

• практического курса «ИИ в деле: ускорьте свою работу», который научит вас автоматизировать задачи с помощью агентов и системно работать с нейросетями.

Или можно сразу сделать решительный шаг к переменам, карьерному росту и повышению дохода с профессиональным обучением:

• на расширенной программе «Аналитик данных», где много практики, разборов тестовых заданий и изучения актуальных BI-решений;

• на курсе «Юнит-экономика и продуктовые метрики», где можно применять знания на своём проекте в процессе обучения;

• профессии «Продакт-менеджер», где идёт акцент на практику и помощь в трудоустройстве;

• на программе «Python для анализа данных», где изучите популярные библиотеки NumPy и Pandas, а также современный стек — Polars, PyArrow, GE, Streamlit.