Как разметить события 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 такие значения режет валидацией, но лучше не отправлять их вовсе.

Разделите клиентские и серверные источники

Показ формы, переход между шагами и клиентская валидация существуют в браузере. Создание аккаунта, получение данных, выдачу доступа и оплату лучше подтверждать сервером.

Для одного сценария допустимы разные события:

• форма оплаты открыта;
• запрос оплаты отправлен;
• платёж подтверждён;
• платёж завершился ошибкой.

Они не дублируют друг друга, потому что описывают намерение, попытку и итоговый факт. Подробный выбор источника разобран в статье серверные и клиентские события.

Добавьте идентификаторы сущностей

Для B2B обычно недостаточно одного actor_id. Событию могут понадобиться:

• user_id для человека;
• account_id для организации или рабочего пространства;
• project_id для предметного объекта;
• event_id или id операции для дедупликации;
• версия схемы.

Один пользователь может работать в нескольких аккаунтах, поэтому контекст аккаунта должен соответствовать конкретному событию. Сценарии входа, выхода и смены контекста описаны в материале об идентификации пользователей.

Версионируйте изменение

Переименование свойства или смена момента срабатывания меняет отчёты. До выпуска:

1. опишите старое и новое определение;
2. задайте версию схемы;
3. определите период совместимости;
4. обновите отчёты;
5. отметьте дату на временных рядах;
6. проверьте несколько реальных сценариев.

Не используйте одно имя для нового смысла без версии.

Проверьте четыре сценария

Минимальный тест включает:

1. успешный путь;
2. ожидаемую ошибку;
3. повторную отправку;
4. смену пользователя или аккаунта.

Для каждого заранее запишите ожидаемую последовательность, затем сравните её с данными. Проверка HTTP-запроса в браузере недостаточна: событие должно пройти приём, хранение и появиться под правильным идентификатором.

Полный контрольный список приведён в статье качество данных продуктовой аналитики.

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