---
title: "Серверный трекинг: зачем нужен и как внедрить без GTM"
description: "Как отправлять конверсии с сервера в рекламные системы и GA4 без GTM: логика, идентификаторы, дедупликация и проверка событий."
canonical: https://adsbeast.pro/blog/ru/servernyy-treking-zachem-nuzhen-i-kak-vnedrit-bez-gtm
language: ru
published: 2026-11-02T02:33:38.681Z
updated: 2026-11-02T02:33:38.681Z
author: "Редакция ADS Beast"
translations:
  - en: https://adsbeast.pro/blog/en/server-side-tracking-without-gtm-setup-that-survives
  - he: https://adsbeast.pro/blog/he/server-side-tracking-without-gtm-setup-that-survives
  - pl: https://adsbeast.pro/blog/pl/sledzenie-po-stronie-serwera-bez-gtm-wdrozenie-krok-po-kroku
  - sk: https://adsbeast.pro/blog/sk/serverove-sledovanie-bez-gtm-ako-ho-zaviest
  - uk: https://adsbeast.pro/blog/uk/serverniy-treking-navishcho-potriben-i-yak-vprovaditi-bez-gtm
---
# Серверный трекинг: как настроить отправку конверсий без GTM

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

**Коротко**

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

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

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

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

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

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

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

| Критерий | Браузерный пиксель | Серверный трекинг |
|---|---|---|
| Где формируется событие | В браузере пользователя | На сервере или в бэкенде CRM |
| Зависимость от блокировщиков | Есть | Нет |
| Данные в событии | То, что доступно на странице | Сумма, статус, ID из базы |
| Сложность внедрения | Низкая | Средняя и выше |
| Риск задвоения | Есть при параллельной отправке | Есть, снимается общим ID |
| Проверка | Отладка в браузере | Журнал отправок и отчёты площадки |

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

## Как внедрить серверный трекинг без 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 конверсий и его границы](/blog/ru/api-konversiy-chto-dayot-i-chego-ne-zamenyaet).

Отдельно про звонки: если конверсией считается звонок, серверное событие привязывают к номеру заказа или лида, который создаёт коллтрекинг. Как это устроено, разбирает материал [про отслеживание звонков и связку с кампанией](/blog/ru/otslezhivanie-zvonkov-svyazka-zvonka-s-kampaniey).

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

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

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

Если цифры в GA4 и в рекламном кабинете не сходятся, это не всегда ошибка трекинга. Причины расхождений разобраны в статье [про то, почему GA4 и рекламный кабинет показывают разные цифры](/blog/ru/ga4-i-reklamnyy-kabinet-pochemu-tsifry-raskhodyatsya). А базовую проверку того, что счётчики вообще стоят и работают, стоит делать до любых экспериментов — [проверка установки счётчиков за пять минут](/blog/ru/ustanovka-schyotchikov-proverka-za-pyat-minut).

Серверные конверсии из стадий CRM и отчёты с CPA, CTR, CPC и CPM доступны в [инструментах отслеживания конверсий](/features/ru/tracking); они помогают держать отправку событий и сверку в одном месте. Если серверный трекинг — часть более широкой задачи, посмотрите [минимальный набор для сквозной аналитики своими силами](/blog/ru/skvoznaya-analitika-svoimi-silami-minimalnyy-nabor).

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

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

## Вопросы и ответы

### Что такое серверный трекинг простыми словами?

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

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

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

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

Событие формируется на вашем сервере или в бэкенде CRM в момент нужного действия и отправляется запросом в API площадки или в Measurement Protocol для GA4. Дальше настраивается сопоставление: одно и то же имя события и одинаковый идентификатор заказа должны уходить и из браузера, и с сервера, чтобы система не посчитала покупку дважды. Проверить работу можно в отчётах площадки и в интерфейсе приёма событий, сравнив записи с данными вашей базы.

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

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

### Где хранить логику серверных событий: в CRM, на бэкенде или в отдельном сервисе?

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