# План аналитики: события, которые отвечают на вопросы

> Как составить план трекинга от вопросов, а не от кнопок: имена событий, свойства, откуда их отправлять и как не утонуть в каше событий.

Published: 2026-04-30 · Source: https://subxcat.com/ru/articles/tracking-plan · Author: SUBXCAT

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

## Начни с вопросов

План начинается не со списка кнопок, а со списка вопросов, на которые команда хочет регулярно получать ответ. Например:

- сколько новых пользователей доходят до ключевого действия и за какое время;
- где они отваливаются по дороге;
- возвращаются ли они через неделю и через месяц;
- какие каналы приводят тех, кто остаётся;
- чем платящие пользователи отличаются от бесплатных.

Каждое событие в плане должно помогать ответить хотя бы на один из этих вопросов. Если событие ни на что не отвечает, его не нужно добавлять, даже если «потом пригодится». Потом пригодится другое.

## Имена

Договорись о формате один раз и держись его везде. Удобный вариант — объект и действие в прошедшем времени: `project_created`, `invoice_sent`, `plan_selected`. Один регистр, одно время, английские слова, даже если интерфейс на русском: так их проще искать и сортировать.

Чего избегать:

- синонимов: `signup`, `user_registered` и `account_created` для одного и того же;
- имён по интерфейсу: `blue_button_clicked` потеряет смысл, когда кнопка станет серой;
- данных, которые должны быть свойством: `plan_selected_pro` и `plan_selected_basic` вместо одного события с полем `plan`.

## Свойства

Свойства делают одно событие полезным во многих разрезах. У `plan_selected` это тариф, период оплаты, цена. У `invoice_sent` — сумма, валюта, способ отправки и то, первый ли это счёт у пользователя.

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

Не отправляй в аналитику персональные данные: почту, телефон, имя, содержимое сообщений. Достаточно идентификатора пользователя, а связать его с человеком при необходимости можно в своей базе.

## Откуда отправлять

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

С клиента отправляй то, что происходит только в интерфейсе: открытие экрана, шаги онбординга, работу с подсказками.

## Документ

План — обычная таблица, которая лежит там, где её найдут. Для каждого события в ней есть:

- имя и описание в одну строку;
- когда именно оно отправляется;
- свойства и их допустимые значения;
- откуда отправляется — с сервера или с клиента;
- на какой вопрос отвечает;
- кто за него отвечает.

Новое событие сначала появляется в плане, потом в коде. Это кажется бюрократией ровно до первого случая, когда кто-то тратит день на выяснение, чем `checkout_started` отличается от `checkout_begin`.

## Как не утонуть

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

Хороший план трекинга скучный. В нём мало событий, у них понятные имена, и по ним можно ответить на вопросы, ради которых всё затевалось.

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