Dimensions (дименшены)

Dimensions. разрезы для группировки и фильтрации метрик. Dimensions можно представить как справочник (словарь маппингов), который определяет, как расшифровывать значения полей для отображения в отчетах по АБ-тестам.

** Важно:** Dimensions заводятся относительно редко. Один и тот же dimension можно переиспользовать для тысяч метрик. Главное. убедиться, что у источника в sources/ или в enrichments/ есть нужное поле для этого dimension.

Конфигурация

# dimensions/dimensions.yaml
dimension_name:
  has_id: true/false # В источниках представлен как <dimension_name>_id
  description: "Описание"
  parent: parent_dim # Опционально: слаг родительского dimension
  slug: short_name # Опционально: сокращенное имя для отображения в отчетах
  is_bool: true/false # Опционально: boolean dimension (не требует SQL-справочника)

Пояснения по полям:

1. has_id: если true, то в источниках поле имеет имя <dimension_name>_id (например, region_id)
2. is_bool: если true, то dimension булевый и не требует создания SQL-справочника в dimensions/sql/
3. slug: краткое имя, как dimension будет отображаться в отчете по результатам АБ-теста (например, logical_category → slug: logcat)
4. parent: используется для иерархических dimensions (например, category → logical_category → vertical)

Типы дименшенов

1. ID-based (has_id: true)

platform:
  has_id: true
  description: "Платформа (mobile, desktop)"

vertical:
  has_id: true
  parent: null
  description: "Вертикаль"

В source:

SELECT platform_id, vertical_id FROM ...

Для has_id = True должно быть выполнено два требования:

1. Тип поля в источнике/обогащениях - int
2. Название поля имеет суффикс _id

2. Boolean (is_bool: true)

is_logged_in:
  is_bool: true
  description: "Авторизованный пользователь"

3. Иерархические (parent)

vertical:
  has_id: true

logical_category:
  has_id: true
  parent: vertical

category:
  has_id: true
  parent: logical_category

Справочники

1. Справочники для дименшена необходим всегда, кроме is_bool = True
2. Справочник задает список допустимых значений (для последующей валидации в конфигах экспериментов)
3. Является источником для расшифровки значений дименшенов с has_id = True

Маппинг ID → значение:

Справочники определяют маппинг между идентификаторами и человекочитаемыми значениями. Например, region_id (это value_id) → region (это value). Это позволяет в отчетах по АБ-тестам отображать понятные названия вместо числовых ID.

-- dimensions/sql/platform.sql
SELECT
  Name as value,                    -- Обязательно: человекочитаемое значение
  Platform_id as value_id,          -- Обязательно для has_id=true: числовой ID
  External_id as value_ext_id       -- Опционально
FROM dds.H_Platform

** Важно:** Поля в SQL-запросе обязательно должны быть переименованы в value и value_id (при необходимости). Trisigma распознает только эти стандартизированные имена полей.

Обязательные колонки:

1. value. всегда обязательна (даже если нет has_id)
2. value_id. обязательна, если has_id = True
3. parent_dimension, parent_value, parent_value_id. обязательны для dimensions с родителем

Опциональные: value_ext_id, is_active

Работа с CLI

# Список дименшенов \{#spisok-dimenshenov}
trisigma sl list-dimensions

# Валидация \{#validatsiya}
trisigma sl validate

Создание dimension

1. Добавить в dimensions.yaml

my_dimension:
  has_id: true
  description: "Описание"

2. Создать SQL

-- dimensions/sql/my_dimension.sql
SELECT dimension_value as value, dimension_id as value_id
FROM dma.my_dimension_table

3. Добавить колонку в source или enrichments

-- sources/sql/buyer_stream.sql
SELECT my_dimension_id FROM ...

4. Валидировать

trisigma sl validate

Best Practices

Рекомендуется

1. Используйте has_id: true для числовых ID
2. Определяйте иерархии через parent
3. Добавляйте description

❌ Не рекомендуется

1. Dimension без SQL в dimensions/sql/
2. has_id: true для строковых полей (валидация не пройдет)
3. Отсутствие description

Следующие шаги

1. Workflow. практика создания
2. Metrics. использование в фильтрах

Подробнее: Концепции → Dimensions