Красные флаги офлайн A/B: если видите эти симптомы — выводам из теста верить нельзя
Офлайн A/B обычно выглядит красиво на слайдах: районы поделили, магазины/курьеров разнесли, метрики посчитали. А потом в отчёте появляется «эффект», но вместе с ним скачки в SLA, странные когорты и магия “работает только в одном районе”. Цена ошибки здесь не в p-value, а в решениях: масштабируете не то, ломаете операционку, ссорите команды.
Почему так происходит: в офлайне лечение почти всегда «протекает» через процессы. Назначение варианта не выдерживается, экспозиция фиксируется криво, параллельно меняются правила работы, и вы тестируете не фичу, а смесь фичи, дисциплины и ручного управления. Данные в логах при этом часто выглядят правдоподобно — пока не начинаешь сверять разные источники.
Минимальный набор “симптом → причина → что проверить”:
- Скачки SLA/отмен/возвратов совпали со стартом теста → вмешались в нагрузку или приоритеты → проверь переключения смен, правила диспетчеризации, лимиты слотов, очереди, а также долю “ручных” обработок и эскалаций в этот период.
- Странные когорты: в тесте внезапно больше “тяжёлых” заказов/премиумов/новых пользователей → назначение было не случайным или с фильтрами → проверь ключ назначения (район, магазин, курьер), стабильность маппинга во времени, долю объектов без варианта, и баланс по пред-периоду на базовых метриках.
- “Эффект” только в одном районе/нескольких точках → локальная акция, управленческая воля или внешний шок → проверь календарь промо и локальных изменений, ротации персонала, а также наличие соседних зон, которые фактически обслуживают друг друга (перетоки).
- В отчёте всё отлично, но операционщики говорят “в реальности не так” → измерение расходится с реальным процессом → сверь логи экспозиции с фактом выполнения: события статусов, времена в трекинге, источники правды (WMS/CRM/колл-центр), и проверь, что события не “догружаются” задним числом асимметрично по вариантам.
- Метрика улучшилась, но только потому что упало покрытие → перестали мерить часть случаев → проверь долю пропусков, таймауты, изменения схемы/валидаторов, и распределение “unknown/other” по вариантам.
Правильная практика офлайн A/B — это не «посчитать среднее», а собрать цепочку причинности: назначение → экспозиция → поведение → результат, и на каждом шаге иметь контроль целостности. Обычно спорят про статистику, но чаще ломается именно трекинг и соблюдение варианта. Если вмешательство нельзя изолировать от процессов (или оно меняется “по ходу”), честнее идти в квази-эксперимент и заранее описывать допущения.
