Интеграция Метрики и CRM: как настроить сквозную аналитику

Материал обновлён 21.08.2026

В статье учтены актуальные сценарии Яндекс Метрики для загрузки заказов и клиентов из CRM: нативные CRM-интеграции, упрощённая загрузка заказов и подробная загрузка данных через API.

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

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

Если вам сначала нужен общий разбор темы, начните со статьи Сквозная аналитика: что это, как работает и зачем нужна бизнесу.

Что именно мы связываем и зачем

Цель сквозной аналитики – увидеть путь пользователя:
клик по объявлению → визиты на сайте → лид/сделка в CRM → выручка/маржа

Ключ к связке – идентификатор, по которому Метрика сможет найти визит пользователя.

• ClientID – основной и самый точный идентификатор для связки сайта и CRM. Метрика рекомендует передавать именно его
• phone или email – допустимый запасной вариант, если ClientID не удалось сохранить. Можно передавать и открытые значения, и md5-хеши, но только в специально предназначенных сценариях передачи CRM- и офлайн-данных
• UserID – имеет смысл только если на сайте уже есть собственная система идентификаторов и вы заранее связываете UserID с ClientID
• yclid – нужен для отдельных сценариев офлайн-конверсий и особенно полезен, если вам важно точнее передавать результат обратно в Яндекс Директ

Что важно понимать сразу:

• ClientID привязан не к человеку, а к браузеру и устройству
• если пользователь пришёл с одного устройства, а оплатил с другого, связка без дополнительных идентификаторов может потеряться
• если данные о заказе или офлайн-конверсии загрузили слишком поздно, Метрика не привяжет их к визиту

Сроки привязки в Метрике:

• новые заказы и офлайн-конверсии привязываются к визитам, если с момента визита прошло не больше 21 дня
• обновлять уже переданный заказ можно до 111 дней с момента визита

Архитектура решения

Выбираем схему интеграции

Если у вас Битрикс24 или amoCRM, сначала проверьте, можно ли закрыть задачу нативной интеграцией. Если CRM нестандартная или нужна своя логика статусов, товаров и полей, используйте API.

Сайт или точка контакта

На сайте, лендинге, квизе, форме или в коллтрекинге нужно сохранить идентификатор, по которому потом найдётся визит: в первую очередь ClientID, дополнительно phone, email, yclid или внутренний UserID.

CRM

В CRM нужно хранить не только сам лид или сделку, но и идентификаторы привязки, время создания сделки, статус, сумму, себестоимость и при необходимости состав заказа.

Канал передачи в Метрику

Данные можно передавать тремя путями:

• нативная интеграция CRM
• упрощённая загрузка заказов
• подробная загрузка клиентов и заказов через API

Контроль качества

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

Какие схемы интеграции используют в 2026

Схема 1. Сайт с формами → CRM → Метрика

Подходит, если лиды приходят через формы на сайте.

• посетитель приходит на сайт
• в форме сохраняется ClientID
• форма передаёт ClientID в CRM вместе с заявкой
• после смены статуса сделки CRM или ETL отправляет заказ в Метрику
• Метрика связывает заказ с визитом и рекламным источником

Схема 2. Сайт → коллтрекинг / звонок → CRM → Метрика

Подходит, если значимая часть продаж начинается со звонка.

• пользователь приходит на сайт
• коллтрекинг или форма обратного звонка сохраняет ClientID
• звонок и сделка попадают в CRM вместе с ClientID, телефоном или email
• в Метрику отправляется заказ или офлайн-конверсия
• отчёты показывают, какие источники привели не просто звонки, а реальные сделки

Схема 3. Несколько лендингов / сайт + квиз → единая CRM → Метрика

Подходит, если заявки собираются из нескольких точек входа.

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

Схема 4. Онлайн-лид → офлайн-продажа → Метрика

Подходит для B2B, шоурумов, офлайн-оплаты и длинного цикла сделки.

• пользователь оставляет заявку на сайте
• CRM хранит ClientID и данные клиента
• после оплаты или подписания договора в CRM обновляется статус сделки
• обновление заказа уходит в Метрику и дополняет исходный визит выручкой, оплатой или вашим кастомным статусом

Сбор ClientID на сайте

Добавьте скрытые поля в формы

<input type="hidden" name="ym_client_id" id="ym_client_id" value="">
<input type="hidden" name="user_id" id="user_id" value=""> <!-- если у вас есть авторизация -->

Подставьте ClientID в скрытое поле

<script>
  (function () {
    var COUNTER_ID = 12345678; // замените на ID вашего счётчика

    function readYmUidFromCookie() {
      var m = document.cookie.match('(?:^|;)\\s*_ym_uid=([^;]*)');
      return m ? decodeURIComponent(m[1]) : null;
    }

    function setField(id, val) {
      var el = document.getElementById(id);
      if (el && val) { el.value = val; }
    }

    function setClientIdSafe(clientId) {
      if (!clientId) clientId = readYmUidFromCookie();
      setField('ym_client_id', clientId);
    }

    if (typeof ym === 'function') {
      try {
        ym(COUNTER_ID, 'getClientID', function(clientId) {
          setClientIdSafe(clientId);
        });
      } catch (e) {
        setClientIdSafe(null);
      }
    } else {
      setTimeout(function () { setClientIdSafe(null); }, 800);
    }
  })();
</script>

Подготовка CRM к выгрузке

Минимальный набор полей

Минимальный набор полей зависит от выбранного способа загрузки, но в рабочей схеме на 2026 год лучше сразу хранить:

• order_id – ID заказа или сделки
• client_crm_id – внутренний ID клиента
• create_date_time – дата и время создания заказа в часовом поясе счётчика
• update_date_time – время последнего обновления заказа
• order_status – текущий статус сделки
• revenue – выручка
• cost – себестоимость, если хотите считать прибыль
• currency – валюта, если работаете не только в одной валюте
• products – состав заказа, если нужен анализ по товарам или услугам
• client_ids или ClientID – основной идентификатор привязки
• phones или emails или их md5-хеши – запасные идентификаторы
• UserID – только если он уже связан с ClientID на сайте

Если внедряете интеграцию не на коленке, сразу предусмотрите ещё два поля:

• source_touchpoint – откуда пришёл лид: сайт, квиз, звонок, офлайн-точка
• pipeline_stage_group – ваша бизнес-группа статусов: новый, квалифицирован, договор, оплата, отмена, спам

Сопоставление статусов

Метрика поддерживает: PAID, IN_PROGRESS, CANCELLED, SPAM, OTHER.
Сопоставьте их со своими CRM-статусами через API /schema/order_statuses.

Сроки

• добавление заказов – до 21 дня от визита
• обновление заказов – до 111 дней

Канал данных из CRM в Метрику

Вариант А. Нативная интеграция CRM

Подходит, если вы используете Битрикс24 или amoCRM и не хотите собирать собственный ETL.

Когда выбирать:

• нужна быстрая настройка
• стандартной логики статусов достаточно
• нет задачи глубоко кастомизировать структуру заказов и клиентов

Что важно:

• для Битрикс24 в документации Метрики есть отдельная интеграция
• для amoCRM интеграция работает через Albato
• к одному счётчику Метрики нельзя бездумно цеплять несколько CRM-проектов
• после подключения всё равно нужно руками проверить поля идентификации и сопоставление статусов

Вариант B. Упрощённая загрузка заказов

Подходит, если вам нужно быстро передавать заказы без сложной схемы клиентов и кастомных атрибутов.

Когда выбирать:

• CRM нестандартная
• нужен короткий путь до первых отчётов
• вам достаточно заказа, суммы, статуса и идентификаторов клиента

Что передаётся:

• id заказа
• дата создания
• один или несколько идентификаторов привязки: ClientID, email, phone, md5
• при необходимости статус, выручка, себестоимость

Вариант C. Подробная загрузка клиентов и заказов через API

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

Когда выбирать:

• нужно передавать клиентов отдельно от заказов
• есть кастомные статусы и JavaScript-цели
• нужен состав заказа, дополнительные атрибуты и стабильная ETL-схема

Практически это означает:

• сначала описываете статусы и атрибуты
• затем загружаете клиентов
• затем загружаете заказы
• потом обновляете заказы по мере движения сделки по воронке

Ограничения

• ClientID не склеивает пользователя между устройствами сам по себе. Один человек с ноутбука и телефона может быть для Метрики двумя разными ClientID

• UserID не работает магически. Если вы хотите использовать его в офлайн-данных, сначала на сайте должна быть настроена связка UserID ↔ ClientID

• Заказы и офлайн-конверсии нельзя откладывать “на потом”: окно привязки к визиту ограничено 21 днём

• Обновлять статус и выручку по уже переданному заказу можно только в пределах 111 дней от визита

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

• Если лид создаётся не с сайта, а руками в CRM, Метрика не восстановит источник без phone, email, yclid или другого идентификатора

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

• Если подключаете CRM-интеграцию, сначала проверьте ограничения самого коннектора: права доступа, тариф CRM, доменная зона, частота синхронизации, количество подключаемых проектов

UTM-метки

Базовый набор

• utm_source
• utm_medium
• utm_campaign
• utm_content
• utm_term

Шаблон для Директа

?utm_source=yandex&utm_medium=cpc&utm_campaign={campaign_id}&utm_content={ad_id}&utm_term={keyword}

Рекомендации

• используйте латиницу и единый регистр
• заведите справочник значений для utm_medium
• в utm_content удобно кодировать сегменты (например, seg--retarget_a)

Проверка и отчёты

После первой настройки проверьте отдельно:

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

Смотрите в первую очередь:

• Источники заказов из CRM – чтобы понять, какие источники приносят заказы
• Источники, расходы и ROI – чтобы сравнить расходы, выручку и прибыль
• Посетители и клиенты – чтобы проверить самих клиентов и их заказы
• Офлайн-конверсии – если передаёте отдельные офлайн-события и нужно видеть причины непривязки

Если что-то не сошлось, сначала ищите причину в идентификаторах, часовых поясах, статусах и дублях заказов.

Частые ошибки и как их избежать

Не передали ClientID в CRM

Что будет: Метрика не сможет связать заказ с визитом, реклама покажет клики без продаж.
Как правильно: во все формы на сайте добавьте скрытое поле ym_client_id и передавайте его в CRM. Проверяйте, чтобы это поле не было пустым.

Перепутали часовой пояс или формат даты

Что будет: заказ попадёт в отчёт в неправильный день или не загрузится.
Как правильно: указывайте дату и время строго в формате 2025-09-29T14:00:00+03:00 и с тем же часовым поясом, что стоит в счётчике Метрики.

Не сопоставили статусы заказов

Что будет: все заказы будут отмечены как прочие, вы не увидите конверсии Оплачен.
Как правильно: заранее составьте таблицу соответствия статус в CRM → статус в Метрике (например, Оплачен → PAID).

Загрузили заказы позже срока

Что будет: данные не привяжутся к визитам.
Как правильно: загружайте данные каждый день. Метрика принимает новые заказы только до 21 дня от визита, обновления – до 111 дней.

Дублировали расходы Директа

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

Разметили кампании по-разному

Что будет: в отчётах появятся десятки разных источников вроде cpc, CPC, клик.
Как правильно: используйте только латиницу, один регистр (лучше строчные буквы) и общий справочник UTM-меток.

Передали персональные данные в чистом виде

Что будет: нарушение закона о персональных данных и блокировка загрузки.
Как правильно: не передавайте имена и телефоны как есть. Используйте только e-mail и телефон, которые Метрика автоматически шифрует.

Сделали файл с ошибками

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

Перепутали счётчик или доступ

Что будет: данные улетят не туда или вовсе не загрузятся.
Как правильно: проверяйте перед загрузкой, что используете правильный ID счётчика и токен доступа именно от него.

Использовали UserID без связки с ClientID

Что будет: часть офлайн-данных не привяжется, хотя UserID формально передан.
Как правильно: используйте UserID только если на сайте уже настроен вызов setUserID и Метрика успела связать ваш внутренний ID с визитами.

Смешали несколько способов загрузки без единого order_id

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

Выбрали слишком сложную схему на старте

Что будет: проект зависнет на ETL и маппинге, а отчётов не будет неделями.
Как правильно: если задача – быстро получить рабочую сквозную аналитику, начните с нативной интеграции CRM или упрощённой загрузки заказов, а подробную схему собирайте после проверки бизнес-логики.

Чек-лист внедрения

На стороне сайта

• установлен счётчик Метрики
• во всех формах есть поле ym_client_id
• работает скрипт getClientID (есть резерв через cookie)

На стороне CRM

• заведены поля под ClientID/UserID
• лиды и заказы принимают эти значения
• статусы сопоставлены с типами Метрики

ETL

• ежедневное формирование JSON/CSV
• загрузка через API
• при необходимости – офлайн-конверсии

UTM

• все кампании размечены корректно

Контроль

• статусы загрузок проверены
• отчёты показывают корректные данные

Примеры API-вызовов

Упрощённая загрузка заказов (CSV)

POST https://api-metrika.yandex.net/cdp/api/v1/counter/{counterId}/data/simple_orders

Импорт заказов (JSON)

POST https://api-metrika.yandex.net/cdp/api/v1/counter/{counterId}/data/orders/json

Импорт офлайн-конверсий (CSV)

POST https://api-metrika.yandex.net/management/v1/counter/{counterId}/offline_conversions/upload

Сопоставление статусов

POST https://api-metrika.yandex.net/cdp/api/v1/counter/{counterId}/schema/order_statuses

Безопасность

Основным идентификатором для связки используйте ClientID.

• Телефон и email используйте как запасные идентификаторы только в механиках CRM- и офлайн-загрузки, где Метрика это допускает
• Если в вашей политике безопасности нельзя передавать открытые phone и email, используйте md5-хеши
• Не передавайте персональные данные в URL, UTM-метках, названиях страниц, JavaScript-событиях, параметрах визита и произвольных userParams
• Если используете UserID, не делайте его персональными данными вроде телефона или email

Быстрый старт

• Проверьте, какой путь вам подходит: нативная CRM-интеграция, simple_orders или подробный API

• Настройте сбор ClientID на всех формах и точках входа, где создаются лиды

• Создайте в CRM поля для ClientID, phone, email, времени сделки, статуса, выручки и себестоимости

• Зафиксируйте таблицу соответствия статусов CRM и статусов Метрики

• Сначала загрузите 2-5 тестовых заказов и проверьте, привязались ли они к визитам

• Только после этого включайте регулярную загрузку по расписанию

• Отдельно проверьте отчёты Источники заказов из CRM, Источники, расходы и ROI, Посетители и клиенты и при необходимости Офлайн-конверсии

Ответы на вопросы

Нужно ли обязательно передавать ClientID

Не обязательно, но это лучший вариант. Если ClientID не сохраняется, можно использовать phone, email, их md5-хеши или отдельные сценарии с yclid. Но именно ClientID обычно даёт самую точную связку сайта, визита и заказа.

Что если заказ был в офлайне

Если визит с ClientID был меньше 21 дня назад, заказ привяжется к нему. Если визита не было или срок больше – заказ попадёт в отчёт без источника.

Какая цель нужна для офлайн-конверсии

Только JavaScript-событие. Метрика не примет загрузку по целям Посещение страницы или Количество просмотров.

Сколько времени обрабатывается загрузка

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

Заключение

Чем раньше вы выстроите связку сайт → CRM → Метрика, тем быстрее получите честную картину окупаемости рекламы.

Что читать дальше

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