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