Подготовка витрины данных

Рекомендации по организации данных для автоматической загрузки через API.

Зачем нужна витрина

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

• Единый источник данных для всех экспериментов
• Простую автоматизацию через API
• Консистентность расчёта метрик
• Эксперименты в UI всегда актуальны, новые появляются автоматически

Типичные источники

Обычно данные для экспериментов находятся в нескольких местах:

1. Таблица сплитов - где система сплитования записывает experiment_id и variant для каждого пользователя
2. Логи событий - трекер событий (Amplitude, Mixpanel, собственный)
3. Бэковые данные - транзакции, заказы, подписки

Целевая структура витрины

Соберите данные в формат:

dt | experiment_id | user_id | variant | metric1 | metric2 | ... | metricX | segment1 | segment2 | ... | segmentX

Пример:

dt         | experiment_id | user_id | variant | purchase | revenue | clicks | device  | country
-----------|---------------|---------|---------|----------|---------|--------|---------|--------
2025-12-01 | homepage_test | user_1  | A       | 1        | 150.00  | 5      | mobile  | US
2025-12-01 | homepage_test | user_2  | B       | 0        | 0       | 2      | desktop | UK
2025-12-02 | homepage_test | user_1  | A       | 0        | 200.00  | 3      | mobile  | US
2025-12-01 | checkout_flow | user_3  | A       | 1        | 50.00   | 1      | mobile  | FR

Ключевые принципы:

• 1 строка = 1 пользователь в 1 эксперименте за 1 день
• Метрики аггрегированы за день (не отдельные события)
• Широкая таблица - все метрики в одной строке
• Сегменты для группировки (device, country, tier и т.д.)

Аггрегация метрик

Conversion метрики (0/1):

• Используйте MAX за день - было действие или нет
• Примеры: purchase (купил/не купил), registration (зарегистрировался/нет)

Numeric метрики:

• Используйте SUM за день - сумма всех действий
• Примеры: revenue (сумма покупок), page_views (количество просмотров)

Ratio метрики (не собираем):

• НЕ нужно собирать ratio метрики (например, средний чек)
• Вместо этого соберите составляющие numeric метрики
• Пример: для AOV (average order value) соберите orders и revenue, а не готовый aov
• Причина: ratio метрики требуют особой обработки, их нельзя корректно агрегировать на уровне пользователя

Обработка NULL:

• Заменяйте NULL на 0 - если не было активности, метрика = 0

Использование с API

С такой витриной загрузка в AB-Labz становится тривиальной:

# Получаем список активных экспериментов (с данными за последние сутки)
active_experiments = get_active_experiments()

# Для каждого эксперимента: выгружаем и загружаем
for exp_id in active_experiments:
    df = get_experiment_data(exp_id)  # SELECT * FROM datamart WHERE experiment_id = ...
    csv = df.to_csv(index=False)
    upload_to_ablabz(exp_id, csv)

Подробнее см. раздел Примеры использования.

Перезапись данных

Система хранит только последнюю версию файла для каждого experiment_id. Каждая новая загрузка перезаписывает предыдущую.

Это правильное поведение для экспериментов:

• Каждая новая загрузка содержит всё больше данных по мере накопления выборки
• Не нужна история версий — нам нужен полный актуальный датасет
• Цель: собрать полную выборку эксперимента с первого дня до последнего

Пример:

• День 1: загружаете 1000 пользователей
• День 2: загружаете 2000 пользователей (1000 старых + 1000 новых)
• День 3: загружаете 3000 пользователей (все с начала эксперимента)

При каждой загрузке отправляйте весь датасет эксперимента, а не дельту. Так вы всегда видите актуальное состояние эксперимента на дашборде: размер выборки и баланс групп (SRM).