Рекламный алгоритм видит ровно то, что вы ему показываете. Если в Google Ads и Meta попадают только клики и отправки форм, бид-стратегия будет оптимизироваться под дешёвые лиды, а не под выручку. В B2B это особенно болезненно: между кликом и закрытой сделкой проходят недели, а решение о качестве лида принимается в CRM, куда рекламный кабинет не заглядывает. В результате алгоритм исправно гонит трафик, который красиво выглядит в отчёте по CPL и плохо конвертируется в деньги.
Данные о реальных деньгах заперты в CRM. Кто дошёл до демо, кто стал MQL, какая сделка закрылась и на какую сумму - всё это известно отделу продаж, но не известно рекламной платформе. Задача сводится к одному: организовать обратный поток данных из CRM (и хранилища) в рекламные кабинеты, чтобы алгоритмы учились на closed-won, а не на кликах.
Reverse ETL и CDP: в чём разница
Это два разных слоя, которые часто путают.
Reverse ETL - это перекачка уже подготовленных, очищенных данных из хранилища (Snowflake, BigQuery) обратно в SaaS-инструменты, где работают команды. По сути это разворот классического ETL: данные не собираются в хранилище, а раздаются из него по операционным системам. Хранилище становится единым источником правды, а CRM, рекламные кабинеты и рассылки - его получателями. Reverse ETL решает задачу активации данных и обычно требует SQL, то есть это инструмент для data- и RevOps-команд.
CDP (customer data platform) решает другую задачу - консолидацию. Она собирает данные о клиенте из разных источников, объединяет их в единый профиль внутри собственного хранилища и даёт маркетингу строить сегменты без участия инженеров. CDP, как правило, дружелюбнее к маркетологу, но хранит копию данных у себя.
Честно говоря, это не конкуренты, а слои одной архитектуры. Если у вас уже есть хранилище и модель данных, Reverse ETL активирует их напрямую, без дублирования. Если данные разрознены, нет хранилища и нет инженерных ресурсов на слой объединения - CDP остаётся разумным выбором. Многие компании используют оба подхода.
Как offline conversion upload учит алгоритм
Технический мост между CRM и рекламой - загрузка офлайн-конверсий.
В Google Ads это связка Enhanced Conversions for Leads и Offline Conversion Import. Когда человек кликает по объявлению и оставляет форму, фиксируется GCLID. CRM ведёт лида дальше, и когда сделка закрывается, конверсия с этим GCLID и суммой сделки уходит обратно в Google. Без этого Google не знает, какая из форм стала демо, а какая - закрытой сделкой. Правильный приём: отправлять Closed-Won как ключевое событие с суммой сделки в качестве value, чтобы ROAS-бид оптимизировался по реальной выручке.
У Meta аналог - Conversions API (CAPI). Сделки, которые закрываются по звонку, в переписке или лично, пиксель не видит. CAPI принимает хешированные данные (email, телефон, FBCLID) как ключи сопоставления и позволяет передать факт закрытия сделки серверным запросом.
Эффект простой: алгоритм перестаёт гнаться за дешёвыми лидами и начинает искать аудитории, похожие на тех, кто реально платит. Именно так выстраивается closed-loop attribution - связь конкретного рекламного источника с фактической выручкой и реальным CAC. Если эту петлю нужно не просто настроить, а постоянно держать чистой и измерять, имеет смысл смотреть в сторону специализированных решений вроде Prooflytics.
Build vs buy
Платформенный путь - Hightouch, Census, готовая CDP - быстрее на старте, не требует поддержки своего кода и закрывает типовые сценарии. Минусы: подписка, потолок гибкости и зависимость от роадмапа вендора.
Кастомная интеграция оправдана, когда логика сопоставления нетривиальна (длинный цикл сделки, несколько касаний, дедупликация по нескольким ключам), когда нужен полный контроль над тем, какие события и значения уходят в кабинеты, или когда объём данных делает подписку платформы дороже разработки. Для EU-команд, которым важен такой контроль над пайплайном данных CRM, мы в Exceltic собираем интеграции под конкретную модель данных и под конкретный набор событий, а не под усреднённый сценарий вендора.
Практичный ориентир: если задача укладывается в стандартные коннекторы и нет жёстких требований к контролю - покупайте. Как только начинается список исключений и кастомной логики - считайте стоимость владения обоими вариантами.
Риски, о которых молчат вендоры
Гигиена данных. Алгоритм учится на том, что вы отправили. Дубли, неверно проставленные стадии сделок, кривые суммы - и оптимизация поедет не туда. Мусор на входе превращается в потраченный бюджет на выходе.
Consent и GDPR. Вы отправляете персональные данные (даже хешированные) во внешние рекламные системы. Для EU это значит: корректное правовое основание, учёт согласия на маркетинг, исключение тех, кто согласия не давал, и понимание, как обрабатываются match keys на стороне платформы. Загрузка офлайн-конверсий не должна обходить ваш consent-слой - иначе закрытие петли атрибуции открывает регуляторную дыру.
Возврат данных из CRM в рекламу - это не разовая настройка, а инфраструктура, которую нужно поддерживать. Но именно она превращает рекламу из генератора кликов в генератор сделок.