Что такое серверный трекинг? Руководство для интернет-магазинов

Серверный трекинг означает, что события конверсий, например покупка, отправляются на рекламные платформы с сервера, а не только из скрипта в браузере покупателя. Для интернет-магазина сервер отправляет каждый заказ в Meta, TikTok или Google через их API, поэтому продажа учитывается, даже если браузерный пиксель заблокирован или не загрузился.

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

Браузерный пиксель и серверный трекинг

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

Серверный трекинг переносит отправку на сервер. Событие может строиться на данных, которые уже есть в вашем магазине, например на оплаченном заказе, а сервер отправляет его в API платформы. Meta называет этот API Conversions API, а TikTok — Events API. Google Ads использует enhanced conversions, которые добавляют к конверсии хешированные данные клиента.

Если запускать оба, платформа получает самые полные данные. Событие из браузера добавляет cookie и контекст страницы. Серверное событие приходит, даже когда браузер подводит. Общий id события гарантирует, что платформа засчитает каждую покупку один раз.

Как работает серверный трекинг?

Серверный трекинг для интернет-магазина состоит из двух частей. Первая происходит в браузере: когда покупатель приходит по рекламе, скрипт сохраняет click id из URL. Вторая происходит на сервере: когда заказ оплачен, сервер связывает этот click id с заказом и отправляет покупку.

Фиксация клика

Рекламные платформы добавляют в URL лендинга click id: fbclid для Meta, ttclid для TikTok, gclid для Google Ads и msclkid для Microsoft Ads. Click id — самая надёжная связь между продажей и рекламой, которая её привела, поэтому его нужно сохранить при первом просмотре страницы. Параметры UTM добавляют названия кампании, группы объявлений и объявления в формате, который вы контролируете.

Сопоставление заказа

Затем серверу нужно узнать, какой посетитель оформил заказ. Самая надёжная связь — значение, которое вместе с корзиной попадает в заказ, например id посетителя, сохранённый в корзине. Другие методы слабее: адрес электронной почты, который посетитель ранее указал на сайте, либо тот же IP-адрес и браузер, замеченные незадолго до заказа. В каждой платформе для интернет-магазинов доступны свои варианты. В нашем руководстве по другим интернет-магазинам перечислены методы, которые ROASaurus использует для каждой платформы.

Отправка события

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

Что содержит серверное событие?

У каждой платформы свои названия полей, но событие покупки везде несёт одни и те же типы данных. Вот сокращённый пример для Meta Conversions API:

{
  "data": [{
    "event_name": "Purchase",
    "event_time": 1793009700,
    "event_id": "order-1042",
    "action_source": "website",
    "event_source_url": "https://yourstore.com/checkout/thank-you",
    "user_data": {
      "em": ["8c87b489ce35cf2e2f39f80e282cb2e804932a56a213983eeeb428407d43b52d"],
      "ph": ["6d420c869d4eb97fe7de4576c9d04bb34d1a5788e0b3a657f61d7be020d8ead0"],
      "client_ip_address": "203.0.113.24",
      "client_user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) ...",
      "fbc": "fb.1.1792832531000.IwAR2xExampleClickId",
      "fbp": "fb.1.1792832529000.1234567890"
    },
    "custom_data": { "currency": "USD", "value": 84.00 }
  }]
}

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

Как работает дедупликация?

Когда пиксель и сервер отправляют одну и ту же покупку, платформа должна засчитать её один раз. Обе копии несут одинаковое название события и одинаковый id события, например order-1042. Meta сравнивает пару и оставляет одну копию, если вторая копия пришла в течение 48 часов после первой.

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

Серверный тегинг и отправка из данных заказа

Термином «серверный трекинг» называют две разные схемы. Обе отправляют события с сервера, но начинаются в разных местах.

Серверный тегинг, например серверные контейнеры Google Tag Manager

При серверном тегинге браузер отправляет свои события на ваш собственный сервер, а не каждому поставщику отдельно. Известный пример — серверный контейнер Google Tag Manager. Он работает в вашем собственном проекте Google Cloud или в другой выбранной вами среде. Он принимает запросы из браузера, а его теги пересылают данные в Google Analytics, Meta и другим поставщикам. Вы решаете, какие данные куда уходят, а сервер может работать на поддомене вашего сайта.

События по-прежнему начинаются в браузере. Если тег в браузере заблокирован или страница благодарности так и не загрузилась, серверному контейнеру нечего пересылать. Кроме того, вы сами запускаете сервер, платите за него и обновляете его.

Отправка из данных заказа

Второй подход строит покупку на записи заказа в вашем магазине. Магазин сообщает серверу об оплаченном заказе через webhook или API, а сервер отправляет его на все подключённые платформы. Браузер нужен только раньше, чтобы сохранить click id, когда покупатель приходит на сайт.

Эти два подхода можно совмещать. Многие магазины собирают просмотры страниц и добавления в корзину в браузере, а покупку отправляют из данных заказа. Именно по покупке рекламные платформы считают ROAS и оптимизируют ставки, поэтому это событие нужно передавать наиболее полно.

Что серверный трекинг исправляет, а что нет?

Согласие по-прежнему действует

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

Атрибуция остаётся у каждой платформы своей

Каждая платформа по-прежнему засчитывает покупки по своим окнам и правилам. Серверные события дают каждой платформе лучшие данные, но итоги по Meta, TikTok и Google всё равно могут в сумме превышать выручку вашего магазина. Чтобы сравнивать каналы по единым правилам, используйте одну модель атрибуции для всех, например модели из атрибуции ROASaurus.

Нужен ли серверный трекинг вашему магазину?

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

• Рекламная платформа получает заметно меньше событий покупки, чем у вашего магазина веб-заказов. В нашем руководстве о блокировщиках рекламы и трекинге показано, как измерить этот разрыв.
• Многие ваши посетители пользуются Safari на iPhone или Mac, где cookie, установленные скриптами, живут не дольше 7 дней. См. Safari ITP и рекламный трекинг.
• Покупатели часто покупают через несколько дней после первого клика по рекламе.
• Оплата завершается вне вашего сайта или заказы оплачиваются позже, как при наложенном платеже или банковском переводе.
• Вы оптимизируете кампании под покупки или ценность покупки, поэтому платформе нужна каждая продажа, чтобы на ней учиться.

Вот как разрыв влияет на решения на практике. У примера магазина за месяц 1,000 веб-заказов. Его пиксель Meta зафиксировал 820 событий Purchase, то есть 18% заказов так и не дошли до Meta из браузера.

ROAS безубыточности магазина равен 2.5, а Ads Manager показывает ROAS 2.3 по данным пикселя. По этим цифрам кампании убыточны. Если заказы из рекламы терялись с той же долей 18%, реальный ROAS составляет около 2.3 ÷ 0.82 = 2.8, то есть выше безубыточности. Это верхняя оценка, потому что не каждый потерянный заказ пришёл из рекламы. Но она показывает, как разрыв в трекинге может заставить прибыльную кампанию выглядеть убыточной.

Серверный трекинг менее важен для магазина, который не рекламируется или тратит на рекламу совсем немного.

Как ROASaurus отправляет серверные события

ROASaurus фиксирует 19 click id и шесть полей UTM при заходе на сайт и сохраняет их вместе с first-party visitor id. Он отправляет каждую покупку из оплаченных заказов вашего магазина в Meta, TikTok, Snapchat, Pinterest, Reddit, X, Microsoft Ads, Taboola, LinkedIn, OpenAI Ads, Spotify, AppLovin, Criteo, AdRoll и Outbrain. В Shopify конверсии Google Ads отправляются из чекаута Shopify. Браузерные пиксели могут работать параллельно с серверными событиями с тем же event id, а Meta, TikTok, Snapchat, Pinterest, Reddit, OpenAI Ads, AppLovin и Spotify дедуплицируют их. Каждая отправка и ответ платформы перечислены в Event log.

Подробнее читайте на странице серверного трекинга или найдите свой интернет-магазин на странице интеграций.

Источники

1. Meta for Developers: Conversions API
2. Meta for Developers: Handling Duplicate Pixel and Conversions API Events
3. Meta for Developers: Customer Information Parameters
4. Google for Developers: An introduction to server-side tagging
5. Google Ads Help: About enhanced conversions

В ROASaurus

• Серверный трекинг в ROASaurus
• Согласие и конфиденциальность
• Как избежать двойного учёта

Читайте дальше