Как найти источник заявки в CRM

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

Поле «Источник» может означать разные вещи. Например, «сайт» описывает способ обращения, а «Яндекс Директ» — рекламный канал. Значение «вручную» говорит о способе создания карточки, но не объясняет, откуда клиент узнал о компании. Если эти признаки смешаны, отчёт не сможет надёжно сравнивать каналы.

Проверь, не возникает ли один из следующих разрывов.

Отсутствие UTM не доказывает прямой заход. Также совпадение телефона само по себе не доказывает, что две заявки пришли из одного канала.

Как проверить передачу UTM от формы до CRM

1. Выбери один вход. Например, форму на посадочной странице. Сначала проверь её отдельно от квиза, звонков и мессенджеров.
2. Открой контрольную ссылку. Используй известные значения кампании и объявления. Сохрани адрес до и после переадресаций. Как собрать ссылку, разобрано в статье про UTM-метки для Директа и CRM.
3. Посмотри отправку формы. Во вкладке Network инструментов разработчика найди запрос формы. Проверь поля и их значения. Если форма передаёт только контактные данные, наличие UTM в адресной строке ничего не гарантирует.
4. Сопоставь отправку с записью CRM. Лучше использовать идентификатор запроса, сохранённый на обеих сторонах. Время отправки помогает найти запись, но при нескольких одновременных заявках его недостаточно для однозначной связи.
5. Проверь сохранённые поля. Сравни исходный источник, кампанию, адрес входа и доступные идентификаторы. Названия полей могут различаться. Нужна явная таблица соответствий между формой, интеграцией и CRM.

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

Как источник заявки попадает в отчёт по сделке

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

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

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

Как сохранить два обращения одного клиента

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

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

Само связывание с существующим контактом корректно. Ошибка возникает, когда вместе с дублем удаляют сведения о новом обращении. Какое из обращений отнести к продаже, решает выбранная модель атрибуции, а не правило объединения контактов.

Какие поля хранить и как обозначать неизвестное

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

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

Не смешивай состояние источника и способ создания. unknown означает, что источник не установлен, recovered — что он восстановлен с подтверждением. manual и import описывают способ создания записи. Импортированная запись вполне может иметь известный источник.

Для привязки данных к визитам Метрика использует разные идентификаторы в зависимости от формата передачи. В частности, ClientId обозначает посетителя, а не отдельный сеанс. yclid обозначает клик Директа. Условия для заказов CRM и офлайн-конверсий различаются, их нужно проверять по справке об импорте офлайн-данных.

Можно ли восстановить источник старой заявки

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

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

Когда исходных данных нет, оставь источник неизвестным и отдельно покажи такие заявки в отчёте. legacy может обозначать старую партию данных, но её возраст не доказывает ни наличие, ни отсутствие источника.

Как организовать проверку CRM за семь шагов

Это порядок аудита, а не обещание устранить все ошибки за семь дней.

1. Перечисли входы: формы, квизы, звонки, мессенджеры, лид-формы площадок, ручные записи и импорты.
2. Для каждого входа зафиксируй, какие сведения действительно получаются.
3. Сверь названия и значения полей между входом, интеграцией и CRM.
4. Проверь повторное обращение существующего клиента.
5. Проследи источник до сделки, оплаты и строки отчёта.
6. Раздели записи с подтверждённым, восстановленным и неизвестным источником.
7. Повтори проверку на выбранных обращениях после исправления.

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

Два практических кейса без названий компаний

Кейс 1. Платный трафик превращался в "прямой"

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

Что помогло:

1. сохранить raw source на уровне лида;
2. при переносе в сделку копировать маркетинговые поля отдельно;
3. разнести creation_source и marketing_source;
4. добавить QA-отчёт по расхождению лида и сделки.

Кейс 2. Лид-формы и ручное создание смешивались в одно поле

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

Что помогло:

1. разделить технический origin и маркетинговую атрибуцию;
2. вынести ручное создание в отдельный тип входа;
3. договориться о нормализованном справочнике источников;
4. не заполнять задним числом то, чего система реально не знает.

Нужен ли DWH для такой проверки

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

После исправления передачи данных всё равно нужно проверить расчёт отчёта: соединения таблиц, фильтры и период. Это отдельная задача из разбора ошибок BI-отчётов.

FAQ

Почему в Метрике источник есть, а в CRM нет?

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

Нужно ли копировать UTM в сделку?

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

Можно ли считать все заявки без UTM прямыми?

Нет. Меток может не быть по разным причинам. «Источник неизвестен» и «прямой заход» нельзя автоматически считать одним значением.

Что считать результатом проверки?

Для выбранных заявок понятно, где источник был получен, как сохранился и откуда попал в отчёт. Для неизвестных записей обозначено, каких подтверждений не хватает. Исправление проверено на тех сценариях, где была найдена потеря.

Вывод

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