Подключение сплиттера
Сплиттер вы подключаете на стороне приложения - на этом шаге эксперимент начинает работать в коде.
Перед этим шагом нужно сделать три вещи:
- Настроить подключение данных.
- Описать метрики в Git-репозитории.
- Создать эксперимент в интерфейсе платформы.
Зачем нужен сплиттер
Сплиттер - это высоконагруженный сервис, который решает две задачи на стороне вашего приложения:
- Разделение аудитории на группы - определяет, какой вариант интерфейса увидит пользователь.
- Фиксация участия (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" }
]
}'
platformid- идентификатор платформы из нашего маппинга. Полная таблица соответствий (Desktop,iOS,Android,Mobile) - в Маппинг платформ.version- версия вашего приложения в формате семантического версионирования (SemVer), например"1.0.0". Передаётся строкой.
Параметры пользователя передаются массивом 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 в одном запросе. Это уменьшает количество сетевых вызовов, если на странице несколько экспериментов.
Сплиттер работает. Следующий шаг - запустить эксперимент и разобраться с отчётом: Запуск и анализ.