Серверная передача конверсий: как включить и не получить двойной счёт

Серверная передача конверсий (CAPI) отправляет данные о действиях пользователей с вашего сайта напрямую в рекламный кабинет, минуя браузер. Это делается для того, чтобы алгоритмы точнее оптимизировали показы, но при неправильной настройке вы получите двойной счёт: одно и то же действие зачтётся дважды, и статистика станет бесполезной. Ниже разберём, как включить передачу и настроить её так, чтобы в кабинете были только реальные уникальные конверсии.

Коротко

• Двойной счёт возникает, когда событие передаётся и пикселем (через браузер), и через сервер без корректной дедупликации.
• Система убирает дубли по ключу: событие + идентификатор пользователя (Client ID или Event ID) + время.
• Есть три способа настройки: через партнёра (Google Tag Manager, CMS-плагин), через API напрямую или через сторонний сервис.
• Проверка на дубли: сравните число конверсий в кабинете с числом заказов в CRM за тестовый период.
• Если цифры разошлись, сначала проверяйте, совпадает ли идентификатор, который вы передаёте, с тем, что видит пиксель.

Как работает серверная передача конверсий и почему появляется двойной счёт

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

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

Чтобы этого избежать, нужно передавать в обоих запросах одинаковый ключ дедупликации. Обычно это комбинация из названия события, идентификатора клиента (Client ID) и времени действия.

Что нужно знать о дедупликации до настройки

Дедупликация работает по принципу точного совпадения полей. Система сравнивает входящие запросы и отбрасывает те, где ключ уже встречался. Механика одинакова у Google Ads и Meta Ads, но названия полей и способы их получения отличаются.

Для Meta Ads (Facebook) ключ дедупликации — это event_id (уникальный номер события) и client_user_agent (если передаёте с сервера). Для Google Ads — gclid (идентификатор клика Google) и conversion_date_time (точное время конверсии) или conversion_environment.

На практике чаще всего используют Client ID для Google Analytics 4 и event_id для Meta. Важно, чтобы пиксель и серверная передача использовали один и тот же источник этого ID. Если пиксель генерирует свой идентификатор, а сервер берёт его из базы данных, но с ошибкой в формате, дубли не склеятся.

Минимальные требования для корректной дедупликации:

Если вы передаёте данные только с сервера (без пикселя), проблема двойного счёта не возникает. Она появляется исключительно при параллельной работе обоих каналов.

Способы настроить серверную передачу конверсий

Выбор метода зависит от вашего стека: есть ли доступ к коду сайта, используете ли вы CMS, готовы ли платить за посредника.

Первый способ — через менеджер тегов или плагин. Google Tag Manager имеет встроенные шаблоны для серверной передачи, а для популярных CMS (WordPress, Tilda, Shopify) есть плагины, которые отправляют события на сервер автоматически. Это самый быстрый вариант, но он ограничен возможностями плагина.

Второй способ — прямая интеграция через API. Вы пишете код на своём бэкенде, который отправляет POST-запросы на эндпоинты рекламной платформы. Даёт полный контроль над данными, но требует разработчика и времени на отладку.

Третий способ — через сервис-посредник (например, серверный контейнер Google Tag Manager или сторонние платформы типа OWOX, Hyros). Они берут на себя передачу данных и дедупликацию. Подходит, если у вас несколько источников трафика и нужно сводить всё в одной точке.

Что выбрать в зависимости от ситуации:

• У вас интернет-магазин на WordPress и нет программиста — ставьте плагин, который официально поддерживает CAPI.
• У вас своя CRM и отдел разработки — прямая интеграция через API даст больше гибкости.
• У вас несколько рекламных кабинетов и сайтов — используйте сервис-посредник, чтобы не плодить интеграции.

Пошаговая инструкция для Meta Pixel и CAPI

Разберём настройку на примере Meta, потому что именно там двойной счёт встречается чаще всего. Схема действий подходит для любого сайта, где уже стоит пиксель.

1. Включите CAPI в кабинете. Перейдите в раздел «Наборы событий» или «Pixel», найдите пункт «Серверные события» и нажмите «Начать».
2. Выберите способ подключения. Если у вас WordPress, поставьте плагин Meta for Business. Если нет — выберите «Настроить вручную» и скопируйте токен доступа и ID пикселя.
3. Настройте передачу event_id. Это самый важный шаг. В коде пикселя, в момент отслеживания конверсии, добавьте параметр eventID с уникальным значением. Это же значение отправьте с сервера в поле event_id.
4. Укажите источник событий. В настройках набора событий отметьте, что события приходят и из браузера, и с сервера. Система попросит выбрать параметры для сопоставления: event_id, client_id или оба.
5. Проверьте статус подключения. В кабинете появится индикатор «Активно» с зелёной точкой. Если статус «Неактивно», проверьте, доходят ли запросы с сервера.
6. Сравните данные. Откройте раздел «Диагностика событий» и посмотрите на количество полученных событий. Оно должно примерно совпадать с числом заказов в CRM.

Нумерация шагов не случайна: пропуск третьего пункта почти гарантированно приводит к двойному счёту. Если вы не передаёте event_id, платформа пытается сопоставить события по времени и IP, но это ненадёжно.

Как избежать двойного счёта в Google Ads

В Google Ads логика другая: там нет отдельного пикселя и сервера в привычном понимании. Вы настраиваете передачу данных через Google Analytics 4 или через Google Ads API напрямую.

Если вы используете GA4, двойной счёт возможен, когда одно и то же событие отправляется и через gtag.js (библиотеку на сайте), и через Measurement Protocol (серверный способ отправки). Чтобы этого избежать, в GA4 есть параметр conversion_environment, который указывает, откуда пришло событие: из браузера или с сервера.

Правило для Google Ads: выберите один канал передачи. Если вы уже отправляете конверсии через GA4, не подключайте дополнительно Google Ads API для тех же целей. Либо настройте в GA4 правило, чтобы серверные события не дублировали браузерные.

На практике чаще всего работает связка: GA4 получает данные из браузера, а серверная передача используется только для событий, которые браузер не видит (например, возврат товара или звонок из CRM). Тогда двойного счёта не возникает по определению.

Проверка: как убедиться, что двойного счёта нет

После настройки подождите 2-3 дня, чтобы накопилась статистика, и проведите сверку.

Порядок действий для проверки:

1. Зафиксируйте количество конверсий в рекламном кабинете за конкретный период.
2. Выгрузите из CRM список заказов или заявок за тот же период, которые пришли из рекламы.
3. Сравните цифры. Допустимое расхождение — 5-10% из-за того, что часть пользователей отключает cookies или использует VPN.
4. Если расхождение больше 20%, проверьте, не передаёте ли вы события дважды. Откройте «Журнал событий» в кабинете и посмотрите, есть ли записи с одинаковым event_id.
5. Если дубли найдены, исправьте код на сервере и в пикселе, чтобы они использовали один и тот же идентификатор.

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

Типичные ошибки при настройке серверной передачи

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

Первая ошибка — передача event_id в разном формате. На клиенте вы сгенерировали 12345, а сервер отправил 12345.0 или с пробелом. Система считает это разными событиями. Решение: используйте строковый тип данных и проверяйте, что значение не меняется при передаче.

Вторая ошибка — отправка серверных событий без проверки на то, что пользователь вообще приходил из рекламы. Если вы передаёте все заказы с сайта, а не только те, что были после клика по объявлению, вы завышаете конверсии. Фильтруйте события по наличию Client ID или gclid.

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

Четвёртая ошибка — игнорирование задержек. Серверная передача может идти с опозданием, а пиксель срабатывает мгновенно. Если сервер отправляет событие через 10 минут после действия, а пиксель уже передал его, дедупликация по времени может не сработать. Старайтесь отправлять серверные события сразу после действия или в течение минуты.

И последняя, пятая ошибка — не проверять статус подключения после обновлений сайта. Любое изменение кода может сломать передачу. Регулярно заглядывайте в диагностику событий.

Когда серверная передача нужна, а когда можно обойтись

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

Она нужна, если вы вкладываете значительный бюджет в рекламу и наблюдаете, что конверсий в кабинете меньше, чем заказов в CRM. Или если ваша аудитория часто пользуется Safari и Firefox, где cookies живут недолго.

Она не нужна, если весь трафик идёт из Google Chrome, а конверсии считаются корректно. В этом случае настройка CAPI добавит работы разработчикам, но не улучшит результаты.

Если вы только начинаете разбираться в аналитике, сначала настройте сквозную аналитику и поймите, откуда приходят заказы. Возможно, проблема не в потере данных, а в том, что вы смотрите не на те метрики. Иногда бюджет уходит на площадках, которые почти не дают конверсий, и серверная передача это не исправит. О том, как выявить такие площадки, читайте в материале про Audience Network, Search Partners и Pangle.

Что делать после настройки: следующий шаг

После того как вы включили серверную передачу и убедились, что двойного счёта нет, не останавливайтесь. Проверьте, как изменение повлияло на оптимизацию кампаний. Если раньше алгоритм недополучал данные, теперь он может начать активнее обучаться. Дайте кампаниям 3-5 дней на переобучение и только потом принимайте решения о ставках.

Затем проведите полный аудит рекламного кабинета, чтобы убедиться, что все остальные настройки тоже корректны: аудит рекламного кабинета за 30 минут покажет, какие ещё места стоит проверить.

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

Частые вопросы

Что такое серверная передача конверсий простыми словами? Это способ отправки данных о действиях пользователей на сайте напрямую с вашего сервера в рекламный кабинет, минуя браузер. Данные не зависят от блокировщиков рекламы и настроек приватности браузера, поэтому доходят до алгоритмов точнее.

Почему возникает двойной счёт при серверной передаче? Когда одно и то же событие отправляется и пикселем из браузера, и с сервера, платформа получает два одинаковых сигнала. Чтобы их объединить, нужен общий идентификатор события (event_id или client_id). Если он не совпадает, система считает два разных действия.

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

Сколько времени занимает настройка серверной передачи? От 2 часов при использовании плагина для CMS до 2-3 дней при прямой интеграции через API. Время зависит от доступности разработчика и сложности сайта. Основное время уходит на согласование идентификаторов и проверку дедупликации.

Что делать, если после настройки конверсий стало меньше? Это нормально на первых порах. Система могла засчитывать дубли ранее, и теперь цифра стала честнее. Подождите 3-5 дней: алгоритмы переобучаются на новых данных, и количество конверсий должно стабилизироваться. Если этого не произошло, проверьте, не потерялись ли события из-за ошибок в передаче.

Похожие материалы

• Когда данных достаточно, чтобы отключить объявление
• Площадки, на которых бюджет исчезает: Audience Network, Search Partners и Pangle

Посмотреть, как это устроено в ADS Beast: серверная передача конверсий.