Почему рекламный кабинет, Яндекс Метрика и CRM показывают разные цифры

Рекламный кабинет сообщает о кликах и конверсиях, Яндекс Метрика — о визитах и достижениях целей, CRM — о лидах, заказах и оплатах. Одинаковый период, одна кампания, но числа не сходятся. Это не обязательно означает, что одна из систем ошибается. Чаще каждая считает свой участок пути клиента, использует собственное время события и по-своему определяет источник.

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

Сначала определите, что именно считает каждая система

Клик, визит, отправка формы, звонок, лид и платёж — разные события. Один человек может нажать объявление дважды, продолжить работу в одном визите, отправить форму, позднее позвонить и оплатить заказ через неделю. В рекламном кабинете появятся клики, в Метрике — визит и цели, в CRM — обращения и заказ. Ни одна из этих величин не обязана совпадать с соседней.

Событие Где обычно фиксируется Ключ для сверки Почему итог отличается
——————— ————————- ————————————— ———————————————————————
Клик по объявлению Рекламный кабинет Идентификатор клика, кампания, время Не каждый клик заканчивается загрузкой страницы
Визит Яндекс Метрика ClientID, источник, время начала Несколько кликов могут относиться к одному пользователю или визиту
Форма Сайт и Метрика ID отправки, ClientID Цель может сработать без принятой CRM заявки или несколько раз
Звонок Коллтрекинг и телефония ID звонка, связанный визит Пропущенный и повторный звонки требуют отдельной классификации
Лид CRM ID лида или обращения Дубли объединяются, спам исключается, обращения квалифицируются
Оплата CRM или учётная система ID заказа, сумма, дата статуса Платёж происходит позднее и может быть частичным или отменённым

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

Уточните и гранулярность. «Звонки» могут быть числом попыток, уникальных номеров, клиентов или обращений; «конверсии» — общим количеством достижений либо числом визитов, в которых цель достигнута хотя бы раз. Если человек отправил форму повторно, Метрика может сохранить несколько событий, а CRM — обновить один лид. Сопоставлять нужно события с событиями, уникальных клиентов с клиентами, а бизнес-объекты с бизнес-объектами.

Клик не равен визиту

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

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

Визит не равен принятой форме

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

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

Звонок живёт сразу в нескольких датах

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

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

Лид, заказ и оплата принадлежат CRM

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

При загрузке данных CRM в Метрику можно передавать идентификаторы клиента и заказа, время заказа, статус, доход, себестоимость и валюту. Для сопоставления доступны ClientID, телефон и электронная почта; документация рекомендует ClientID как вариант с наибольшей вероятностью привязки. Один заказ должен сохранять неизменный ID при обновлении статуса. Повторная отправка того же объекта с другим идентификатором создаст не обновление, а ещё одну запись.

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

Выровняйте период, часовую зону и дату события

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

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

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

UTM-метки распадаются из-за мелочей

UTM-параметры чувствительны к регистру: значения telegram и Telegram образуют разные строки. То же происходит с лишними пробелами, разными названиями кампаний и произвольными сокращениями. Ошибка в синтаксисе, обрезанная ссылка или редирект могут полностью убрать метку. Для первой страницы визита это особенно важно: Метрика определяет источник по первому просмотру, и метка, появившаяся лишь на следующей странице, не исправит источник всего визита.

Нужен единый словарь значений и генерация ссылок по шаблону. Проверить синтаксис до публикации помогает генератор UTM-меток (https://synchroweb.ru/instrumenty/utm/). После запуска кампании проверяют не только наличие параметров в объявлении, но и итоговый адрес после всех перенаправлений, первую загрузившуюся страницу и фактические значения в отчёте Метрики.

После 20 мая 2026 года действуют другие модели атрибуции

Сравнение источников зависит от модели атрибуции — правила, по которому визиту с конверсией назначается источник. 20 мая 2026 года Яндекс отключил модели «Первый переход», «Последний значимый переход», «Последний переход из Директа» и «Последний переход из Директа кросс-девайс». В актуальной документации перечислены «Первый переход кросс-девайс», «Последний переход», «Последний значимый переход кросс-девайс» и «Автоматическая атрибуция».

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

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

У офлайн-данных есть окно привязки

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

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

Разложите unknown на проверяемые причины

Строка «неизвестный источник» не должна быть окончательным ответом. Она объединяет разные ситуации: лид создан вручную, ClientID не попал в CRM, UTM потерялась на редиректе, телефон не сопоставился, заказ загружен поздно, идентификатор перезаписан, звонок не связан с визитом или клиент действительно пришёл по офлайн-рекомендации.

Создайте справочник причин неизвестности и назначайте его при разборе. Часть причин определяется автоматически: пустой ClientID, нарушение окна, отсутствующий ID звонка, неизвестная посадочная страница. Остальные подтверждает сотрудник. В отчёте показывают не только долю unknown, но и её состав. Тогда видно, что исправлять в интеграции, что — в дисциплине CRM, а что является допустимым офлайн-источником.

Сверяйте цепочку от оплаты назад

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

1. Зафиксируйте период, часовую зону, модель атрибуции и определения показателей.
2. Выгрузите оплаченные, отменённые и находящиеся в работе заказы с неизменными ID.
3. Проверьте, есть ли у каждого заказа лид и первичное обращение.
4. Сопоставьте формы по ID отправки, а звонки — по ID звонка.
5. Проверьте ClientID, дату визита и соблюдение окна загрузки.
6. Сравните UTM без изменения регистра и исходный URL после редиректов.
7. Отнесите каждый разрыв к конкретной причине, а не к общей категории «прочее».
8. Только после этого пересчитайте воронку и оцените масштаб каждой причины.

Если сайт ещё не передаёт ключи в CRM, сначала полезно выстроить сам маршрут данных. В отдельном материале разобрано, как передавать источник заявки в CRM (https://synchroweb.ru/blog/kak-peredavat-istochnik-zayavki-v-crm/); здесь же важно проверить, сохраняется ли связь до заказа и оплаты.

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

Нормальны различия, которые следуют из определения событий: кликов больше или меньше визитов в зависимости от правил учёта; один лид имеет несколько обращений; оплата происходит позже привлечения; последний и первый источник дают разные срезы. Их не «исправляют», а документируют в методике отчёта.

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

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

Источники

— Яндекс Метрика: модели атрибуции (https://yandex.ru/support/metrica/ru/reports/attribution-model)
— Яндекс Метрика: определение источника по меткам (https://yandex.ru/support/metrica/ru/general/source-tags)
— Яндекс Метрика: отчёты по UTM-меткам (https://yandex.ru/support/metrica/ru/reports/tags-utm)
— Яндекс Метрика: сквозная аналитика (https://yandex.ru/support/metrica/ru/analytics/intro)
— Яндекс Метрика: передача данных из CRM (https://yandex.ru/support/metrica/ru/crm/about)
— Яндекс Метрика: передача данных о звонках (https://yandex.ru/support/metrica/ru/data/calls)
— Яндекс Метрика: отчёт «Звонки, детально» (https://yandex.ru/support/metrica/ru/reports/calls-detail)