Битрикс24 и Яндекс Метрика: как связать рекламу с оплаченными сделками

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

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

Разберём это на учебном примере поставщика оборудования. Цифры и компания вымышлены; схема подходит и для услуг с оплатой после переговоров.

Сначала определите, какой результат считать конверсией

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

Для начала составьте короткий словарь:

Успешная стадия сделки и оплата должны проверяться отдельно. Менеджер может закрывать сделку после подписания договора, а покупатель платить позднее. В Битрикс24 статус оплаты заказа отображается отдельно в таймлайне и канбане. Его нельзя подменять фактом просмотра страницы оплаты. Как Битрикс24 показывает оплату.

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

Два способа передачи: событие или заказ из CRM

В документации Метрики есть разные механизмы. Их поля и поведение нельзя объединить в один условный «файл конверсий».

Офлайн-конверсии передают отдельное достижение цели: например, подтверждённую оплату. В таком файле указывают идентификатор посетителя или покупки, цель и фактическое время события; дополнительно можно передать ценность и валюту. Поддерживаются ClientID, UserID, yclid и PurchaseId. Это механизм дополнения визита событием, а не карточка заказа с изменяемыми стадиями. Передача офлайн-конверсий.

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

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

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

Далее разбираем упрощённую CRM-загрузку как учебную модель такого обмена. Она показывает, какие данные и проверки нужны; писать собственный API для каждой компании не требуется. Одна сделка Битрикс24 соответствует одному заказу Метрики. Если бизнес делит сделку на несколько самостоятельных заказов, это соответствие нужно изменить до запуска.

Как связать обращение с визитом

Связь лучше сохранять в момент заявки, пока посетитель находится на сайте. Для выбранного CRM-формата используем ClientID: идентификатор посетителя, который выдаёт Метрика. Его получают методом getClientID, передают вместе с формой и сохраняют в CRM. Для звонков нужно проверить, передаёт ли его система коллтрекинга. Подготовка CRM-данных.

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

Соседние идентификаторы решают другие задачи:

• UserID задаёт владелец сайта, например для личного кабинета. Для офлайн-конверсий его предварительно связывают с посетителем вызовом setUserID на сайте. Номер контакта Битрикс24 сам по себе такой связи не создаёт.
• yclid обозначает клик по объявлению Яндекс Директа. Он подходит для поддерживающего его механизма офлайн-конверсий. Подставить его вместо ClientID в simple_orders нельзя.
• UTM-метки описывают источник, кампанию и другие параметры перехода. Они нужны в CRM для разбора рекламы, но не идентифицируют посетителя: одна ссылка используется множеством людей.

Яндекс отдельно перечисляет поддержку идентификаторов: UserID и yclid доступны для офлайн-конверсий и звонков, а CRM-заказы связываются по ClientID, телефонам и почте, включая предусмотренные форматом хеши. Идентификаторы офлайн-данных.

Для нашего сценария достаточно ClientID. Не добавляйте в выгрузку весь контакт, комментарии менеджера и переписку. Если выбран другой способ сопоставления, передавайте только необходимые данные и соблюдайте его формат. Хеширование не заменяет правила работы с персональными данными. Токены Метрики и доступ к Битрикс24 должны храниться на сервере; в коде формы им места нет.

Какие данные понадобятся: пример одной сделки

Покупатель пришёл по рекламе 5 октября, оставил заявку на насос и получил предложение на 120 000 ₽. Через неделю внёс аванс, а 25 октября доплатил остаток. В CRM всё это время существует сделка № 8401.

В simple_orders статус нужно передавать явно: если его пропустить, заказ считается оплаченным. Поле id позволяет обновлять заказ, а исходную дату создания после загрузки менять нельзя. Денежные поля также имеют точный смысл: revenue является выручкой; при переданной себестоимости cost доход целей рассчитывается как revenue − cost. Не сравнивайте его с выручкой без поправки на эту разницу. Формат упрощённых CRM-данных.

В этом примере 120 000 ₽ в карточке ещё не означают поступившие 120 000 ₽. До полной оплаты статус остаётся «в работе». Для отчёта по поступлениям нужен отдельный реестр платежей; сумма заказа его не заменяет.

Повторные изменения: одна сделка остаётся одним заказом

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

Рабочая последовательность выглядит так:

1. При создании заказа отправить его с явным статусом IN_PROGRESS.
2. При изменении значимых данных перечитать актуальную карточку и подтверждение оплаты.
3. Подготовить обновление с тем же ID и прежней датой создания.
4. Отправить его в выбранном режиме обновления, затем проверить обработку и привязку.
5. При сбое повторить подготовленную версию без нового ID и выдуманной даты события.

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

Разработчик может получать изменения через события Битрикс24 и проверять карточки по расписанию. В актуальном API сделки читаются и изменяются универсальными методами crm.item.*; документы оплаты имеют отдельную группу методов. Технический способ зависит от того, где компания учитывает реальные поступления. Обзор методов сделок Битрикс24. Основные принципы доступа описаны в материале про REST API и вебхуки.

При передаче отдельных офлайн-конверсий нужен свой журнал событий: например, «первая оплата сделки 8401». Повторное уведомление об одном платеже не должно создавать новую отправку. Не переносите сюда логику обновления CRM-заказа: изменение DateTime при повторе не является исправлением прежнего события.

Авансы, возвраты и длинный цикл продаж

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

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

Долгие переговоры. Для первоначального дополнения визитов офлайн-данными действует период 21 день. Для CRM-заказа, который уже привязан к визиту, предусмотрено изменение данных в пределах 111 дней с начала этого визита. Это отдельное правило CRM-заказов, которое нельзя распространять на произвольные офлайн-цели. Периоды дополнения визитов.

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

Как проверить результат и оценивать рекламу

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

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

Критерии приёмки можно записать заранее:

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

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

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

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

Частые вопросы

Можно ли обойтись UTM-метками в сделке?

Они помогут группировать обращения в CRM, но не заменят идентификатор для привязки к визиту Метрики. В выбранном здесь CRM-формате сохраняйте ClientID вместе с заявкой; UTM храните рядом как сведения об источнике.

Достаточно ли отправлять стадию «Успешно завершена»?

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

Почему Метрика приняла заказ, но реклама не получила конверсию?

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

Можно ли после возврата убрать прошлую оплату из всех отчётов?

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

Что делать, если продажа занимает больше трёх месяцев?

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

Как поставить задачу на интеграцию

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

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

Источники и документация

Материал проверен по документации 25 октября 2026 года. Перед настройкой обмена следует повторно сверить выбранный формат и доступные возможности конкретного портала.

• Яндекс Метрика: CRM-заказы и их привязка, формат simple_orders.
• Яндекс Метрика: офлайн-конверсии, идентификаторы и периоды дополнения визитов.
• Битрикс24: информация об оплате, обзор REST-методов сделок.