Серверный трекинг: как настроить отправку конверсий без GTM

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

Коротко

• Событие формируется там, где появляется достоверный факт: в бэкенде сайта или в CRM при смене стадии.
• Без GTM всё делается запросом к API площадки или к Measurement Protocol для GA4.
• Чтобы конверсии не задвоились, нужен стабильный ID заказа, одинаковый в браузере и на сервере.
• Measurement Protocol отправляет события в GA4, а не напрямую в Google Ads: это разные пути.
• Работу проверяют сверкой журнала отправок с данными вашей базы и отчётами площадки.

Зачем нужен серверный трекинг и что он решает

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

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

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

Чем серверный трекинг отличается от браузерного пикселя

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

Выбирать «или-или» не нужно. Разумная схема — оставить пиксель и добавить серверную отправку с общим идентификатором. Так вы не теряете быстрые события вроде просмотра страницы и получаете надёжные данные по покупкам.

Как внедрить серверный трекинг без Google Tag Manager

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

1. Определите, какое действие считается конверсией и где оно достоверно фиксируется. Оплата в биллинге, смена стадии сделки в CRM, подтверждение заявки оператором.
2. Выберите стабильный идентификатор события: номер заказа, transaction ID или внутренний ID записи в CRM. Он должен быть одинаковым для одной и той же покупки во всех источниках.
3. Сформируйте событие в момент действия и отправьте запрос в API площадки. Для GA4 это Measurement Protocol.
4. Настройте сопоставление с браузерным трекингом: одно имя события и один идентификатор с обеих сторон.
5. Заведите журнал отправок: что ушло, когда, с каким ID и какой ответ вернул сервер.
6. Сверьте записи журнала с данными базы и с тем, что показывает интерфейс приёма событий площадки.

Шестой шаг пропускают чаще всего. Без сверки невозможно отличить «событие не отправилось» от «событие отправилось, но не принято». Это разные проблемы и чинятся они по-разному.

Где хранить логику серверных событий

Место зависит от того, где появляется достоверное событие. Если статус оплаты меняется в CRM, отправку удобнее ставить на смену стадии. Если покупка фиксируется в биллинге сайта, логику кладут на бэкенд. Отдельный сервис-посредник имеет смысл, когда источников несколько и нужно единое правило сопоставления событий.

У каждого варианта свои слабые места. Логика в CRM зависит от того, насколько аккуратно менеджеры двигают стадии: ручные перескоки дают ложные события. Логика на бэкенде зависит от релизов сайта: при обновлении checkout отправку легко сломать незаметно. Посредник добавляет точку отказа и требует сопровождения.

Что бы вы ни выбрали, журнал отправок нужен в любом случае. Он отвечает на вопрос «какие события ушли и с какими идентификаторами» без чтения кода.

Какой идентификатор нужен, чтобы конверсии не задвоились

Нужен стабильный ID, который одинаков для одной и той же покупки во всех источниках: номер заказа, transaction ID или внутренний идентификатор записи в CRM. Google Ads дедуплицирует повтор одной конверсионной акции с тем же transaction/order ID. Одинаковый ID не объединяет разные конверсионные акции, поэтому важно не только передать ID, но и не заводить отдельные акции под одну и ту же покупку.

Google поддерживает согласованные источники: браузер и серверную загрузку с общим ID. Утверждение «оставьте только один источник» неверно. Другой вопрос — как акции учитываются в отчётах: primary и secondary определяют включение в «Conversions» и в ставки, secondary видны в «All conversions», у custom goals свои правила. Раздельные акции для одной покупки могут искажать итог, но наличие двух источников само по себе не доказывает двойной счёт.

У Meta логика похожая: дедупликация пикселя и Conversions API идёт по совпадению названия события и event_id, отдельного переключателя нет. Поэтому имя события и ID — не формальность, а рабочий механизм.

Какие ограничения и ошибки встречаются на практике

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

Вторая — разные имена событий в браузере и на сервере. Система видит два разных события и не может их сопоставить. Договоритесь о словаре событий до внедрения.

Третья — отсутствие повторов при сбоях сети. Запрос не дошёл, событие потеряно, и никто об этом не узнал. Нужна повторная отправка с тем же ID: дедупликация как раз для этого и существует.

Четвёртая — путаница путей. Measurement Protocol отправляет серверные события в GA4, а не напрямую в Google Ads. Импорт из GA4 и передача через Google Ads API или Data Manager — разные пути, и называть Measurement Protocol настройкой конверсионного действия Google Ads нельзя. Подробнее о том, что умеет и чего не заменяет такой канал, — в разборе про API конверсий и его границы.

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

Что проверить после внедрения

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

• Событие уходит в момент фактического действия, а не раньше.
• Имя события одинаково в браузере и на сервере.
• ID заказа уникален и не меняется при повторной отправке.
• В журнале видно ответ площадки на каждый запрос.
• В отчётах нет систематического расхождения с базой.

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

Серверные конверсии из стадий CRM и отчёты с CPA, CTR, CPC и CPM доступны в инструментах отслеживания конверсий; они помогают держать отправку событий и сверку в одном месте. Если серверный трекинг — часть более широкой задачи, посмотрите минимальный набор для сквозной аналитики своими силами.

Следующий шаг

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