Как передать результат работы с заявкой в Яндекс Метрику

Чтобы передать в Метрику результат работы с заявкой, сохраните связь заявки с посетителем сайта и загрузите событие из CRM. Затем проверьте обработку события и его связь с визитом.

Как результат по заявке становится офлайн-конверсией

Заявка пришла с сайта, а оплату менеджер отметил позже в CRM. Офлайн-конверсия помогает связать этот результат с визитом. Человек отправляет форму, менеджер получает заявку в CRM, уточняет запрос и отмечает оплату. Рекламодателю важно видеть эти этапы отдельно: отправленная форма ещё не означает, что обращение подошло компании или завершилось продажей.

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

Для анализа это три разных события: обращение, подтверждение и оплата.

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

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

Такой выбор не подойдёт компании, где статус подтверждения ставят нерегулярно.

Какие статусы CRM передавать как цели

Выбирайте статусы, за которыми стоит понятное действие, и сопоставляйте каждый с отдельной целью. Статус «Новая» сообщает лишь о появлении записи в CRM: отправку формы обычно уже отражает цель на сайте. Для оценки обращений полезнее подтверждённая заявка, а для оценки продаж — оплата. Общая цель «Сделка» смешает этапы и затруднит анализ.

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

Как связать заявку в CRM с визитом на сайт

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

ClientID, UserID и yclid обозначают разные идентификаторы. Не подставляйте одно значение вместо другого лишь потому, что оно есть в CRM. Допустимый идентификатор и состав полей нужно проверить в инструкции к выбранному способу передачи.

Создайте тестовую заявку без персональных данных и проследите, какие значения дошли до CRM. Если идентификатор пустой, сначала исправьте передачу из формы.

Что подготовить в счётчике и CRM до передачи

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

Проверьте подготовку на одной заявке:

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

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

Для ручной загрузки Яндекс описывает цель типа «Целевое событие» и CSV с идентификатором цели Target, временем события DateTime и хотя бы одним поддерживаемым идентификатором. Уточните состав полей и формат времени по инструкции Метрики.

Как передавать данные: CSV, API или интеграция с CRM

Способ передачи зависит от частоты изменений в CRM и того, кто будет разбирать ошибки. CSV удобен для пробной ручной загрузки. API подходит для обмена, который нужно запускать по расписанию или после смены статуса. Готовая интеграция сокращает объём разработки, но требует проверки сопоставленных полей и событий.

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

То же относится к адресу метода API и способу авторизации: их нужно сверить с действующей инструкцией.

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

Как проверить, что событие загрузилось и появилось в отчёте

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

1. Найдите тестовую заявку в CRM и сверьте ID, идентификатор посетителя, статус и время события.
2. Проверьте результат загрузки файла или ответ API. Сохраните сообщение об ошибке, если оно есть.
3. Проверьте результат обработки переданных данных.
4. Откройте отчёт по нужной цели и проверьте период и сегмент.
5. Если событие найдено, проверьте его связь с исходным визитом. Яндекс предупреждает, что статусы привязки в отчёте могут отображаться неверно, поэтому актуальную долю привязанных конверсий следует также посмотреть на странице загрузки данных в настройках счётчика.

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

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

Как оценивать рекламу по офлайн-целям

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

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

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

Почему конверсия не появилась: порядок диагностики

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

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

Для проверки рекламной части цепочки пригодится список того, что заказчику проверить в настройке Яндекс Директа.

С чего начать передачу офлайн-конверсий

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

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

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

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