Зачем нужно уменьшать snippet?

Уменьшение snippet (выборки) для тестирования

Это практический вопрос о статистике и экспериментальном дизайне. Дам прямой ответ с примерами.

Что такое snippet в контексте A/B тестирования?

Snippet — это подвыборка данных из всей базы, используется для:

• Быстрого анализа (вместо всех 1 млрд юзеров смотрим на 100k)
• Предварительной проверки гипотезы (риск ошибиться меньше)
• Контроля типа ошибки (false positives)

Зачем нужно уменьшать snippet?

1. Контроль множественных сравнений

Основная причина: когда мы проверяем много гипотез одновременно, вероятность false positive (ошибка типа I) растёт.

Пример:

• Тестируем новый дизайн
• Смотрим на 20 метрик: конверсия, retention, ARPU, bounce rate, ...
• Даже если никакого эффекта нет, в среднем 1 из 20 метрик будет "значима" с p-value < 0.05

Решение: уменьшить snippet (взять меньшую выборку) или применить correction (Bonferroni).

2. Контроль false discovery rate (FDR)

Суть: когда мы проверяем много гипотез, нужно контролировать, какой процент из них — ошибки.

Стратегия:

• Сначала проверяем на маленькой выборке (snippet), считаем, какие эффекты выглядят реальными
• Потом проверяем на большой выборке (полной базе)
• Это двухэтапный A/B тест

На цифрах:

• Первый snippet: 10% трафика, 10 дней, ищем эффекты
• Второй этап: 100% трафика, 20 дней, подтверждаем значимые эффекты

3. Ускорение итераций

Бизнес-причина: каждый день A/B теста стоит денег, пользователи ждут фич.

Сценарий:

• Тестируем новую фичу на 5% трафика
• Видим чёткий негативный эффект (конверсия вниз на 30%)
• Останавливаем тест, не ждём 30 дней
• Экономим деньги на потерянных продажах

Альтернатива:

• Ждали бы 30 дней на 100% трафика
• Потеряли бы больше денег

4. Ограничение p-hacking (cherry picking)

Проблема: если смотреть на результаты в реальном времени, легко найти ошибочный эффект.

Пример:

• День 1: конверсия в тесте выше на 25% (lucky day, не значимо)
• День 2: конверсия в контроле выше на 15%
• День 5: случайно выросла в тесте на 10%
• Объявляем: "Ура, тест значимый!" (ошибка)

Решение: анализировать на маленьком snippet раз в неделю, вместо того, чтобы смотреть каждый час.

Пример из практики

Сценарий: e-commerce компания тестирует новый способ оплаты

День 1-2 (маленький snippet, 2% трафика):

• N = 10k пользователей
• Конверсия: контроль 5%, тест 5.5%
• Effect size: +10%, но не значимо (p-value = 0.15)
• Вывод: нужно больше данных

День 3-7 (средний snippet, 10% трафика):

• N = 50k пользователей
• Конверсия: контроль 5%, тест 5.3%
• Effect size: +6%, значимо (p-value = 0.02)
• Вывод: эффект реальный, но скромнее

День 8-14 (полный тест, 100% трафика):

• N = 500k пользователей
• Конверсия: контроль 5%, тест 5.28%
• Effect size: +5.6%, очень значимо (p-value < 0.0001)
• Вывод: внедряем новый способ оплаты

Как правильно проводить пошаговые тесты

Вариант 1: Sequential Testing (Sequential Probability Ratio Test)

Идея: закончить тест как только достаточно доказательств.

Процесс:

1. Определяем размер эффекта, который хотим обнаружить (30% прирост)
2. Определяем Type I и Type II errors (alpha=0.05, beta=0.2)
3. Рассчитываем sample size (N нужно)
4. Каждый день проверяем: есть ли значимость? Если да — стоп, если нет — продолжаем

Плюсы:

• Можем закончить тест на 30% раньше, если эффект большой
• Контролируем false positive rate

Минусы:

• Требует корректировку для multiple tests
• Нужно знать формулы (или использовать инструменты)

Вариант 2: Bonferroni correction

Для 20 метрик, вместо p-value < 0.05, требуем p-value < 0.05/20 = 0.0025

Плюсы:

• Просто, легко применить
• Уменьшает false positives

Минусы:

• Очень консервативный (может пропустить реальные эффекты)
• Плохо работает, если метрики скоррелированы

Вариант 3: FDR (False Discovery Rate) control

Более мягкий, чем Bonferroni:

• Контролируем не вероятность одной ошибки, а % ошибок среди найденных эффектов
• Например: из 20 найденных эффектов, максимум 5% ошибки

Это более практично для реальных экспериментов.

Когда НЕ нужно уменьшать snippet

1. Если у вас одна основная метрика

• A/B тест с одним KPI (например, только конверсия)
• Множественное тестирование не нужно
• Обычный t-test работает

2. Если уже запланирован размер выборки

• Если рассчитали, что нужно 1 млн пользователей
• Уменьшать snippet может привести к false negatives

3. Если нет ограничений по времени/бюджету

• Если можем ждать 30 дней результаты
• Тогда просто проводим полный тест

Мой практический совет

Процесс, который я использую:

1. Планирование (перед запуском теста):

   • Определяю одну основную метрику (конверсия, retention, ARPU)
   • Рассчитываю минимальный sample size
   • Определяю, какие метрики буду мониторить (максимум 5)

2. Первый check (день 3-5, 10% данных):

   • Смотрю на основную метрику
   • Если есть очень большой негативный эффект (>20% падение), завершаю тест
   • Иначе, жду дальше

3. Второй check (день 10-15, 50% данных):

   • Проверяю статистическую значимость основной метрики
   • Если она уже значима, завершаю (сэкономил время)
   • Иначе, жду запланированный срок

4. Финальный анализ:

   • После того, как собрал весь запланированный sample size
   • Не смотрю, что было "значимо" в промежуточных анализах
   • Делаю финальный тест на полном наборе данных

Вывод

Уменьшение snippet (маленькие выборки) — это инструмент контроля ошибок и ускорения итераций. Главные причины:

✓ Контроль false positives — при проверке многих гипотез ✓ Быстрая остановка — если очевидный негативный эффект ✓ Экономия ресурсов — не ждёшь 30 дней, если уже ясно ✓ Предварительная валидация — перед полным запуском

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