Как разметить события B2B SaaS: шаблон из 14 событий

Команды обычно ошибаются в одну из двух сторон: либо трекают всё подряд и тонут в мусоре, либо ставят «просмотр страницы» и останавливаются. Ниже — пример из 14 событий для пути от регистрации до отмены подписки. Это отправная точка, а не универсальная схема: состав и смысл событий нужно адаптировать к модели конкретного SaaS.

Регистрация и онбординг

• signup_started — пользователь открыл форму регистрации. Вместе с signup_completed даёт конверсию самой первой воронки.
• signup_completed — аккаунт создан. Может быть точкой отсчёта для когорт по регистрации; для когорт по активации или оплате нужна другая стартовая точка.
• onboarding_step_completed — пройден шаг онбординга, номер шага — в свойствах. Показывает, где именно новички сходят с дистанции.

Активация и команда

• project_created — создана первая рабочая сущность. Это возможный кандидат на событие активации, если команда проверила, что он действительно отражает первую ценность продукта.
• invite_sent — отправлено приглашение коллеге. Может быть ранним сигналом командного сценария, но само по себе не доказывает активацию.
• invite_accepted — приглашение принято. Пара sent/accepted — воронка вирального роста внутри компаний.
• key_action_performed — условное имя для действия, которое команда определила как важное именно для своего продукта: запуск сборки, отправка рассылки или проведение сделки. Оно может входить в определение активации после проверки на данных.

Ценность

• report_created — создан отчёт. Считать это получением ценности можно только тогда, когда отчёт действительно является результатом целевого сценария продукта.
• report_shared — отчётом поделились. Событие помогает проверить гипотезу о командном использовании; его связь с удержанием нужно измерять, а не предполагать заранее.

Деньги

• trial_started — начался триал. От него считаются конверсия в оплату и длина цикла сделки.
• paywall_viewed — пользователь упёрся в платную функцию. Карта таких событий подсказывает, что двигать в тарифах.
• checkout_started — открыта страница оплаты. Разрыв между ней и оплатой — прямые потери денег.
• payment_succeeded — биллинг подтвердил успешную оплату. Такое событие лучше отправлять с сервера или из доверенного платёжного контура.
• subscription_cancelled — подписка отменена. Для расчёта churn команда должна отдельно определить единицу анализа и момент оттока: отмена, окончание оплаченного периода и потеря пользователя — не всегда одно и то же.

Три правила для свойств

1. Словарь до кода. Имена и типы свойств фиксируются в одном документе раньше, чем попадают в код: plan: "growth" и plan_name: "Growth" в соседних событиях — это навсегда два разных поля.
2. Контекст, а не вычисления. Кладите то, что нельзя восстановить позже: тариф, роль, источник. Всё, что считается из других событий, в свойствах не нужно.
3. Никаких ПДн. E-mail и телефонам в свойствах не место — пользователя идентифицирует actor_id. Наш ingest такие значения режет валидацией, но лучше не отправлять их вовсе.

Этот список — пример, а не потолок. Перед внедрением зафиксируйте словарь, источники и критерии проверки данных. Чек-лист подготовки и параллельного перехода есть на странице миграции.