Проще говоря, схема событий помогает команде говорить на одном языке. Если один разработчик отправляет `signup`, второй `user_registered`, а третий `registration_done`, аналитика быстро превращается в хаос. Воронки ломаются, retention считается неправильно, а AI-агент делает выводы по грязным данным.
Событие обычно отвечает на вопрос “что произошло”. Например: пользователь зарегистрировался, начал оформление заказа, оплатил подписку, открыл чат-виджет, отправил сообщение, посмотрел вебинар или завершил онбординг. Свойства события объясняют детали: тариф, источник, сумма, канал, роль пользователя, платформа, campaign_id, session_id.
Для AI-агента схема событий полезна как контракт данных. Агент может читать события, искать аномалии, объяснять падение конверсии, строить summary метрик, находить проблемные шаги в воронке и предлагать гипотезы. Но если события названы непоследовательно или свойства меняются без версии, агент будет уверенно объяснять неверные цифры.
Схема событий отличается от списка метрик. События - это сырые факты: что случилось. Метрики - это расчеты поверх событий: conversion rate, activation, retention, ARPU, churn, время до первого действия. Сначала нужна понятная схема событий, потом уже надежные метрики.
Схема событий отличается и от tracking plan. Tracking plan чаще включает не только события, но и план внедрения: где в коде отправлять событие, в какой инструмент, кто отвечает, как тестировать и когда выпускать. На практике эти понятия часто идут вместе.
В AI-проектах важно не отправлять все подряд. События должны быть осмысленными, без лишних персональных данных, с понятными правилами хранения и стабильными названиями. Лучше 30 хорошо описанных событий, чем 300 случайных.
Минимальная хорошая запись в схеме: `event_name`, русское описание, trigger, required_properties, optional_properties, property_types, allowed_values, owner, source, destination, pii_flag, retention_days, version, status и пример payload.
Примеры
- Для интернет-магазина событие `checkout_started` отправляется, когда пользователь начал оформление заказа. Обязательные свойства: cart_id, items_count, total_amount, currency, traffic_source.
- В чат-виджете событие `message_sent` фиксирует отправку сообщения посетителем. Свойства: session_id, channel, page_url, has_contact, topic, handoff_required.
- Для вебинара событие `webinar_attended` отправляется после участия. Свойства: event_id, user_id, attendance_minutes, questions_count, lead_type.
- Если команда переименовала `trial_start` в `trial_started` без миграции, retention и activation могут сломаться. Схема событий должна фиксировать версии и deprecated-события.
Где используется
- продуктовая аналитика
- воронки конверсии
- retention и activation
- аналитика интернет-магазина
- события чат-виджета
- вебинары и маркетинговые события
- BI-дашборды
- AI-агент для продуктовых метрик
- контроль качества данных
- согласование событий между продуктом, аналитикой и разработкой
Связанные термины
Частые вопросы
Зачем нужна схема событий?
Чтобы команда одинаково называла события и свойства. Без схемы в аналитике появляются дубли, разные форматы и спорные метрики, которые сложно использовать для решений.
Что должно быть в event taxonomy?
Название события, описание, trigger, обязательные и дополнительные свойства, типы данных, допустимые значения, владелец, источник, место отправки, статус, версия и пример payload.
Чем схема событий отличается от метрик?
События - это сырые факты о действиях пользователя или системы. Метрики считаются поверх событий: конверсия, retention, activation, churn, средний чек и другие показатели.
Можно ли дать AI самому придумать события?
AI может предложить черновик схемы, но финальные названия, свойства и правила отправки должны подтвердить продукт, аналитик и разработка. Иначе агент создаст красивый, но непроверенный словарь.
Какая частая ошибка в схеме событий?
Отправлять слишком много событий без владельца и правил. Еще одна ошибка - менять названия и свойства без версии, из-за чего ломаются воронки, BI-отчеты и выводы AI-агента.
