Как проверить передачу UTM-меток из всех модальных и обычных форм сайта

Исходное требование перечисляет пять UTM-полей и все лид-формы, включая модальные. В этой статье речь о полноте покрытия, а не о выборе воронки по маркеру и не о расследовании одного потерянного поля. Учебные значения условны, реальные рекламные токены, контакты и посетительские идентификаторы не используются.

Зафиксировать пять проверяемых значений

В базовый реестр входят utm_source, utm_medium, utm_campaign, utm_content и utm_term. Официальная справка Google Analytics описывает назначение ручных параметров кампании. Для теста каждому задают отличающееся безопасное значение, чтобы перестановку полей было видно. Одинаковое слово во всех пяти колонках скрывает ошибочное сопоставление.

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

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

Составить реестр форм

Перечислите каждую независимую конфигурацию: встроенная форма, модалка товара, форма под статьёй, нижний блок, обратный звонок и другие реальные точки. Укажите сайт, язык, компонент и обработчик. Одинаковый дизайн не означает общий путь передачи. Реестр должен позволять понять, какую форму уже проверили, а какая лишь похожа на неё.

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

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

Определить источник и срок жизни меток

Метки могут читаться из текущего URL, сохраняться в состоянии визита или приходить из интеграции аналитики. Назовите источник истины и приоритет. Если один скрипт пишет поля из адреса, а другой восстанавливает старое значение, результат будет зависеть от порядка выполнения. Нужен согласованный механизм, а не несколько независимых подмен.

Структурированный разбор URL, например URLSearchParams, помогает получить значения без ошибок ручного деления строки. Но он не решает, какое значение актуально, и не делает вход доверенным. Проверьте повторяющиеся ключи, кодирование и допустимую длину. Политика неоднозначности должна быть явной, особенно когда разные библиотеки выбирают первое или последнее вхождение.

Срок хранения и область должны соответствовать модели сайта. Переход между страницами, новый визит и другая витрина могут менять контекст. Не сохраняйте метки бессрочно ради удобства теста. В учебной матрице указывают ожидаемый результат для каждого состояния. Реальные cookie и рекламная история посетителя в публичный пакет не попадают.

Проверить обычную форму

Откройте учебный URL с пятью разными значениями и найдите форму, которая присутствует сразу. Сверьте доступное состояние компонента, фактическое тело запроса и сохранённый результат. Эти три уровня показывают, где теряется поле. Не ограничивайтесь просмотром скрытого input: обработчик может собирать другой объект и не включать его.

Используйте синтетические контактные данные и разрешённый тестовый маршрут. Подготовка статьи не требует отправки реальных сообщений клиентам. Если нет доступа к принимающей CRM, отмечайте конечную сверку как недоступную, а локальные этапы проверяйте отдельно. Нельзя выдавать правильный сетевой JSON за доказательство заполненного поля CRM.

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

Проверить модальное окно

Откройте диалог после загрузки страницы и сравните пять значений. Затем закройте его и откройте снова. Если компонент пересоздаётся, он должен получить текущий разрешённый контекст, а не пустые поля или старую копию первого открытия. Несколько обработчиков не должны добавляться при каждом показе и отправлять одну заявку несколько раз.

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

Если содержимое диалога загружается асинхронно, проверьте медленный ответ и быстрое повторное открытие. Поздний ответ прежней формы не должен перезаписать актуальный набор. Учебная проверка с отличающимися значениями помогает увидеть гонку. Не нужно создавать искусственную историю реального посетителя: безопасных условных наборов достаточно.

Проверить переходы и возврат

После первого открытия перейдите на другую страницу без меток в URL и отправьте форму по согласованной модели хранения. Ожидаемый результат должен быть известен заранее. Если метки должны сохраняться в визите, проверьте их наличие; если нет, убедитесь, что старые значения не подставились. Тест не выбирает маркетинговую политику, а подтверждает её реализацию.

Затем выполните новый переход с другим учебным набором. Определите, должен ли он заменить прежний источник или сохраняться по другому правилу. Проверьте возврат назад и повторное открытие модалки. Браузерное восстановление страницы и текущее состояние хранилища могут различаться, поэтому видимые поля не всегда отражают то, что реально уйдёт в запросе.

Для группы сайтов проверьте границы отдельно. Не предполагается, что метки одной витрины должны автоматически переходить на другую. Если такой механизм нужен, он должен быть согласован и проверен. Статья не предлагает расширять cookie или обмениваться данными между доменами без необходимости. Здесь важна точность выбранной области.

Заполнить учебную матрицу покрытия

Матрица должна содержать ожидаемый и фактический результат, а не только отметку «форма открылась». В рабочем документе можно использовать сокращения S/M/C/O/T для пяти полей, сохранив словарь. Для каждой строки укажите этап проверки: запрос сайта или конечная CRM. Это не позволяет смешать локально подтверждённую передачу с непроверенным внешним сохранением.

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

Обработать пустые и частичные значения

Проверьте все пять полей по отдельности. Наличие только utm_source не должно заставлять код выдумывать остальные. Если принимающая система ожидает пустую строку, отсутствие ключа или null, это определяется контрактом. Разные формы должны использовать один согласованный способ, чтобы отчёты не считали технические различия разными источниками.

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

Значения не должны исполняться как HTML в интерфейсе или журнале. Рекламный параметр остаётся входными данными. Для публичной демонстрации используйте нейтральные строки, а не настоящие токены. Полный набор UTM не является разрешением сохранять всю адресную строку со служебными и чувствительными параметрами.

Проверить кодирование значений

Добавьте учебное значение с пробелом и разрешёнными неASCII-символами, если такие метки используются проектом. Сравнивайте смысл после штатного декодирования, а не буквальное совпадение закодированной строки в URL и текста в CRM. Ручное разделение по символам может обрезать значение или превратить часть его содержания в другой параметр. Штатный парсер уменьшает этот риск, но требует проверки на границах.

Отдельно проверьте перенос через скрытое поле и JSON. На каждом этапе должен быть один понятный формат, без повторного кодирования уже подготовленной строки. Если в CRM появились служебные последовательности вместо обычного текста, найдите, где произошло лишнее преобразование. Не исправляйте конечное поле глобальной заменой символов: это способно повредить законные значения других кампаний.

Сверить CRM и наблюдение

В разрешённой учебной записи найдите каждое поле и сравните с отправленным набором. Проверьте, что source не записался в medium и что content/term не исчезли в старом сопоставлении. Успешная интеграция может создавать запись, но игнорировать неизвестное поле. Только чтение сохранённого результата подтверждает конечный этап.

Если CRM нормализует значения или использует собственную атрибуцию, определите границу ответственности. Не считайте любое отличие ошибкой формы, пока не проверен принимающий слой. Но и не объясняйте пропуск «особенностью аналитики» без документации. Рабочая карта должна показывать первый этап расхождения и конкретную гипотезу для проверки.

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

Оставить проверку для следующих изменений

После стабилизации сохраните небольшой набор сценариев: первый визит, повторная модалка, переход, пустые значения и новый набор. Тесты должны проверять контракт передачи, а не только наличие конкретных имён input в шаблоне. Если механизм общий, его проверяют один раз глубоко, а подключение каждой конфигурации подтверждают по реестру.

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

В итоговой заметке укажите источник, срок, список полей и реальный статус конечной сверки. Для каждой формы отдельно отметьте пять значений в фактическом запросе и пять сохранённых значений CRM. Если последняя проверка недоступна, оставьте соответствующие ячейки непроверенными. Готовность подтверждается покрытием всех точек и правильным сопоставлением полей, а не одним успешным набором скрытых input.

Документация и источники

• Google Analytics: параметры кампании: Назначение стандартных ручных UTM-параметров; правила хранения сайта задаются отдельно
• MDN: URLSearchParams: Разбор значений URL без самодельного деления строки