SQL для A/B тестирования: расчёт метрик и выборок

Что обычно считают в A/B тесте

• Conversion Rate (CR) — доля пользователей, совершивших целевое действие
• Average Revenue Per User (ARPU) — средняя выручка на пользователя
• Retention — возврат пользователей через N дней
• Средний чек / число заказов / CTR — в зависимости от продукта

Важно: метрики почти всегда считают по пользователю, а не по событиям. Иначе один активный пользователь может исказить результат.

Как собрать выборки

Основа любого теста — разделение пользователей на группы A и B. Обычно в таблице есть:

• user_id
• experiment_group
• дата попадания в тест
• события: просмотры, клики, покупки

Пример базовой выборки пользователей:

SELECT user_id, experiment_group
FROM experiment_users
WHERE experiment_name = 'new_checkout_test'

Пример расчёта конверсии

Допустим, целевое действие — покупка:

SELECT
    eu.experiment_group,
    COUNT(DISTINCT eu.user_id) AS users_cnt,
    COUNT(DISTINCT p.user_id) AS buyers_cnt,
    ROUND(COUNT(DISTINCT p.user_id) * 1.0 / COUNT(DISTINCT eu.user_id), 4) AS conversion
FROM experiment_users eu
LEFT JOIN purchases p
    ON eu.user_id = p.user_id
    AND p.created_at >= eu.entered_at
WHERE eu.experiment_name = 'new_checkout_test'
GROUP BY eu.experiment_group;

Здесь важно:

• использовать LEFT JOIN, чтобы не потерять пользователей без покупки
• считать COUNT(DISTINCT user_id), чтобы убрать дубли
• учитывать только события после входа в эксперимент

Пример расчёта ARPU

SELECT
    eu.experiment_group,
    COUNT(DISTINCT eu.user_id) AS users_cnt,
    SUM(COALESCE(p.amount, 0)) AS revenue,
    ROUND(SUM(COALESCE(p.amount, 0)) * 1.0 / COUNT(DISTINCT eu.user_id), 2) AS arpu
FROM experiment_users eu
LEFT JOIN purchases p
    ON eu.user_id = p.user_id
    AND p.created_at >= eu.entered_at
WHERE eu.experiment_name = 'new_checkout_test'
GROUP BY eu.experiment_group;

Частые ошибки в SQL для A/B тестов ⚠️

• Смешивание событий до и после старта теста
• Подсчёт событий вместо уникальных пользователей
• Потеря “нулевых” пользователей из-за INNER JOIN
• Неверная агрегация при нескольких покупках на одного пользователя
• Игнорирование фильтров: платформы, страны, источника трафика

Что проверить перед выводами

• равномерность распределения пользователей по группам
• одинаковый горизонт наблюдения
• отсутствие пересечения групп
• корректность логики исключений
• соответствие метрики бизнес-цели 📈

Хороший SQL в A/B тестировании — это не просто запрос, а способ защитить эксперимент от ложных выводов. Чем чище выборка и точнее расчёт метрик, тем выше шанс принять правильное продуктовое решение.