Event Taxonomy с нуля: AI-генерация Tracking Plan за 1 час
Что такое event taxonomy?
Event taxonomy (таксономия событий) — это контролируемый словарь, определяющий какие действия пользователей отслеживать в продукте, как их последовательно именовать и какие свойства прикреплять к каждому событию. Предотвращает хаос в аналитике, когда одно действие фиксируется под разными несовместимыми названиями, и делает данные пригодными для анализа без ручной очистки.
TL;DR
- -Без event taxonomy за 6 месяцев в аналитике SaaS накапливается 200+ событий, 60% из которых — дубли или мусор
- -Формула именования: Объект + Действие в прошедшем времени — 'Subscription Created', а не 'create_subscription'
- -Три категории свойств: обязательные (timestamp, user_id, session_id), специфичные для объекта, контекстные
- -Типичному SaaS нужно 8–12 объектов; больше 12 — таксономия слишком детализирована
- -AI генерирует tracking plan из 30 событий по описанию продукта меньше чем за 1 час
70% данных в аналитических системах SaaS-продуктов непригодны для анализа. Причина не в инструментах. Причина в отсутствии event taxonomy, формализованной структуры именования и классификации событий. Без неё данные превращаются в хаос: click_button, buttonClick, btn-clicked описывают одно действие тремя способами. Аналитик тратит часы на расшифровку вместо анализа.
Статья о том, как спроектировать event taxonomy с нуля, используя AI для генерации tracking plan из 30 событий за один час. Покрывает структуру таксономии, naming conventions, промпты, готовый пример для SaaS и пошаговый процесс внедрения.
Что такое Event Taxonomy
Event taxonomy — это контролируемый словарь событий продукта. Она определяет три вещи:
- Какие события трекать. Не всё подряд, а конкретные действия пользователя, значимые для бизнеса.
- Как их называть. Единые naming conventions, которые делают события читаемыми без документации.
- Какие свойства передавать. Набор атрибутов (properties) для каждого события, обеспечивающих контекст.
Без таксономии происходит следующее:
- Разработчики называют события произвольно. Один пишет
signup_completed, другойuser_signed_up, третийregistration_done. - Свойства не стандартизированы. Где-то
plan_name, где-тоplanType, где-тоsubscription_tier. - Через полгода в системе 200+ событий, из которых 60% дубликаты или мусор.
- Аналитик не может построить воронку, потому что не знает, какое из трёх событий регистрации актуально.
Event taxonomy решает эту проблему на уровне архитектуры данных. Один раз спроектировать правильно дешевле, чем месяц чистить данные потом.
Три уровня структуры
Рабочая таксономия строится на трёх уровнях: объект, действие, свойства.
Уровень 1: Объект (Object)
Объект — сущность продукта, с которой взаимодействует пользователь. Примеры: Account, Project, Invoice, Subscription, Report.
Объекты формируют верхний уровень иерархии. Для типичного SaaS-продукта достаточно 8–12 объектов. Больше 12 — признак того, что таксономия слишком гранулярна.
Уровень 2: Действие (Action)
Действие — то, что происходит с объектом. Стандартный набор действий для SaaS:
| Действие | Значение | Пример события |
|---|---|---|
| Created | Объект создан | Project Created |
| Updated | Объект изменён | Project Updated |
| Deleted | Объект удалён | Project Deleted |
| Viewed | Объект просмотрен | Report Viewed |
| Completed | Процесс завершён | Onboarding Completed |
| Started | Процесс начат | Trial Started |
| Submitted | Форма отправлена | Feedback Submitted |
| Exported | Данные выгружены | Report Exported |
Формула именования события: Object + Action (в past tense). Subscription Created, а не Create Subscription или subscription.create.
Уровень 3: Свойства (Properties)
Свойства дают контекст событию. Без них событие Subscription Created бесполезно: непонятно, какой план, какой период, откуда пришёл пользователь.
Свойства делятся на три категории:
Обязательные (required). Передаются с каждым событием. Минимальный набор: timestamp, user_id, session_id.
Объектные (object-specific). Зависят от объекта. Для Subscription Created: plan_name, billing_cycle, price, currency. Для Report Exported: report_type, format, row_count.
Контекстные (contextual). Описывают обстоятельства: source (откуда пришёл), device_type, referrer, experiment_id.
Naming Conventions, которые масштабируются
Naming conventions определяют устойчивость таксономии. Без них система деградирует с каждым новым разработчиком. Вот набор правил, который работает для продуктов любого размера.
Формат события: Object Action
✅ Subscription Created
✅ Report Exported
✅ Onboarding Step Completed
❌ created_subscription
❌ reportExported
❌ onboarding.step.completed
Title Case с пробелами. Читается как естественный язык. Mixpanel, Amplitude, PostHog поддерживают этот формат нативно.
Past tense для действий. Событие фиксирует то, что уже произошло. Created, а не Create. Viewed, а не View.
Формат свойств: snake_case
✅ plan_name
✅ billing_cycle
✅ is_annual
❌ planName
❌ BillingCycle
❌ isAnnual
snake_case для свойств. Совместим со всеми аналитическими платформами и консистентен с SQL, на котором пишется большинство запросов к данным.
Правила для типов данных
| Правило | Пример | Почему |
|---|---|---|
Булевы начинаются с is_ или has_ | is_annual, has_discount | Понятно без документации |
Количества заканчиваются на _count | member_count, item_count | Отличает от ID |
Суммы содержат _amount и валюту | total_amount, currency: "USD" | Нет двусмысленности |
Временные метки заканчиваются на _at | created_at, expired_at | Отличает от дат |
Идентификаторы заканчиваются на _id | project_id, workspace_id | Не перепутать со значением |
Запрещённые паттерны
- Глагольные события без объекта.
Clicked,Viewed,Submitted. Что именно? Всегда добавлять объект. - Вложенные свойства.
plan.name,user.email. Плоская структура лучше для SQL-запросов и совместимости. - Свойства-массивы в корне.
tags: ["a", "b"]. Большинство аналитических систем не умеют фильтровать по элементам массива. Лучше:tag_count: 2,primary_tag: "a". - PII в свойствах. Email, имя, телефон не передаются в событиях. Только
user_id, остальное через user profiles.
Промпты для генерации Tracking Plan
AI ускоряет процесс проектирования таксономии в 5–10 раз. Вместо ручного перебора экранов и функций — структурированный промпт, который генерирует полный tracking plan.
Базовый промпт
Ты — product analytics architect. Задача: спроектировать event taxonomy
для SaaS-продукта.
ПРОДУКТ: [название и одно предложение о функции]
КЛЮЧЕВЫЕ ФУНКЦИИ: [список из 5-8 основных функций]
БИЗНЕС-МОДЕЛЬ: [freemium / trial / enterprise]
АНАЛИТИЧЕСКАЯ ПЛАТФОРМА: [Mixpanel / Amplitude / PostHog]
NAMING CONVENTIONS:
- События: Title Case, Object + Action (past tense)
- Свойства: snake_case
- Булевы: is_ / has_ префикс
- Количества: _count суффикс
- Идентификаторы: _id суффикс
ТРЕБОВАНИЯ:
1. 25-35 событий, покрывающих полный user lifecycle:
- Acquisition (регистрация, онбординг)
- Activation (первое значимое действие)
- Engagement (ключевые действия продукта)
- Revenue (подписка, оплата)
- Retention (возвращение, реактивация)
2. Для каждого события: название, описание (1 строка), список свойств
с типами данных
3. Отдельно: список super properties (передаются с каждым событием)
4. Отдельно: user profile properties
ФОРМАТ ВЫВОДА: таблица Markdown.
Промпт для валидации
После генерации плана стоит прогнать его через второй промпт:
Проверь этот tracking plan на типичные ошибки:
1. ДУБЛИКАТЫ: есть ли события, описывающие одно и то же действие?
2. ПРОБЕЛЫ: какие этапы user lifecycle не покрыты?
3. NAMING: все ли события следуют формату "Object Action" (Title Case,
past tense)?
4. СВОЙСТВА: есть ли свойства без типа данных? Есть ли PII?
5. ГРАНУЛЯРНОСТЬ: есть ли события, которые можно объединить?
Есть ли слишком общие события, которые стоит разделить?
[вставить tracking plan]
Этот двухэтапный процесс (генерация + валидация) повторяет паттерн LLM-as-Judge. Один AI генерирует, другой проверяет. Результат стабильно лучше, чем однопроходная генерация.
30 событий для SaaS-продукта
Конкретный пример для типичного B2B SaaS. Платформа управления проектами. Freemium-модель, ключевые функции: проекты, задачи, коллаборация, отчёты, интеграции.
Super Properties (передаются с каждым событием)
| Свойство | Тип | Описание |
|---|---|---|
workspace_id | string | ID рабочего пространства |
plan_name | string | Текущий план (free/pro/enterprise) |
user_role | string | Роль в workspace (owner/admin/member) |
is_trial | boolean | Пользователь на триале |
session_id | string | ID текущей сессии |
Acquisition (5 событий)
| # | Событие | Описание | Ключевые свойства |
|---|---|---|---|
| 1 | Account Created | Пользователь завершил регистрацию | signup_method (string), referral_source (string), utm_source (string), utm_medium (string), utm_campaign (string) |
| 2 | Onboarding Started | Пользователь начал онбординг-флоу | onboarding_version (string) |
| 3 | Onboarding Step Completed | Завершён один шаг онбординга | step_name (string), step_number (int), is_skipped (boolean) |
| 4 | Onboarding Completed | Весь онбординг пройден | total_steps_completed (int), total_steps_skipped (int), duration_seconds (int) |
| 5 | Teammate Invited | Отправлено приглашение в workspace | invite_method (string), invitee_role (string) |
Activation (5 событий)
| # | Событие | Описание | Ключевые свойства |
|---|---|---|---|
| 6 | Project Created | Создан первый/новый проект | project_type (string), is_template (boolean), template_name (string) |
| 7 | Task Created | Создана задача | project_id (string), has_due_date (boolean), has_assignee (boolean), priority (string) |
| 8 | Task Completed | Задача отмечена как выполненная | project_id (string), time_to_complete_hours (float), priority (string) |
| 9 | Integration Connected | Подключена внешняя интеграция | integration_name (string), integration_category (string) |
| 10 | First Value Moment Reached | Пользователь достиг aha-moment | trigger_event (string), days_since_signup (int) |
Engagement (10 событий)
| # | Событие | Описание | Ключевые свойства |
|---|---|---|---|
| 11 | Task Updated | Изменены параметры задачи | project_id (string), fields_changed (string), change_count (int) |
| 12 | Task Assigned | Задача назначена на пользователя | project_id (string), assignee_role (string), is_reassignment (boolean) |
| 13 | Comment Created | Добавлен комментарий к задаче | project_id (string), task_id (string), has_mention (boolean), has_attachment (boolean) |
| 14 | File Uploaded | Загружен файл в проект/задачу | file_type (string), file_size_kb (int), upload_context (string) |
| 15 | Report Viewed | Просмотрен отчёт/дашборд | report_type (string), date_range (string) |
| 16 | Report Exported | Экспортирован отчёт | report_type (string), format (string), row_count (int) |
| 17 | Search Performed | Выполнен поиск | query_length (int), result_count (int), search_context (string) |
| 18 | Filter Applied | Применён фильтр к списку | filter_type (string), filter_value_count (int), context (string) |
| 19 | View Switched | Переключен режим отображения | from_view (string), to_view (string) |
| 20 | Notification Clicked | Клик по уведомлению | notification_type (string), channel (string), time_to_click_seconds (int) |
Revenue (6 событий)
| # | Событие | Описание | Ключевые свойства |
|---|---|---|---|
| 21 | Trial Started | Активирован пробный период | trial_duration_days (int), plan_name (string) |
| 22 | Trial Ended | Триал истёк | converted (boolean), days_active (int), feature_usage_count (int) |
| 23 | Subscription Created | Оформлена платная подписка | plan_name (string), billing_cycle (string), price_amount (float), currency (string), coupon_code (string) |
| 24 | Subscription Upgraded | Переход на более высокий план | from_plan (string), to_plan (string), upgrade_reason (string) |
| 25 | Subscription Downgraded | Переход на более низкий план | from_plan (string), to_plan (string), downgrade_reason (string) |
| 26 | Subscription Cancelled | Подписка отменена | plan_name (string), cancel_reason (string), lifetime_days (int), feedback_text (string) |
Retention (4 события)
| # | Событие | Описание | Ключевые свойства |
|---|---|---|---|
| 27 | Session Started | Начата новая сессия | days_since_last_session (int), device_type (string), entry_page (string) |
| 28 | Feature Discovered | Пользователь впервые использовал фичу | feature_name (string), discovery_context (string), days_since_signup (int) |
| 29 | Workspace Setting Changed | Изменена настройка workspace | setting_name (string), old_value (string), new_value (string) |
| 30 | Account Deleted | Пользователь удалил аккаунт | delete_reason (string), lifetime_days (int), plan_at_deletion (string) |
User Profile Properties
Передаются отдельно от событий, обновляются при изменении:
| Свойство | Тип | Описание |
|---|---|---|
signup_date | date | Дата регистрации |
plan_name | string | Текущий план |
company_name | string | Название компании |
company_size | string | Размер (1-10, 11-50, 51-200, 200+) |
industry | string | Отрасль |
total_projects_created | int | Всего проектов создано (increment) |
total_tasks_completed | int | Всего задач завершено (increment) |
last_active_at | datetime | Последняя активность |
lifetime_value | float | Общая сумма платежей |
От промпта до внедрения за 1 час
Минуты 0–10: подготовка входных данных
Перед запуском AI нужно собрать три вещи:
- Список экранов продукта. Пройти по основным разделам, записать функции. Для MVP достаточно скриншотов или списка из 5–8 пунктов.
- Бизнес-вопросы. На какие вопросы должна отвечать аналитика? “Где пользователи отваливаются?”, “Какие фичи коррелируют с конверсией в платный план?”, “Какой onboarding step вызывает больше всего отказов?”
- Текущее состояние. Если трекинг уже есть, выгрузить список существующих событий. AI поможет смапить старые события на новую таксономию.
Минуты 10–25: генерация таксономии
Подставить данные в базовый промпт, запустить генерацию. AI выдаст первую версию за 2–3 минуты. На этом этапе важно:
- Проверить покрытие всех этапов lifecycle (acquisition через retention)
- Убедиться, что naming conventions соблюдаются
- Удалить события, которые не отвечают ни на один бизнес-вопрос
Минуты 25–40: валидация и доработка
Прогнать результат через промпт валидации. Типичные находки:
- Пропущены события отмены/даунгрейда (revenue-critical)
- Слишком гранулярные события в engagement (можно объединить)
- Отсутствуют свойства для сегментации (plan, role)
- Нет события-маркера activation (first value moment)
Внести правки, прогнать валидацию повторно. Этот цикл повторяет логику автоматизированного quality gate, описанного в статье про LLM-as-Judge.
Минуты 40–50: документация
Финальный tracking plan должен содержать:
- Naming conventions. Правила именования (чтобы новые разработчики не ломали схему).
- Таблица событий. Название, описание, свойства с типами.
- Super properties. Что передаётся с каждым событием.
- User profile properties. Что обновляется в профиле.
- Governance rules. Кто может добавлять новые события, процесс ревью.
Документацию тоже можно сгенерировать с помощью AI: скормить ему финальную таблицу и попросить оформить как внутренний стандарт.
Минуты 50–60: план имплементации
Последний шаг: план внедрения. Промпт для генерации:
На основе этого tracking plan создай план имплементации:
1. Приоритизация: какие события внедрить первыми
(критерий: бизнес-ценность вопросов, на которые они отвечают)
2. Для каждого события: в каком месте кода вызывать track()
3. QA-чеклист: как проверить, что событие отправляется корректно
[вставить tracking plan]
Типичные ошибки при проектировании
Слишком много событий. 100+ событий для MVP ведут к data swamp. 25–35 событий покрывают 90% аналитических вопросов. Добавлять новые стоит только при появлении конкретного бизнес-вопроса, на который нельзя ответить текущими данными.
Трекинг UI-действий вместо бизнес-действий. Button Clicked, Dropdown Opened, Modal Closed — это UX-аналитика, а не product analytics. Трекать нужно бизнес-действия: Task Created, не Create Task Button Clicked.
Отсутствие governance. Без процесса добавления новых событий таксономия деградирует за 3–6 месяцев. Минимальный governance: PR review для tracking-кода, где ревьюер проверяет соответствие naming conventions.
Игнорирование negative events. Subscription Cancelled, Account Deleted, Trial Ended (converted: false) — неприятные, но критически важные для бизнеса события. AI часто пропускает их в первой итерации, потому что фокусируется на happy path.
Одинаковые свойства с разными именами. plan, plan_name, plan_type, subscription_plan — четыре имени для одного свойства в разных событиях. Super properties решают эту проблему: определить plan_name один раз, передавать автоматически.
Инструменты для управления Tracking Plan
Tracking plan живёт не в Google Docs. Для продуктов с 2+ разработчиками нужен инструмент с версионированием и валидацией.
Avo. Специализированный инструмент для tracking plan management. Визуальный редактор, автогенерация кода, CI/CD-валидация (проверяет, что отправляемые события соответствуют схеме). Бесплатный план для небольших команд.
Amplitude Data. Встроенный tracking plan в Amplitude. Автоматически детектит отклонения от схемы, показывает unexplained events.
Mixpanel Lexicon. Управление таксономией внутри Mixpanel. Можно скрывать, переименовывать и описывать события без изменения кода.
Google Sheets + Git. Для команд из 1–3 разработчиков: таблица с событиями в репозитории. Дёшево, версионируется, ревьюится через PR.
Мониторинг качества данных после запуска
Tracking plan без мониторинга устареет за месяц. Три метрики для отслеживания:
Schema compliance rate. Процент событий, соответствующих схеме. Цель: 99%+. Если ниже, кто-то добавляет события в обход процесса.
Property fill rate. Процент событий, где обязательные свойства заполнены. plan_name: null в 30% событий Subscription Created указывает на проблему в коде, а не в таксономии.
Event volume anomalies. Резкое падение или рост объёма конкретного события указывает на баг. Стоит настроить алерты на отклонения больше 50% от среднего за 7 дней.
Для мониторинга LLM-систем, включая те, что генерируют события, подходят инструменты observability, описанные в руководстве по Langfuse. Тот же принцип: логировать, версионировать, отслеживать качество.
С чего начать
- Выписать 5–8 ключевых функций продукта. Экраны, которые видит пользователь. Действия, за которые платят.
- Сформулировать 10 бизнес-вопросов. “Где теряем пользователей?”, “Какие фичи используют платящие клиенты?”, “Какой канал привлечения даёт лучший retention?”
- Запустить базовый промпт. Подставить продукт и функции, получить первую версию tracking plan.
- Провалидировать через второй промпт. Найти пробелы, дубликаты, нарушения naming conventions.
- Внедрить 10 событий из acquisition и activation. Не все 30 сразу. Первая итерация: регистрация, онбординг, первое значимое действие, конверсия в платный план.
- Настроить мониторинг. Schema compliance, property fill rate, volume anomalies.
- Добавлять события итеративно. Новое событие только при появлении бизнес-вопроса, на который нельзя ответить текущими данными.
Event taxonomy не разовый проект. Это живой документ, который растёт вместе с продуктом. AI сокращает время проектирования с дней до часа, но governance и мониторинг остаются ответственностью команды.