Меня зовут Даниил Никольский, я бэкенд-инженер команды Trisigma. В создании статьи участвовали Искандер Мирмахмадов, руководитель продуктового направления, и Александр Кузнецов, старший аналитик. В этой статье я расскажу про Switchback-эксперименты, рассмотрим как они устроены, почему для него не подходит обычный t-тест, и какая инфраструктура нужна, чтобы проводить такие эксперименты в промышленном масштабе.
Решение доступно всем желающим по ссылке, а тут можно познакомиться с подробной технической документацией.
В этой статье:
Когда классический A/B ломается
Мы знаем, что классический A/B-тест опирается на предположение о независимости единиц эксперимента. Если пользователь из тестовой группы не влияет на пользователя из контрольной, оценки работают корректно. Однако в ряде предметных областей это условие нарушается системно. Давайте разбираться подробнее.
Это может быть:
Конкуренция за общий ресурс
В таком сценарии, пользователи из разных групп претендуют на один и тот же ограниченный ресурс. Типичные примеры — каршеринг и кикшеринг (машины, самокаты), рекламные биржи (слоты для показов), сервисы доставки.
Когда тестовая и контрольная группы борются за одни и те же объекты, эффект воздействия перетекает из группы в группу. Тестовая группа не генерирует дополнительный спрос, а перехватывает ресурс у контрольной. Оценка среднего эффекта воздействия, Average Treatment Effect (ATE), оказывается систематически смещённой.
Распространение информации
В данном случае, участники теста узнают об условиях, в которых находятся другие участники, и меняют свое поведение. Это характерно для социальных сетей, маркетплейсов с отзывами, сервисов с видимыми ценами или рейтингами.
Важно! В данном случае, под «маркетплейсами» подразумевается бизнес-модель, в которой взаимодействуют два типа аудиторий. Например: селлеры и баеры, водители и пользователи, репетиторы и ученики и т.п.
Если пользователь из контрольной группы видит, что тестовая группа получает скидку, он может изменить свои действия — например, отложить покупку или перейти на другой сервис.
Нарушается принцип SUTVA (Stable Unit Treatment Value Assumption) — требование к эксперименту, согласно которому воздействие на каждый объект должно быть строго одинаковым по форме (нет скрытых вариаций) и не влиять на результат других объектов через межличностное взаимодействие. Из-за этого перестаёт работать классическая статистика.
Техническая сложность
Демонстрировать разным пользователям разное поведение архитектурно дорого или невозможно. Например, при тестировании моделей ценообразования расчёт может занимать часы или требовать пересборки сложных конвейеров.
Другой случай — рекомендательные системы с предварительным вычислением эмбеддингов. Запуск параллельных версий алгоритма для разных групп пользователей может потребовать двукратного увеличения вычислительных ресурсов. В таких ситуациях эксперимент либо становится экономически нецелесообразным, либо вовсе нереализуемым.
Юридические и этические ограничения
В ряде отраслей закон или этические нормы прямо запрещают предоставлять разным пользователям разный опыт. Федеральный закон в офлайн-ритейле (как в российской практике, так и в зарубежных аналогах) запрещает показывать разную цену разным покупателям в зависимости от их предпочтений.
В банкинге и медицине разный уровень сервиса или разная стоимость услуг для разных клиентов может считаться дискриминацией. В таких сферах классический A/B-тест с user-level рандомизацией неприменим по правовым основаниям.
Следовательно, нужен метод, который не опирается на независимость единиц эксперимента. Такую альтернативу предлагает Switchback.
Практические кейсы
Давайте смоделируем ситуацию на примере гипотетического кейса с такси и посмотрим, из-за чего конкретно классическое A/B-тестирование дает неправильный результат.
Проверяется гипотеза: снижение ценового коэффициента для водителей с 1.0 до 0.5 увеличивает число поездок за счёт более низкой цены для пассажиров. Задача — корректно измерить эффект.
Попытка №1: делим водителей по user_id
Первый и самый очевидный подход — классический A/B-тест. Все водители случайным образом делятся на две группы по идентификатору пользователя. Тестовая группа получает коэффициент 0.5, контрольная остаётся с коэффициентом 1.0.
В реальности этот дизайн не работает. Водители из обеих групп ездят по одним улицам и конкурируют за одних и тех же пассажиров. Заказ, который достался водителю из тестовой группы, мог быть выполнен водителем из контрольной. При этом цена поездки не определяет сам факт совершения поездки — пассажиру в любом случае нужно добраться до работы.
Эффект воздействия перетекает между группами. Тестовая группа не генерирует дополнительные заказы, а забирает их у контрольной. Оценка ATE (среднего эффекта воздействия) систематически смещается. Такой эксперимент не даёт ответа на исходный вопрос.
Попытка №2: Москва — тест, Санкт-Петербург — контроль
Вторая попытка решает проблему перетока за счет географической изоляции. Вся тестовая группа размещается в Москве, контрольная — в Санкт-Петербурге. Водитель из Москвы физически не может отобрать заказ у водителя из Петербурга. Изоляция достигнута.
Однако теперь группы становятся несравнимы. Москва и Санкт-Петербург различаются по плотности трафика, экономике транспорта, погодным условиям, наличию разводных мостов и сезонным паттернам спроса. Любое изменение в метриках, зафиксированное в эксперименте, может быть как следствием нового коэффициента, так и фундаментальной разницы между городами. Изоляция есть, а сравнимости нет.
Попытка №3: один город, разные районы
Третий подход сохраняет эксперимент внутри одного города, но делит районы. Например, Петроградский район назначается тестом, Адмиралтейский — контролем. Погода, экономика, сезонные процессы теперь одинаковы. Сравнимость лучше.
Проблема возникает с временной динамикой. Утром поток пассажиров движется в центр города, вечером — обратно. Один район становится донором пассажиров, другой — точкой назначения. Это не случайный шум, который усредняется на длинной дистанции, а систематический сдвиг, который со временем только растёт. Метрики искажаются из-за направленного движения людей между районами.
Попытка №4: тасуем районы во времени
Четвертая попытка объединяет идеи предыдущих. Районы не закрепляются за группами навсегда. Каждый час (или другой временной интервал) каждому району случайным образом назначается тестовая или контрольная группа. Через следующий час назначение может измениться.
В Петроградском районе с 14:00 до 15:00 может действовать коэффициент 0.5, с 15:00 до 16:00 — коэффициент 1.0. Адмиралтейский район в те же временные интервалы получает противоположные значения. На протяжении всего эксперимента каждый район побывает и в тестовой, и в контрольной группе в разные часы суток, в разные дни недели.
Систематический временной сдвиг усредняется. Эффект, наблюдаемый в итоговых метриках, обусловлен именно воздействием на тестовую группу, а не разницей между районами или временем суток. Изоляция сохраняется, поскольку в каждый момент времени районы не конкурируют друг с другом за пассажиров (пассажиры и водители остаются в своих районах в пределах окна).
Все подходы упираются в одно и то же противоречие: нужна одновременно изоляция групп и их сравнимость. Решение существует и называется Switchback-тестированием.
Единицей рандомизации в таком дизайне становится не пользователь и не географический регион. Это пара: кластер (район, точка на карте, любая группа объектов) и временное окно. В рамках одного кластера в заданный интервал времени действует фиксированная группа. Следующий интервал может принести другую группу.
Метод Switchback-экспериментов не ограничивается геозадачами. Кластером может быть рекламная кампания, точка офлайн-ритейла или категория товара. Подход работает в банкинге, телекоме, маркетплейсах — везде, где классический A/B не может корректно применяться из-за сетевых эффектов.
Анатомия Switchback: геохрон, окна, перетекание эффекта
Чтобы понять, как такой эксперимент работает на уровне инфраструктуры, необходимо разобрать три вещи: суть геохрона, универсальность кластера и проблему перетекания эффекта между временными окнами.
Что такое геохрон и почему это first-class citizen
В классическом A/B-тесте фундаментальной единицей является пользователь (user_id). Ему назначается группа, по нему агрегируются действия, на нём считается эффект. В Switchback-дизайне эта роль переходит к другому объекту — геохрону.
Геохрон — это пара, состоящая из идентификатора кластера и временного окна. Например: «Петроградский район с 14:00 до 15:00 в среду». Кластер может быть географическим (район, квартал, гексагон), но не обязан им быть. Временное окно — непрерывный интервал, в течение которого для данного кластера действует фиксированная группа (тест или контроль).
Геохрон выполняет три функции. Во-первых, он является единицей сплитования: именно на геохрон назначается группа. Во-вторых, единицей анализа: метрики агрегируются на уровне геохрона, а не на уровне пользователя. В-третьих, единицей отсчёта: средний эффект воздействия (ATE) вычисляется на агрегированных геохронах. Если в платформе для экспериментов эта концепция отсутствует, вероятно, она не поддерживает Switchback на системном уровне.
Cluster ID — это просто строка
В индустрии Switchback традиционно ассоциируется с геоэкспериментами. DoorDash использует целые города как кластеры. Delivery Club делит карту по рекам и магистралям. Ситимобил опирается на гексагоны H3 и полигоны. Однако с точки зрения метода кластер — это произвольный идентификатор.
cluster_id в общем случае является строкой. Значение этой строки определяет сам сервис и его доменная модель. Кластером может быть название города, идентификатор рекламной кампании, код точки офлайн-ритейла, категория товара в интернет-магазине. Например: campaign:promo_2026_q2, store:auchan_msk_42, category:auto.
Такая универсальность расширяет применимость метода далеко за пределы геозадач. Switchback работает в банкинге (кластеры — отделения или типы клиентских операций), в ритейле (кластеры — магазины или категории товаров), в телекоме (кластеры — базовые станции или тарифные планы), а также в любых регулируемых сферах, где разный опыт для разных пользователей запрещен юридически.
Spillover effect и параметры Burn-in / Burn-out
При переключении групп во времени возникает побочный эффект. Предположим, водитель получает заказ в тестовой группе (коэффициент 0.5) в последнюю минуту временного окна. Поездка длится 20 минут. Списание средств происходит уже в следующем окне, где группа может быть контрольной (коэффициент 1.0). Событие, порождённое тестовым воздействием, атрибутируется к контрольной группе. Это явление называется spillover effect — перетекание эффекта между группами из-за смены группы во времени.
Для борьбы со spillover используются два параметра: Burn-in и Burn-out.
Burn-in (период «прогрева») исключает из анализа начало временного окна — события, которые могли быть инициированы в предыдущем окне.
Burn-out (период «затухания») исключает конец окна — события, которые могут «улететь» в следующее окно. Между ними остается «чистое» ядро окна, где группа гарантированно соответствует воздействию.
Ключевая особенность: Burn-in и Burn-out являются настраиваемыми параметрами анализа, а не дизайна эксперимента. Аналитик может выставить их после завершения теста, посмотреть, как меняются результаты, и при необходимости пересчитать отчёт. Это позволяет исправлять ошибки без перезапуска эксперимента. Если же окно слишком короткое (например, 5 минут), разместить в нем ненулевые Burn-in и Burn-out физически невозможно — это становится ограничением самого дизайна.
Таким образом, Switchback строится на трёх элементах: геохрон как единица эксперимента, произвольный строковый идентификатор кластера и параметры очистки переходных периодов. Но на выходе мы получаем метрики, по которым нужно принять решение — значим эффект или нет. Здесь возникает следующий вопрос: как считать статистику, если наблюдения внутри геохрона заведомо зависимы? Обычный t-тест для такого случая не годится. Разберём почему.
Почему обычный t-test не подходит
Зависимые наблюдения внутри геохрона
A/B-тест основан на предположении о независимости наблюдений. Каждое действие пользователя считается независимым событием. Это позволяет вычислять стандартные ошибки по стандартным формулам и применять t-тест.
В Switchback-дизайне ситуация иная. Все события, произошедшие внутри одного геохрона (кластер × временное окно), не являются независимыми. Пользователи внутри кластера конкурируют за общий ресурс (машины, курьеры, слоты), обмениваются информацией или влияют на поведение друг друга. Наблюдения скоррелированы.
Если применить обычный t-тест к таким данным, стандартные ошибки окажутся заниженными. Доверительные интервалы станут слишком узкими. В результате ложноположительная ошибка (false positive rate, FPR) будет существенно выше заявленного. Эксперимент будет показывать статистически значимый эффект там, где его на самом деле нет. Это делает классический t-тест неприменимым для Switchback.
Cluster-Robust Standard Errors (CRSE, он же sandwich estimator)
Необходим оценщик, который учитывает корреляцию наблюдений внутри кластеров и временных окон. Таким инструментом являются кластерно-устойчивые стандартные ошибки (Cluster-Robust Standard Errors, CRSE), известные также как sandwich estimator.
Идея метода заключается в том, чтобы явно сообщить оценщику структуру зависимости. Наблюдения группируются по кластерам (геохронам). Оценщик вычисляет ковариационную матрицу таким образом, чтобы корреляция внутри кластеров не приводила к занижению стандартных ошибок. Формально это достигается через корректировку произведения градиентов.
CRSE работает в рамках регрессионной модели и применим к произвольным метрикам — счётчикам (counter), уникальным объектам (uniq), отношениям (ratio). Результат — валидные доверительные интервалы, которые корректно отражают реальную дисперсию эксперимента.
При этом сам метод не требует изменения дизайна эксперимента или агрегации данных. Достаточно передать оценщику информацию о принадлежности каждого наблюдения к своему геохрону.
Как Trisigma сделала платформу для Switchback
Промышленный Switchback требует не только корректной статистики, но и инфраструктуры: управления назначениями, атрибуции событий, гибкой настройки параметров. Посмотрим, как эти задачи решены в системе Trisigma.io.
Платформа изначально разрабатывалась в Авито как инструмент для автоматизации A/B-тестирования и аналитики. Сейчас это выросло до отдельного решения, которое самостоятельно представлено на рынке.
Все желающие могут установить и познакомиться с платформой более предметно по ссылке. Если у вас возникнут вопросы, или вы хотите поделиться обратной связью, можно связаться с нами по указанным контактам.
Изначально платформа решала задачи классических user-level экспериментов, но затем в нее была добавлена полноценная поддержка Switchback-дизайна. Ниже рассмотрим ключевые возможности и архитектурные решения, которые позволяют проводить такие эксперименты в промышленном масштабе.
Что аналитик может настроить
Аналитик, создающий Switchback-эксперимент, получает несколько степеней свободы.
Размер окна. Длительность временного окна определяется доменной инерцией конкретной системы. В одном сервисе эффект от изменения может проявиться за 15 минут, в другом — за сутки. Платформа не навязывает фиксированный шаг. Допустимы любые значения: от 15 минут до нескольких дней. Разные эксперименты могут использовать разные размеры окон.
Аллокация трафика. В каждом временном окне случайным образом выбирается определенный процент кластеров, которые получают тестовую группу. В следующем окне выборка происходит заново. Это не фиксированная разбивка, а настоящая рандомизация с перетасовкой.
ABCDN-тесты. Поддерживается произвольное количество групп. Аналитик может задать любые веса: 50/50, 75/25, 33/33/34, 10/20/30/40. В одном эксперименте проверяется несколько гипотез одновременно.
Изменение параметров на ходу. Развесовка групп и правила аллокации могут быть скорректированы без остановки и перезапуска эксперимента. Например, если в районе возникает аномалия, его можно исключить из теста прямо во время его проведения. Это полезно для постепенной раскатки рискованных изменений.
Главное архитектурное решение: материализация назначений
При реализации Switchback возникает соблазн вычислять группу для каждого геохрона на лету по хешу от идентификатора кластера и временного окна. Этот подход порождает несколько проблем.
Первая проблема — race condition. Два последовательных запроса, пришедших в одну миллисекунду, могут получить разные группы из-за того, что временная метка округлилась по-разному.
Вторая проблема — десинхронизация между SDK и DWH. Сервис и хранилище данных могут использовать разные реализации хеш-функции или разное представление времени, из-за чего join событий с назначениями не сходится.
Третья — невоспроизводимость. Если нет сохраненного снапшота назначений, невозможно ответить на вопрос, какая группа действовала в пятницу в 15:00 на Петроградке.
Четвёртая — отсутствие аудита.
Платформа Trisigma.io решает эти проблемы через материализацию назначений. Заранее генерируется таблица assignments, содержащая для каждого эксперимента, временного окна и кластера фиксированную группу. SDK и DWH читают одну и ту же таблицу. Гонка исключена, десинхронизация невозможна, воспроизводимость обеспечена. Цена — дополнительные вычислительные ресурсы (до 2 миллионов записей в сутки на крупных тестах), но она признаётся оправданной.
API: один контракт, две стратегии
Клиентский сервис (например, диспетчер доставки) обращается к API платформы с запросом на получение назначений для текущего момента. Контракт един для всех стратегий и возвращает список пар {clusterId, experimentId, group, windowStart, windowEnd}.
В текущей версии используется стратегия deterministic random. Группа вычисляется как хеш от experiment_id, window_start и cluster_id. Это детерминированный, воспроизводимый и материализуемый способ.
В разработке находится стратегия балансировщика. Это жадный алгоритм, который в near-realtime режиме собирает метрики supply и demand (доступные машины, поступившие заказы) и динамически корректирует назначение групп для более честного перемешивания. Важно, что внедрение балансировщика не потребует изменения кода клиентов — API уже абстрагирован от внутренней реализации. Требование к latency — не более 500 миллисекунд на 99-м перцентиле.
Что нужно от клиента – только cluster_id
Клиентский сервис не должен самостоятельно определять группу или эксперимент. Достаточно, чтобы каждое событие (заказ, поездка, клик) содержало три поля: cluster_id, dtm (временная метка) и тип события. Остальное делает DWH.
Хранилище данных джойнит поток событий с таблицей assignments по двум ключам: cluster_id и dtm (с учётом попадания временной метки в интервал window_start — window_end). В результате каждое событие получает атрибуцию к конкретному эксперименту и группе. Такой подход позволяет пересчитывать эксперимент задним числом, меняя параметры Burn-in/Burn-out или даже исключая целые кластеры, без повторной отправки данных от клиента.
Та же фабрика метрик, что и для обычных A/B
В Trisigma.io реализован семантический слой — конфигурационное описание метрик на YAML. Слой поддерживает три базовых типа: counter (число событий), uniq (уникальные объекты), ratio (отношение). Из них можно собирать произвольные бизнес-метрики.
Для Switchback не потребовалось создавать отдельный механизм. Достаточно переключить один флаг в конфигурации источника метрик: assignments_source_enabled = false. В этом режиме атрибуция происходит не через exposure, который присылает клиент, а через пару (cluster_id, dtm). Все остальные слои аналитики — агрегация, построение отчётов, расчёт доверительных интервалов через CRSE — работают единообразно. Аналитик использует один и тот же интерфейс и один и тот же навык для обычных A/B и для Switchback.
Где Switchback работает, а где лучше быть аккуратным
Switchback — не универсальное решение для всех экспериментов. Его применимость зависит от трех условий. Если они выполняются, метод дает корректные оценки. При нарушении хотя бы одного из них результаты могут оказаться ненадежными.
Работает хорошо
Кластеры почти независимы. Взаимодействие между разными кластерами должно быть минимальным. Добиться полной независимости невозможно, но высока вероятность, что события в одном кластере не влияют на события в другом. Например, два географически удалённых района с ограниченным перемещением людей подходят хорошо.
Окно длиннее доменной инерции системы. Под инерцией понимается время, за которое система полностью переходит под действие новой группы. Если изменение коэффициента в такси начинает влиять на поведение водителей через 3 минуты, а окно установлено в 2 минуты, то корректный Burn-in разместить не удастся. Окно должно заведомо превышать все переходные процессы.
Большинство пользователей не пересекают границы кластера за одно окно. Чем стабильнее состав пользователей внутри кластера на протяжении временного окна, тем чище оценка. Для географических экспериментов это означает, что люди не должны массово переезжать из района в район в течение часа.
Аккуратно
Размер кластеров требует отдельного внимания. Слишком маленькие кластеры могут приводить к высокой дисперсии метрик, но влияние на статистическую мощность неоднозначно — в некоторых конфигурациях мощность может даже вырасти. Оптимальный размер кластера зависит от конкретной задачи, структуры данных и дизайна эксперимента. Его подбор — самостоятельная задача при проектировании Switchback.
Слишком короткие окна. Выбор размера окна — компромисс между статистической мощностью и возможностью очистки переходных периодов. Короткое окно оставляет мало места для параметров Burn-in и Burn-out: если окно составляет 5 минут, вычитание первой и последней минуты может оставить слишком мало данных для анализа. Однако в ряде случаев бизнес-логика диктует фиксированную длину окна (например, при обновлении цен в сервисе каждые 15 минут). Размер окна следует подбирать исходя из оптимума по мощности и в соответствии с неизменяемыми ограничениями предметной области.
Высокомобильные пользователи. Если объекты эксперимента (водители, курьеры, пользователи) регулярно перемещаются между кластерами в пределах одного временного окна, нарушается предположение о стабильности состава. Классический пример — междугородние перевозки, где один водитель за час может сменить три кластера. В таких условиях Switchback теряет эффективность.
Платформа предоставляет инструменты для проведения Switchback-экспериментов, но не берет на себя выбор кластеров и размера окон. Проектирование дизайна эксперимента остается ответственностью аналитика. Не существует автоматического способа определить, является ли данный набор кластеров достаточно независимым или данное окно достаточно длинным. Это предметное знание, которое должен привносить сам сервис.
Roadmap
Платформа Trisigma.io уже поддерживает Switchback-эксперименты в описанном объёме, но три направления находятся в разработке.
MDE-калькулятор для Switchback
В классических A/B-тестах минимально детектируемый эффект (Minimum Detectable Effect, MDE) вычисляется аналитически на основе дисперсии метрики и размера выборки. Для Switchback дисперсия зависит от размера кластеров и длины временного окна. Универсальной аналитической формулы не существует.
В текущей версии задача оценки мощности эксперимента решается аналитиком самостоятельно: он задаёт предполагаемый эффект и параметры дизайна, проводит симуляции и интерпретирует результаты. Платформа пока не берет на себя этот расчёт, но в roadmap входит встроенный калькулятор MDE для заданных геохронов.
Расширение пула оценщиков
В текущей реализации используется CRSE (cluster-robust standard errors) в рамках регрессионной модели. Это надёжный, но не единственный подход. Рассматриваются альтернативные оценщики, в частности MLM (mixed linear models) и Horvitz-Thompson estimator. Разные классы задач могут требовать разных статистических инструментов. Расширение пула оценщиков позволит аналитику выбирать метод в зависимости от структуры данных и бизнес-вопроса.
Балансировщик
Deterministic random — стратегия, основанная на хешировании. Она воспроизводима и проста, но не учитывает текущее состояние системы. В условиях резких перекосов спроса и предложения (например, в час пик или плохую погоду) хеш может давать несбалансированные группы. Балансировщик — это жадный алгоритм, который в near-realtime режиме собирает метрики supply/demand и динамически назначает группы так, чтобы в каждый момент времени тестовая и контрольная группы были сопоставимы по критическим параметрам. Его внедрение не потребует переинтеграции клиентов, так как API уже абстрагирован от стратегии назначения групп.
Заключение
Классический A/B-тест остаётся основным инструментом экспериментальной аналитики, но в системах с сетевыми эффектами он систематически даёт смещённые оценки. Конкуренция за общий ресурс, распространение информации, технические ограничения и юридические запреты делают user-level рандомизацию либо невозможной, либо некорректной. Switchback-дизайн предлагает альтернативу: единицей эксперимента становится не пользователь, а геохрон — пара из кластера и временного окна. Это позволяет сохранить изоляцию групп (за счёт разделения по кластерам) и обеспечить сравнимость (за счёт перетасовки групп во времени).
Однако переход от идеи к промышленной реализации требует не только понимания статистики, но и продуманной инфраструктуры. Наивный подход с вычислением групп на лету порождает гонки, десинхронизацию между сервисами и невоспроизводимость результатов. Материализация назначений в единой таблице assignments решает все эти проблемы ценой дополнительных вычислительных ресурсов. Аналогично, использование обычного t-теста для Switchback приводит к завышенному false positive rate — необходимы кластерно-устойчивые стандартные ошибки (CRSE), которые учитывают корреляцию наблюдений внутри геохронов.
Платформа Trisigma.io, построенная на этих принципах, позволяет аналитику настраивать размер окна, аллокацию трафика и веса групп, менять параметры на ходу и пересчитывать отчеты с разными значениями Burn-in/Burn-out без перезапуска эксперимента. При этом единственное требование к клиентскому сервису — передавать cluster_id и временную метку; всё остальное джойнится в хранилище данных. Один и тот же семантический слой работает как для классических A/B, так и для Switchback.
Этот вывод применим не только к такси и не только к геоэкспериментам. cluster_id — это просто строка. Её значение определяется доменной моделью: рекламная кампания, магазин, категория товара, тип клиентской операции. Switchback применим везде, где user-level рандомизация ломается – в банкинге, телекоме, ритейле, регулируемых сферах. Если в сервисе есть «странные» A/B, которые не дают стабильных результатов или противоречат здравому смыслу, стоит проверить, нет ли в них неучтённых сетевых эффектов. И если они есть — попробовать взглянуть на эксперимент как на Switchback.
Кстати, если вам близка тема честного измерения — Хабр совместно с ЭКОПСИ как раз сейчас проводит большое исследование IT-брендов работодателей. Это один из немногих случаев, когда голос каждого специалиста реально влияет на результат — в прошлом году проголосовали 34 000 человек. Если у вас есть опыт работы в IT-компаниях, ваша оценка там точно будет полезна.
