Трекинг-план · Продуктовая аналитика · Data Governance · PTOS

Трекинг-план как продуктовый контракт: почему аналитика начинается до Build

Объясняем, почему разработка трекинг-плана и словаря данных должна происходить до начала Build, чтобы обеспечить измеримость изменений и избежать 'споров после факта'.

Трекинг-план как продуктовый контракт: почему аналитика начинается до Build

«Сделали фичу, метрики потом» — это одна из самых дорогих ошибок, которую может совершить продуктовая команда. Если аналитика и события для измерения (instrumentation) добавляются «после факта», фаза Evaluate превращается в гадание, а весь цикл обучения — в фикцию.

В методологии PTOS Трекинг-план (Tracking Plan) — это не техническая задача для аналитика или разработчика. Это продуктовый контракт, который создаётся до начала фазы Build и гарантирует, что любое изменение будет измеримым.

Почему «трекинг потом» — это смертный грех продукта?

1. Вы не сможете провести честный Evaluate. У вас просто не будет данных, чтобы ответить на главный вопрос: «Изменилось ли поведение?».
2. Вы будете принимать решения вслепую. Без данных любой «разбор полётов» превращается в спор о мнениях, где побеждает самый громкий голос (HiPPO).
3. Это порождает технический долг. Добавление аналитики задним числом — это всегда сложнее, дороже и с большим количеством ошибок.

Что такое Трекинг-план?

Трекинг-план — это живой документ, который описывает, какие действия пользователя мы отслеживаем, как мы их называем и, самое главное, на какой бизнес-вопрос каждое событие помогает ответить. Это «единый источник правды» для продуктовой команды, инженеров и аналитиков.

Как отмечает Amplitude, ведущие продуктовые команды формализуют трекинг-план как «живой документ», определяющий, что, зачем и откуда трекается, и создают taxonomy (события, свойства, конвенции).

Ключевые компоненты Трекинг-плана («Словарь данных»)

Хороший трекинг-план должен отвечать на три ключевых вопроса:

1. Пользуются ли фичей?
2. Где пользователи застревают?
3. Что сломалось или ухудшилось?

Для этого по каждой новой фиче составляется «словарь» из 10–20 ключевых событий. Каждое событие в этом словаре должно иметь «паспорт»:

1. Действие пользователя: Что именно пользователь делает в интерфейсе?

   • Пример: Нажимает на кнопку «Сохранить отчёт».

2. Название события (Event Name): Как мы называем это действие в нашей аналитической системе. Название должно быть однозначным и следовать единой конвенции (например, Object_Action).

   • Пример: report_saved.

3. Свойства (Properties): Какой дополнительный контекст нам важен для анализа? Это позволяет сегментировать данные.

   • Пример: report_type: 'standard', user_segment: 'enterprise', previous_screen: 'editor'.

4. Триггер: В какой именно момент отправляется событие?

   • Пример: Сразу после успешного ответа от сервера о сохранении.

5. Бизнес-вопрос: На какой вопрос помогает ответить это событие? Это самый важный пункт, который связывает техническую реализацию с продуктовым смыслом.

   • Пример: «Как часто пользователи из разных сегментов сохраняют отчёты разных типов?».

Трекинг-план как часть Definition of Done для Build

В PTOS фаза Build считается завершённой не тогда, когда «код написан», а когда выполнено несколько условий, и одно из ключевых — готовность к измерению.

• DoD для Build:
  • Трекинг-план/словарь событий готов.
  • События реализованы в коде.
  • Данные реально приходят на стейджинговом или тестовом окружении (а не «должны приходить»).

Только при выполнении этих условий можно переходить в фазу Launch.

Вывод

Перестаньте относиться к аналитике как к чему-то, что можно «прикрутить потом». Трекинг-план — это не задача для аналитика, а продуктовый артефакт, за который отвечает продакт-менеджер.

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