Факт-таблица (fact table) в аналитическом контуре

Факт-таблица (fact table) в аналитическом контуре

Факт-таблица — это таблица в модели данных аналитики, где хранятся измерения поведения и событий как “факты”: что произошло и при каких параметрах. Типичные поля: идентификатор события/действия, время (timestamp), ключи к контексту (пользователь, сессия, заказ, продукт), а также числовые метрики (количество, выручка, длительность) или коды атрибутов (канал, устройство, план тарифов).

Чем отличается от измерительной (dimension) таблицы:
— Факт-таблица отвечает на вопрос “как часто и сколько” (и для чего это было).
— Dimension-таблица отвечает на вопрос “какой” (кто/какой продукт/какой канал/какие свойства).
GA4, Amplitude и Mixpanel по смыслу близки к комбинированию этих слоёв, но в BI-слое (DWH/витринах) модель чаще явно разделяют: факты — события, измерения — справочники.

Типичные ошибки:
— Смешивать в одном месте “справочные” значения и “событийные” метрики: например, хранить название кампании в каждой строке события, вместо нормализации в dimension.
— Делать событие “пользователь_создал_аккаунт” измерением пользователя: тогда теряется многократность и корректная динамика по времени.
— Подменять “metric” логикой вычислений в момент запроса и получать разные результаты в GA4 и в отчёте DWH.

Пример:
В e-com вы фиксируете fact-талицу `orders_events`: каждая строка — событие покупки с ключами `user_id`, `order_id`, `product_id`, `timestamp` и полем `revenue`. Dimension-таблицы содержат `channels` (UTM/источник), `products` (категория/маржа) и `users` (когортные признаки). Это помогает корректно считать LTV и удержание (retention) даже при privacy-first атрибуции, когда last-click становится менее надежным.

Заголовок вашей модели данных должен звучать так: “Факт — это строки про события, измерения — это описания для фильтров”.