Можно запустить кампанию, получить реальные заявки или покупки и при этом увидеть в рекламном кабинете меньше конверсий, чем показывает партнёрка, CRM или трекер. На первый взгляд кажется, что где-то сломалась статистика. На практике часть событий действительно может потеряться по дороге — ещё до того, как рекламная система успеет их нормально зафиксировать.
Недавно уже выходила новость о Google Tag Gateway для Demand Gen. Google сообщил, что рекламодатели, усилившие сбор данных с помощью Tag Gateway, в среднем увидели более 20% прироста конверсий в Demand Gen. Но воспринимать эту цифру как гарантированные +20% новых продаж точно не стоит: речь идёт о среднем результате внутреннего анализа Google, а сама технология в первую очередь помогает сделать передачу данных устойчивее и дать рекламной системе больше качественных сигналов.
Чем больше реальных конверсий видит рекламная система, тем полнее данные, на которых обучается её алгоритм.
Почему рекламный кабинет вообще может терять конверсии
При обычном веб-трекинге большая часть событий передаётся через браузер пользователя. Человек кликает по рекламе, заходит на сайт, на странице срабатывает тег или пиксель, после чего информация должна вернуться в рекламную систему.
Проблема в том, что между сайтом и рекламной платформой находится браузер со своими ограничениями, настройками приватности и расширениями. В результате сама заявка или покупка может произойти, но рекламный кабинет не всегда получает тот же объём данных, который уже виден в CRM, партнёрке или трекере.
Поэтому ситуация, когда одна система показывает 120 конверсий, другая — 116, а рекламный кабинет заметно меньше, сама по себе не означает, что кто-то считает неправильно.
Разные системы просто могут видеть разные участки одной и той же воронки.
Как работает обычный client-side tracking
При классической схеме многое происходит прямо в браузере пользователя.
Условно цепочка выглядит так:
реклама → сайт → браузерный тег → рекламная система
Пользователь совершает действие, браузер фиксирует его через установленный тег и отправляет событие дальше. Пока вся цепочка работает без ограничений, этого вполне достаточно.
Но чем сильнее сбор данных зависит от браузера, тем больше появляется потенциальных точек, где сигнал можно потерять. Именно эту проблему хорошо показывает уже упомянутая на сайте история с Google Tag Gateway. В материалах Google инструмент описывается как способ запускать Google tags через инфраструктуру самого сайта — например CDN, балансировщик или веб-сервер — и тем самым улучшать качество измерения.
Что меняется при server-side tracking
Основная идея server-side tracking в том, чтобы не оставлять всю передачу событий исключительно на стороне браузера.
Часть данных проходит через серверную инфраструктуру, после чего уже передаётся дальше в рекламную платформу, трекер или другую систему.
Упрощённо:
пользователь → сайт → сервер → рекламная система
Так появляется дополнительный контроль над тем, какие данные отправляются, в каком формате и куда именно они должны попасть.
Но здесь важно не смешивать все инструменты в одно понятие. Server-side GTM, Meta CAPI, postback и Google Tag Gateway — не одно и то же. Они могут решать похожую проблему более стабильной передачи данных, но работают по-разному.
Google Tag Gateway, например, скорее находится рядом с этой логикой, чем является классическим server-to-server трекингом в привычном для арбитражника понимании.
Что именно делает Google Tag Gateway
Смысл Tag Gateway заключается в том, что Google tag может обслуживаться через инфраструктуру и домен рекламодателя, а не только по стандартному пути напрямую к инфраструктуре Google.
Для рекламодателя это даёт более устойчивую схему сбора first-party данных и уменьшает зависимость от части ограничений обычного браузерного трекинга. Google сейчас вообще активно продвигает идею Data Strength — чем качественнее и полнее сигналы, тем больше данных получает автоматическая оптимизация.
Именно поэтому показатель более 20% uplift в Demand Gen интересен не сам по себе. Гораздо важнее другое: Google прямо показывает, насколько серьёзно качество передачи данных уже связано с эффективностью автоматизированных кампаний.
Подробнее механизм уже разбирался в отдельной новости о Google Tag Gateway
Почему потерянные события влияют не только на красивую статистику
Можно подумать: если продажа состоялась и деньги получены, какая разница, увидел её рекламный кабинет или нет?
Разница появляется тогда, когда кампания оптимизируется автоматически.
Google Ads, Meta и другие рекламные системы используют полученные конверсии как сигнал для алгоритмов. Если платформа видит только часть реальных целевых действий, она получает неполную информацию о том, какие пользователи на самом деле приносят результат.
Представим, что реклама привела 100 покупателей, но рекламная система смогла корректно связать с кампанией только 80. Для бизнеса продажи никуда не исчезли. А для алгоритма оставшиеся 20 пользователей выглядят значительно менее понятными.
На небольшом тесте разница может быть почти незаметной. На больших объёмах неполные данные уже могут влиять на обучение кампании, распределение бюджета и работу автоматических стратегий.
Где здесь postback
Арбитражникам серверная передача данных давно знакома хотя бы по postback.
Пользователь совершил целевое действие у рекламодателя, после чего партнёрская система отправляет информацию о конверсии в трекер. Сам браузер пользователя в этой передаче уже не нужен.
Условно:
партнёрка → трекер
Но дальше возникает другая задача — вернуть полезный сигнал рекламной системе:
трекер / сервер / CRM → рекламная платформа
Поэтому postback и server-side tracking не обязательно заменяют друг друга. Они могут работать внутри одной инфраструктуры и закрывать разные участки передачи данных.
По похожему принципу работает Meta CAPI
У Meta для серверной передачи событий используется Conversions API. Он позволяет отправлять данные о событиях напрямую с серверной стороны и дополнять информацию, которую собирает браузерный Pixel.
Из-за этого часто используется комбинированная схема:
Pixel + CAPI
Pixel фиксирует доступные события в браузере, а серверная передача помогает дополнить данные.
У Google экосистема устроена немного иначе: есть Tag Gateway, Enhanced Conversions, Data Manager и другие инструменты, которые постепенно усиливают работу с first-party данными.
Общий тренд при этом один: рекламные платформы стараются меньше зависеть от одного браузерного сигнала.
Главная проблема server-side — события можно задвоить
Как только одна и та же конверсия начинает передаваться несколькими способами, появляется противоположная проблема.
Представим, пользователь совершил покупку. Pixel успешно отправил событие из браузера, а сервер спустя секунду отправил ту же покупку ещё раз.
Если система решит, что это две разные конверсии, статистика уже окажется завышенной.
Поэтому при гибридной передаче событий особенно важна дедупликация. Обычно одной покупке или событию присваивается единый идентификатор, который передаётся разными способами. Тогда платформа понимает, что получила два сигнала об одном действии.
То есть задача server-side tracking заключается не в том, чтобы отправить как можно больше конверсий.
Нужно передать реальные события максимально полно, но не посчитать одну покупку дважды.
Зачем тогда нужен обычный трекер
Трекер при этом никуда не исчезает.
Если команда работает с несколькими источниками, лендингами, офферами и партнёрками, именно он помогает собрать цепочку в одном месте: определить источник клика, сохранить параметры, принять postback и связать конверсию с конкретной кампанией.
Server-side передача решает немного другую задачу — помогает донести нужные сигналы дальше.
Поэтому трекер и server-side tracking логично рассматривать не как конкурирующие решения, а как части одной инфраструктуры.
Трекер показывает, что произошло внутри воронки. Серверная передача помогает нужным платформам получить данные об этом событии.
Когда server-side действительно имеет смысл
Не каждой тестовой кампании нужна сложная серверная инфраструктура.
Если вы только проверяете оффер на небольшом объёме, статистика между системами сходится, а рекламная платформа получает достаточно данных для оптимизации, усложнять схему просто ради модного термина нет особого смысла.
Другое дело, когда объёмы растут, используются автоматические стратегии, а между фактическими конверсиями и данными кабинета появляется стабильная разница.
Особенно чувствительно это для e-commerce, лидогенерации и других моделей, где алгоритм постоянно обучается на покупках, заявках или ценности конверсии.
Чем больше решений рекламный алгоритм принимает автоматически, тем важнее качество данных, на которых он учится.
С чего начинать внедрение
Начинать лучше не с покупки сервера и настройки десятка новых интеграций, а с проверки текущей статистики.
Сравните данные рекламного кабинета с CRM, трекером или партнёрской программой. Посмотрите не только итоговое количество конверсий, но и стабильность расхождения.
Если потери действительно есть, дальше уже можно разбираться, на каком участке они появляются и какой инструмент решает именно вашу проблему: Google Tag Gateway, CAPI, server-side GTM, Enhanced Conversions или другая серверная интеграция.
После подключения нужно снова сверить данные и обязательно проверить дедупликацию.
Если раньше кабинет показывал 100 покупок, а после настройки внезапно начал показывать 170 при неизменной фактической выручке, первым делом стоит проверить не «рост эффективности», а не отправляется ли одно событие несколько раз.
Что в итоге
Недавняя новость о Google Tag Gateway в Demand Gen хорошо показывает, насколько сильно рекламные платформы сегодня зависят от качества данных. Google сообщает, что рекламодатели с усиленным Data Strength и Tag Gateway в среднем получают более 20% conversion uplift в Demand Gen, но этот показатель нельзя автоматически переносить на любую кампанию.
Главный вывод здесь намного шире одной функции Google.
Рекламному алгоритму недостаточно просто получить бюджет и креатив. Ему нужны нормальные сигналы о том, какие пользователи действительно совершают целевые действия.
Поэтому server-side tracking постепенно перестаёт быть исключительно технической темой для аналитиков. На больших объёмах он становится частью работы с рекламными алгоритмами, атрибуцией и оптимизацией.
И если рекламный кабинет регулярно показывает меньше конверсий, чем вы реально получаете, возможно, проблема находится не в оффере и не в качестве трафика.
Иногда часть результата просто теряется между кликом пользователя и моментом, когда рекламная система должна была его увидеть.
Нет комментариев.