Почему источник лида в CRM меняется после повторного визита

Если CRM хранит только один набор полей utm_source, utm_medium и utm_campaign, повторный визит может заменить исходный источник новым. В результате реклама, которая впервые привела человека, исчезает из карточки, а письмо или прямой заход получает весь результат. Исправление начинается со схемы данных: сохраняйте первый известный источник отдельно от источника сессии, в которой создан лид.

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

Сначала зафиксируйте, что именно меняется

Возьмите одну тестовую заявку и сохраните три снимка:

1. параметры первой размеченной ссылки;
2. параметры повторного визита;
3. поля созданной записи в CRM.

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

Полезно различать четыре уровня:

UTM описывают назначение размеченной ссылки. gclid и yclid создаются рекламными платформами и используются отдельными механизмами сопоставления. Не записывайте один тип данных поверх другого и не помещайте контактные данные человека в URL.

Учебный пример: одно поле скрывает первое касание

Представим последовательность одного браузера:

Если форма передаёт в CRM только текущие UTM, в карточке останется crm_email / email. Это корректный ответ на вопрос о визите с заявкой, но он ничего не говорит о первом наблюдаемом привлечении. Если сайт при первом визите записал google / cpc, а при повторном безусловно заменил это значение, восстановить исходную строку из CRM уже не получится.

Учебная цепочка показывает два разных поля одной заявки. Значения не относятся к реальной кампании.

GA4 использует такой же принцип разделения вопросов: измерения с префиксом First user относятся к источнику первого привлечения пользователя, а измерения Session назначаются заново для каждой сессии. Это не шаблон для копирования полей GA4 в CRM, но полезная проверка смысла: отчёты с разной областью действия закономерно дают разные ответы.

Задайте правило записи до разработки

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

Минимальная схема карточки:

lead_id
created_at
first_source / first_medium / first_campaign / first_seen_at
lead_source / lead_medium / lead_campaign / lead_seen_at
click_id_type / click_id_value
attribution_schema_version

attribution_schema_version помогает понять, по какому правилу заполнена старая запись. Без версии изменение логики формы смешает в одном отчёте лиды, собранные по разным правилам.

Храните исходные значения отдельно от нормализованных. Например, first_source_raw=Google может отображаться в отчёте как google, но исходная строка нужна для проверки и отката. Порядок нормализации разобран в материале «Как нормализовать UTM-метки и не исказить отчёт».

Проведите тест из двух визитов

Используйте отдельные тестовые кампании, которые легко исключить из рабочих отчётов. Не подставляйте вымышленные gclid или yclid в импорт офлайн-конверсий: платформа не найдёт соответствующий клик. Для проверки внутренних полей достаточно безопасных UTM-значений и собственного маркера теста.

1. Откройте тестовую ссылку A в чистом профиле браузера: utm_source=qa_paid&utm_medium=cpc&utm_campaign=first_touch_test.
2. Убедитесь, что сайт сохранил первый источник и время. Зафиксируйте снимок данных доступным разработчику способом.
3. В том же профиле откройте ссылку B: utm_source=qa_email&utm_medium=email&utm_campaign=lead_touch_test.
4. Отправьте форму один раз и запишите полученный lead_id.
5. Выгрузите карточку из CRM. В полях first_* должна остаться ссылка A, в lead_* — ссылка B.
6. Откройте страницу без UTM и повторите просмотр. Пустой прямой визит не должен стирать уже сохранённый первый источник.
7. Проверьте повторную отправку формы и обновление сделки: существующие поля первого источника не должны меняться.

В комплекте к статье есть учебный events.csv и скрипт derive_sources.py. Он выбирает первую размеченную строку и строку создания лида, затем формирует derived-sources.csv. Ожидаемый результат для L-1001: qa_paid / cpc в first_* и qa_email / email в lead_*.

Отделите потерю данных от смены вопроса

Расхождение ещё не доказывает ошибку. Сначала определите, какие два значения сравниваются.

• Первый источник отличается от источника заявки. Это нормальная последовательность нескольких визитов, если оба поля сохранены.
• Первый источник стал равен последнему после обновления. Вероятна перезапись поля.
• В URL есть UTM, а в форме и CRM их нет. Проверьте передачу параметров в скрытые поля или серверный обработчик.
• UTM дошли до страницы после нескольких переходов, но затем исчезли. Пройдите цепочку редиректов и найдите первый ответ с потерей параметров.
• CRM и аналитика показывают разные источники. Сверьте область действия, идентификатор пользователя, сессию и время. Один источник CRM нельзя механически приравнять к First user source, Session source или атрибуции ключевого события GA4.

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

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

Google Ads указывает, что для импорта офлайн-конверсий по GCLID идентификатор нужно получить из URL и сохранить вместе с данными соответствующего потенциального клиента; значение чувствительно к регистру. Яндекс Метрика для офлайн-конверсий принимает ClientId, UserId, Yclid или PurchaseId и требует сохранить подходящие идентификаторы в CRM до передачи результата.

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

Общий процесс от заявки до квалифицированного лида описан в статье «Качество лидов и офлайн-конверсии». Правила именования и проверка ссылки до CRM — в гайде по UTM-меткам.

Что принять в работу

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

Приёмка завершена, когда тест из двух визитов воспроизводится, прямой возврат не стирает первое касание, а CRM-выгрузка и исходный журнал дают одинаковую пару first_* и lead_*. После этого маркетолог может отдельно сравнивать привлечение новых пользователей и сессии, которые приводят к заявкам.

Источники

• Источник 1
• Источник 2
• Источник 3
• Источник 4
• Источник 5
• Источник 6
• Источник 7

Материал подготовлен редакцией WiseLab с помощью AI. Источники и фактические утверждения проверены при подготовке.