Заявки идут, бюджет расходуется, а менеджер закрывает сделку по телефону или в офисе — и рекламный кабинет об этом никогда не узнает. В отчёте Google Ads красуется дешёвый лид, но действительно ли он превратился в оплату — загадка. Это классический разрыв между маркетингом и продажами, из-за которого ROAS в кабинете становится фикцией.
Решение — отслеживание офлайн-конверсий. Разберём, что это такое, какими способами данные передаются обратно в рекламные системы и как настроить процесс так, чтобы алгоритмы обучались на реальных деньгах, а не на «сырых» заявках.
Онлайн-конверсия фиксируется прямо на сайте: заявка, звонок с колбэка, оплата в интернет-магазине. Офлайн-конверсия — это действие, которое происходит за пределами сайта: клиент оставил заявку, а купил спустя неделю в шоуруме или подтвердил сделку по телефону с менеджером.
Проблема в том, что между заявкой (MQL) и реально закрытой продажей (SQL) — пропасть. Пользователь мог кликнуть по объявлению, оставить контакты, а затем передумать, взять паузу или просто не дозвониться. Без передачи офлайн-данных рекламный кабинет считает конверсией сам факт заявки, хотя реальных денег может не быть вовсе. В итоге отчётный ROAS выглядит красиво, а фактическая рентабельность рекламы — совсем другая история.
Возврат данных о реальных продажах в Google Ads или Meta Ads решает сразу несколько задач: алгоритмы получают точный сигнал, какие клики привели к деньгам, бюджет перераспределяется в пользу источников с качественными лидами, а не просто дешёвыми заявками. Это также помогает найти новые ключевые слова и сегменты аудитории, которые чаще доходят до оплаты.
Ключевую роль в связке клика и сделки играют уникальные идентификаторы: GCLID и его модификации GBRAID и WBRAID для Google Ads, FBCLID — для Meta. При переходе по рекламе система присваивает пользователю такой код, который сохраняется в CRM вместе с карточкой лида. Когда сделка переходит в статус «оплачено», идентификатор вместе с Transaction ID или Order ID отправляется обратно в рекламный кабинет — так система понимает, какой конкретно клик привёл к продаже.

Есть несколько подходов, которые различаются по трудозатратам и масштабируемости.
Ручная загрузка через файл. Самый простой способ — выгрузить данные о сделках из CRM в CSV или Google Таблицы по шаблону Google Ads, указав GCLID, название конверсии, время, ценность и валюту. Подходит для небольшого объёма сделок, но требует регулярной ручной работы и не даёт мгновенной синхронизации.
Автоматическая интеграция через CRM и коннекторы. Bitrix24, AmoCRM, HubSpot и Salesforce можно связать с рекламными кабинетами через сервисы вроде Albato, Zapier, Make или ROMI Center. Как только сделка меняет статус в CRM, коннектор автоматически передаёт данные в Google Ads или Meta без участия человека.
Server-Side GTM и Conversions API. Наиболее устойчивый к блокировкам метод — передача событий через серверный контейнер Google Tag Manager и API конверсий (CAPI). Данные идут напрямую с сервера в рекламную систему, минуя браузер и cookies пользователя, что критично в условиях ограничений iOS и блокировки сторонних cookies.
Google Ads Data Manager. Google консолидировал разрозненные сценарии импорта конверсий в единый интерфейс внутри рекламного кабинета. Data Manager позволяет подключить CRM, BigQuery, Google Таблицы и сторонние аналитические сервисы без написания сложного кода — настройка сводится к выбору источника данных и сопоставлению полей.
Data Manager API. Это интерфейс для разработчиков, пришедший на смену устаревшему протоколу OCI (Offline Conversion Import) в составе Google Ads API. Он позволяет передавать события воронки и First-Party Data напрямую из бэкенда компании, что удобно при высоком объёме сделок и необходимости синхронизации в реальном времени.
Если идентификатор клика потерян (например, из-за истечения срока хранения cookies или ограничений браузера), на помощь приходят Enhanced Conversions for Leads. Механизм сопоставляет конверсию с кликом по хешированным (SHA-256) данным пользователя — email или телефону, которые он оставил в форме заявки. Это позволяет восстановить связку даже там, где классический GCLID недоступен.
Если основная часть заявок приходит по телефону, без коллтрекинга (Ringostat, Calltouch) данные о звонках попросту потеряются. Сервис подменяет номер телефона на сайте для каждого источника трафика и фиксирует, какой звонок пришёл с какой кампании. Далее статус звонка (состоялась сделка или нет) можно передать в CRM и далее — в рекламный кабинет как офлайн-конверсию.

Процесс настройки в целом сводится к следующему: включить автоматическую маркировку тегами в аккаунте, обеспечить сохранение GCLID вместе с карточкой лида в CRM, создать в разделе «Конверсии» новое действие типа «Импорт» и указать параметры — категорию, ценность, окно конверсии. Дальше данные загружаются либо вручную файлом, либо через настроенную интеграцию или Data Manager.
Важный нюанс: срок хранения GCLID в Google Ads ограничен — обычно до 90 дней. Если цикл сделки у вас длиннее (например, B2B с долгими переговорами), часть конверсий рискует не связаться с исходным кликом, и это стоит учитывать при планировании отчётности.
Чаще всего расхождения в данных возникают из-за:
Автостратегии Google Ads, ориентированные на ценность конверсий (Value-Based Bidding), обучаются именно на тех данных, которые вы им передаёте. Внедрять офлайн-конверсии в автостратегии нужно поэтапно, иначе алгоритм резко «переобучится» на неполных данных.
На этапе тестирования сделка из CRM добавляется в кабинет со статусом Secondary (второстепенная) — она видна в отчётах и позволяет наблюдать за динамикой, но не влияет на автоматическое назначение ставок. После накопления статистики — как правило, от 30–50 успешных импортов офлайн-сделок в месяц — закрытую продажу переводят в статус Primary (основная), а исходную заявку с сайта, наоборот, понижают до Secondary. Такая последовательность предотвращает двойной учёт одной и той же сделки (заявка плюс продажа) и позволяет Smart Bidding корректно оптимизироваться именно на реальную выручку, а не на количество лидов.
Если сделка совершается не через CRM с менеджером, а на кассе физического магазина, применяются другие механики склейки клика и покупки.
Программы лояльности. На кассе клиент называет номер телефона или email, которые ранее указывал при регистрации на сайте или в онлайн-форме. Эти данные хешируются по алгоритму SHA-256 и отправляются в рекламный кабинет — система сопоставляет их с исходным кликом, не раскрывая реальные контакты покупателя.
POS-системы и импорт чеков. Кассовое программное обеспечение можно напрямую интегрировать с Google Ads Data Manager, чтобы закрытые транзакции — суммы чеков и список позиций — автоматически подтягивались в рекламный кабинет без ручной выгрузки.
Динамические промокоды и QR-коды. Пользователь получает уникальный код на сайте или в рекламном объявлении и предъявляет его продавцу в точке продаж. Такой код работает как офлайн-аналог GCLID: он однозначно связывает конкретный визит в магазин с конкретной онлайн-кампанией.
Google Store Visits (визиты в магазин). Google автоматически оценивает посещения физических филиалов на основе анонимизированной геолокации пользователей, кликнувших по локальной или поисковой рекламе. Метрика доступна только при наличии сети из нескольких точек и достаточного объёма кликов и показов — это скорее агрегированная оценка, чем точная привязка конкретной сделки к клиенту.

В экосистеме Meta аналогичную роль играет Offline Events Manager в Meta Ads Manager — туда загружаются данные о продажах, совершённых после взаимодействия с рекламой, но вне сайта. Более надёжный способ — Conversions API (CAPI), который передаёт события напрямую с сервера, не завися от пикселя в браузере пользователя. Это особенно важно после введения App Tracking Transparency на iOS и повсеместной блокировки сторонних cookies: CAPI компенсирует часть потерянных данных и позволяет алгоритмам Meta продолжать оптимизацию по реальным конверсиям.
Передавая email, телефон или другие персональные данные клиента в Google Ads или Meta, их необходимо хешировать алгоритмом SHA-256. Это требование самих рекламных платформ и одновременно условие соответствия нормам защиты персональных данных (GDPR, 152-ФЗ). Хешированное значение позволяет системе сопоставить пользователя, не раскрывая его реальные контактные данные.
Ручная загрузка файлов, готовые коннекторы и Data Manager закрывают базовые сценарии, но при большом объёме сделок и необходимости передавать события в реальном времени потребуется серверный контейнер GTM. Настройка sGTM требует размещения серверного окружения, написания тегов и триггеров под конкретную CRM или POS-систему — здесь без участия веб-разработчика или технического аналитика обойтись, как правило, не получится.
Без передачи данных о реальных сделках рекламный кабинет видит только верхушку воронки — клики и заявки, но не деньги. Автостратегии в такой ситуации обучаются на «сыром» потоке лидов, включая тех, кто никогда не заплатит, а бюджет утекает в сегменты, которые выглядят эффективными только на бумаге. Настройка офлайн-конверсий — будь то через CRM, коллтрекинг, POS-интеграцию или Google Ads Data Manager — закрывает этот разрыв и превращает рекламную аналитику из набора догадок в инструмент, основанный на фактических продажах.
Заказать звонок
Отправьте заявку, и вскоре наш менеджер свяжется с вами!
Ваши данные успешно отправлены
Ждите нашего звонка в течение нескольких часов 😉