Настройка разметки трафика

В этом разделе вы ознакомитесь с заведением и настройкой параметров разметки пользователей, типов участников и особенностями их работы в Trisigma.

Контекстные параметры

В файле context_params.yaml описаны параметры пользователя, которые могут быть обработаны платформой АБ-тестов.

Эти параметры могут применяться в:

условиях попадания пользователей в эксперимент
условиях исключения пользователей из экспериментов
для разделения пользователей на группы в экспериментах

Свойства параметров

Каждый параметр имеет следующие свойства:

Атрибут	Описание	Значения
domain	Логическое подразделение компании, в котором данный параметр может быть использован. Домены служат исключительно для группировки параметров в интерфейсе Trisigma.	`Delivery`, `MainPage`, `Ads Cabinet` - str
label	Имя параметра уникальное в рамках дом	Строка в формате snake_case
type	От типа параметра зависит то, какие к нему могут применяться компараторы. Про компараторы смотри раздел "Условия попадания и исключен	int, str, float, bool, date, semver
title	Описание параметра. Будет отображаться в админке экспериментов вместе с лей	str
splitter_allocation_param	Имя поля, которое необходимо заполнить в запросе к сервису сплитования, чтобы оно было учтено при вычислении группы участия в экспер	Строка в формате snake_case
report_allocation_column*	Имя колонки, используемой для определения участия пользователя при подготовке отчет	Строка в формате snake_case
report_metric_join_column*	Имя колонки, которая будет использована для мержа таблицы участников и источника	Строка в формате snake_case
assignments_source_enabled*	Определяет, будет ли тип участника связан с таблицами трафика. См. "Настройка assignments_source	True, False
status	Статус	`draft`, `active`, `archive`

Атрибуты, отмеченные *, являются необязательными при соблюдении определенных условий (См. "Настройка assignments_source_enabled").

Статусы параметров:

draft - параметр можно редактировать, но нельзя использовать
active - параметр нельзя редактировать. Он используется в экспериментах и может быть подключен в новых
archived - параметр нельзя редактировать. Он используется в экспериментах, но не может быть подключен в новых

Условия попадания и исключения

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

Компараторы применяются для сравнения параметра трафика с одним или более значений из конфигурации.

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

Оператор	Описание
eq	Равно
ne	Не равно
gt	Больше чем
lt	Меньше чем
ge	Больше либо равно
le	Меньше либо равно
in	Входит в множество
not_in	Не входит в множество

Таблицы трафика

На стороне Trisigma исходя из настроек параметров пользователя формируются специальные "таблицы трафика", в которых фиксируются все события, созданные или зафиксированные Trisigma. В общем случае это события контакта пользователя с экспериментом ("exposure") и событие назначения пользователя в эксперимент, не гарантирующее контакта ("assignment").

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

Как заполнить поля splitter_allocation_param / report_allocation_column / report_metric_join_column?

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

Например, пусть splitter_allocation_param = "users_best_music_instrument". Тогда запрос в сплиттер будет выглядет так:

POST https://<host>/getFeaturesByTag/

{
  "tag": "<ваш_тег>",
  "platform": {
    "id": 1,
    "version": "2.15.0"
  },
  "participant": {
    "userId": 123456
  },
  "randomizationUnits": [
    {
      "type": "users_best_music_instrument",
      "value": "piano"
    }
  ]
}

Рекомендуется заполнять этот параметр так же, как и label контекстного параметра. Это упростит работу в будущем

report_allocation_column - это колонка в источнике событий (таблице трафика). Колонка выполняет ту же роль, что splitter_allocation_param, но при воспроизведении сплита во время вычисления отчета. Очень важно, чтобы данные в этой колонке совпадали с теми, что передаются в сплиттер с использованием splitter_allocation_param.

Например, в сплиттер я передал ключ "users_best_music_instrument": "piano". А в таблице трафика есть колонка best_music_instrument, в которую попадает то же значение "piano".

Тогда в представлениях я могу добавить колонку best_music_instrument и сделать ей алиас "users_best_music_instrument".

В report_allocation_column я запишу этот алиас "users_best_music_instrument". Рекомендуется для новых полей выбирать алиас, совпадающий с ключом для сплиттера.

report_metric_join_column. В некоторых сценариях сущности в dwh имеют свой синтетический ID. Это обстоятельство делает невозможным использование report_allocation_column для расчета метрик в группах экспериментов. Поэтому колонка report_allocation_column связывается с колонкой report_metric_join_column, содержащей внутренний dwh_id той же сущности, что и report_allocation_column.

Продолжим пример. Мы уже добавили "users_best_music_instrument" в представления. Теперь добавим соответствующее id поле с алиасом "users_best_music_instrument_dwh_id".

Комментарий. Колонка report_metric_join_column связывается с label параметра с одной стороны. С другой стороны в источниках метрик мы имеем описание участника вида "participant: {user: user_id}". Здесь первое поле "user" это label параметра, а "user_id" - это колонка в источнике метрик. Таким образом колонка report_metric_join_column связывается с колонкой в источнике. Благодаря этому, становится возможным вычислять метрики по отдельным группам эксперимента.

Комментарий 2. Колонка report_metric_join_column может совпадать с колонкой report_allocation_column.

Имя колонки report_metric_join_column можно выбрать любым. Главное, чтобы оно не пересекалось с другими параметрами и ассоциировалось со своим контекстным параметром.

Настройка assignments_source_enabled

Параметр assignments_source_enabled определяет, будет ли тип участника связан с источником назначений (assignments в таблицах трафика).

По умолчанию: True
При значении True: тип участника связан с таблицами трафика, необходимо настраивать report_allocation_column и report_metric_join_column
При значении False: тип участника не связан с таблицами трафика, настройка report_allocation_column и report_metric_join_column не требуется

Значение False полезно для Switchback экспериментов, которые построены не на трафике, а на других источниках данных (например, на временных интервалах или других бизнес-сущностях).

Использование параметров пользователя для сплитования

Чтобы по параметру можно было делить пользователей на test / control, необходимо объявить его как participant_type (тип участника). Для этого добавь его в файл participant_types в раздел participant_types.

Маппинги типов участников

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

Для этого нужно указать пару типов участника в participation_mapping.

"{from: visitor, to: user}" - строка означает, что, если visitor будет определён как участвующий в эксперименте, то соответствующий пользователь из событий в таблицах трафика тоже будет определён как участвующий.

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

Чтобы параметр можно было использовать для построения отчета, необходимо описать как мапить внешние параметры в dwh_id. Это делается при помощи параметров ind_id_mapping и transform. Параметры int_id_mapping описывают dds, при помощи которого выполняется маппинг. Параметры transform описывают дополнительные преобразования, которые необходимо применить к параметрам report_metric_join_column и splitter_allocation_param (например, произвести хеширование значения cookie пользователя)

Примеры заполнения параметров маппинга:

String (cookie)

    # сначала поле из событием обрабатываем функцией hash, к её значению применяем dds.
    int_id_mapping:
      table: dwh.dds.h_cookie
      source_column: cookie_id
      assignment_column: external_id
    transform:
      assignment_column_transform: hash({column})

Int (user_id)

    int_id_mapping:
      table: dwh.dds.h_user
      source_column: user_id
      assignment_column: external_id
    # transform не нужен

Без маппинга (secure_user_id)

    # в случае secure_user_id внешние и внутренние параметры просто совпадают, поэтому маппинг описывать не нужно

String без маппинга

    # dds не нужен
    # в событиях и источниках получаем строку, которую преобразуем к int при помощи hash
    transform:
      source_column_transform: hash({column}))
      assignment_column_transform: hash({column})

Настройка allowed_experiment_types

Параметр allowed_experiment_types определяет список типов экспериментов, в которых разрешается использовать данный тип участника.

Пример конфигурации:

- context_param: user
  allowed_experiment_types:
    - regular
    - retro
- context_param: geo_bucket
  allowed_experiment_types:
    - switchback

Доступные типы экспериментов:
- regular: Стандартные A/B-тесты
- retro: Ретроспективные эксперименты
- switchback: Switchback-эксперименты (например, на временных интервалах)

Если allowed_experiment_types не указан, тип участника доступен в regular и retro экспериментах по умолчанию.

Контекстные параметры​

Свойства параметров​

Условия попадания и исключения​

Таблицы трафика​

Как заполнить поля splitter_allocation_param / report_allocation_column / report_metric_join_column?​

Настройка assignments_source_enabled​

Использование параметров пользователя для сплитования​

Маппинги типов участников​

Настройка allowed_experiment_types​