Передача UTM-меток в CRM: источник обращения и сохранение истории

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

Чтобы этого не произошло, заранее определите поля, владельцев данных и правила изменения атрибуции. В этом руководстве используется модель first touch + last non-direct: первая допустимая недиректная атрибуция остаётся неизменной, а последняя меняется только после нового визита с допустимыми UTM. Канал последнего визита хранится отдельно. Это правило помогает проследить источник одного обращения, но не заменяет полноценный отчёт по продажам.

Какую задачу решает этот процесс

Маркетологу нужно понять, из какой кампании пришёл человек. CRM-аналитику — увидеть, как это значение попало в обращение и почему оно изменилось или осталось прежним. Для этого система должна связать четыре объекта:

1. размеченный переход на посадочную страницу;
2. визит с отдельным visit_id;
3. отправку формы или передачу из мессенджера;
4. обращение с устойчивым lead_external_id и полями атрибуции в CRM.

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

Граница задачи узкая. Здесь мы проверяем сохранность атрибуции между сайтом, формой или мессенджером и CRM. Выручка, сделки, расходы и сводные показатели относятся к автоматизации CRM-отчётов. Наличие UTM в карточке само по себе не доказывает влияние рекламы на продажу.

Какие данные и правила подготовить

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

Короткий синтетический образец без клиентских данных:

landing_url=https://example.test/offer?utm_source=search&utm_medium=cpc&utm_campaign=campaign_a
visit_id=v-001
lead_external_id=L-001
contact_value=test-user@example.test
consent_status=granted
transfer_channel=form

Адрес example.test, названия кампании и все идентификаторы здесь условные. Это учебные данные, а не запись клиента или результат внедрения Switch On AI.

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

Какие метки сохранять и где

UTM в URL, сессия, cookie и поле CRM — не одно и то же.

• URL содержит входные параметры кампании. Официальная документация Google Analytics описывает utm_source, utm_medium, utm_campaign, utm_content и utm_term как параметры специальных URL. Она подтверждает назначение этих меток для данных кампаний, но не гарантирует их автоматическую запись в CRM.
• Сессия или визит получает собственный visit_id. Он связывает событие входа с дальнейшими действиями в пределах принятого правила.
• Cookie или серверное хранилище может связывать разрешённые визиты одного браузера. Способ и срок хранения зависят от архитектуры и правил работы с данными.
• CRM-поля содержат атрибуцию конкретного обращения: отдельно first touch, last non-direct и последний канал визита.

Используйте whitelist — закрытый список разрешённых параметров:

utm_source
utm_medium
utm_campaign
utm_content
utm_term

Не переносите автоматически произвольные параметры строки запроса. В URL не должны попадать телефон, электронная почта, ФИО, свободный комментарий и другие персональные данные. Даже если форма умеет читать строку запроса, это не делает такой способ передачи подходящим.

Для каждого разрешённого значения задайте одинаковую нормализацию:

1. декодировать значение один раз;
2. убрать пробелы по краям;
3. привести служебные значения к согласованному регистру;
4. проверить допустимые длину и набор символов;
5. сохранить нормализованное значение либо null с кодом причины.

Пустая или повреждённая метка получает null и, например, код invalid_or_empty. Нельзя превращать её в source=direct: отсутствие допустимой метки и прямой визит — разные факты. Исходный landing_url, если его хранение разрешено, держите отдельно от нормализованных полей. Это позволяет разобрать ошибку, не подменяя рабочие значения необработанной строкой.

Как связать первый и повторный визит

Согласуйте модель до разработки. В этой статье:

• first touch — первая по времени допустимая недиректная атрибуция;
• last touch — последняя по времени допустимая недиректная атрибуция, то есть last non-direct;
• last visit channel — канал самого позднего визита, включая прямой;
• источник обращения — снимок выбранных атрибуционных полей, связанный с конкретным lead_external_id.

Поля first_* заполняются при первой валидной записи и после этого не меняются. Поля last_* меняются только при новом визите с допустимыми UTM. Прямой возврат без меток может установить last_visit_channel=direct, но не стирает last_* и не заменяет источник уже созданного обращения.

Такое разделение отвечает на два разных вопроса. last_visit_channel показывает, как человек пришёл в последний раз. last_source и last_campaign показывают последнюю известную недиректную атрибуцию по принятой модели. Если хранить всё в одном поле, прямой возврат сотрёт кампанию либо система назовёт прямым визит, для которого канал на самом деле неизвестен.

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

Как проверить форму, редиректы и мессенджеры

Ниже — учебная последовательность будущей проверки, а не заявление о выполненном тесте в конкретной CRM.

1. Откройте синтетическую ссылку с разрешёнными UTM и зафиксируйте ожидаемый visit_id.
2. Отправьте форму с вымышленным контактом, предназначенным для тестовой среды.
3. Сопоставьте visit_id и lead_external_id в событии передачи и в CRM.
4. Повторите доставку того же события с тем же lead_external_id.
5. Убедитесь, что повтор обновил технический статус существующей записи, а не создал вторую историю обращения.

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

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

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

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

Учебный пример: путь от входных данных до результата

Все имена, времена и идентификаторы в этом разделе синтетические. Они показывают ожидаемую работу правил, а не результат клиента Switch On AI.

Исходные события:

Промежуточное решение строится по трём правилам:

first_touch = min(created_at) среди визитов с валидной атрибуцией
last_non_direct = max(created_at) среди визитов с валидной атрибуцией
число историй обращения = count(distinct lead_external_id)

В 10:00 система получает первую допустимую недиректную атрибуцию и заполняет first_* и last_*. В 12:00 прямой визит меняет только last_visit_channel. При отправке формы система связывает обращение L-001 с визитом v-002, но сохраняет найденную ранее недиректную атрибуцию. Событие в 12:06 имеет тот же ключ идемпотентности, поэтому не создаёт новую историю.

Итог: first_source=search, first_campaign=campaign_a, last_source=search, last_campaign=campaign_a, last_visit_channel=direct. Выражение count(distinct lead_external_id) даёт условный результат 1, потому что обе доставки относятся к L-001. Это воспроизводимый вывод из четырёх заданных событий, а не измерение рабочей CRM.

Как проверить результат перед запуском

Перед приёмкой вслух назовите модель: first touch + last non-direct, а последний канал визита хранится отдельно. Затем проверьте, что команда не смешала visit_id и lead_external_id: первый обозначает визит, второй — событие обращения и служит ключом защиты от повторной доставки.

Отсутствующая метка не становится direct, organic или другим удобным значением. Система записывает только наблюдаемый факт: допустимое значение, отсутствие значения или ошибку нормализации.

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

Что согласовать для внедрения

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

ИИ-помощник уместен не для хранения UTM как такового, а для работы с обращением: уточнить недостающие сведения по утверждённому сценарию и передать заявку человеку. Бот обеспечивает диалог в выбранном канале. Обычная интеграция переносит структурированные поля и контролирует повторы. Эти роли не следует смешивать.

До разработки согласуйте:

• модель атрибуции и неизменяемые поля;
• whitelist, справочники значений и правила нормализации;
• способ создания visit_id и lead_external_id;
• связь доменов, формы, мессенджера и CRM;
• основание и срок хранения данных;
• владельцев полей и ручных исключений;
• CRM, мессенджер, версию, тариф, права и доступные операции API;
• ожидаемые результаты обычного пути, дубля, прямого возврата и повреждённой метки.

Switch On AI может разработать ИИ-помощника, бота или интеграцию для этой операции после проверки данных и API. Подходящий сценарий связан с ИИ-помощником для продаж, но совместимость с конкретной CRM, каналом, тарифом и набором прав проверяется отдельно. Эта статья не подтверждает выполненное внедрение какого-либо вендора и не обещает эффект или срок.

Практический следующий шаг — проследить один тестовый лид от рекламы до CRM: записать входной URL, visit_id, событие передачи, lead_external_id и фактические значения целевых полей. Затем повторить доставку и прямой визит. Если готовые настройки не покрывают согласованные правила, можно разобрать одну операцию со Switch On AI и согласовать границы прототипа. Прототип проверяет ключевой сценарий, но не равен полному внедрению.