Серверный трекинг 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 менее чем за две минуты.
• client_id - это то, что связывает серверное событие с сессией GA4; Elido устанавливает 1st-party куку UUID при редиректе по короткой ссылке и включает её в каждую пересылку конверсии, поэтому вам не нужно считывать куку _ga из браузера.
• Валидация занимает около десяти минут: 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 они вставляются в Workspace Settings в разделе Integrations → GA4. После сохранения Elido проверяет пару через отладочный эндпоинт GA4 и подтверждает соединение. Валидация происходит мгновенно; ошибка 4xx на этом этапе означает, что Measurement ID или API secret указаны неверно.

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

В справочнике 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 без тела независимо от того, было ли событие принято. Используйте отладочный эндпоинт (описанный в разделе валидации), чтобы отловить переполнения.

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 решает эту проблему на уровне редиректов. Когда пользователь кликает по короткой ссылке, edge-обработчик Elido генерирует UUID и устанавливает его как 1st-party куку _elido_cid в ответе редиректа - еще до того, как пользователь попадет на ваш сайт. UUID также добавляется к целевому URL как ?elido_click=<uuid> (настраивается для каждого воркспейса). Поток:

Ваша целевая страница или диспетчер тегов считывает elido_click из URL и записывает его в кастомные атрибуты заказа. В момент конверсии ваш вебхук заказа передает этот UUID. Elido ищет его, формирует полезную нагрузку Measurement Protocol с установленным client_id на этот UUID и пересылает её в GA4.

Это надежнее, чем считывание _ga из браузера, так как UUID фиксируется в момент клика, до того как сессия браузера пользователя определит, принимаются ли куки. Даже если ITP удалит куку _ga в течение 24 часов, кука _elido_cid от Elido сохранится как 1st-party кука под вашим доменом коротких ссылок - а атрибут заказа в любом случае сохранится в вашей базе данных.

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

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

Когда приходит POST /v1/conversions с click_id, Elido собирает полезную нагрузку Measurement Protocol и пересылает её. Чтобы вызвать эндпоинт напрямую - минуя Elido и тестируя связку на стороне GA4 MP - используйте curl:

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 отобразится здесь.

При использовании Elido такая же видимость валидации доступна через GET /v1/conversions/{id} - запись конверсии показывает статус пересылки в GA4 и любой ответ об ошибке от отладочного эндпоинта в режиме тестирования.

Валидация: 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 всегда заполнено перед отправкой запроса. В настройках Elido отсутствие client_id означает, что параметр elido_click не был записан в заказ при конверсии - проверьте тег целевой страницы или обработчик вебхука.

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

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

Валюта берется из конфигурации страницы, а не из заказа. Если ваша настройка 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 заказа, который можно было бы использовать. Здесь подойдет ID клика: установите event_id на UUID elido_click. И пиксель на стороне браузера, и серверная пересылка ссылаются на одно и то же значение. Эта же дисциплина описана в руководстве по сквозному отслеживанию UTM, которое охватывает более широкую настройку тегирования кампаний, делающую этот ID доступным на протяжении всей воронки.

Окно дедупликации в 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-кампаний.

Интерфейс продукта для этой настройки: в функциях отслеживания конверсий документирован полный API /v1/conversions, включая многоплатформенное разветвление, события возврата и семантику повторных попыток. Решения для маркетологов показывают, как конвейер конверсий вписывается в рабочий процесс кампании наряду с шаблонами UTM и интеллектуальной маршрутизацией ссылок.

Сама настройка - учетные данные в настройках воркспейса, шаг в диспетчере тегов для elido_click на целевой странице, подключение вебхука заказа - занимает полдня у большинства команд. Шаг валидации 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)