Ситуация: Разбери A/B-тест нового алгоритма прогноза ETA, где ключевая метрика — ratio (доля заказов в обещанном окне), и объясни, почему нельзя наивно z-тестить по заказам.
Сервис доставки. Продуктовая команда выкатила ETA-алгоритм v3: он точнее предсказывает время прибытия курьера. Рандомизация — на уровне пользователя (все заказы юзера получают старый или новый ETA), 50/50. Главная бизнес-метрика — точность ETA = доля заказов, доставленных в обещанное окно (ratio: числитель — заказы вовремя, знаменатель — все заказы юзера). Ловушка: юнит рандомизации (пользователь) не совпадает с юнитом наблюдения (заказ), заказы одного юзера коррелируют. Аналитик считает метрики на уровне пользователя, чтобы юнит анализа совпал с юнитом рандомизации. Тест шёл 14 дней (05.05–18.05.2026).
Control (ETA v2): 15 200 пользователей; средняя |ошибка ETA| на юзера 6.4 мин (sd 3.8)Variant (ETA v3): 15 100 пользователей; средняя |ошибка ETA| на юзера 6.1 мин (sd 3.7)Снижение ошибки ETA на 0.3 мин (−4.69% относительно 6.4 мин)Ratio-метрика 'доля заказов в окне', агрегированная до пользователя: Control 74.0% (11 248/15 200 юзеров с заказом в окне), Variant 76.0% (11 476/15 100) → +2 п.п.Всего заказов за период ~205 тыс. в каждой группе (~13.5 заказа на юзера) — заказы одного юзера коррелируютСплит по факту: 15 200 vs 15 100 при заявленном 50/50alpha 0.05 двусторонний; заказы кластеризованы по пользователю (нужен delta-метод/кластерные SE для order-level ratio)