QA, SRM и раскатка: вопросы для собеседования (часть 3)
SRM (Sample Ratio Mismatch) — один из главных диагностических инструментов: если группы разъехались по размеру, результатам эксперимента нельзя доверять. На собеседовании спрашивают, как обнаружить SRM, какие причины за ним стоят и как безопасно раскатывать изменения после успешного теста.
Вопросы 11–15 из 20
11В A/A-тесте вы заметили значимое отличие по инвариантным метрикам — например, по числу пользователей в эксперименте или по распределению платформ. Что это чаще всего означает?
AАудитория «улучшилась» сама по себе: будущие изменения в продукте сработают ещё лучше, фича уже работает
BЕсть проблема в разбиении или измерениях: группы оказались неэквивалентны, и A/A-тест нельзя считать валидным
CЭто допустимая ситуация: инвариантные метрики не влияют на основные выводы, можно запускать настоящий A/B-тест
DДостаточно увеличить выборку и подождать ещё несколько дней: различие в инвариантных метриках исчезнет
Ответ: Расхождение по инвариантным метрикам в A/A-тесте обычно сигнализирует о проблеме в данных или рандомизации.
Инвариантные метрики должны оставаться одинаковыми, потому что продукт и логика одинаковы в обоих вариантах. Если они различаются, значит, в группы попали разные типы пользователей или часть данных теряется несимметрично. В этом случае лучше остановиться и починить разбиение или трекинг до запуска настоящего A/B-теста, иначе любой найденный эффект будет смесью реального и шума разбиения.
Подробный разбор → 12Вы обнаружили `SRM` (sample ratio mismatch — несоответствие долей выборки): фактическое распределение трафика 47/53 вместо ожидаемых 50/50, и тест на `SRM` показывает сильную значимость. Какой следующий шаг наиболее полезен для диагностики?
AРазбить счётчики по платформе, версии, источнику трафика и точкам распределения, чтобы локализовать место перекоса в назначении
BСразу выкатить вариант с лучшим значением целевой метрики на всех пользователей, не разбираясь с причиной перекоса распределения
CЗаменить целевую метрику на ту, по которой эффект между группами оказался крупнее, и продолжить эксперимент без пересчёта дизайна
DПринять текущий перекос как допустимый и интерпретировать оценку эффекта по основной метрике без проверки источника несоответствия
Ответ: При `SRM` важно локализовать источник перекоса: разрезы по сегментам и проверка всей цепочки распределения обычно дают самый быстрый сигнал.
Сам факт `SRM` говорит, что что-то пошло не так с трафиком или включением в эксперимент. Разрезы по платформам и версиям часто быстро показывают, где перекос сильнее всего, а значит — где искать причину. Параллельно важно проверить, что ключ распределения одинаков на всех шагах и что фильтры включения не зависят от варианта. Игнорировать перекос или менять метрику посреди теста — типичные ошибки, которые делают результат непригодным для решения.
Подробный разбор → 13В середине эксперимента команда изменила схему события и обновила логику подсчёта метрики, не зафиксировав версию. Какой подход к исправлению наиболее корректен?
AПринять смену схемы как часть нормального процесса и анализировать данные обоих периодов вместе без приведения к единому определению
BЗафиксировать версии, привести расчёт к единому определению (в идеале пересчитать историю) и при необходимости перезапустить эксперимент
CАнализировать только период до изменения схемы и игнорировать данные после смены, считая первую часть эксперимента самодостаточной
DЗаменить статистический критерий на менее чувствительный к различиям подсчёта, чтобы расхождения определений в отчёте стали незаметны
Ответ: Изменение определения метрики без версионирования делает сравнение некорректным и требует унификации расчёта.
Если метрика считалась по-разному в разные дни или в разных вариантах, вы сравниваете не одно и то же. В таких случаях нужно зафиксировать определение (версию) и пересчитать результаты единообразно для всего периода. Если пересчёт невозможен или смешение слишком сильное, честнее перезапустить эксперимент после исправления логирования. Замена критерия или удаление одного из вариантов проблему не решают, а только маскируют её.
Подробный разбор → 14Какое поведение p-value вы ожидаете увидеть в корректном A/A‑тесте, если проводить много независимых прогонов?
Ap-value всегда будет около 0.5 и никогда не опустится ниже 0.05 в большом числе прогонов
Bp-value всегда будет близок к нулю, потому что выборки берутся из одной и той же популяции
Cp-value всегда будет равен 1, так как реального эффекта между группами в A/A‑тесте нет вовсе
Dp-value распределён примерно равномерно, и около 5% прогонов случайно дадут p-value ниже 0.05
Ответ: В корректном A/A‑тесте p-value распределён примерно равномерно, и около 5% прогонов случайно покажут p-value ниже 0.05.
Если статистика и данные корректны, A/A‑тест имитирует ситуацию без эффекта. При уровне значимости 0.05 примерно 5% прогонов могут случайно показать «значимость» — это и есть ожидаемая частота ложных срабатываний. Если значимых результатов намного больше или они повторяются стабильно, это повод искать проблему в разбиении или сборе данных. Распределение p-value под нулевой гипотезой при правильно выбранном тесте близко к равномерному на отрезке от 0 до 1.
Подробный разбор → 15В целом метрика в варианте B выросла, но в разрезе iOS и Android она падает в обоих сегментах. Что это чаще всего подсказывает и что стоит проверить?
AЭто доказывает баг в статистике; разрезы по платформам нельзя использовать в продуктовом анализе и принятии решений
BЭто означает, что `SRM` (Sample Ratio Mismatch) автоматически отсутствует, раз общий эффект положительный по основной метрике
CВозможен эффект смешения сегментов (например, разный состав трафика по платформам); проверить распределение пользователей и корректность агрегации
DНужно смотреть только общий эффект и никогда не открывать разрезы по платформам, чтобы избежать ложных выводов из данных
Ответ: Противоречие между общим эффектом и эффектами в сегментах часто означает смещение состава трафика или некорректную агрегацию.
Если доли сегментов в вариантах отличаются, общий результат может быть «искусственным» за счёт перераспределения аудитории. В таких случаях важно проверить распределение платформ, источников трафика и других ключевых признаков, а также убедиться, что метрики агрегируются одинаково. Иногда помогает стратификация или анализ по заранее заданным сегментам. Это может быть проявлением эффекта смешения (например, парадокса Симпсона).
Подробный разбор →