Таксономия событий (Event Taxonomy Template)

• Один язык и один стиль.
• Событие описывает факт, а не экран: `report_exported`, а не `export_button_clicked`.
• Не кодировать mutable details в event name.
• Properties используются для контекста, а не для создания сотен событий.

У события должны быть owner, version/change log и правила deprecation. Иначе старые dashboards продолжают считать метрики по уже изменённой логике.

Шаблон особенно полезен, если одной метрикой пользуются несколько команд, данные собираются из разных систем или расчёт влияет на бюджет и решения. Для одноразового анализа допустима облегчённая версия, но definition и источник данных всё равно должны быть указаны. Чем дольше живёт показатель, тем важнее governance и change log.

• Начните с решения и бизнес-вопроса, а не с доступных таблиц. Это определит, какие метрики и уровень детализации действительно нужны.
• Зафиксируйте definitions, grain, time window и source of truth до построения расчётов. Одинаковое название не гарантирует одинаковую метрику.
• Проверьте качество данных: полноту, дубли, пропуски, изменения tracking и структурные разрывы во времени.
• Для прогнозов и моделей явно храните assumptions, диапазоны и сценарии. Не маскируйте неопределённость одной точной цифрой.
• Назначьте owner и cadence пересмотра. Аналитический артефакт без ответственного и правил обновления быстро перестаёт быть источником истины.

После нескольких релизов вместо `click_button_3` и `new_export` вводятся события, описывающие бизнес-факт: `report_exported`, `trial_started`, `invite_sent`.

Результат работы с шаблоном «Таксономия событий» — не заполненная форма сама по себе, а согласованный рабочий артефакт, который можно использовать для решения, передачи контекста и последующей проверки результата. У документа должны быть понятны владелец, исходные данные, допущения, дата актуальности и следующий шаг. Если эти элементы невозможно определить, полезнее сократить документ до минимальной версии и вернуть недостающие данные, чем заполнять поля формально.

• У каждой метрики есть точная definition.
• Источник данных и grain указаны.
• Метод позволяет ответить именно на поставленный вопрос.
• Неопределённость, лаги и limitations не скрыты.
• Есть owner и правило обновления.

Пересматривайте определения при изменении tracking, CRM, data model, business logic или accounting rules. Любое изменение формулы должно иметь change log, дату вступления в силу и оценку влияния на исторические сравнения.

Нужно ли хранить все метрики в одном документе?

Нет. Канонический dictionary и measurement plan должны быть связаны, но operational dashboards могут показывать только релевантный subset.

Что делать, если источники дают разные цифры?

Назначить source of truth и документировать расхождение. Нельзя тихо выбирать источник, который показывает более удобный результат.

Как часто пересматривать модель?

По cadence бизнеса и при изменении данных. Forecast и campaign metrics могут обновляться часто, definitions и governance — реже, но обязательно после системных изменений.

• Tracking Plan
• Metric Dictionary
• Dashboard Specification

• Event Taxonomy
• Data Lineage
• Analytics Data Quality