Как научить Google Ads и Meta Ads отличать продажу от мусорной заявки

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

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

Решение — вернуть в Google Ads и Meta Ads события из CRM. Тогда алгоритмы начинают видеть не только вход в воронку, но и её реальные результаты.

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

Google прямо рекомендует связывать CRM с рекламой и передавать обратно квалифицированные или закрытые лиды. В 2026 году enhanced conversions for leads и offline conversion imports объединяются вокруг Data Manager: система сопоставляет хешированные first-party данные и идентификаторы клика с последующими CRM-событиями. Data Manager поддерживает прямые подключения к HubSpot, Salesforce, BigQuery и другим источникам.

В Meta ту же задачу решают Pixel, Conversions API и CRM-события. Технические способы различаются, но бизнес-логика одна: платформа должна получить более поздний и более ценный сигнал.

Pixel фиксирует браузерные действия, а Conversions API позволяет передавать события с сервера или из CRM. Когда одно и то же событие отправляется обоими путями, нужен общий event_id: по нему Meta распознаёт дубль и не считает одну конверсию дважды. Без этого «надёжная двойная отправка» может искусственно увеличить результат.

Для сопоставления используются разрешённые идентификаторы и first-party данные. Качество сопоставления нужно проверять в Events Manager вместе с диагностикой ошибок, а не считать сам факт ответа API доказательством работоспособности. Высокий технический match ещё не делает событие полезным: если статус SQL менеджеры применяют по-разному, система быстрее масштабирует плохую разметку.

Практически полезно разделить события по смыслу: Lead остаётся верхним сигналом, QualifiedLead или его согласованный аналог отражает подтверждённое качество, Purchase или закрытая сделка — выручку. Названия могут отличаться, но event_name, время, event_id, value, currency и данные для сопоставления должны передаваться стабильно. Сначала новый CRM-сигнал наблюдают и сверяют, затем ограниченно используют для оптимизации.

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

Хорошее определение проходит три проверки:

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

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

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

Минимальный набор состоит из идентификатора или first-party данных, названия события, времени события и ценности. Для сделки добавляется сумма или маржинальная ценность, если бизнес готов её считать. Для промежуточных этапов можно использовать условные веса, но они должны отражать вероятность дохода, а не желание нарисовать красивый ROAS.

Например, если из десяти квалифицированных лидов в среднем закрывается два, а средняя маржа сделки составляет 5 000 условных единиц, ожидаемая ценность квалификации — около 1 000 до учёта операционных расходов. Это лучше случайной оценки «назначим встрече ценность 100, потому что так удобно».

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

До разработки полезно зафиксировать договор между CRM, аналитикой и рекламными системами. В каждой записи должны быть: внутренний lead_id или order_id, рекламные идентификаторы, название и версия события, реальное event_time с часовым поясом, value и currency, разрешённые данные для сопоставления, источник, а также уникальный event_id для защиты от дублей.

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

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

Статусы заполняются задним числом или не заполняются вообще
Если менеджер меняет этап раз в месяц, реклама слишком поздно получает сигнал. Если один менеджер ставит «квалифицирован», когда дозвонился, а другой — после встречи, данные становятся несопоставимыми.

Повторные обращения считаются новыми лидами
Один человек может отправить форму, позвонить и написать в мессенджер. Без дедупликации в отчёте появятся три конверсии, хотя в CRM это одна возможность.

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

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

Для аналитики недостаточно хранить только текущее значение «сделка закрыта». Нужен журнал переходов: идентификатор объекта, предыдущий и новый статус, реальное время события, источник изменения и версия правила квалификации. Тогда можно восстановить задержку, отменить ошибочный сигнал и не отправить одну и ту же продажу повторно после редактирования карточки.

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

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

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

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

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

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

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

Шаг 2. Выбрать 1–2 события для оптимизации
Обычно это квалифицированный лид и продажа. Если цикл длинный, начните с квалификации или встречи, но продолжайте передавать сделки для отчётности и будущей value-based оптимизации.

Шаг 3. Обеспечить сопоставление
Сохраняйте GCLID и другие рекламные идентификаторы, передавайте хешированные email и телефоны там, где это разрешено и корректно, настройте Conversions API для Meta. Проверьте, что данные не теряются между формой, телефонией, мессенджером и CRM.

Шаг 4. Сверить две стороны
За одинаковый период сравните число событий в CRM и рекламной системе. Расхождение не обязано быть нулевым из-за окон атрибуции и правил сопоставления, но оно должно быть объяснимым.

Шаг 5. Только потом менять оптимизацию
Сначала наблюдайте новый сигнал как secondary, затем проведите ограниченный тест на части кампаний. Сравнивайте не только CPL, но стоимость квалификации, продажи и валовую прибыль.

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

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

Даже идеально переданные CRM-события не доказывают, что реклама создала все приписанные ей продажи. Google Ads и Meta Ads используют собственные окна и модели атрибуции: они отвечают, какие взаимодействия платформа связала с результатом. Вопрос «сколько продаж произошло именно благодаря рекламе» требует отдельного инкрементального теста — holdout, геоэксперимента или другой причинной методики.

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

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

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

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

Для Google Ads полезно сохранять внутренний ID лида или заказа, GCLID, а для части iOS- и web-to-app-сценариев — GBRAID или WBRAID, а также разрешённые first-party-данные для сопоставления в хешированном виде. Вместе с конверсией передают её тип, реальное время с часовым поясом, ценность, валюту и уникальный order ID, если событие связано с заказом.

Для Meta базовый пакет строится вокруг event_name, event_time, event_id и action_source. В user_data передают только разрешённые идентификаторы пользователя, а в custom_data — ценность, валюту и бизнес-параметры события. Если одно событие отправляется и браузерным Pixel, и через Conversions API, одинаковый event_id помогает дедупликации.

Если click ID отсутствует, это не повод подставлять выдуманное значение. Используйте разрешённые first-party-идентификаторы, сохраняйте исходный источник в CRM и не перезаписывайте его после прямого повторного визита. Точный набор полей всегда сверяйте с актуальной документацией платформы и правовыми требованиями вашего рынка.

Предположим, за неделю CRM создала 100 SQL. В очередь выгрузки попали 96, платформа приняла 91, а сопоставить с пользователями смогла 78. Это четыре разных числа: 4 записи потерялись при подготовке, ещё 5 были отклонены из-за схемы или полей, 13 не сопоставились. Принятое событие не равно сопоставленному, а сопоставленное не равно атрибутированной рекламе.

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

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

Рабочая RACI-схема проста: marketing отвечает за бизнес-события и качество сигнала; CRM/engineering — за схему, доставку, idempotency и мониторинг; sales — за корректность стадий и причин отказа; legal или privacy-функция согласует основание, текст согласия и срок хранения; владелец бизнеса утверждает экономику и допустимый риск.