Skip to content
  1. Главная
  2. Справочный центр
  3. Разработчикам
  4. Словарь событий — как называть и где ставить вызов

Словарь событий — как называть и где ставить вызов

Обновлено:

Это читают один раз до кода. Правила одинаковы для сайта, приложения и статики: они про то, как событие превращается в метрику, а не про то, каким кодом оно отправлено. Форма вызова — Вызовы счётчика.

Согласуйте словарь до первого вызова

Имя события — не подпись для себя, а адрес, по которому событие потом считается метрикой. Переименование задним числом рвёт историю: старые записи остаются под старым именем, и метрика показывает разрыв там, где ничего не менялось.

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

Назовите событие по правилам адреса

  • Латиница, нижний регистр, слова через _. Двоеточий в имени быть не должно — событие запишется, но посчитать его метрикой будет нельзя.
  • Прошедшее время, что_произошло: report_exported, plan_upgraded, checkout_completed. Не export_report и не click_button.

Различия между случаями кладите в данные, а не в имя

lead_submitted с полем product — а не lead_submitted_basic и lead_submitted_pro.

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

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

Ставьте вызов на подтверждённый факт, а не на клик

  • Сохранение, смена статуса, оплата — событие идёт в успешной ветке ответа сервера. Отказ решением пользователя не является.
  • Успех формы, о котором знает только JS, фактом не является. Надёжнее считать успехом состояние страницы после отправки — то, что человек действительно увидел.
  • Только то, что произошло в браузере. Оплата, подтверждённая на сервере, или ночной пересчёт — не события сайта: у них нет визита.
  • Событие на уходе со страницы может не успеть. Считайте его «по возможности», а надёжный якорь ставьте на принимающей странице: не «нажал оформить», а «открыл страницу оформления». Расхождение между этими двумя числами само себя показывает в отчёте и говорит правду о доставке.

Защитите от повторов то, что перерисовывается

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

  • Ключ «это уже посчитано» держите в sessionStorage: он переживает перезагрузку, но не переносится в новую вкладку.
  • Ключ из данных ответа (например, даты создания записи) не годится: он переживает и вторую попытку, поэтому вторая просто не посчитается.
  • Проверять надо не «нет ли дублей вообще», а «не растёт ли счётчик от повторного показа».

Приводите значения из адреса к списку известных

Всё, что попадает в данные события из query-параметров, сводите к перечню:

var src = new URLSearchParams(location.search).get('from') || '';
var known = ['pricing', 'blog', 'email'];
track('signup_started', { from: known.indexOf(src) !== -1 ? src : 'other' });

Иначе любой, кто откроет адрес с произвольным ?from=, заведёт в разрезе новую строку — и разрез перестанет быть читаемым.

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

Не дублируйте то, что КО заполняет само

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

Просмотры страниц счётчик тоже пишет сам, включая маршруты SPA. Своя подписка на роутер с собственным «просмотр страницы» удваивает просмотры, а не подстраховывает.

Что рядом