Как связать Яндекс Директ с CRM и видеть, какие заявки стали продажами

Связь Директа с CRM начинается с определения сущностей. Обращение, контакт, сделка, заказ и платёж не взаимозаменяемы. Один человек может позвонить дважды, открыть две сделки и внести несколько платежей. Без правила объединения интеграция перенесёт эти различия в отчёт как ложный рост результатов.

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

Карта полей до выбора интегратора

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

Сохранить источник и ClientId

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

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

Статус должен иметь проверяемый смысл

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

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

Тестовая цепочка с искусственными данными

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

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

Передача и привязка — разные результаты

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

Для длинной сделки сохраните собственную историю независимо от окна рекламной системы. Иначе поздняя оплата исчезнет из управленческого анализа или будет ошибочно приписана текущему месяцу. Принцип сравнения периодов разобран в справке о прогнозе и бюджете.

Пример формулировки: «Один новый клиент считается один раз; дополнительные контакты, сделки и платежи хранятся, но не увеличивают число привлечённых клиентов».

Итогом настройки становится проверяемая карта связи. Она полезна даже при частичной передаче в Метрику: владелец видит известные результаты, ограничения покрытия и место конкретной потери.

Что проверяет прогнозный сценарий

Прогнозный сценарий. Не средние по рынку и не гарантия результата. Все входы условные: они показывают арифметику решения, а не средние цены клика и конверсии отрасли. Период — месяц привлечения в условном регионе России; после завершения сделок выбранной месячной когорты.

Сценарии описывают экономику привлечения с проверяемыми статусами. Их нельзя загружать в CRM как реальные результаты или выдавать за эффект подключения интеграции.

Период: Условный месяц привлечения с отдельным завершением его сделок. Регион: Условный регион России; реальная география и спрос не измерены. Денежная база: Полные условные рублёвые расходы без возмещения входного НДС; единая база CPC, бюджета и вклада; налоговые ставки не заданы. Условные входные значения заданы редакцией для объяснения формул; они не измерены в рекламном кабинете. Вклад после маркетинга не равен чистой прибыли.

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

Дробные события — математические ожидания. Расход ограничен условно доступными кликами; свободные производственные мощности проверяются отдельно. Полный CAC включает размещение, работу специалиста и дополнительные расходы привлечения. Вклад после маркетинга не является чистой прибылью: прочие постоянные расходы и налоги здесь не рассчитаны. Все денежные входы заданы на одной базе полных рублёвых затрат без возмещения входного НДС.

Как подготовить задачу

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

Источники и границы проверки

Яндекс: «Загрузка данных из CRM»; Яндекс: «Отчёт Клиенты». Проверено 2026-10-05. Практическая таблица — редакционный инструмент; спрос, частотность и рыночные конверсии не измерены.