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

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

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

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

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

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

Имена

Договорись о формате один раз и держись его везде. Удобный вариант — объект и действие в прошедшем времени: 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 помогает составить план трекинга под вопросы конкретного продукта и встроить события так, чтобы им можно было доверять.