Красный флаг на A/B собесе: «я посчитал конверсию» вместо «я измерил эффект» — не уточнил единицу анализа.
Типичный сценарий: рандомизация по пользователю, а в SQL считают по сессиям или заказам. Цифра получается красивой, статистика “сходится”, но это уже другой эксперимент: вы дали больший вес тем, кто чаще приходит или чаще покупает. В итоге эффект легко “рисуется” одной активной когортой, а решение потом больно бьёт по продукту.
Механика простая: в A/B важно, кто получает лечение, и кто является независимым наблюдением. Если лечение назначили пользователю, то все его сессии и заказы — зависимые внутри одного кластера. Наивный SQL превращает одного человека в десять строк и делает вид, что это десять независимых людей. Плюс классика: вы фильтруете данные по событиям, которые сами же меняете экспериментом, и теряете часть аудитории из анализа.
Минимальный стандарт, который я ожидаю услышать и увидеть в запросах:
- На чем рандомизировали: user_id, device_id, cookie, account_id, geo, день? Это и есть базовая единица, под которую строится анализ.
- Метрика должна агрегироваться на уровне рандомизации: сначала считаем результат на пользователя (0/1, выручка, число заказов), потом сравниваем группы. Не наоборот.
- Повторяющиеся события не “усредняем” строками: сессии и заказы схлопываем в user-level фичи за окно, иначе получаем перекос по heavy users.
- Четко фиксируем exposure и окно: кто считается попавшим в эксперимент, когда старт измерения, как режем хвосты. Без этого легко поймать leakage и разный риск-тайм.
- Бережно с джойнами: 1-to-many джойн без контроля = скрытое умножение. Проверка простая: после всех джойнов число уникальных единиц рандомизации в группе не должно “плавать”.
В правильной практике эффект — это разница распределений на уровне рандомизации, с понятным правилом включения (обычно intent-to-treat) и прозрачным окном. А сессии/заказы — это сырьё для user-level метрик, а не “наблюдения” сами по себе. Исключение одно: если рандомизация реально была на уровне сессии, тогда да — можно анализировать сессии, но это должен быть осознанный дизайн, а не случайность в SQL.
