План трекинга событий: как сделать разметку событий для аналитики

Автор

Практика продуктовой и маркетинговой аналитики (единого автора нет); описана в документации Segment, Amplitude, Mixpanel и Google Analytics, 2010–2020-е

Уровень

201 · Инструмент

Подходит

стартап, растущая компания

Время на внедрение

День на первый черновик плана для одного раздела продукта; больше — на согласование и внедрение разметки

Что понадобится

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

План трекинга событий — это письменная спецификация разметки: какие действия пользователей сайт или приложение записывает, как называется каждое событие и какие детали оно несёт. Это один общий документ с версиями, а не решение, которое каждый разработчик или маркетолог принимает сам. Единого автора у практики нет. Segment называет документ Tracking Plan и построил вокруг его соблюдения продукт Protocols. Amplitude называет систему названий под ним таксономией. Mixpanel ведёт свой словарь данных под названием Lexicon. Google Analytics 4 предлагает узкую версию той же идеи — список рекомендованных событий с заданными именами и параметрами. В Яндекс Метрике ту же роль играет список целей счётчика. Как бы это ни называлось, команда без плана рано или поздно получает одно и то же: одно действие пользователя записано тремя способами тремя людьми и в каждом отчёте считается как три разных.

Объект и действие, больше ничего

У названия события ровно две рабочие части: общий объект и действие в прошедшем времени. Документация Segment рекомендует для названий Title Case и описывает схему как объект (например, Blog Post) плюс действие (например, Read). Amplitude держится той же идеи с другим регистром — существительное плюс глагол в прошедшем времени, вроде song_played, — и предупреждает, что её система запишет Song Played и song played как два отдельных события. Человеку, который листает отчёт, разница незаметна, а программа считает каждую строку отдельно.

Какой стиль написания выбрать, менее важно, чем выбрать один и соблюдать его везде. План ломается, когда Title Case и snake_case живут для одного действия в двух углах кода.

Параметры несут конкретику

Название события оставляют общим, а всё конкретное передают параметром того же события. В документации Segment есть пример: вместо события Business Tier Workspace Created записывать Workspace Created с параметром account_tier: "business". Событие остаётся одной строкой, которую отчёт считает, а деталь живёт в поле, по которому отчёт фильтрует. Для клиники это выглядит так: одно событие Appointment Requested, а направление, филиал и врач — параметрами.

Та же дисциплина касается ключей параметров. Segment предупреждает против динамически создаваемых ключей вроде feature_1: "true", feature_2: "false": каждый новый ключ становится новой колонкой во всех системах дальше по цепочке и засоряет отчёты полями, которые никто не определял.

В Яндекс Метрике событие с сайта отправляют методом reachGoal, а идентификатор цели заранее создают в настройках счётчика как цель типа «JavaScript-событие»; дополнительные данные передаются параметрами визита. Если проект ведёт и Метрику, и GA4, в плане удобно держать одну строку на событие и две колонки: идентификатор цели в Метрике и имя события в GA4.

Один владелец, одна версия, один документ

У плана трекинга должен быть ровно один человек, который утверждает добавления. Документация Snowplow описывает план как логические группы связанных бизнес-событий с определённым владельцем, а руководство Mixpanel по внедрению привязывает рабочий план к этапу управления данными, у которого есть ответственный. До появления специальных инструментов, как пишет сам Segment, планы жили в таблицах и служили инструментом, который выравнивает всю компанию вокруг данных. Таблице или её современной замене нужны две вещи из репозитория кода: номер версии и журнал изменений. Тогда отчёт, построенный в марте, можно сверить с планом, который действовал в марте.

План трекинга и словарь данных звучат одинаково, но отвечают на разные вопросы.

Проверка до релиза

Новое или изменённое событие сверяют с планом до того, как оно попадёт на рабочий сайт. Segment Protocols проверяет живые события по плану и помечает нарушение сразу, когда событие не совпало. Руководство Mixpanel требует тестирования и аудита разметки перед широким запуском. В GA4 для той же проверки есть DebugView и отчёт «В реальном времени»: параметры нового события видны по мере поступления, не нужно ждать завтрашнего отчёта.

Ставки хорошо видны по исследованиям экспериментов, построенных на тех же записанных событиях. Книга Кохави, Тан и Сюй о надёжных онлайн-экспериментах и рецензируемая работа о расхождении долей выборки (sample ratio mismatch — когда в группах теста оказалось не столько пользователей, сколько ожидалось) описывают одну проблему: число мало что значит, если никто не может точно сказать, что оно посчитало. План трекинга — самое дешёвое место, где эту проблему можно поймать.

Здесь план и окупается. Анализу воронки нужно, чтобы каждый шаг был записан под одним именем на всём пути. План не даёт «Payment Started» превратиться на середине пути в «payment_started» и незаметно сломать подсчёт конверсии между шагами.

Персональные данные и согласие

Разметку нужно согласовать с законом о персональных данных. Российский закон № 152-ФЗ относит к персональным данным любую информацию, относящуюся к прямо или косвенно определённому или определяемому человеку (статья 3). Сведения о состоянии здоровья закон относит к специальным категориям, обработка которых не допускается, кроме случаев, перечисленных в статье 10, например письменного согласия. Для клиники практический вывод простой: в плане рядом с каждым параметром отметьте, может ли он раскрыть что-то о здоровье пациента, и не передавайте в Метрику и GA4 диагноз, жалобу или направление к врачу узкого профиля.

Если сайт работает и на аудиторию из ЕС или Великобритании, там действует отдельное правило о согласии: директива ePrivacy требует согласия на запись и чтение информации на устройстве пользователя, британский регулятор ICO применяет такое же правило, а Европейский совет по защите данных в руководстве 2024 года подтвердил, что это касается cookie, пикселей и SDK для аналитики, а не только для рекламы. Этот раздел пересказывает общие нормы и не заменяет юридическую проверку конкретного сайта.

Ничто из этого не отменяет решения о том, что отслеживать вообще. План с пятьюдесятью событиями, за которыми не стоит ни одного бизнес-вопроса, — тот же мусор, только с аккуратными названиями. Свяжите его с отчётами, ради которых он создан, и пересматривайте в том же ритме, что и работу по Marketing-Operational System. Тогда отчёт полугодовой давности сравним с отчётом этой недели: оба построены на одних определениях.

Как применять: План трекинга событий: как сделать разметку событий для аналитики по шагам

1. Выпишите действия, которые важны. Начните с вопросов бизнеса, на которые команде действительно нужен ответ, а не со всех кликов, которые можно записать. Каждому вопросу сопоставьте одно-два действия пользователя, которые на него отвечают: регистрацию, оплату, подтверждённую запись на приём. На первом проходе этого достаточно.
2. Называйте событие как «объект + действие». Выберите один порядок, сначала объект, потом действие, и один стиль написания, и держите все события в этом формате. «Account Created» и «account created» для большинства систем аналитики — два разных события, хотя человек в отчёте считает их одним.
3. Детали — в параметры, а не в название. Название события оставьте общим, а всё конкретное, тип услуги, филиал, канал, передайте параметром того же события. Если название меняется под каждый вариант, оно размножается в десятки почти одинаковых строк, по которым невозможно построить чистый отчёт.
4. Назначьте владельца и ведите один документ с версиями. Один человек утверждает добавления и изменения. План лежит там, где его видят все, кто работает с данными: в таблице или в специальном инструменте, с номером версии и журналом изменений.
5. Сверяйте новую разметку с планом до релиза. Новое или изменённое событие проверяют по плану на код-ревью или автоматически по схеме, до того как оно попадёт на рабочий сайт. Событие, проскочившее без проверки, через несколько недель тихо ломает отчёт.
6. Подключите план к отчётам, ради которых он создан. Анализ воронки, дашборды и эксперименты стройте на событиях из плана, а сам план обновляйте сразу, как только меняется продукт. План, который никто не перечитывает, быстро расходится с тем, что продукт делает на самом деле.

Примеры

Заявки с лендинга медицинского центра

Иллюстративный пример. Медицинский центр ведёт рекламу услуги в Яндекс Директе на отдельный лендинг. В плане три события: «Appointment Form Viewed», «Appointment Form Submitted» и «Callback Requested», у каждого параметры service_type и branch. В Яндекс Метрике под них настроены цели типа «JavaScript-событие», в GA4 — события с теми же именами. Маркетолог и колл-центр видят одну и ту же воронку, а не девять почти одинаковых событий, разбросанных по разным формам.

Онлайн-запись клиники

Иллюстративный пример. Виджет записи клиники отслеживает «Appointment Slot Viewed», «Appointment Requested» и «Appointment Confirmed» с параметрами doctor и appointment_type. План ведёт управляющий клиникой, он же согласует любое новое событие. Слабая неделя видна как меньшее число «Appointment Requested», а не как смесь по-разному названных событий в коде двух филиалов. Диагнозы и жалобы пациента в параметры событий не передаются.

Когда применять

Используйте план, как только с разметкой работает больше одного человека — продукт, разработка или маркетинг, — или как только отчёту нужно сравнивать одно и то же действие между релизами, сайтом и приложением, Метрикой и GA4. Составляйте его до начала разметки, а не после того, как дашборд начал показывать странные цифры.

Когда не применять

Не формализуйте план для прототипа, который делает один человек, с одним-двумя разовыми событиями: накладные расходы выше пользы, пока не появился второй участник или второй отчёт на этих данных. План также не заменяет решение о том, какие вопросы важны. Без бизнес-вопроса за каждым событием он превращается в «записываем всё, не анализируем ничего».

Частые ошибки

• Каждая команда называет одно действие по-своему — «Sign Up», «signup», «User Signed Up», — и один шаг воронки в отчёте распадается на три несвязанные строки.
• Новое событие на каждый вариант действия вместо параметра: «Business Tier Workspace Created» и «Free Tier Workspace Created» дробят то, что должно быть одним «Workspace Created» с параметром account_tier.
• Изменения разметки уходят в релиз без сверки с планом, и переименованный параметр ломает дашборд за несколько недель до того, как кто-то найдёт причину.
• План воспринимают как разовый документ без версий, и он до сих пор описывает экран, который переделали два релиза назад.
• В параметры событий передают сведения о здоровье пациента — диагноз, жалобу, направление — и проблема качества данных становится проблемой закона о персональных данных.

Вопросы и ответы

Что такое план трекинга событий?

План трекинга событий — это спецификация разметки, обычно версионированная таблица. В ней перечислены все действия пользователя, которые фиксирует сайт или приложение, название каждого события, его параметры и ответственный за определение. Segment, Amplitude и Mixpanel описывают эту практику каждый в своей документации. Новое событие сверяют с планом до релиза, а не придумывают на ходу.

Что должно быть в плане разметки событий?

Каждая строка описывает одно событие в формате «объект + действие», его параметры и их типы, владельца определения и версию. В документации Segment советуют начинать с короткого списка событий, привязанных к реальным целям бизнеса, а не записывать каждый возможный клик.

Кто должен отвечать за план трекинга?

Один названный человек или команда, а не группа по очереди. В руководстве Mixpanel по внедрению рабочий план связан с этапом управления данными, у которого есть владелец и аудит до широкого запуска. Без владельца названия расползаются, и дубли событий появляются раньше, чем кто-то заметит странный отчёт.

Как разметка событий работает в Яндекс Метрике и GA4?

В Яндекс Метрике событие с сайта передаётся методом reachGoal, а идентификатор цели заранее настраивают в интерфейсе счётчика как цель типа «JavaScript-событие»; детали можно передать параметрами визита. В GA4 событие отправляют с параметрами напрямую, а для типовых действий Google предлагает список рекомендованных событий. Один план может описывать обе системы.

Чем план трекинга отличается от словаря данных?

План трекинга пишут до разметки или во время неё: он определяет, что нужно отслеживать. Словарь данных — в Mixpanel он называется Lexicon — описывает то, что уже приходит в систему, задним числом. Одни команды ведут один документ на обе роли, другие держат оба и сверяют их по графику.

Источники

1. Twilio Segment, Protocols Tracking Plan
2. Twilio Segment, Data Collection Best Practices
3. Twilio Segment, Best Practices for Event Calls
4. Twilio, Naming conventions: why you need them for clean data
5. Amplitude, Plan your taxonomy, Amplitude Docs
6. Amplitude, What Are the Components of Event Data
7. Mixpanel, Lexicon: Describe your events and data using a dictionary, Mixpanel Docs
8. Mixpanel, Establish Data Governance, Onboarding Playbook
9. Mixpanel, Build Your Tracking Strategy, Onboarding Playbook
10. Snowplow, Introduction to tracking design, Snowplow Documentation
11. Avo, Naming conventions, Avo Docs
12. Google, [GA4] Recommended events, Analytics Help
13. Google, [GA4] Event parameters, Analytics Help
14. Google, About events, Analytics Help
15. Google for Developers, Set up events [GA4]
16. Google for Developers, Set up event parameters [GA4]
17. Яндекс Метрика, Справка: метод reachGoal (отправка достижения цели)
18. Ron Kohavi, Diane Tang, Ya Xu, Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing, Cambridge University Press, 2020
19. Aleksander Fabijan, Jayant Gupchup, Somit Gupta, Jeff Omhover, Wen Qin, Lukas Vermeer, Pavel Dmitriev, Diagnosing Sample Ratio Mismatch in Online Controlled Experiments, KDD 2019
20. MIT Sloan Management Review, How to Get Proactive About Data Quality
21. Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных», статья 3, КонсультантПлюс
22. Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных», статья 10, КонсультантПлюс
23. European Parliament and Council, Directive 2002/58/EC (ePrivacy Directive), Article 5, Official Journal via EUR-Lex
24. European Data Protection Board, Guidelines 2/2023 on the Technical Scope of Article 5(3) of the ePrivacy Directive, v2.0
25. Information Commissioner's Office (ICO), Cookies and similar technologies, Guide to PECR

Обновлено 1 октября 2026

Илья ПушинОснователь PUSHERS & COO Fintech ServiceИлья строит операционные системы для растущих компаний в медицине и финтехе. С 2021 года руководит трансграничными платежами в ARBI Exchange, лицензированном обменнике в Таиланде, включая KYC, AML и выход в новые юрисдикции.Об автореLinkedIn