В performance-маркетинге назревал кризис точности: с одной стороны, алгоритмы Smart Bidding требуют всё больше качественных сигналов для обучения, с другой — клиентские скрипты на сайтах (tag-based tracking) теряют от 10% до 35% реальных действий. Причины известны каждому специалисту: блокировщики рекламы, политики Safari ITP / Firefox ETP, сбои при загрузке тяжелых страниц, отказы от передачи cookie в Consent Mode и прерывание сессий на этапе оплаты.
До недавнего времени у рекламодателя было два изолированных мира:
- Веб-теги (Google Tag / GTM), которые фиксировали действия на сайте «здесь и сейчас», но страдали от потери данных на стороне браузера.
- Офлайн-импорт (Offline Conversion Tracking / OCI), который настраивался как отдельное действие конверсии и часто приводил к дилемме: либо задвоение метрик, если учитывать и тег, и CRM, либо потеря быстрой обратной связи для автостратегий, если полностью перейти на загрузку постфактум.
Google Ads выкатил ключевое архитектурное обновление: Multi-Source Conversions (дополнение тегов внешними источниками данных). Теперь система позволяет объединить веб-тег и серверные/офлайн-данные внутри одного и того же действия конверсии. Офлайн-загрузки больше не конкурируют с пикселем, а закрывают его пробелы и корректируют ценность заказов.
Разбираемся, как устроена механика, в чём фундаментальная выгода для Smart Bidding и что необходимо настроить, чтобы алгоритмы не исказили статистику.
Как работает гибридная атрибуция Multi-Source
Суть обновления — слияние двух потоков данных (онлайн и офлайн) в единую точку с автоматической дедупликацией на стороне Google:
Механика дедупликации: роль Transaction ID
Главным связующим звеном становится уникальный идентификатор транзакции (transaction_id или order_id).
- Если тег сработал штатно: Google фиксирует конверсию в момент оформления заказа на сайте, привязывает её к клику и передает сигнал в Smart Bidding. Позже, когда CRM передает офлайн-файл с тем же
transaction_id, система распознает дубль. Она не создает второе событие, но обновляет данные (например, если в CRM изменилась сумма заказа из-за скидки или возврата части позиций). - Если тег заблокирован или сорвался: Браузер закрыли до срабатывания страницы
Thank You, сработал AdBlock или сбойнул скрипт. В веб-аналитике события нет. Однако в вашей CRM или базе заказов транзакция зафиксирована. При регулярной выгрузке Google Ads находит соответствующий переход (по сопутствующим данным сессии / хешированным контактам / gclid) и дописывает конверсию задним числом, привязывая её к исходной кампании и ключевому слову.
Почему это меняет эффективность Smart Bidding
Для контекстной рекламы с оплатой за результат (tCPA) или возврат инвестиций (tROAS) это обновление устраняет фундаментальный перекос:
- Предотвращение занижения ставок (Bid Suppression): Когда кампания теряет 15–20% конверсий из-за приватности браузеров, алгоритм считает, что аудитория или ключевые фразы не конвертируются. Ставки снижаются, показы падают. Восстановление реального объема заказов возвращает кампаниям правильный аукционный приоритет.
- Передача реального LTV и чистого чека: В e-commerce частая проблема — несовпадение корзины на сайте и факта оплаты (отмены, апсейлы оператором, замена позиций на складе). Новая модель позволяет тегом ловить факт намерения, а офлайн-потоком актуализировать точную сумму закрытой сделки.
- Сглаживание длинных циклов сделки: В B2B и сфере услуг (недвижимость, авто, медицина, сложный консалтинг) первичный клик фиксируется пикселем, а квалификация лида и оплата происходят через недели. Гибридная атрибуция объединяет эти фазы в непрерывную линию ценности.
Архитектура внедрения: три шага к запуску
Интеграция офлайн-источников к существующему веб-действию конверсии требует инженерной точности. Ошибки здесь чреваты двойным учетом или падением обучаемости кампаний.
Шаг 1. Унификация идентификаторов (Web + CRM)
Обязательное условие: на стороне фронтенда тег Google (через GTM или gtag.js) должен генерировать или захватывать transaction_id.
В коде события покупки параметр должен строго совпадать с номером заказа в CRM:
В CRM этот же
ORDER_128945должен быть первичным ключом записи.
Шаг 2. Настройка канала передачи через Data Manager
Google постепенно убирает необходимость писать кастомные парсеры под старый API. Основной инструмент сегодня — Google Ads Data Manager:
- Подключение коннекторов без кода (Google BigQuery, HubSpot, Salesforce, Google Cloud Storage, SFTP, Zapier).
- Сопоставление полей:
Transaction ID,Conversion Time,Conversion Value,Currency, а также параметров Enhanced Conversions (хешированные SHA-256emailиphone number).
Важно: Не создавайте новое действие конверсии! В интерфейсе конверсий найдите ваше текущее веб-действие и используйте опцию подключения дополнительного источника данных («Boost website measurement using additional data sources»).
Шаг 3. Учет 14-дневного адаптационного периода (Monitoring Period)
Google внедрил защитный механизм: при подключении офлайн-источника к активной конверсии система автоматически включает 14-дневный период мониторинга (Diagnostics Only).
- В течение этих двух недель офлайн-данные отображаются только в отчетах и диагностике.
- Они не участвуют в расчете ставок Smart Bidding. Это необходимо, чтобы алгоритм оценил процент расхождений, откалибровал дедупликацию и не вызвал резких скачков ставок в кампаниях.
- На 15-й день объединенные данные становятся полноправным сигналом для оптимизатора ставок.
Чек-лист: где чаще всего ошибаются
Перед активацией проверьте критические узлы:
Итог
Объединение тегов и офлайн-источников закрывает многолетний спор о том, чей учет главнее — пикселя или базы данных. Теперь это симбиотическая система: тег обеспечивает моментальную реакцию для алгоритмов в реальном времени, а офлайн-загрузка выступает гарантом достоверности и финансовой точности.
Для бизнеса это прямой путь к росту ROAS: алгоритмы обучаются не на гипотетических кликах и сорвавшихся скриптах, а на фактически оплаченных сделках из вашей CRM.
👉🏻 Все ключевые новости, инсайды и обновления — в Telegram-канале «Новости Арбитража».
Нет комментариев.