Серверный трекинг GA4 через уровень редиректов

Клиентская маркировка GA4 через gtag.js или GTM - это база атрибуции, которую большинство команд использует по умолчанию. Это хорошо работает в идеальных условиях: пользователь Chrome на десктопе с быстрым соединением, без блокировщика рекламы, сессия в Safari, которая не попала под ограничение 24-часового жизненного цикла скриптовых кук ITP. Идеальные условия покрывают примерно 65-75% трафика в ЕС в 2026 году.

Остальное - пользователи uBlock Origin, встроенная блокировка Brave, Intelligent Tracking Prevention от Safari на iOS, растущая группа блокировщиков на уровне сети, таких как NextDNS и Pi-hole - отправляет события, которые либо пропадают, не дойдя до www.google-analytics.com, либо приходят без пригодного для использования идентификатора клиента, потому что кука _ga была удалена. Типичный разрыв на аудиториях с преобладанием ЕС составляет 25-35% событий конверсии. В некоторых отраслях - финтех, инструменты конфиденциальности, инструменты для разработчиков - он еще выше, так как демография пользователей коррелирует с использованием блокировщиков рекламы.

Measurement Protocol в GA4 - это серверный путь, который обходит все эти ограничения. Ваш сервер напрямую общается с эндпоинтом сбора данных Google. Состояние браузера не имеет значения. В этом посте рассматривается точная настройка: учетные данные, форма полезной нагрузки, привязка client_id, валидация и паттерн дедупликации для команд, использующих gtag параллельно с серверным путем.

Базовая архитектура пересылки конверсий - почему серверный путь выигрывает и как работает разветвление на несколько платформ - описана в обзоре серверного отслеживания конверсий. Версия этого руководства для Meta CAPI находится по адресу пересылка конверсий в Meta CAPI; паттерн настройки идентичен, здесь приведены специфичные для GA4 параметры.

TL;DR

• GA4 gtag.js теряет 25-35% событий конверсии на типичном трафике из ЕС из-за блокировщиков рекламы (uBlock, Brave) и ITP (ограничения срока жизни кук Safari); Measurement Protocol обходит все это, так как запрос исходит от вашего сервера.
• Вам понадобятся два реквизита: Measurement ID (G-XXXXXXXX) вашего потока данных и API secret, созданный в разделе Admin → Data Streams → Measurement Protocol API secrets. Именно их запрашивает интеграция Elido с GA4, которая пересылает события кликов (не покупки) и настраивается примерно за две минуты.
• client_id - это то, что связывает серверное событие с сессией GA4. Elido не проставляет ID клика и не устанавливает куку при редиректе по короткой ссылке, а покупки в GA4 пока не пересылает, поэтому вы фиксируете client_id на собственном сайте и отправляете событие Measurement Protocol со своего сервера.
• Валидация занимает около десяти минут: GA4 DebugView показывает события Measurement Protocol, поступающие примерно в течение десяти секунд; стандартные отчеты обновляются в течение 24-48 часов.

Две необходимые учетные данные

Для GA4 Measurement Protocol требуются две части информации, обе из консоли администратора GA4.

Measurement ID. Идентификатор потока данных в формате G-XXXXXXXX. Его можно найти в Admin → Data Streams → ваш веб-поток → панель сведений о потоке. Это тот же ID, который вы передаете в gtag('config', 'G-XXXXXXXX') при клиентской настройке - это не секрет, он виден в исходном коде страницы.

API secret. Это учетные данные, которые разрешают серверную запись в эндпоинт сбора. Перейдите в Admin → Data Streams → ваш веб-поток → Measurement Protocol API secrets → Create. Секрет представляет собой короткую буквенно-цифровую строку. Относитесь к нему как к ключу сервисного аккаунта: храните его как секрет рабочего пространства, ротируйте вместе с другими сервисными учетными данными, не фиксируйте в исходном коде.

В Elido они вставляются в настройки рабочего пространства в разделе Integrations → GA4. Нажатие Test connection отправляет тестовое событие на сервер валидации GA4 и, если полезная нагрузка проходит проверку, отправляет его по-настоящему с установленным debug_mode. Эта проверка охватывает полезную нагрузку, но не учетные данные: сервер валидации принимает любой API secret и даже Measurement ID, который не относится ни к одному ресурсу, поэтому успешный результат не доказывает корректность пары. Подтвердите тестовое событие в DebugView или Realtime, прежде чем полагаться на эту настройку.

Форма события

В справочнике GA4 Measurement Protocol (доступ от 12.05.2026) указан формат запроса. Эндпоинт:

POST https://www.google-analytics.com/mp/collect?measurement_id=G-XXXXXXXX&api_secret=<secret>

Тело запроса содержит client_id, необязательный user_id и массив events. Вот полезная нагрузка для события покупки:

{
  "client_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "user_id": "user-shop-12847",
  "events": [
    {
      "name": "purchase",
      "params": {
        "transaction_id": "ord_98231",
        "value": 89.5,
        "currency": "EUR",
        "engagement_time_msec": 1,
        "items": [
          {
            "item_id": "sku-spring-jeans-32-blue",
            "item_name": "Spring Jeans 32 Blue",
            "quantity": 1,
            "price": 89.5
          }
        ]
      }
    }
  ]
}

Несколько моментов в этой полезной нагрузке, в которых легко ошибиться:

event_name должен быть в нижнем регистре snake_case. В справочнике событий GA4 (доступ от 12.05.2026) перечислены рекомендуемые названия событий: purchase, sign_up, generate_lead, add_to_cart. Отправка Purchase (с заглавной P) создаст отдельное событие в отчетах GA4, а не объединит его с вашими событиями purchase, запущенными через gtag. Платформа не выдает предупреждений; событие просто фиксируется как кастомное событие с необычным именем.

engagement_time_msec должен присутствовать и быть положительным целым числом. Без него GA4 засчитает событие, но не засчитает вовлеченность в сессии, и некоторые модели атрибуции исключают события без времени вовлеченности. Значения 1 достаточно для выполнения требования.

event_params ограничено 25 параметрами на событие. Measurement Protocol отклонит полезную нагрузку, превышающую этот лимит. Отклонение по умолчанию происходит молча - запрос возвращает 204 без тела независимо от того, было ли событие принято. Используйте отладочный эндпоинт с validation_behavior, установленным в ENFORCE_RECOMMENDATIONS (описанный в разделе валидации), чтобы отловить переполнения; режим по умолчанию пропускает 26-й параметр.

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

Привязка client_id: почему это важно и как это делает Elido

client_id - это поле, которое GA4 использует для связи серверного события с сессией браузера. Когда gtag.js запускается на странице, он считывает куку _ga и использует её UUID в качестве client_id для всех запускаемых событий. Если ваше серверное событие содержит тот же client_id, GA4 сможет объединить эти события в один путь пользователя и сессию.

Задача состоит в том, чтобы передать этот UUID на сторону сервера. Кука _ga является 1st-party кукой на вашем домене, поэтому ваш сервер может считать её во время оформления заказа и включить в полезную нагрузку конверсии. Но это работает только в том случае, если в браузере пользователя установлена кука _ga, а это как раз та часть аудитории, которую вы теряете из-за ITP и блокировщиков рекламы.

Elido пока не решает эту проблему на уровне редиректов: он не устанавливает куку и не добавляет ID клика к целевому URL, а также не пересылает конверсии в GA4. ID клика есть в нашем бэклоге, но не выпущен. Пока вы строите связку сами, на своём сайте. Поток:

Ваша целевая страница или диспетчер тегов считывает значение _ga, если оно есть, или генерирует собственный 1st-party UUID, если его нет, и записывает его в кастомные атрибуты заказа. В момент конверсии ваш вебхук заказа передаёт это значение. Ваш сервер формирует полезную нагрузку Measurement Protocol с client_id, равным ему, и отправляет её в GA4.

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

В руководстве по отправке событий GA4 (доступ от 12.05.2026) описывается, как client_id работает в клиентских и серверных путях.

Пересылка Elido: реальный curl

Elido не собирает и не пересылает эту полезную нагрузку для покупок; это делает ваш собственный сервер, когда приходит вебхук заказа. Вызов, который он совершает и который можно также выполнить вручную для проверки стороны GA4 в связке, выглядит так:

curl -X POST \
  "https://www.google-analytics.com/mp/collect?measurement_id=G-XXXXXXXX&api_secret=YOUR_SECRET" \
  -H "Content-Type: application/json" \
  -d '{
    "client_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
    "user_id": "user-shop-12847",
    "events": [
      {
        "name": "purchase",
        "params": {
          "transaction_id": "ord_98231",
          "value": 89.50,
          "currency": "EUR",
          "engagement_time_msec": 1
        }
      }
    ]
  }'

GA4 возвращает 204 как для валидных, так и для невалидных событий. Вы не сможете отличить неверно сформированное событие от успешного приема только по коду состояния HTTP. Чтобы увидеть, корректно ли сформировано событие, используйте отладочный эндпоинт во время разработки:

POST https://www.google-analytics.com/debug/mp/collect?measurement_id=G-XXXXXXXX&api_secret=YOUR_SECRET

Отладочный эндпоинт возвращает тело JSON со списком ошибок валидации для каждого события. Событие с неверным именем параметра, полезной нагрузкой более 25 параметров или некорректным client_id отобразится здесь. Некоторые из них отображаются только если для validation_behavior в теле отладки задано значение ENFORCE_RECOMMENDATIONS, а API secret вообще не проверяется; в руководстве по отладке Measurement Protocol описано, что именно проверяет валидатор, а что нет.

При использовании Elido Test connection выполняет эту проверку для вас и показывает все validationMessages как ошибку. Чистый результат по-прежнему ничего не говорит об API secret, поэтому следующий шаг - DebugView.

Валидация: DebugView

DebugView в GA4 - это самый быстрый цикл обратной связи во время настройки. Чтобы активировать его для серверных событий, добавьте "debug_mode": 1 в объект params события. События с этим флагом появляются в DebugView примерно через десять секунд; они не учитываются в данных рабочих отчетов.

В DebugView (GA4 Admin → DebugView) для каждого события отображается его имя, переданные параметры и информация о том, были ли отклонены какие-либо параметры. Представление группирует события по client_id, так что вы можете отследить весь путь пользователя от клика до конверсии.

Что нужно проверить перед удалением debug_mode:

• Имя события отображается именно так, как ожидалось, в потоке событий DebugView (purchase, а не Purchase или ecommerce_purchase).
• Параметр transaction_id виден и соответствует формату ID вашего заказа.
• client_id представляет собой строку в формате UUID - не пустую и не резервную строку "unknown".
• currency - это правильный код ISO 4217 (EUR, а не eur или Euro).

Стандартным отчетам GA4 требуется 24-48 часов, чтобы отразить данные о серверных конверсиях. Не оценивайте точность отчетов в первый день. DebugView подтверждает форму события; отчеты подтверждают атрибуцию и итоги.

Распространенные ошибки

Отсутствие client_id. События без client_id молча отбрасываются Measurement Protocol. Это самая распространенная причина сбоев. Отбрасывание невидимо - запрос возвращает 204, DebugView ничего не показывает, конверсия никогда не появляется. Убедитесь, что поле client_id всегда заполнено перед отправкой запроса. В описанной выше настройке отсутствие client_id означает, что идентификатор не был записан в заказ при конверсии - проверьте тег целевой страницы или обработчик вебхука.

Неверный формат имени события. Purchase создает кастомное событие с именем Purchase наряду с существующими событиями purchase из gtag. Общее количество покупок в отчетах GA4 будет разделено на два имени событий. Решение - принудительное использование нижнего регистра snake_case для всех имен событий, отправляемых на эндпоинт Measurement Protocol. В справочнике событий GA4 (ссылка выше) перечислены канонические имена для событий электронной коммерции.

Превышение 25 event_params. Measurement Protocol молча отклоняет полезную нагрузку, содержащую более 25 параметров на событие. Команды, пересылающие полные метаданные заказа (все позиции, все кастомные атрибуты), часто достигают этого лимита, не осознавая этого. Используйте отладочный эндпоинт в режиме ENFORCE_RECOMMENDATIONS, чтобы отловить переполнения при разработке. В продакшене удаляйте несущественные параметры и делайте полезную нагрузку событий лаконичной.

Валюта берется из конфигурации страницы, а не из заказа. Если ваша настройка gtag по умолчанию использует USD, а ваши заказы оформлены в EUR, серверное и клиентское события будут содержать разные значения валюты. GA4 записывает их под одним и тем же именем события, но не может агрегировать значения. Берите валюту из записи заказа в вашем бэкенде, а не из конфигурации gtag на уровне страницы.

Дедупликация с клиентским gtag

Если вы одновременно используете клиентский gtag.js и серверный Measurement Protocol, вам понадобится дедупликация. GA4 дедуплицирует события, используя client_id в сочетании с временным окном. Этот механизм менее явный, чем поле event_id в Meta CAPI, но практический подход такой же: передавайте согласованный transaction_id в событиях покупки по обоим путям.

Для событий покупки установите transaction_id равным ID вашего заказа. Ваш клиентский gtag запускает purchase с transaction_id: "ord_98231" при загрузке страницы подтверждения; ваше серверное событие Measurement Protocol содержит тот же transaction_id: "ord_98231". GA4 дедуплицирует их в пределах одного окна сессии. Если одна и та же комбинация client_id + transaction_id придет дважды в течение окна дедупликации, вторая будет проигнорирована.

Для событий выше по воронке - generate_lead, sign_up, add_to_cart - нет ID заказа, который можно было бы использовать. Здесь подойдёт сгенерированный вами идентификатор посетителя: установите event_id на UUID, который вы сохранили на собственном сайте. И пиксель на стороне браузера, и серверная пересылка ссылаются на одно и то же значение. Эта же дисциплина описана в руководстве по сквозному отслеживанию UTM, которое охватывает более широкую настройку тегирования кампаний, которая проносит идентификаторы через всю воронку.

Окно дедупликации в GA4 не документировано публично с такой точностью, как это делает Meta для CAPI. На практике события с совпадающими client_id + transaction_id, поступающие в течение одного окна сессии, дедуплицируются. Одновременное использование обоих путей является более безопасной конфигурацией - оно обеспечивает резервное покрытие для аудитории, активно использующей блокировщики рекламы, и в то же время дает алгоритму более чистый сигнал из серверного пути.

Место в воронке атрибуции

Measurement Protocol устраняет разрыв в сигналах GA4 так же, как CAPI устраняет разрыв в сигналах Meta. Механизмы различаются - GA4 использует client_id и transaction_id, а Meta использует event_id и ключи соответствия - но архитектура идентична: серверное событие, которое не зависит от состояния браузера.

Для получения полной картины того, на какие платформы выполнять пересылку и как работает разветвление в масштабе, в обзоре серверного отслеживания конверсий GA4, Meta CAPI и TikTok Events рассматриваются бок о бок. Для кампаний, где тегирование UTM является предварительным шагом, обязательным к прочтению является руководство по сквозному отслеживанию UTM-кампаний.

Продукты для этой настройки: функции отслеживания конверсий описывают то, что работает сегодня: покупки в Stripe и Shopify, привязанные к ссылке через elido_link_id. Пересылка покупок в GA4, Meta или TikTok пока недоступна. Решения для маркетологов показывают, как конвейер конверсий вписывается в рабочий процесс кампании наряду с шаблонами UTM и интеллектуальной маршрутизацией ссылок.

Сама настройка - учетные данные в конфигурации вашего сервера, шаг в диспетчере тегов, сохраняющий идентификатор на целевой странице, подключение вебхука заказа - занимает полдня у большинства команд. Шаг валидации DebugView добавляет еще тридцать минут. Результатом являются данные о конверсиях GA4, которые отражают то, что на самом деле приносят ваши кампании, а не те 65-75%, которые выживают в клиентском пути.

---

Источники

• Google Analytics 4: Обзор Measurement Protocol. developers.google.com/analytics/devguides/collection/protocol/ga4 (доступ от 12.05.2026)
• GA4 Measurement Protocol: Справочник событий. developers.google.com/analytics/devguides/collection/protocol/ga4/reference/events (доступ от 12.05.2026)
• GA4 Measurement Protocol: Отправка событий. developers.google.com/analytics/devguides/collection/protocol/ga4/sending-events (доступ от 12.05.2026)