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

Подключение сплиттера

Сплиттер вы подключаете на стороне приложения - на этом шаге эксперимент начинает работать в коде.

Перед этим шагом нужно сделать три вещи:

  1. Настроить подключение данных.
  2. Описать метрики в Git-репозитории.
  3. Создать эксперимент в интерфейсе платформы.

Зачем нужен сплиттер

Сплиттер - это высоконагруженный сервис, который решает две задачи на стороне вашего приложения:

  1. Разделение аудитории на группы - определяет, какой вариант интерфейса увидит пользователь.
  2. Фиксация участия (Exposure) - записывает момент взаимодействия пользователя с экспериментальным блоком.

Как работает взаимодействие

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

getFeaturesByTag - запрашивает конфигурацию при открытии страницы. В ответ приходит лейбл группы: control или test.

curl -X POST "https://<YOUR_HOST>/getFeaturesByTag/" \
-H "Authorization: Bearer <YOUR_TOKEN>" \
-H "Content-Type: application/json" \
-d '{
"tag": "<YOUR_TAG>",
"platform": {
"id": 1,
"version": "1.0.0"
},
"randomizationUnits": [
{ "type": "user_id", "value": "12345" }
]
}'
{
"result": {
"features": [
{ "experimentLabel": "your_experiment", "label": "test" }
]
}
}

exposeManyV2 - отправляет подтверждение показа в момент рендеринга блока. Это связывает пользователя с выбранным вариантом в базе данных Trisigma.

curl -X POST "https://<YOUR_HOST>/exposeManyV2/" \
-H "Authorization: Bearer <YOUR_TOKEN>" \
-H "Content-Type: application/json" \
-d '{
"exposures": [
{
"experimentLabel": "your_experiment",
"platform": {
"id": 1,
"version": "1.0.0"
},
"randomizationUnits": [
{ "type": "user_id", "value": "12345" }
]
}
]
}'
Доступы к сплиттеру

URL эндпоинта и токен выдаёт менеджер Trisigma лично - запросите у вашего менеджера. Доступы для прода и тестовой ручки (см. ниже) разные: URL и токен отличаются, выдаются отдельно.

Тестирование интеграции

У Trisigma нет отдельного тестового контура в привычном понимании. Вместо этого у сплиттера есть тестовая ручка, которая принимает и возвращает те же значения, что и основная.

Главное отличие: тестовая ручка не записывает события в базу данных и никогда не влияет на итоговый отчёт.

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

Кейс для примера интеграции (Подключение сплиттера)

Сквозной кейс из вступления: команда продукта проверяет, влияет ли цвет кнопки «Добавить в корзину» на количество кликов. Дальше - как подключить сплиттер для этого кейса.

Шаг 1. Получение фичей (getFeaturesByTag)

На этом шаге приложение методом getFeaturesByTag запрашивает у сплиттера список активных экспериментов по тегу.

Теги - это способ разделить эксперименты по зонам приложения. Сплиттер возвращает только те эксперименты, которые привязаны к запрошенному тегу. Подробнее - в статье Что такое tag.

Если тегов ещё нет - начните с одного универсального, например default. Все эксперименты привязываются к нему, и в ответе приходит полный список активных. Когда экспериментов станет больше, теги можно разделить по зонам:

ТегГде вызываетсяЧто приходит в ответе
defaultвездевсе эксперименты
homepageглавнаятолько эксперименты главной
catalogкаталогтолько эксперименты каталога

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

curl -X POST "https://<YOUR_HOST>/getFeaturesByTag/" \
-H "Authorization: Bearer <YOUR_TOKEN>" \
-H "Content-Type: application/json" \
-d '{
"tag": "default",
"platform": {
"id": 1,
"version": "1.0.0"
},
"randomizationUnits": [
{ "type": "user_id", "value": "1001" }
]
}'
к сведению
Поле platform
Передача параметров пользователя

Параметры пользователя передаются массивом randomizationUnits - каждый объект описывает один параметр через пару type / value. В одном запросе можно передавать сразу несколько идентификаторов - стандартные (user_id, visitor_id) и кастомные (phone_hash, device_id, и т.д.):

"randomizationUnits": [
{ "type": "user_id", "value": "1001" },
{ "type": "visitor_id", "value": "a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8" },
{ "type": "phone_hash", "value": "33AFF380-6289-4B76-BB19-46EB8B7D8998" }
]

Система выбирает нужный идентификатор по настройкам конкретного эксперимента на платформе.

value всегда передаётся строкой, даже для числовых типов (user_id, age и т.п.). Число без кавычек приведёт к ошибке валидации.

В ответе приходит лейбл группы для эксперимента blue_button_test:

{
"result": {
"features": [
{
"experimentLabel": "blue_button_test",
"label": "test"
}
]
}
}

Шаг 2. Применение логики в коде

На основе полученного лейбла разработчик добавляет ветвление: если приходит test - код показывает синюю кнопку; если control или запрос не удаётся - серую (дефолтное состояние).

Важность дефолтного состояния

Сплиттер не должен быть «точкой отказа» для интерфейса. Если сервис недоступен или запрос завершился ошибкой, пользователь должен увидеть обычную версию сайта.

Шаг 3. Подтверждение показа (Exposure)

В момент рендеринга кнопки код отправляет подтверждение. Это связывает пользователя с выбранным вариантом в базе данных Trisigma.

curl -X POST "https://<YOUR_HOST>/exposeManyV2/" \
-H "Authorization: Bearer <YOUR_TOKEN>" \
-H "Content-Type: application/json" \
-d '{
"exposures": [
{
"experimentLabel": "blue_button_test",
"platform": {
"id": 1,
"version": "1.0.0"
},
"randomizationUnits": [
{ "type": "user_id", "value": "1001" }
]
}
]
}'
Пакетная отправка

Можно отправлять события как по одному, так и пачками до 2000 в одном запросе. Это уменьшает количество сетевых вызовов, если на странице несколько экспериментов.

Сплиттер работает. Следующий шаг - запустить эксперимент и разобраться с отчётом: Запуск и анализ.