Метрики и guardrail-метрики: вопросы для собеседования (часть 3)
Выбор основной метрики, вспомогательных и guardrail-метрик — критический этап проектирования эксперимента. Guardrail-метрики защищают от негативных побочных эффектов: например, рост конверсии не должен сопровождаться падением retention. На собеседовании просят спроектировать систему метрик для конкретного эксперимента.
Вопросы 11–15 из 20
11В тесте вы заметили, что в варианте B существенно больше iOS-пользователей, хотя фича не должна менять платформу. Что это скорее всего означает?
AНарушены `invariant metrics`: возможна ошибка рандомизации или таргетинга, и результаты нельзя интерпретировать напрямую
BФича «привлекла» iOS-пользователей и это нормальный эффект
CЭто неважно, если `primary metric` вырос
DЭто всегда исправляется простым увеличением длительности эксперимента
Ответ: Сильные различия по `invariant metrics` обычно сигнализируют проблему назначения или сбора данных.
Если эксперимент не должен влиять на платформу, страна и другие базовые признаки, то их различия между группами подозрительны. Это может быть следствием некорректного таргетинга, перекоса трафика или ошибки в логировании назначения варианта. В такой ситуации важно сначала восстановить валидность теста, а уже потом обсуждать эффект по метрикам результата.
12В тесте новый онбординг улучшил `primary metric` (активацию), но упали повторные визиты и выросли отписки. Как корректнее использовать `secondary metrics` в такой ситуации?
AИгнорировать `secondary metrics`, если `primary metric` значимо вырос
BЗаменить `primary metric` на повторные визиты и пересчитать тест «как будто так и было»
CИспользовать `secondary metrics` для диагностики и оценки компромиссов, прежде чем принимать решение о запуске
DСчитать `secondary metrics` как `invariant metrics`, потому что они не должны меняться
Ответ: `secondary metrics` нужны, чтобы понимать последствия и механизмы, даже если `primary metric` показывает рост.
Рост `primary metric` не гарантирует, что пользовательский опыт и долгосрочная ценность не ухудшились. `secondary metrics` помогают увидеть, где именно возникает проблема, и оценить, приемлем ли компромисс. Часто по ним принимают решение о доработке, ограниченном запуске или выборе другого дизайна эксперимента.
13Вариант B увеличил число сессий на пользователя, поэтому общее время в приложении выросло. Почему сравнение общего времени без `normalization` может вводить в заблуждение?
AОбщее время всегда корректно и не нуждается в корректировках
BВремя в приложении нельзя использовать в A/B тестах
CНужно заменить метрику на количество кликов, потому что оно проще
DПотому что рост может быть вызван изменением объёма активности, и лучше считать время на активного пользователя или на сессию как `normalization`
Ответ: Без `normalization` агрегаты могут расти из-за изменения количества наблюдений, а не из-за изменения поведения.
Если пользователи стали заходить чаще, то суммарное время неизбежно вырастет даже при том же качестве сессии. Чтобы понять, стало ли использование «лучше» или просто «больше», применяют `normalization`, например время на пользователя или на сессию. Это помогает отделить эффект изменения продукта от эффекта роста или падения активности.
14Вы планировали сплит 50/50, но стабильно видите 57/43 по пользователям в A/B. Какое объяснение и действие наиболее корректные?
AЭто нормально, если `primary metric` улучшился, можно выкатывать
BТакое бывает из-за `seasonality`, поэтому просто подождите ещё пару дней
CНужно заменить `primary metric`, потому что она «ломает» распределение
DЭто похоже на `SRM` (Sample Ratio Mismatch), что видно по `invariant metrics`, поэтому сначала нужно расследовать назначение и сбор данных
Ответ: `SRM` (Sample Ratio Mismatch) — это сигнал проблем со сплитом, который часто обнаруживают через `invariant metrics` ещё до анализа эффекта.
Существенный и стабильный перекос в долях групп часто означает, что часть трафика не случайно распределяется или где-то ломается логика назначения. В таком случае статистические выводы по `primary metric` могут быть ненадёжными. Правильный шаг — остановиться и проверить пайплайн: экспериментальные флаги, таргетинг, логирование, фильтры и дедупликацию пользователей.
15В тесте средний чек вырос, но количество заказов и доля повторных покупок снизились. Почему так могло случиться и что сделать первым делом?
AСредний чек вырос, значит тест точно успешен, дополнительные проверки не нужны
BНужно смотреть только средний чек, остальные метрики — шум
CЭто всегда признак `SRM` (Sample Ratio Mismatch), не нужно разбираться дальше
DВозможен сдвиг состава: «маленькие» покупатели стали покупать реже; проверьте сегменты, `secondary metrics` и используйте `normalization` на пользователя/заказ
Ответ: Средние показатели могут меняться из-за состава аудитории, поэтому нужно проверять сегменты и использовать корректную `normalization`.
Рост среднего чека может происходить не потому, что все стали покупать больше, а потому что часть пользователей с малыми покупками перестала покупать. Это типичная ловушка интерпретации, особенно при изменении ассортимента, цен или порога бесплатной доставки. Практично проверить `secondary metrics` по воронке, разрезы по сегментам и метрики, нормализованные на пользователя или заказ, чтобы понять реальную динамику.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в Telegram