Чтобы передавать данные из CRM в Яндекс, нужно связать сделку с рекламным визитом, настроить цели для нужных этапов воронки и отправлять события в Яндекс Метрику или Центр конверсий Директа. Для связи обычно используют ClientID Метрики, идентификатор рекламного клика yclid или другой поддерживаемый идентификатор клиента.
В статье разберём, какие данные стоит передавать, как выбрать способ интеграции, сохранить рекламные идентификаторы в CRM, настроить отправку конверсий и проверить, что Яндекс правильно учитывает сделки и выручку. Инструкция подойдёт компаниям, у которых продажа происходит не сразу на сайте: после звонка, консультации, визита в офис или работы менеджера.
Зачем передавать данные из CRM в Яндекс
Счётчик на сайте видит отправку формы, звонок или переход в мессенджер, но не всегда знает, чем закончилась работа с обращением. Заявка могла оказаться спамом, клиент мог отказаться, а сделка — закрыться через несколько недель. Если рекламная система получает только данные о лидах, она оптимизирует кампании под количество обращений, а не под продажи.
Передача CRM-данных дополняет веб-аналитику событиями, которые происходят после первого обращения. В Яндекс можно отправлять, например:
- квалифицированный лид;
- назначенную встречу или консультацию;
- выставленный счёт;
- оплаченный заказ;
- сумму сделки и валюту;
- повторную покупку, если её можно корректно связать с клиентом.
После настройки такие события можно анализировать в Метрике и использовать как цели рекламных кампаний. Это помогает сравнивать источники по качеству обращений, оценивать стоимость продажи и обучать автоматические стратегии на более значимых действиях.
Передавать все статусы CRM не требуется. Для аналитики полезны только события с однозначным бизнес-смыслом. Например, технические стадии «назначен ответственный» или «добавлен комментарий» не характеризуют ценность лида и создают лишний шум.
Какой способ передачи выбрать
Подход зависит от CRM, объёма сделок, доступных идентификаторов и требований к скорости обновления. Основные варианты можно сравнить по уровню автоматизации.
| Способ | Когда подходит | Ограничения |
|---|---|---|
| Ручная загрузка файла | Нужно проверить гипотезу, сделок немного, регулярная интеграция пока не оправдана | Файл приходится готовить и загружать повторно; возможны задержки и ошибки сотрудников |
| Готовый модуль CRM или коннектор | CRM поддерживает передачу конверсий в сервисы Яндекса, а стандартных настроек достаточно | Доступные поля, правила и периодичность зависят от конкретного решения |
| Интеграция через API | Нужна регулярная передача статусов и выручки, есть разработчик или интегратор | Потребуются проектирование, авторизация, журналирование и контроль ошибок |
| Серверная интеграция через собственное хранилище | Данные поступают из нескольких CRM, телефонии, сайта и внутренних систем | Самый сложный вариант: нужно объединять клиентов, устранять дубли и управлять схемой данных |
Для разового теста обычно достаточно файла. Для постоянной оптимизации рекламы предпочтительна автоматическая передача: событие отправляется после смены статуса сделки, а результат запроса сохраняется в журнале.
До выбора технологии определите точку назначения. Офлайн-конверсии можно передавать в Метрику и затем использовать соответствующие цели в Директе. В некоторых конфигурациях данные загружают через инструменты Директа, предназначенные для объединения конверсий. Доступные варианты и названия разделов могут меняться, поэтому архитектуру лучше строить вокруг состава данных и идентификаторов, а не вокруг расположения кнопки в интерфейсе.
Какие данные нужно подготовить
Ключевая задача интеграции — доказать, что конкретная CRM-сделка относится к определённому посетителю или рекламному клику. Одного номера сделки для этого недостаточно: Яндекс не знает внутреннюю структуру CRM.
Идентификатор посетителя ClientID
ClientID создаётся счётчиком Метрики и хранится в браузере пользователя. Значение нужно получить на сайте при отправке формы или другом целевом действии, передать вместе с обращением и записать в отдельное поле CRM. В дальнейшем ClientID добавляют к офлайн-конверсии.
ClientID нельзя подменять внутренним идентификатором контакта или сделки. Это разные значения. Если CRM автоматически преобразует длинные номера, удаляет символы или меняет формат поля, сопоставление может перестать работать.
Идентификатор клика yclid
yclid добавляется к адресу страницы при переходе из рекламы Яндекса. Параметр необходимо считать из URL, сохранить на время пользовательской сессии и передать в CRM вместе с заявкой. Такой идентификатор позволяет связать последующее событие с конкретным рекламным переходом.
Сайт должен корректно сохранять параметр при переходах между страницами. Редиректы, сокращение URL, некоторые формы и сторонние виджеты могут потерять yclid до отправки обращения.
Параметры самой конверсии
Кроме идентификатора, обычно подготавливают:
- название или код цели;
- дату и время фактического события;
- сумму покупки или сделки, если показатель нужен для аналитики;
- валюту;
- уникальный идентификатор заказа или события для защиты от дублей;
- источник и технический статус отправки.
Передавайте дату оплаты, если целью является продажа, а не дату создания лида или выгрузки файла. Иначе отчёты будут искажать период, в котором произошла конверсия.
Контактные данные клиентов следует обрабатывать только при наличии надлежащих оснований и в объёме, необходимом для задачи. Доступ к выгрузкам, токенам и журналам интеграции нужно ограничить. Если выбранный инструмент поддерживает сопоставление по телефону или электронной почте, соблюдайте его требования к формату, преобразованию и защите данных.
Пошаговая настройка передачи данных
Шаг 1. Опишите воронку и выберите цели
Зафиксируйте, какие CRM-статусы действительно отражают прогресс клиента. Для большинства проектов достаточно двух или трёх уровней: квалифицированный лид, подтверждённая продажа и выручка. Чем сложнее схема, тем труднее поддерживать единые правила для менеджеров и рекламной системы.
Для каждой цели задайте точное условие. Например, «Продажа» может означать только поступившую оплату, а не устное согласие клиента или выставленный счёт. Условие должно одинаково применяться всеми сотрудниками.
Шаг 2. Настройте сбор идентификаторов на сайте
Проверьте установку счётчика Метрики и разметку рекламных ссылок. Затем добавьте получение ClientID и yclid во все точки обращения: формы, обратный звонок, онлайн-запись, корзину и сторонние виджеты, если они позволяют передавать дополнительные поля.
Идентификаторы лучше хранить в отдельных технических полях CRM. Не размещайте их в комментарии менеджера: свободный текст сложно надёжно обрабатывать через API и легко удалить при редактировании сделки.
Шаг 3. Передайте идентификаторы в CRM
При создании лида сайт должен отправлять не только имя и телефон, но и рекламные параметры. Проверьте путь на тестовой заявке: значение появляется в браузере, уходит в запросе формы, принимается обработчиком и сохраняется в нужной карточке CRM.
Если одна заявка создаёт контакт, лид и сделку, заранее определите, в каком объекте будет храниться идентификатор. При объединении дублей значение не должно пропадать. Для повторных обращений полезно сохранять историю идентификаторов, а не безусловно заменять первый визит последним.
Шаг 4. Создайте цели в Яндексе
Названия целей должны соответствовать событиям CRM и быть понятными без технической документации: «Квалифицированный лид», «Оплаченный заказ», «Повторная покупка». Для интеграции также задаётся технический код цели, который будет использоваться при загрузке файла или запросе API.
Если данные должны участвовать в оптимизации Директа, убедитесь, что счётчик связан с рекламным аккаунтом и нужная цель доступна в настройках кампании. Права доступа к Метрике, Директу и интеграции должны принадлежать рабочим аккаунтам, а не личной учётной записи бывшего сотрудника.
Шаг 5. Настройте загрузку
При ручном варианте выгрузите из CRM таблицу с идентификатором посетителя или клика, кодом цели, датой события, ценностью и валютой. Приведите столбцы к формату, который показывает выбранный инструмент Яндекса, и сначала загрузите небольшой тестовый файл.
При работе через API сформируйте событие после изменения статуса CRM. Интеграция должна проверить обязательные поля, отправить запрос, записать ответ и пометить событие как обработанное. Повторная отправка допустима только по заранее определённому правилу, иначе одна продажа может попасть в статистику несколько раз.
Шаг 6. Проведите контролируемый тест
Создайте тестовый рекламный или размеченный визит, отправьте форму и сохраните полученные идентификаторы. Затем переведите сделку в целевой статус и запустите передачу. Проверяйте всю цепочку, а не только успешный ответ API: принятие запроса ещё не означает, что событие корректно сопоставлено и появилось в нужном отчёте.
Как проверить интеграцию и использовать данные в Директе
Проверку удобно разделить на техническую и аналитическую. Техническая проверка отвечает на вопрос, доставлены ли события. Аналитическая показывает, можно ли доверять получившимся данным.
После запуска контролируйте:
- долю CRM-сделок, у которых заполнен ClientID или yclid;
- число отправленных, принятых и отклонённых событий;
- причины ошибок и возможность повторной обработки;
- совпадение количества продаж и суммы выручки в CRM и отчётах за сопоставимые периоды;
- наличие дублей;
- задержку между сменой статуса и появлением конверсии;
- распределение конверсий по рекламным кампаниям и другим источникам.
Полного совпадения между CRM и Метрикой может не быть. Часть клиентов приходит без поддерживаемого идентификатора, использует разные устройства, блокирует аналитические технологии или обращается после визита из канала, который не удалось связать со сделкой. Важно не искусственно добиться одинаковых итогов, а понимать причины расхождений и поддерживать стабильную долю сопоставления.
Не переключайте рекламные кампании на новую CRM-цель сразу после первой успешной загрузки. Сначала убедитесь, что событие передаётся регулярно, отражает реальную бизнес-ценность и накапливается в достаточном для выбранной стратегии объёме. Конкретный объём зависит от структуры кампаний, длительности цикла сделки и настроек стратегии.
Если продаж мало, в качестве цели оптимизации можно выбрать более частое промежуточное событие — например, квалифицированный лид. При этом итоговые продажи и выручку всё равно стоит передавать для оценки качества кампаний.
Типичные ошибки и чек-лист перед запуском
Чаще всего интеграция перестаёт быть полезной не из-за способа передачи, а из-за разрыва цепочки данных. Например, сайт собирает yclid, но форма не отправляет его; CRM хранит ClientID, но выгрузка берёт другое поле; менеджеры используют один статус для оплаченных и отменённых заказов.
Распространённые ошибки:
- Передача только номера сделки. Внутренний ID не связывает заказ с визитом в Метрике.
- Подмена времени события. Дата выгрузки используется вместо даты квалификации или оплаты.
- Дублирование конверсий. Одна сделка повторно отправляется после каждого редактирования карточки.
- Оптимизация по слишком раннему этапу. Кампания получает сигнал о любой заявке, включая спам и нецелевые обращения.
- Потеря идентификаторов. Редирект, виджет, интеграционный модуль или импорт в CRM удаляет техническое поле.
- Отсутствие мониторинга. После изменения формы или CRM данные перестают поступать, но ошибка обнаруживается только в отчётах.
- Смешение разных правил. Один отдел считает продажей выставленный счёт, другой — оплату.
Перед рабочим запуском пройдите короткий чек-лист:
- События CRM имеют однозначные условия и ответственных.
- Счётчик Метрики установлен на всех нужных страницах.
- ClientID и yclid собираются и сохраняются без изменения формата.
- Идентификаторы проходят через все формы, виджеты и промежуточные системы.
- Цели созданы и доступны нужному рекламному аккаунту.
- Дата, сумма и валюта передаются из корректных CRM-полей.
- Повторная отправка не создаёт дубли.
- Ошибки фиксируются, а ответственный получает уведомление.
- Тестовая сделка отображается в отчётах ожидаемым образом.
- Есть регулярная сверка CRM с данными Яндекса.
Интеграцию стоит учитывать вместе со структурой кампаний, выбором целей и логикой автостратегий. Если требуется комплексная настройка, Granat развивает контекстную рекламу для бизнеса с опорой на измеримые этапы воронки.
Частые вопросы
Можно ли передавать данные из CRM без разработчика?
Да. Для теста можно использовать ручную загрузку файла или готовый модуль CRM. Разработчик обычно нужен, когда требуется автоматическая передача, нестандартная логика статусов, объединение нескольких систем или контроль повторных запросов.
Что лучше передавать: ClientID или yclid?
Выбор зависит от точки назначения и доступных данных. ClientID связывает событие с посетителем Метрики, а yclid — с рекламным кликом Яндекса. Практически полезно сохранять оба идентификатора, если сайт и выбранный способ загрузки позволяют это сделать.
Можно ли загрузить старые сделки?
Можно загрузить только события, которые соответствуют требованиям выбранного инструмента по идентификаторам и допустимому периоду обработки. Если в старых карточках CRM не сохранялись ClientID, yclid или другие поддерживаемые данные, корректно связать сделки с рекламными визитами может быть невозможно.
Почему продаж в Яндексе меньше, чем в CRM?
Не каждая продажа сопоставляется с цифровым визитом. Причинами могут быть отсутствие идентификатора, переход между устройствами, потеря параметров в форме, ограничения аналитики, ошибки формата или продажа из другого источника. Диагностику начинают со сравнения сделок с заполненными и пустыми идентификаторами.
Нужно ли передавать сумму сделки?
Сумма нужна, если бизнес оценивает рекламу по выручке, ценности конверсий или окупаемости. Если сумма в CRM предварительная и часто меняется, передавайте подтверждённое значение на согласованном этапе либо обновляйте событие по правилам выбранного инструмента.
Как часто отправлять CRM-конверсии?
Для регулярной оптимизации данные лучше передавать автоматически вскоре после наступления целевого статуса. Пакетная загрузка по расписанию также допустима, если задержка известна и не мешает анализу. Главное — стабильность, отсутствие дублей и соблюдение ограничений выбранного способа передачи.
