Вопросы по теме «Метрики и guardrail-метрики»
Выбор основной метрики, вспомогательных и guardrail-метрик — критический этап проектирования эксперимента. Guardrail-метрики защищают от негативных побочных эффектов: например, рост конверсии не должен сопровождаться падением retention. На собеседовании просят спроектировать систему метрик для конкретного эксперимента.
Всего в этом разделе 20 вопросов. Каждый — с правильным ответом и кратким разбором теории. Разбито на 4 части по 5 вопросов.
Вопросы 1–5 из 20
1Вы тестируете новую логику отправки push-уведомлений, которая напрямую меняет количество отправок. Можно ли число отправленных push считать `invariant metrics`?
AДа, `invariant metrics` должны быть любыми метриками, которые легко посчитать
BДа, потому что `invariant metrics` всегда совпадают между группами
CНет, потому что эксперимент напрямую влияет на эту метрику, и её роль скорее `secondary metrics` или часть результата
DДа, но только если увеличить размер выборки
Ответ: `invariant metrics` не должны зависеть от воздействия эксперимента, иначе их изменение не будет «красным флагом».
Если фича меняет вероятность отправки уведомлений, то число отправок закономерно будет различаться между вариантами. В таком случае это не инвариант, а ожидаемая часть механики или результат, который можно анализировать как `secondary metrics`. Инварианты выбирают так, чтобы их изменение сигнализировало об ошибке, а не о работе фичи.
2Вы тестируете увеличение числа рекламных блоков в ленте, ожидая рост выручки. Какие метрики наиболее уместны как `guardrail metrics`?
AВремя загрузки ленты и доля сбоев/крашей приложения
BКоличество показов рекламы и `CTR` по рекламе
CВыручка от рекламы на пользователя
DРазмер выборки и доля трафика в варианте B
Ответ: `guardrail metrics` должны защищать качество опыта и стабильность системы, даже если `primary metric` улучшается.
Реклама может повысить доход, но одновременно ухудшить скорость, стабильность и удовлетворённость пользователей. Поэтому важно поставить ограничения на метрики надежности и производительности. Если `guardrail metrics` ухудшаются, запуск может быть опасным даже при росте выручки.
3Какое утверждение лучше всего описывает правильную работу с `guardrail metrics`?
AИх выбирают после теста, когда уже виден результат по `primary metric`
BИх можно менять в процессе теста, чтобы подогнать вывод под ожидания бизнеса
CОни должны быть такими, чтобы всегда значительно менялись, иначе они бесполезны
DИх фиксируют заранее и задают правила: какой уровень ухудшения недопустим и что делать при нарушении
Ответ: `guardrail metrics` должны быть определены до запуска и работать как заранее согласованные ограничения.
Если выбирать `guardrail metrics` постфактум, легко заняться рационализацией и получить непоследовательные решения. Практика — заранее определить список и пороги или правила реагирования, чтобы команда понимала, что считается риском. Это делает выводы прозрачнее и снижает вероятность «выкатываем несмотря ни на что».
4Вы меняете текст про доставку на чекауте; `primary metric` — конверсия в заказ. Какую метрику логичнее поставить как `guardrail metrics`, чтобы контролировать риск для бизнеса?
AКоличество скроллов на странице доставки
BДоля отмен и возвратов после покупки
CСредняя длительность сессии в приложении
DЧисло пользователей, попавших в эксперимент
Ответ: `guardrail metrics` выбирают так, чтобы они ловили опасные побочные эффекты от изменения.
Изменение текста может «продавить» пользователей к покупке, но привести к разочарованию после оплаты. Рост отмен и возвратов сигнализирует, что мы ухудшили качество ожиданий или ввели людей в заблуждение. Поэтому такую метрику логично использовать как `guardrail metrics`, ограничивая риск.
5Эксперимент длился 2 дня и пришёлся на выходные, а обычно в выходные конверсия выше. Как правильнее учитывать `seasonality` при выводах?
AЗапускать тест так, чтобы покрыть полный недельный цикл, или сравнивать одинаковые дни недели между группами
BИгнорировать `seasonality`, потому что есть контрольная группа
CСравнивать только один день с самым большим трафиком
DСчитать, что `seasonality` относится только к выручке, а не к конверсии
Ответ: `seasonality` может менять базовый уровень метрик по дням недели и событиям, поэтому дизайн и интерпретация должны это учитывать.
Даже при наличии контроля короткий тест на «особые» дни может давать нестабильные выводы, потому что поведение в разные дни различается. Практика — запускать эксперимент на период, покрывающий типичный цикл спроса, например неделю, или анализировать сопоставимые дни недели. Так меньше риск принять решение из-за календарного эффекта, а не из-за изменения продукта.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в Telegram