Проведение одного A/B-теста — задача вполне управляемая. Масштабировать A/B-тестирование до сотен экспериментов в десятках команд гораздо сложнее, так как команды могут принимать разные решения по поводу метрик, рандомизации, раскатки и анализа. Протоколы экспериментов в Datadog Experiments превращают утвержденную методологию в повторно используемую конфигурацию, обеспечивая для экспериментов одного типа единую отправную точку.

В этой статье вы узнаете, как:

Превратить утвержденную методологию в повторно используемый протокол

Превратить утвержденную методологию в повторно используемый протокол

Определять первичные метрики и защитные барьеры перед запуском

Определять первичные метрики и защитные барьеры перед запуском

Стандартизировать рандомизацию и поэтапный охват

Стандартизировать рандомизацию и поэтапный охват

Проверять данные эксперимента перед интерпретацией результатов

Проверять данные эксперимента перед интерпретацией результатов

Адаптировать протоколы под повторяющиеся типы экспериментов

Адаптировать протоколы под повторяющиеся типы экспериментов

Превратить утвержденную методологию в повторно используемый протокол

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

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

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

Определять первичные метрики и защитные барьеры перед запуском

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

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

Каждая метрика имеет тип (простая, отношение или процентиль), а также направление, в котором она должна измениться. Ожидаемое направление позволяет Datadog сигнализировать о том, что защитный барьер сместился не в ту сторону, даже если за этим никто специально не следит. Метрики берутся из клиентских SDK Datadog или из таблицы хранилища данных клиента.

Сопоставляйте окно наблюдения с результатом

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

Однако показатель ценности клиента за все время (LTV) может потребовать месяцев наблюдения. Если это превышает окно принятия решений, выберите краткосрочный индикатор и проверьте его взаимосвязь с LTV. Данные хранилища могут поддержать долгосрочные измерения; окно наблюдения должно отражать изучаемый результат и принимаемое решение.

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

Стандартизировать рандомизацию и поэтапный охват

Установите единицу рандомизации для каждого протокола

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

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

В Datadog тип объекта определяет, каким образом события охвата связываются с событиями метрик. Для экспериментов с использованием Datadog Feature Flags передайте соответствующий идентификатор в качестве параметра targetingKey в SDK. Если вы измените тип объекта в протоколе, Datadog попросит вас подтвердить удаление несовместимых метрик. Выберите единицу рандомизации для проверяемой гипотезы и данных, доступных команде.

Поэтапно наращивайте охват и следите за защитными барьерами на каждом шаге

Протоколы настраивают поэтапный охват с помощью тех же элементов управления раскаткой, что и при обычной настройке экспериментов. Раскатка на 1%, 5%, 25%, а затем равное распределение ограничивают ущерб от неудачного изменения до того, как вы его заметите. Если для эксперимента не требуется поэтапная раскатка, задайте его целевой охват напрямую.

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

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

Проверять данные эксперимента перед интерпретацией результатов

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

Дисбаланс трафика, также называемый несоответствием соотношения выборок (SRM), проверяет, существенно ли отличаются наблюдаемые количества назначений по вариантам от настроенного разделения трафика. Считайте сбой блокирующим фактором, поскольку это означает, что рандомизация, логирование показов или популяция анализа смещены. Дисбаланс размерных назначений идет на уровень глубже и проверяет, отличается ли вероятность назначения по значениям измерений, таким как тип устройства или страна. Допустим, вы ожидаете равного разделения и видите 48/52. Сбой по размеру для типа устройства может помочь локализовать причину, например специфичный для устройства баг в доставке вариантов или телеметрии показов.

Смешанные назначения фиксируют появление одного и того же субъекта в более чем одном варианте, и Datadog исключает такие субъекты из анализа. Диагностика проходит успешно при показателе 5% или ниже, выдает предупреждение выше этого значения и завершается ошибкой при 20% или более. Растущая доля исключений обычно указывает на изменения в инструментировании или таргетинге, а не на результат, который стоит изучать.

Проверяйте наличие ухудшений в сегментах

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

Стандартизируйте план анализа

Согласуйте план статистического анализа до запуска. Установите метод расчета доверительного интервала и уровень доверия, затем выберите, применять ли поправку на множественное тестирование. Также изучите контролируемый эксперимент с использованием предэкспериментальных данных (CUPED) — метод, который снижает дисперсию метрик. Повторное использование этих настроек дает командам единую основу для интерпретации похожих экспериментов.

Метод анализа определяет, как промежуточные результаты могут повлиять на принятие решения. Последовательный частотный анализ поддерживает повторяющиеся проверки и ранние решения при одновременном контроле уровня ложноположительных результатов. Для анализа с фиксированной выборкой заранее выберите размер выборки или длительность и избегайте их изменения на основе промежуточных результатов. Байесовский анализ объединяет наблюдаемые данные с априорными и требует собственных критериев принятия решений.

Используйте предэкспериментальные данные для снижения дисперсии

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

Адаптируйте протоколы под повторяющиеся типы экспериментов

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

Рассмотрите три повторяющихся варианта использования: внедрение функций, UX-эксперименты, а также эксперименты в области ML и ИИ. Команды релиза могут отдавать приоритет повторяемой настройке с использованием флагов функций в рамках своего рабочего процесса разработки. Командам UX нужны результаты, которые могут исследовать инженеры, продакт-менеджеры и специалисты по работе с данными. Командам ML и ИИ может потребоваться сравнение вариантов конфигурации и планирование взаимодействий между экспериментами.

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

Документируйте дополнительные требования к дизайну

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

Начало работы с протоколами Experiments

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

Чтобы начать работу с протоколами Experiments, прочитайте нашу документацию. Если вы еще не являетесь клиентом Datadog,