120 или 85 регистраций? Словарь событий SaaS, без которого воронке нельзя верить

Проблема, которую не решить красивым дашбордом

Сервис показывает 120 регистраций в понедельник и 85 во вторник. Похоже на падение. Но, возможно, в понедельник signup отправлялся дважды: при нажатии на кнопку и после ответа API. Пока команда не договорилась, что означает каждое событие, любой график можно читать как угодно.

Поэтому перед воронкой нужен небольшой словарь событий — документ, в котором каждому имени соответствует одно действие в продукте. Ниже — из чего он состоит и промпт, который соберёт черновик под твой продукт.

Какие события нужны небольшому SaaS

Для первого рабочего варианта достаточно 6–10 событий. Не надо сразу отслеживать каждый клик.

Событие	Что считается фактом
signup_started	Пользователь открыл первый шаг регистрации и начал вводить данные
signup_completed	Сервер подтвердил создание учётной записи
workspace_created	Создано первое рабочее пространство
first_value_reached	Пользователь выполнил главное полезное действие продукта
checkout_started	Начат процесс оплаты
subscription_activated	Сервер подтвердил активацию подписки

Названия здесь даны для примера. Важно, чтобы смысл совпадал с тем, как устроено твоё приложение. Не заменяй подтверждение оплаты кликом по кнопке «Оплатить».

Контракт события

У каждого события должны быть как минимум:

• Имя: уникальное и стабильное, например workspace_created.
• Определение: точный момент, когда событие должно возникать.
• Источник: браузер, сервер или биллинг; данным сервера обычно доверяют больше.
• Идентификатор: user_id или анонимный anonymous_id и правило, как связать их после входа.
• Время: UTC timestamp и правила для запоздавших событий.
• Контекст: допустимые свойства, например тип тарифа или версия интерфейса.
• Защита от дублей: уникальный event_id и что делать, если событие пришло повторно.
• Владелец: кто отвечает за качество и изменение определения.

Пример JSON — иллюстрация, не данные реального продукта:

{
  "event_id": "evt_example_001",
  "event_name": "workspace_created",
  "event_version": 1,
  "user_id": "user_demo_17",
  "workspace_id": "workspace_demo_3",
  "occurred_at": "2026-10-01T12:00:00Z",
  "source": "backend"
}

В событиях не должно быть паролей, токенов, текста личной переписки или полных платёжных реквизитов. Идентификаторы для аналитики должны соответствовать твоей политике конфиденциальности.

Как не сломать аналитику при обновлении

Не меняй смысл старого события молча. Если first_value_reached раньше означал создание проекта, а теперь — публикацию проекта, старые и новые цифры уже нельзя сравнивать. Заведи новую версию события или новое имя и запиши в журнал изменений дату и причину.

Не смешивай клиента и сервер без правил. Браузер может повторить событие или не отправить его из-за блокировщика. Регистрацию и оплату надёжнее считать по данным сервера.

Проверяй тестовыми цепочками. Создай 3–5 тестовых пользователей, пройди регистрацию, повторный вход, незавершённую регистрацию, отменённую оплату. Сравни, какие события пришли, с тем, что записано в словаре.

Промпт: словарь событий по описанию продукта

Заполни скобки и вставь в любой ИИ-чат. Если продукт собираешь в Claude Code или Cursor, дай промпт агенту прямо в проекте: он сам посмотрит, какие события уже отправляются.

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

О продукте:
— что делает продукт: [одно-два предложения];
— как пользователь в него попадает и регистрируется: [шаги];
— главное полезное действие, момент, когда продукт впервые принёс пользу: [например, создал первый отчёт];
— как устроена оплата: [бесплатно / пробный период / подписка, через какой сервис];
— какие события уже отправляются: [список или «пока ничего»].
…

Черновик от ИИ ещё нужно проверить. Покажи его тому, кто пишет код, и пройди по тестовым сценариям из конца ответа.

Что сделать за один вечер

1. Запиши одно главное пользовательское действие — момент, когда продукт впервые принёс пользу.
2. Собери черновик словаря промптом выше: не больше десяти событий до и после этого момента.
3. Для каждого события проверь условие срабатывания и назначь ответственного.
4. Прогони пять тестовых сценариев и проверь дубли.
5. После этого строй воронку через промпт диагностики регистрации.

Словарь событий — нулевой шаг перед маршрутом из 10 AI-проверок SaaS. Без него воронка и A/B-тесты опираются на цифры, которым нельзя верить.

Чек-лист самопроверки

• Два разработчика независимо одинаково объясняют смысл каждого события.
• Подтверждение с сервера не дублируется событием из браузера, которое считают ещё одной конверсией.
• Для каждого события понятно, что делать с повтором.
• Смысл старых метрик не меняется без новой версии.
• В события не попадают секреты и лишние личные данные.

Результат: короткий словарь, по которому любой в команде одинаково понимает каждую цифру в воронке. Анализ таблицы нужен позже: он разбирает уже собранные данные, а словарь не даёт собрать их неправильно.

Частые вопросы