Что такое событие в аналитике и автоматизации

В отделе маркетинга решили отслеживать все. Через месяц в отчете было четыреста видов событий, включая «наведение курсора на логотип», и ни одного – об оплате заказа.

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

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

Из чего состоит событие

Как бы ни называлась система, запись о событии почти всегда содержит одни и те же части:

• Название – что произошло: form_submit, purchase, deal_stage_changed
• Время – с точностью до секунды, а то и миллисекунды
• Субъект – кто это сделал: посетитель, клиент, сотрудник или сама система
• Параметры – подробности: какая форма, какая сумма, с какой стадии на какую
• Контекст – откуда пришел пользователь, с какого устройства, в рамках какого визита

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

События в веб-аналитике

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

В Google Analytics 4 событием считается вообще все, включая просмотр страницы: модель данных целиком построена на событиях и их параметрах. В Яндекс Метрике событие чаще всего становится основой цели – цель типа «JavaScript-событие» срабатывает, когда на странице вызывают метод reachGoal с заданным идентификатором. Разница принципиальная: событие фиксирует факт, а цель – это событие, которое компания объявила важным и по которому оценивает сайт и рекламу.

Отсюда простое правило: не каждое событие должно быть целью. Если выбрать для оптимизации рекламы все подряд, рекламная система с одинаковым усердием будет искать и тех, кто оставит заявку, и тех, кто охотно кликает по логотипу. Вторых, как правило, находить проще.

События в CRM и автоматизации

В CRM событием служит любое изменение данных: создан лид, сделка перешла на новую стадию, пришла оплата, клиент не ответил на письмо, менеджер просрочил задачу. На этих событиях держится вся автоматизация. Правило звучит как «когда произошло одно, сделай другое»: пришла заявка с сайта – назначь ответственного и поставь задачу перезвонить, сделка выиграна – отправь документы в бухгалтерию.

В Битрикс24 такие правила строят на триггерах и роботах: триггер реагирует на событие и переводит сделку или лид на нужную стадию, а робот выполняет действие, когда элемент на эту стадию попал. Механика подробно разобрана в статьях о триггерах и о роботах в Битрикс24.

Между разными системами события передают через вебхуки: система, в которой что-то произошло, сама отправляет запрос по заранее указанному адресу, и вторая узнает о случившемся сразу, без опроса каждые пять минут «ну что, оплатили?». Так обычно устроены уведомления о платежах, новых сообщениях в мессенджерах и изменениях в CRM. Как системы вообще договариваются друг с другом, объясняет термин API.

Событие, цель и конверсия – в чем разница

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

Как размечать события и не утонуть

Хорошая разметка начинается не с кода, а с вопроса: какие решения будут приниматься по этим данным. Если ответа нет, событие лучше не заводить – оно будет исправно копиться, занимать место в отчетах и ничему не служить.

• Составить план событий – таблицу с названием, моментом срабатывания, параметрами и тем, кому и зачем это нужно
• Договориться о названиях – один стиль и никаких синонимов вроде form_send, sendForm и zayavka_ok для одного и того же действия
• Фиксировать факт, а не намерение – «форма отправлена» после успешного ответа сервера, а не по нажатию кнопки, которое могло закончиться ошибкой
• Искать дубли – одно действие, засчитанное дважды, тихо удваивает конверсию и самооценку отдела
• Пересматривать план после каждого редизайна – новая кнопка с другим классом ломает разметку без единого сообщения об ошибке

Отдельный риск – персональные данные. В параметры события по неосторожности легко положить телефон или email из формы, и они уедут в стороннюю систему аналитики. Параметры должны описывать действие, а не человека.

Когда событий слишком много

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

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