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