Как менять названия событий без разрыва истории
Как изменить событие аналитики и сохранить смысл истории: карта старого и нового имени, дата перехода, проверка доставки и защита от двойного учёта.
Переименовать form_submit в lead_created можно одной строкой. Но если первое событие означало клик по отправке, а второе теперь означает запись в CRM, история не стала единой от похожего названия. Изменился измеряемый факт.
В системе аналитики я бы сначала описал контракт события, затем менял имя. Это помогает отделить косметическую миграцию от нового определения результата. Иначе на графике появится скачок, который команда объяснит изменением конверсии.
Составьте карточку события
Запишите условие отправки, место в приложении, обязательные параметры и идентификатор логической операции. Укажите, может ли событие срабатывать несколько раз в одном визите. Если оно зависит от успешного ответа сервера, назовите, что именно подтверждает этот ответ.
| Изменение | Можно ли объединять историю | Что проверить |
|---|---|---|
| Исправление опечатки в имени при прежнем условии | Обычно да, через явную карту | Совпадают параметры и точка срабатывания |
| Клик заменён подтверждённым созданием заявки | Требуется граница определения | Старый показатель не выдан за новый |
| Событие разделено по типам формы | Зависит от нового состава | Не потерялись формы и нет пересечений |
| Добавлен серверный дубль браузерного события | Только с согласованной дедупликацией | Одна операция не считается дважды |
Правило не переписывает прошлое само
Справка GA4 по изменению событий указывает, что новые и изменённые события не применяются к историческим данным. Создание правила и получение первого подходящего события — разные этапы. Поэтому пустое новое имя в настройке ещё не доказывает готовую конверсию.
Сохраните время переключения и версию приложения. Если нужен непрерывный отчёт, добавьте отдельное нормализованное поле, где старое и новое имена сопоставлены по документированному правилу. Оригинальное имя оставьте для диагностики. Не склеивайте разные определения ради ровной линии.
Параллельный период требует защиты от суммы
Иногда старое и новое событие временно отправляются вместе для сравнения. Это полезно только если отчёт не складывает оба как два результата. Создайте отдельную сверку по ID операции и контролируйте расхождения. Одна и та же заявка должна иметь понятную роль в каждом показателе.
Если общего ID нет, совпадение дневных сумм не доказывает соответствия записей. Одни события могли потеряться, другие задвоиться. Начните с ограниченного числа разрешённых тестов и проследите каждый по всей цепочке. Технические повторы разбираются по сценарию двойной отправки.
Четыре проверки вместо одного статуса
- Приложение отправило событие при нужном действии и не отправило при неподходящем.
- Система аналитики получила имя и необходимые параметры.
- Предусмотренное правило конверсии или key event применено к нужному событию.
- Итоговый отчёт учитывает операцию один раз и показывает правильное определение.
После проверки запишите владельца миграции и условия отключения старого имени. Для результата с разными основаниями нужен контракт метрики, для пропавшего источника — проверка CRM-пути. История становится полезной, когда читатель видит, где поменялось поведение аудитории, а где способ измерения.