Как связать Яндекс Метрику с Битрикс24 и увидеть продажи, а не только заявки

Чтобы видеть продажи, недостаточно установить счётчик и цель на кнопку. Нужно связать визит с обращением, передать из CRM итог сделки и договориться, какое событие бизнес считает продажей. Проверяйте настройку на одной согласованной тестовой цепочке: визит → заявка → сделка → оплата → отчёт. В каждом звене должен оставаться идентификатор для сверки.

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

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

Возьмём учебную сделку, не данные клиента. Посетитель пришёл на страницу оборудования, отправил форму и получил идентификатор обращения lead-demo-001. В CRM создаётся сделка deal-demo-001, куда сохраняются доступный идентификатор посетителя, страница и источник. Тестовые обозначения ниже нужны для сверки; реальные персональные данные в публичный отчёт не включают.

Для этого примера полная оплата считается одним событием. Если заказ оплачивается частями, заранее выберите модель: отдельные платежи или событие достижения полной оплаты. Повторная доставка pay-demo-001 не должна увеличивать сумму. Возврат учитывают по поддерживаемой схеме интеграции и сверяют с учётом, а не скрывают ручной правкой итоговой таблицы.

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

После проверки можно считать CPL по уникальным обращениям и CAC по новым платящим клиентам. Передача оплат даёт основу для расчёта, но сама по себе не выбирает модель атрибуции и не делает любую выручку прибылью. Состав работ по настройке — на странице сквозной аналитики.

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

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

Выберите одну воронку и один тип продажи для первого запуска. Если сервисное направление работает по предоплате, а товарное — с оплатой при получении, единая трактовка финального статуса скроет различия. Назначьте сотрудника, который поддерживает статусы и суммы; интеграция не исправит пропущенные действия менеджера.

Подключите CRM и проверьте идентификаторы

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

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

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

Проведите одно обращение через всю цепочку

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

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

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

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

Сравните отчёты по одинаковым правилам

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

Проверьте период, часовой пояс, воронку, набор статусов и способ атрибуции. В отчёте может учитываться источник визита, к которому удалось привязать заказ, а в CRM — источник, записанный при создании карточки. Это разные поля. Их расхождение требует объяснения, но не всегда свидетельствует об ошибке интеграции.

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

Исправляйте конкретный участок потери данных

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

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

Что уточняют перед запуском

Должны ли суммы CRM и Метрики совпасть до рубля?

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

Достаточно цели «отправка формы»?

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

С чего начать, если воронки не настроены?

Согласуйте этапы и ответственных в рамках внедрения Битрикс24. Затем подключайте сквозную аналитику и принимайте её на проверяемых сделках. Смысл результата важнее количества построенных диаграмм.

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

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

Выберите небольшой набор согласованных тестовых обращений и пройдите их по цепочке. Записывайте технический ID, время и итоговый статус без публикации контактов клиента. Если событие отправляется с сервера, заранее задайте защиту от повторов: server-side tracking не устраняет дубли автоматически.

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

Отделите принятое обращение от квалифицированного лида

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

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

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