Основное предназначение A/B-тестов — оценить эффективность вносимых изменений и, в случае увеличения целевых метрик, зафиксировать эти изменения, а в случае снижения — откатить. Как правило, один из критериев хорошего дизайна A/B-теста — это конкретное и реалистичное с практической точки зрения время его проведения.

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

Непрекращающиеся A/B-тесты

"Может быть, вечность — это не место и даже не время"

Звучит немного странно: откуда вообще появляется потребность в тестах, которые не могут быть завершены? На это есть ряд теоретических и практических предпосылок. 

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

В предпосылках классического A/B-теста есть важное предположение о том, что продукт и поведение пользователя (а также сам некий типичный пользователь) не меняются или меняются слишком незначительно за "достаточно большой" промежуток времени, чтобы можно было выделить эффект нововведения, тем самым изолировать его от остальных переменных факторов и численно оценить. То есть при изменении продукта посредством введения нового функционала весь существенный вклад в изменение рассматриваемых метрик вносит только фича. В реальности, как мы знаем, все намного сложнее.

Во-первых, информационные системы меняются достаточно быстро. Причем скорость изменений и накопления информации как во внешней среде, так и в ее частях, носит нелинейный характер. Особенно когда в улучшении продукта участвуют десятки команд, которые двигаются в разных направлениях с разными целями и способами их достижения. 

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

Такое возможно, когда функционал не статичный, а основан на каких-либо случайных факторах. Такая ситуация может быть, например, при использовании статистических моделей. Также распространен случай, когда функционал фичи связан с человеческим фактором. Например, функционал CRM/ERP-систем и сотрудники компании, где на пользователя в итоге выходит совокупный эффект от работы фичи и работы персонала. Причем эффект самой фичи отделить невозможно, так как самостоятельно она не работает и не выходит на пользователя, а лишь позволяет автоматизировать и улучшать производительность труда сотрудников.

Субъективный фактор часто встречается при нововведениях, связанных с клиентским сервисом. Поскольку клиентский сервис (support, kyc, sales и т.д.) — это сотрудники, в работе которых всегда присутствует субъективный фактор, то имеет место непостоянство контекста, усугубленное непостоянством других элементов A/B-теста. Что было верно сегодня, может иметь менее заметный или даже противоположный эффект завтра. 

Например, сегодня специалист техподдержки удачно работает и у него все получается с помощью "крутой" фичи в CRM, а через месяц у него снизилась производительность в виду каких-либо систематических причин (началась сессия в университете, уволился хороший руководитель и т.п.). В таком случае, если мы захотим снова оценить фичу, помогающую ему обслуживать чат, то увидим, что эффективность сильно упала. Также возможны ситуации, когда изменения затрагивают целый департамент и носят систематический характер. 

Одним из решений отслеживания эффективности в таких случаях являются непрекращающиеся A/B тесты.

Непрекращающиеся A/B тесты — это подход к тестированию, который позволяет отслеживать влияние изменений в продукте или в сервисе на целевые метрики даже при условии непостоянства контекста. Как следствие, такой подход позволяет адекватно оценивать вклад изменений и принимать оперативные решения при меняющейся эффективности, в отличие от классических A/B тестов. Проведение таких тестов, как понятно из названия, не прекращается, и для таких тестов необходимо, чтобы в любой момент после набора статистической значимости была возможность сделать замер наиболее точной дельты эффективности. Такие тесты необходимы там, где не пройдет подход "сделал изменение -> поделил пользователей -> провел тест -> набрал статистическую значимость -> опубликовал изменение на всю аудиторию -> измерил прогнозируемую прибыль по полученным данным", потому что возможна ситуация, когда вскоре после публикации изменений на всю аудиторию прирост эффективности станет нулевой, при этом конверсия останется на таком же высоком уровне, но  из-за изменившегося контекста изменится и базовый (контрольный) уровень конверсии. По абсолютным показателям это отследить сложно, если дисперсия по времени в контрольной группе выше, чем сам прирост, или базовый уровень поднялся выше предыдущих значений. Такой подход обретает особенную актуальность, если на воздействия тратятся ресурсы, например, человеческие.

Подходы к непрерывному тестированию

Итерационные тесты — самый простой и достоверный вариант: каждый раз в заданный промежуток времени тест запускается заново. А старые результаты используются для подведения итогов за этот период.
Запуск: регулярное возобновление тестирования через заданные промежутки времени, например, ежемесячно или ежеквартально.
Преимущества: высокая точность оценки эффективности на каждом временном периоде.
Недостатки: необходимость ожидания накопления статистической значимости в каждом новом периоде при риске несоответствия ожидаемой эффективности. Требуется вовлеченность в интерпретацию и подведение результатов в каждом временном промежутке, а также поиск причин снижения эффективности при необходимости.

Итерационные тесты с перерывами — вариация итерационных тестов, когда тесты запускаются раз в несколько периодов. Например, один период работают, два периода оцениваются по результатам предыдущего периода.
Запуск: итерационное чередование периодов активного тестирования и периодов оценки результатов по полученным данным.
Преимущества: можно пустить больше трафика по наиболее эффективному флоу и получить больше прибыли.
Недостатки: в случае изменений в продукте, в поведении клиента или во внешних условиях информация об эффективности становится доступной только при запуске нового тестового цикла. При самом плохом сценарии  произойдет снижение в периодах оценки, а в новом цикле тестирования это снижение не будет обнаружено. 
Таким образом, если вы убедились или у вас есть точные основания думать о некотором сезонном постоянстве, то итерационные тесты с перерывами  – лучший вариант.

И наконец самые настоящие непрекращающиеся тесты – это когда тест запускается один раз и перезапускается только в случае изменения условий. В получении результатов используются только данные за необходимое время из теста.
Запуск: однократный старт с возможным перезапуском при смене условий.
Преимущества: непрерывное наличие статистически значимых данных, позволяющее оценивать эффективность в любой момент.
Недостатки: сложность определения влияния на конкретные временные промежутки из-за наличия данных за широкий диапазон периодов.

Как работать с такими тестами

Приведу пример из рабочей практики. Для целевых заданных когорт пользователей и интентов их сообщений при обращении в саппорт идет переадресация чата на специально подготовленный департамент, в котором идет обработка чата с элементами продаж. 

Суть такого перенаправления — предоставление более квалифицированной помощи на выделенной линии поддержки с элементами продаж. На такой линии более индивидуальный подход,  отсутствуют очереди и работают обученные техникам продаж агенты. Цель — повышение конверсии в покупку. То есть после решения проблемы саппорт пробует повышать конверсию. Всех клиентов направлять на такую линию невозможно, так как большая часть когорт нерелевантна, и такой уровень поддержки слишком дорогой. Такая линия целесообразна только тогда, когда она окупает себя и приносит дополнительную прибыль. Для контроля ее эффективности целесообразно использовать непрекращающийся A/B тест.

Рассмотрим на примере модельных данных. Допустим, у нас есть входной поток пользователей, дополнительная конверсия в тестовой группе 1%. Чем больше в тестовой группе людей, тем больше покупок. В идеале все должны попадать в тестовую группу. 

Но что делать, если эффективность скриптов продаж поменялась, или изменился продукт, или пришли другие пользователи и дополнительная конверсия стала 0,5%? Как быстро мы можем это заметить и какими будут потери?

В случае обычного теста:

На графике выше и далее синим обозначена конверсия для тестового варианта, а желтым — для контрольного. Как видно из графика, A/B тест закончен, прирост конверсии ~8% (с учетом дисперсии, в реальности около 10%) зафиксирован. Далее раскатывается функционал на всех пользователей и результаты даже немного растут и стабилизируются, но в реальности видим, что настоящий профит спустя некоторое время составляет всего 5%. И мы бы это увидели, если бы присутствовала контрольная группа.

В случае итерационного теста:

В данном случае все три периода оцениваются последовательно. Как можно понять по графику, вторая итерация из-за изменений конверсии будет оценена с бОльшей погрешностью, но точнее, чем в обычном A/B тесте. Также везде за три периода набирается статистическая значимость. Первый и второй периоды в момент стабилизации конверсии оценены максимально приближено к реальности.

В случае итерационного теста с перерывами:

На этом графике  видно, что если период изменения конверсии попал в промежуток оценки результатов по предыдущему тесту, то получится погрешность в оценке, которая исправится после оценки результатов следующего теста. 

В случае непрерывного теста:

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

Баланс эффективности

Какой бы вариант из постоянных тестов мы ни выбрали, в случае более эффективного тестового варианта хочется максимизировать трафик по этому сценарию и при этом оценивать реальную эффективность. Идеальный вариант для набора статистической значимости — это 50/50, идеальный вариант для максимизации прибыли — 0/100, где 100% трафика идет на тестовый флоу, если он более эффективный. Если есть подтверждение неизменности дельты эффективности, то оптимальнее использовать обычное A/B тестирование. Любые непрерывные тесты будут показывать такой же результат, но с потерей трафика на контрольную группу.  

При изменяемости дельты конверсии в непрерывных A/B тестах хочется найти оптимум x/y, чтобы получить максимальную прибыль. Поиск оптимальной пропорции — задача нетривиальная. Более того, способ может меняться даже в рамках одного теста на больших промежутках времени. Нужно выбирать x таким образом, чтобы с учетом исторических данных набрать статистическую значимость для меньшей группы за выбранный период. Дисперсия будет искажать реальное распределение контрольной (меньшей) группы относительно тестовой. Поэтому при подведении результатов важно проводить обнаружение и коррекцию выбросов данных. 

Резюмируя вышесказанное, приведу иллюстрацию с рекомендацией к выбору подхода к тестированию в зависимости от предположений относительно дельты эффективности и постоянства контекста A/B теста.

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

А как вы оцениваете эффективность при меняющихся предпосылках? И как часто перепроверяете однажды подтвержденные результаты?