Эксперименты

ActionPulse не распределяет трафик и не является системой A/B-тестирования. Он не назначает варианты, не управляет фича-флагами и не решает, кому что показать. Всё это делает ваша система. ActionPulse читает события показа варианта, которые вы прислали, и считает по ним разбор — readout.

Из этого следует практическое: качество разбора целиком определяется качеством ваших событий показа. Раздел в кабинете — Анализ → Анализ экспериментов, и он честно подписан: «Readout внешних assignment/exposure-событий».

Какие события нужно отправлять

Одно каноническое событие — experiment_exposure, по одному на факт показа варианта конкретному человеку.

Часть события	Что в неё кладётся
event	ровно experiment_exposure
user_id или anon_id	тот же идентификатор, что и в остальных ваших событиях
time	время назначения варианта
props.experiment_key	ключ эксперимента
props.variant	ключ варианта
props.allocation_unit	необязательно; либо отсутствует, либо равно идентификатору актора
props.exposure_id	необязательно; ключ дедупликации, до 128 символов

{
  "batch": [
    {
      "event_id": "8b0d3f2e-1c4a-4f0e-9b1d-2a3c4d5e6f70",
      "event": "experiment_exposure",
      "user_id": "YOUR_USER_ID",
      "time": "2026-07-20T10:15:00Z",
      "props": {
        "experiment_key": "checkout_one_step",
        "variant": "treatment",
        "exposure_id": "checkout_one_step:YOUR_USER_ID"
      }
    }
  ]
}

Транспорт — обычная отправка событий, лучше с бэкенда: см. отправку событий с бэкенда.

Ещё две ловушки, которые видно только по предупреждениям:

• allocation_unit, не совпадающий с идентификатором актора, не объединяется с метричными событиями молча — такие строки исключаются и считаются в unsupported_allocation_unit. Считать по своей единице распределения (аккаунт, устройство, сессия) продукт не умеет.
• Событие показа с временем далеко в прошлом обычным приёмом не сохранит своё время: вне окна ±48 часов оно заменяется временем приёма. Отправляйте показ в момент показа. Историю грузите загрузкой данных, а не приёмом.

Участие определяется первым валидным событием показа в окне анализа. Повторы того же актора считаются в «Повторные exposure того же actor_id», а показ другого варианта тому же актору — в «Actor_id увидел разные варианты», и на участие уже не влияют. Если вы присылаете exposure_id, повтор того же значения отбрасывается.

Метрики считаются по вашим обычным событиям, а не по событиям показа. Для денежной метрики значение берётся из знакового числового свойства revenue — возвраты остаются отрицательными.

Как задать эксперимент

Определение эксперимента создаётся методами API — в кабинете экрана создания нет, и интерфейс это прямо говорит: «Определение может создать участник с ролью Аналитик или выше через API». Методы — в справочнике по экспериментам.

Что входит в определение:

Поле	Правила
key	ключ эксперимента; после создания не меняется
name, hypothesis	название до 200 символов, гипотеза до 2000
starts_at, ends_at	границы эксперимента
variants	от 2 до 20; у каждого key, name, признак control и expected_weight
primary_metric	основная метрика: conversion, count или revenue
guardrail_metrics	до 10 защитных метрик
audience	до 20 фильтров, тех же, что в отчётах
status	draft, running, completed, archived
random_assignment_confirmed	ваше утверждение о том, что назначение было случайным

У метрики задаются ключ, название, вид, имя события и до 20 фильтров. Для вида revenue дополнительно указывается свойство значения — revenue.

Чтение эксперимента и запуск разбора доступны с роли наблюдателя, создание и правка определений — с роли аналитика. Отдельного тарифного ограничения у экспериментов нет.

Что показывает отчёт

Кнопка «Рассчитать readout» считает разбор по окну самого эксперимента — от starts_at до ends_at.

Блоки результата:

• Участники — сколько акторов попало в эксперимент.
• Соотношение выборок — фактическая и ожидаемая доля каждого варианта, плюс вердикт проверки SRM.
• Основное сравнение — по каждому неконтрольному варианту: среднее в контроле, среднее в варианте, абсолютная разница, относительный прирост, 95% доверительный интервал, p-value и вердикт значимости.
• Guardrail-метрики — то же самое по защитным метрикам.
• Хронология exposure — распределение показов по дням.
• Качество данных — агрегированные счётчики отброшенных и подозрительных строк.
• Assignment и exposure — напоминание, что варианты назначает внешняя система.
• Интерпретация — «Причинная оценка» или «Только связь».

Границы расчёта, о которые можно упереться на больших экспериментах:

Ограничение	Значение
Диапазон окна	до 400 дней и внутри дат эксперимента
Строк событий показа	до 100 000 за один разбор
Строк метричных событий	до 200 000 на все метрики разбора
Дедлайн расчёта	30 секунд
Свойства события показа	до 4 КиБ на строку

Если предел по метричным строкам достигнут, в качестве данных появится metric_row_cap — «Достигнут лимит metric rows». Это значит, что числа считаны не по всем данным; сузьте аудиторию или период.

Как читать границы значений

Доверительный интервал — двусторонний 95% интервал для разницы «вариант минус контроль». Читается так: если интервал накрывает ноль, различие на этом объёме данных не отличимо от шума. +0,4 … +3,1 п.п. — эффект есть и он в этих пределах; −1,2 … +2,0 п.п. — вы пока не знаете, есть ли он вообще.

Для конверсии разница и границы показаны в процентных пунктах, для счётчика и выручки — в единицах метрики.

p-value сравнивается с порогом 0,05: ниже — «Значимо», иначе «Незначимо». Значения меньше 0,001 показываются как <0.001.

Относительный прирост отсутствует, если среднее в контроле равно нулю: на ноль делить нечего, и продукт показывает «н/д», а не бесконечность.

«Недостаточная выборка» и «assumptions не выполнены» — интервал, p-value и вердикт значимости не показываются вовсе, вместо того чтобы показать правдоподобный ноль. Требования жёстко заданы:

Вид метрики	Что нужно для интервала
Конверсия	минимум 5 успехов и 5 неуспехов в каждой ветке
Счётчик и выручка	минимум 30 наблюдений в каждой ветке

Причины отказа подписаны: «Недостаточно успешных и неуспешных исходов для интервала», «Control mean равен нулю, relative uplift недоступен», «Некорректный второй момент для count/revenue оценки».

Проверка соотношения выборок (SRM) — отдельная и намеренно более строгая проверка: порог 0,001 вместо 0,05, потому что это сигнал о качестве данных, а не об эффекте. Три состояния:

• «Без предупреждений» — фактические доли согласуются с ожидаемыми весами.
• «Возможен SRM» — расходятся. Сначала ищите ошибку в назначении вариантов или в отправке событий показа, и только потом читайте результат метрик. Перекос выборки обычно означает, что сравниваются не те группы, которые вы думаете.
• «Недостаточно данных» — ожидаемая доля какого-то варианта даёт слишком малую ячейку, и проверку делать некорректно.

Какие оговорки продукт делает сам

Это не мелкий шрифт, а часть контракта: продукт отказывается выглядеть надёжнее, чем он есть.

Каждый разбор помечен как оценка. В интерфейсе — «Оценка, не факт», в ответе API — постоянный признак meta.estimate. Снять эту метку нельзя.

«Причинная оценка» ставится только при выполнении всех условий сразу: вы объявили random_assignment_confirmed, проверка SRM выполнена и без предупреждения, нет блокирующих предупреждений качества данных и выборки достаточно. Иначе интерпретация — «Только связь», и в интерфейсе прямо написано: ActionPulse не знает, как внешняя система назначала варианты.

Блокирующие предупреждения качества данных:

Код	Что означает
invalid_exposure	строка события показа не прошла проверку
multiple_exposure	у актора больше одного события показа
conflicting_exposure	одному актору показаны разные варианты
duplicate_exposure_id	повтор того же exposure_id
unknown_variant	вариант, которого нет в определении
unsupported_allocation_unit	единица распределения отличается от актора
metric_population_mismatch	population метрики не совпала с участниками

Маркер случайного назначения — это ваше утверждение, а не проверка. random_assignment_confirmed продукт принимает на слово: подтвердить рандомизацию извне он не может.

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

Что проверить перед запуском

1. Событие показа уходит в момент показа, а не пачкой в конце дня.
2. В props события показа только разрешённые ключи — иначе строки уйдут в invalid_exposure.
3. Идентификатор актора в событиях показа тот же, что в метричных событиях. Иначе метрика не найдёт участников.
4. У одного из вариантов выставлен признак control — без контроля сравнивать не с чем.
5. expected_weight соответствует тому, что реально делает ваша система, — иначе SRM будет ругаться на исправный эксперимент.
6. Метричное событие приходит и по контролю, и по вариантам: односторонняя разметка даёт «победу» варианта на пустом месте.
7. starts_at и ends_at покрывают весь период показа: разбор считается по этому окну.
8. Перед чтением метрик проверьте SRM и качество данных. Значимый результат на перекошенной выборке — это не результат.