Перейти к основному содержимому

Switchback-эксперименты

Что такое Switchback-эксперимент

Switchback-эксперименты используются, когда классическая рандомизация по пользователям искажает результаты. Причина — сетевые эффекты: действия одного пользователя влияют на поведение или метрики других участников.В таких условиях традиционное A/B-тестирование может давать смещенные оценки эффекта изменений. Более релевантным дизайном для эксперимента является Switchback.

Когда применять Switchback

Этот тип экспериментов подходит для следующих сценариев:

  • Конкуренция за ограниченные ресурсы: когда пользователи из разных групп влияют друг на друга через общий пул ресурсов

  • Распространение информации: когда участники могут обмениваться информацией об условиях эксперимента

  • Техническая сложность: когда реализация персонализированного опыта для каждого пользователя технически затруднительна

  • Этические или юридические ограничения: когда различный опыт для разных пользователей недопустим

Примеры использования

Маркетплейсы и платформы доставки

Эксперименты с ценообразованием в маркетплейсах представляют классический пример необходимости Switchback-подхода. Если часть пользователей видит сниженные цены, они могут:

  • Делиться этой информацией с другими пользователями, создавая недовольство
  • Занимать слоты доставки, уменьшая доступность для контрольной группы

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

Офлайн-бизнес

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

Методология тестирования

Принцип работы

В отличие от классического A/B-теста, где рандомизация основана на пользователях, Switchback использует временну́ю и географическую рандомизацию (далее — геохрон). Геохрон — это пара: id кластера (например, регион) и временное окно (например, регион Москва в периоде с 9:00 по 9:30).

Основные принципы тестирования:

  • Все участники в определённом регионе в конкретный временной интервал получают одинаковый вариант.
  • Через заданный период происходит переключение между тестовой и контрольной версиями.
  • Анализ данных основан на сравнении метрик между периодами с разными вариантами для оценки среднего эффекта (Average Treatment Effect, ATE).

Схема работы сплиттера представлена ниже: Демонстрация сплитования по геохрону

Статистическая оценка

Стандартный t-критерий, обычно используемый в традиционных A/B-тестах, не рекомендуется для Switchback-экспериментов:

  • Единица анализа — не пользователь, а геохрон. Сетевые эффекты и зависимость наблюдений внутри кластера делают сравнение по пользователям некорректным.
  • При большом количестве маленьких геохронов или коротком эксперименте статистическая мощность теста может быть недостаточной.
  • Влияние treatment может различаться по регионам и времени, что приводит к дополнительной гетерогенности.

Оценка ATE с использованием CRSE (Sandwich Estimator)

В Trisigma основным методом оценки ATE является CRSE (Cluster Robust Standard Error), также известный как Sandwich Estimator.

Sandwich Estimator — это способ корректной оценки стандартных ошибок и доверительных интервалов в регрессионных моделях, когда наблюдения внутри групп (кластеров) могут быть зависимы друг от друга, но кластеры между собой независимы.

В классических моделях OLS предполагается, что ошибки независимы между всеми наблюдениями. В Switchback это предположение нарушается: события внутри одного геохрона часто коррелированы за счёт сетевых эффектов. Sandwich Estimator корректирует стандартные ошибки, делая выводы валидными даже при наличии внутрикластерной корреляции.

Создание Switchback-эксперимента в Trisigma

Добавление типа участника и источника

Перед созданием списка кластеров добавьте новый тип участника, который будет использоваться в Switchback-экспериментах.

  1. Перейдите в репозиторий вашего проекта

  2. Измените participant_types.yaml<id кластера> укажите предпочтительный):

    participant_types:
    - context_param: <id кластера>
    allowed_experiment_types:
    - switchback # указать тип для свитчбэков
  3. Измените context_params.yaml (id аналогично выше):

    context_params:
    - label: <id кластера>
    domain: Trisigma
    type: str
    title: <id кластера>
    status: active
    splitter_allocation_param: <id кластера>
    assignments_source_enabled: false

    Необходимо установить параметр assignments_source_enabled = false для отключения поиска в таблицах трафика.

  4. Добавьте в sources.yaml источник с сырыми данными:

    <название источника>:
    ...
    participant: { <id кластера>: geo_region_string, <id пользователя>: user_id }
    dtm: <поле с датой и временем события>
    ...
    • participant – указывается в формате пары кластера из context_params.yaml и id пользователя
    • dtm – название поля с датой и временем события. Принимается формат поля YYYY-MM-DD HH:MM:SS. Например, 2026-02-25 11:21:30
  5. Сделайте push изменений в репозиторий и Merge Request / Pull Request

Создание списка

После добавления участника в интерфейсе появится новый идентификатор. Далее добавьте список кластеров — он используется для разбиения на группы.

  1. Перейдите в Экспериментирование → Списки → Создать список

  2. В Типе источника выберите CSV, в Типе идентификатора<Ранее указанный id> (в примере на изображении ниже – h3) Заведение списка

  3. Сохраните список. Теперь он доступен для выбора в форме создания эксперимента

В CSV должно быть одно поле с перечислением всех уникальных идентификаторов кластера. Поле должно называться bucket_id.

Ограничения

  • Для Switchback-экспериментов доступен выбор идентификатора с доступным типом эксперимента Switchback в participant_types.yaml. UserID и VisitorID не доступны для использования.
  • Максимум 1 млн строк для одного файла и 10 файлов в эксперименте, но не более 3 млн строк на все файлы

Создание эксперимента

  1. Перейдите в Экспериментирование → Эксперименты → Новый эксперимент
  2. В поле Тип выберите Switchback Выбор свитчбэка
  3. Заполните остальные поля (Название, Команда, ...) и нажмите Продолжить
  4. Укажите необходимые поля и настройки в разделе Дизайн эксперимента. Подробное описание — ниже. Нажмите Продолжить.
  5. Укажите метрики в разделе Метрики. На текущий момент поддерживается только CRSE-метод вычисления результатов. О том как настроить метрики, см. Настройка метрик
  6. Заполните параметры в разделе Настройка отчёта. В отличие от обычного эксперимента, параметр Exposure недоступен для настройки.
  7. Перейдите в раздел Предпросмотр и проверьте настройки эксперимента.

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

  • В Типе бакета укажите id рандомизации, ранее заданный в participant_types.yaml и context_params.yaml. Идентификатор используется только для разбиения в Switchback-экспериментах. На него присваивается id группы (контроль, тест и т.п.).
  • В Списках бакетов перечислите все id кластеров для разбиения. В разбиении участвуют только id, указанные в списках. Все id, по которым поступает обращение через API или SDK, но которые не указаны в списках, — игнорируются. Пример: вы запрашиваете группу по bucket_id = 1, но в списках указаны только 2, 3 — ответ не содержит группы, так как 1 отсутствует в списке.

Параметры аллокации

  • В Объёме кластеров укажите долю bucket_id, участвующих в разбиении. Пример: в списках 1000 уникальных bucket_id, в Объёме кластеров указано 50% — в эксперимент попадёт только 500 кластеров. Трафик внутри кластеров не учитывается.
  • В Временной зоне эксперимента укажите значение, от которого настраивается расписание.
  • В Дате и времени запуска укажите планируемое время старта. От него рассчитывается распределение Switchback-окон (см. далее).
  • Длительность эксперимента — необязательный параметр.
  • Длительность окна — период, на который фиксируется разбиение групп. Максимум — 1440 минут (24 часа).
  • Burn In / Burn Out — переходные периоды внутри Switchback-окна, исключаемые из анализа. Необходимы для нивелирования эффекта перетекания между группами и повышения точности результатов. Минимум — 5 минут. Если длительность окна составляет 15 минут или меньше, Burn In / Burn Out не задаются.

Интеграция API

После создания и настройки эксперимента в Trisigma интегрируйтесь с API Switchback в кодовой базе. Подробнее: Интеграция с возможностями Switchback-платформы