Event taxonomy: как построить tracking plan без мусора
Что такое event taxonomy?
Event taxonomy — контролируемый словарь и семантические правила для имён product events и properties. Tracking plan применяет этот язык к реализации: определяет, что и когда срабатывает, какой source владеет фактом, что означает каждое поле и как проверяется payload.
TL;DR
- -Event taxonomy задаёт язык аналитики. Tracking plan описывает реализованные на этом языке события, properties, producers, owners и проверки.
- -Начинайте с решений и бизнес-вопросов. Список из 30 правдоподобных событий не становится analytics strategy.
- -Выберите одну naming convention и зафиксируйте смысл. Title Case против snake_case менее важен, чем стабильная семантика и enforcement.
- -До инструментирования определите identity, event time, source of truth, типы, nullability, privacy class и поведение при дублях.
- -AI может преобразовать переданные journeys и вопросы в draft. Каждое событие должно ссылаться на input, а неизвестное оставаться UNKNOWN.
- -Валидируйте payloads в development и production, следите за пропущенными полями и volume, версионируйте несовместимые изменения смысла.
Самый быстрый способ испортить продуктовую аналитику — инструментировать каждый экран.
Событий много, dashboards строятся, но никто не уверен, что означают цифры. Subscription Created может срабатывать при открытии checkout, успешной оплате или появлении строки в базе. Во всех случаях имя выглядит аккуратно, а metric означает разное.
Event taxonomy решает проблему языка. Tracking plan — проблему реализации. AI помогает подготовить оба документа, но сначала команда должна решить, какие вопросы важны и какая система владеет каждым фактом.
Taxonomy и tracking plan — разные документы
Актуальный гайд Amplitude проводит полезную границу: taxonomy определяет, как называть сущности, а tracking plan — что собирать, включая firing conditions и properties (Amplitude).
Сохраните это разделение в документации:
Taxonomy
- паттерн имён событий;
- паттерн имён properties;
- словарь общих понятий;
- типы данных и единицы;
- правила identity, time и versions;
- deprecation policy.
Tracking plan
- поддерживаемый бизнес-вопрос и metric;
- имя события и точное определение;
- producer и source of truth;
- trigger и exclusions;
- контракт properties;
- privacy classification;
- owner и lifecycle status;
- требования к тестам и мониторингу.
Имя Invoice Paid относится к taxonomy. Формулировка «срабатывает один раз на сервере после подтверждения settlement платёжным провайдером; повторная доставка использует тот же event ID» относится к tracking plan.
Шаг 1. Начните с решений, а не экранов
В руководстве Twilio Segment сначала определяется, что команда хочет узнать, и только затем вопросы связываются с events и properties. Такой порядок не даёт инструментированию превратиться в каталог UI controls (Segment).
До именования событий составьте decision table:
| Решение | Вопрос | Metric или analysis | Нужные evidence |
|---|---|---|---|
| Улучшить onboarding | Где подходящие accounts останавливаются до first value? | step conversion по account cohort | account created, обязательные steps, value event |
| Изменить trial | Какие accounts конвертируются после meaningful use? | conversion по заранее заданному activation behavior | trial eligibility, activation evidence, paid conversion |
| Исправить collaboration | Становятся ли приглашённые коллеги active members? | invite-to-activation funnel | invite sent, invite accepted, core action |
Здесь становятся видны расплывчатые metrics. Activation не является событием, пока product team не определила behavior, actor, time window и активируемую сущность. В B2B единицей часто служит account, а не человек. Зафиксируйте определение рядом с North Star metric и retention model, а не прячьте в SDK call.
Если событие не поддерживает текущее решение или analysis, не добавляйте его в первый release. Evidence можно собрать позже. Исторические данные, смысл которых никто не может объяснить, не становятся активом.
Шаг 2. Определите grain события и source of truth
До выбора имени закончите фразу:
Одна строка означает один ___, выполненный ___ над ___ в момент ___.
Например:
Одна строка Invoice Paid означает один оплаченный invoice,
принадлежащий одному workspace, подтверждённый billing service,
во время settlement у provider.
Затем определите:
- actor: anonymous device, user, service или admin;
- subject: account, project, invoice, document или другая сущность;
- grain: один click, attempt, state transition или business transaction;
- producer: web client, mobile client, backend service, webhook processor;
- source of truth: система, имеющая право утверждать факт;
- event time: момент действия, а не только приёма данных vendor;
- deduplication key: стабильный ID для retries, если pipeline его поддерживает.
Client-side event уместен для взаимодействия, наблюдаемого только клиентом, например показа panel. Billing, permissions, успешные jobs и другие authoritative state transitions обычно надёжнее отправлять с server side. Если обе стороны фиксируют связанные сигналы, разведите смысл: Checkout Submitted от клиента и Invoice Paid от billing service.
Не разрешайте двум producers отправлять одно имя с разной семантикой. Dashboard не исправит это задним числом.
Шаг 3. Выберите одну naming grammar
Object Action в past tense легко читать:
Account Created
Invite Accepted
Report Exported
Lowercase snake_case удобен в коде и warehouse:
account_created
invite_accepted
report_exported
Оба варианта допустимы при стабильном смысле. Даже first-party рекомендации различаются: Amplitude показывает object-plus-action в Title Case или snake_case, а PostHog публиковал convention с lowercase snake_case. Поддержка формата платформой не делает его обязательным.
Рабочие правила:
- Выберите единый регистр и tense для custom events.
- Используйте язык предметной области, а не подписи buttons.
- Описывайте наблюдаемый завершённый факт, а не желаемый результат.
- Выносите вариации в properties, если смысл события один.
- Зарезервируйте vendor-defined names и prefixes.
- Никогда не собирайте event name динамически.
Report Exported с format: "csv" проще поддерживать, чем CSV Report Exported, PDF Report Exported и новое событие для каждого формата. Но разные факты не стоит сжимать в бессодержательное Action Completed.
Properties требуют той же дисциплины:
workspace_id string
billing_interval enum: monthly | annual
amount_minor integer
currency ISO 4217 string
is_first_invoice boolean
occurred_at RFC 3339 timestamp
Документируйте units. amount: 99 бесполезно, пока plan не объясняет, это cents, dollars или другая currency.
Шаг 4. Опишите настоящий event contract
Строка tracking plan должна давать developer, analyst и reviewer одно толкование.
| Поле | Пример |
|---|---|
| Event | invoice_paid |
| Purpose | Revenue и trial-conversion analysis |
| Definition | Billing provider подтвердил settlement |
| Fires | Один раз на settled invoice |
| Does not fire | Checkout открыт, payment pending, получен retry |
| Producer | billing-webhook |
| Subject | workspace |
| Event ID | provider invoice ID + settlement transition |
| Required properties | workspace_id, invoice_id, amount_minor, currency, plan_id |
| Optional properties | coupon_id |
| Owner | Billing engineering |
| Privacy | pseudonymous account data; без free text |
| Status | proposed / implemented / verified / deprecated |
Отделяйте event properties от изменяемых profile или entity properties. Сумма invoice на момент платежа относится к событию. Текущий план workspace может находиться в account profile, но изменяемое значение не должно переписывать исторический смысл.
Не добавляйте без privacy и cardinality review универсальные free-text поля: feedback_text, URL с query string, search query, имя документа или raw error. В них часто попадают secrets и personal data, а число значений растёт без контроля.
Шаг 5. Спроектируйте identity до воронок
Ошибки identity создают вымышленных пользователей, разорванные funnels и утечки между accounts.
Зафиксируйте:
- создание и rotation anonymous identifier;
- момент назначения известного
user_id; - правила merge anonymous и known профиля;
- logout и shared-device behavior;
- account или group identity;
- membership пользователя в нескольких accounts;
- deletion и suppression flow;
- согласованность server и client.
Не считайте, что SDK автоматически реализует нужную продукту модель. У Amplitude, Mixpanel, PostHog, Segment и warehouse-first pipeline разные identity models и reserved fields. Сохраните одну conceptual model и добавьте mapping для каждой destination.
Постоянный user_id не становится анонимным только потому, что в нём нет email. ICO отмечает, что pseudonymised data может быть повторно связана с человеком через отдельно хранимую информацию. Для пользователей из ЕС применяются, среди прочего, purpose limitation, data minimisation, storage limitation и accountability (European Commission, ICO).
Для каждой property запишите:
purpose | legal basis/approval | classification | destinations |
retention | deletion path | access group
Требования зависят от юрисдикции и данных — нужна проверка privacy или legal specialist. Строка в taxonomy не создаёт legal basis.
Шаг 6. Ограничьте AI переданными evidence
Опасный prompt: «Сгенерируй 30 событий для моего SaaS». Он оптимизирует полноту таблицы, а не качество данных. Модель не знает ваши решения, реализацию, privacy obligations и event grain.
Передайте ограниченный набор inputs:
Ты готовишь tracking plan только из переданных evidence.
Inputs:
- утверждённые бизнес-вопросы и metric definitions
- user journeys и state-transition diagrams
- экспорт существующих событий
- релевантные API contracts и code locations
- taxonomy rules
- privacy classification rules
Для каждого события:
1. Укажи бизнес-вопрос и input, требующий это событие.
2. Определи actor, subject, grain, trigger, exclusions, producer,
source of truth, event time и deduplication behavior.
3. Перечисли required и optional properties: type, unit,
allowed values, nullability и privacy class.
4. Сопоставь duplicates и legacy events.
5. Пиши UNKNOWN для недостающих фактов.
6. Отмечай high-cardinality, free-text, identity и PII risks.
Не выдумывай:
- activation definitions
- implementation locations
- legal bases
- retention periods
- thresholds
- vendor capabilities
Quality gate — это human review, schema validation и test payloads. Вторая LLM помогает найти несоответствия, но согласие двух моделей не доказывает связь с продуктом.
Шаг 7. Сократите plan до первого полезного slice
Project-management product не нужен универсальный список из 30 событий в первый день. Допустим, текущие вопросы относятся к account activation и совместной работе. Первый slice может выглядеть так:
| Event | Producer | Зачем нужен | Key properties |
|---|---|---|---|
account_created | backend | denominator для cohort | account_id, created_by_user_id, signup_source |
onboarding_step_completed | backend или trusted client | step funnel | account_id, step_id, flow_version |
project_created | backend | первое setup behavior | account_id, project_id, creation_method |
task_created | backend | создан core object | account_id, project_id, task_id |
task_completed | backend | завершена core work | account_id, project_id, task_id |
invite_sent | backend | начало collaboration funnel | account_id, invite_id, role |
invite_accepted | backend | следующий шаг collaboration | account_id, invite_id, user_id |
subscription_started | billing service | paid conversion | account_id, subscription_id, plan_id, currency |
Это тоже draft. Account activation лучше рассчитывать из базовых фактов, а не отправлять как First Value Moment Reached. Derived metric можно изменить без просьбы к приложению угадать, когда появился value.
До добавления событий «return» и «reactivation» свяжите данные с объявленной retention analysis. Sessions полезны для отдельных вопросов, но сами по себе не определяют retention.
Шаг 8. Проверяйте до и после release
Таблица, однажды прошедшая review, начнёт расходиться с кодом. Ставьте проверки рядом с producers.
До merge
- schema file или generated typed wrapper обновлён;
- event owner одобрил semantic change;
- required и forbidden properties покрыты тестами;
- representative payload не содержит raw PII и secrets;
- поведение duplicates и retries проверено;
- старые consumers найдены;
- изменение записано в changelog.
В staging
Смотрите raw payload в collector, а не только финальный chart. Проверьте одно ожидаемое событие на trigger, отсутствие события для exclusions, правильные timestamp и IDs, одинаковые properties в web, mobile и backend sources.
В production
По каждому event и producer отслеживайте:
- observed и expected event names;
- наличие required properties;
- type и enum violations;
- duplicate rate;
- задержку между event time и ingestion time;
- изменение volume и distinct IDs;
- новые high-cardinality properties;
- неожиданные personal и free-text поля.
Не копируйте универсальную цель 99% completeness или порог anomaly 50%. Service levels зависят от business criticality и нормальной вариативности. Billing event может требовать почти полного reconciliation с ledger; потеря части малозначимых UI exposures допустима.
Критичные failures должны попадать в общий процесс metric alerts вместе с product и infrastructure signals. Alert без owner, runbook и reconciliation path быстро становится фоновым шумом.
Managed tools умеют хранить, ветвить, подтверждать и проверять schemas. Amplitude сейчас поддерживает tracking-plan branches и official designations; Segment Protocols валидирует события по плану. Маленькая команда может начать с versioned JSON или CSV, runtime validation и CI tests. Важен один authoritative contract с владельцем, а не логотип инструмента.
Как менять schema и не ломать историю
Классифицируйте изменения:
- Additive: новая optional property или event.
- Compatible tightening: документация enum или validation, совпадающая с существующими данными.
- Breaking: rename, новый grain, другая firing point, смена type или новый смысл под старым именем.
- Deprecation: прекращение новых записей при сохранении исторической трактовки.
Для breaking change создайте новую version или event name. Параллельно отправляйте старую и новую схему только при необходимости, обновите зависимые dashboards, затем выключите старый producer. Не переименовывайте historical data в новый смысл ради аккуратного каталога.
Запишите решение:
change: invoice_paid v1 -> v2
reason: event now represents settlement, not authorization
effective_at: 2026-09-01T00:00:00Z
owners:
producer: billing-engineering
consumers: finance-analytics
migration:
- add v2 payload and validation
- reconcile v2 against payment ledger
- update revenue dashboards
- deprecate v1 after named consumers move
Практическая последовательность
- Выпишите решения и вопросы, которые должны поддержать данные.
- Определите metrics, entity, cohort и time windows.
- Выберите event grain, producer, source of truth и identity behavior.
- Примите единые naming и property rules.
- Опишите contracts с privacy и lifecycle metadata.
- Используйте AI для mapping переданных evidence, а не создания product truth.
- Реализуйте минимальный полезный slice.
- Тестируйте raw payloads, schemas и reconciliation критичных фактов.
- Следите за качеством по event и producer.
- Версионируйте semantic changes и осознанно отключайте obsolete data.
Надёжная event taxonomy — не самый длинный список событий. Это минимальный общий язык, на котором product, engineering и analytics получают воспроизводимый ответ.
Источники
- Amplitude: taxonomy versus tracking plan
- Amplitude: CSV tracking-plan branches
- Amplitude: official events and properties
- Twilio Segment: create a tracking plan
- Twilio Segment: tracking-plan validation
- PostHog: analytics naming guidance
- European Commission: GDPR processing principles
- ICO: pseudonymisation guidance