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

В Trisigma управление метриками происходит через Git-репозиторий. Это позволяет версионировать изменения, проводить ревью кода и гарантировать точность расчетов. И использовать единый источник правды расчета метрик для всей компании в целом. Открыто и прозрачно.

Подготовка к работе

Если вы впервые настраиваете метрики, вам нужно сделать:

Получите доступ к репозиторию конфигураций. Репозиторий конфигураций — это обычный проект в GitLab или GitHub. Если у вас нет к нему доступа, обратитесь к команде Trisigma или администратору платформы в вашей компании.
Склонируйте репозиторий. Выполните команду git clone для копирования проекта на ваш компьютер.
Настройте окружение. Для проверки корректности ваших правок установите Trisigma CLI.

Концепция семантического слоя

Семантический слой — это абстракция над вашими сырыми данными в DWH. Вместо написания сложных SQL-запросов для каждого отчета, вы один раз описываете бизнес-логику в связке Source + Metric:

Опишите источники (Source) через SQL-запросы, которые готовят «плоские» таблицы с событиями и привязывают их к идентификаторам пользователей.
Настройте метрики (Metric), используя правила агрегации (сумма, количество уникальных, соотношение), которые накладываются на источники.

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

Процесс применения изменений

Работа с конфигурациями проходит через стандартный Git-флоу:

Создайте новую ветку через команду git checkout -b metrics_delivery.
Напишите необходимые SQL-запросы для определения источников данных.
Заполните файл metrics.yaml, описав в нем целевые показатели для расчета.
Проверьте синтаксис конфигураций через Trisigma CLI с помощью команды trisigma sl validate.
Пройдите несколько итераций тестирования с помощью команды run test.
Оставьте финальный комментарий run merge после прохождения ревью в GitLab или GitHub, чтобы бот Trisigma автоматически применил изменения.

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

Добавление новых метрик в будущем

Если через некоторое время вам потребуется добавить новый показатель, вы следуете тем же путем: создаете SQL-запрос для новых данных, регистрируете его в sources.yaml и описываете формулу в YAML-файле метрик. Модульная архитектура платформы позволяет неограниченно расширять набор доступных метрик без риска сломать существующие расчеты.

Заведение метрик для кейса доставки

к сведению

Ниже показано описание метрик для кейса «Точная дата доставки» из вступления. Формулы и SQL-запросы в вашем репозитории будут зависеть от структуры вашего DWH.

Рассмотрим, как настроить расчет конверсии и отмен для нашего эксперимента.

1. Подготовка источников (Sources)

Для анализа нам нужны данные о заказах и добавлениях в корзину. Создайте SQL-файлы в папке sources/sql/.

Файл: sources/sql/orders.sql

-- sources/sql/orders.sql
SELECT user_id, order_id, status, order_date 
FROM dwh.orders
WHERE order_date BETWEEN :first_date AND :last_date

Файл: sources/sql/cart.sql

-- sources/sql/cart.sql
SELECT user_id, event_time 
FROM dwh.cart_events
WHERE event_time BETWEEN :first_date AND :last_date

Текущий период

Запись :first_date и :last_date — это обязательные технические плейсхолдеры. При расчете эксперимента платформа автоматически подставляет в них даты начала и окончания теста. Это позволяет СУБД эффективно фильтровать данные, не вычитывая историю за несколько лет.

Создание таких SQL-источников позволяет изолировать аналитическую логику от физической структуры вашего хранилища. При изменении схем данных в DWH вам достаточно обновить только SQL-файл, при этом все зависимые метрики продолжат работать корректно.

Свяжите эти запросы с системой через sources/sources.yaml. Этот файл объясняет платформе, что именно она «видит» в результатах ваших SQL-запросов:

# sources/sources.yaml
orders_source:
  # Название SQL-файла в папке sources/sql/
  sql: orders
  # Маппинг: колонка user_id из SQL становится участником типа user_id
  participant: { user_id: user_id }
  # Колонка order_date используется как дата события для расчетов
  dtm: order_date
  # Ссылка на файл с формулами метрик (metrics/delivery_metrics.yaml)
  metric_configs: [delivery_metrics]

cart_source:
  sql: cart
  participant: { user_id: user_id }
  dtm: event_time
  metric_configs: [delivery_metrics]

2. Описание формул (Metrics)

Теперь опишем саму логику расчета в файле metrics/delivery_metrics.yaml.

# metrics/delivery_metrics.yaml
metric.uniq:
  # Название метрики для интерфейса
  total_buyers:
    # Ссылка на источник из sources.yaml
    counter: orders_source
    # Что именно считаем уникальным (тип участника из sources.yaml)
    key: user_id

  users_added_to_cart:
    counter: cart_source
    key: user_id

metric.ratio:
  # Результирующая метрика: отношение двух показателей
  purchase_cr:
    # Числитель: покупатели из orders_source
    num: total_buyers
    # Знаменатель: системная метрика (все, кто увидел эксперимент в Сплиттере)
    den: exposure_users

  add_to_cart_rate:
    num: users_added_to_cart
    den: exposure_users

  # Контрольная метрика: Доля отмен
  cancel_rate:
    # Числитель: количество отмен
    num: total_cancelled_orders
    # Знаменатель: количество покупателей
    den: total_buyers

Здесь total_cancelled_orders должен быть предварительно описан как metric.uniq в этом же файле на основе соответствующего SQL-источника.

Такая структура позволяет собирать сложные показатели из простых «кубиков». Вы один раз описываете базовые счета (metric.uniq), а затем комбинируете их в коэффициенты (metric.ratio). Использование exposure_users в качестве знаменателя гарантирует, что конверсия будет считаться только по тем пользователям, которые физически взаимодействовали с вашим экспериментом.

Итоговый файл metrics/delivery_metrics.yaml:

metric.uniq:
  total_buyers:
    counter: orders_source
    key: user_id
  users_added_to_cart:
    counter: cart_source
    key: user_id
  total_cancelled_orders:
    counter: orders_source
    key: user_id

metric.ratio:
  purchase_cr:
    num: total_buyers
    den: exposure_users
  add_to_cart_rate:
    num: users_added_to_cart
    den: exposure_users
  cancel_rate:
    num: total_cancelled_orders
    den: total_buyers

После заведения метрик и описания YAML-файлов проверьте синтаксис конфигураций через Trisigma CLI с помощью команды trisigma sl validate.

Если ошибок нет, переходите к следующему этапу - слиянию в мастер. Оставьте комментарий run merge в вашем репозитории, после чего бот Trisigma автоматически применит изменения.

Следующий шаг - создание эксперимента. Перейдите по ссылке Создание эксперимента.

Подготовка к работе​

Концепция семантического слоя​

Процесс применения изменений​

Заведение метрик для кейса доставки​

1. Подготовка источников (Sources)​

2. Описание формул (Metrics)​