Серверне відстеження GA4 через рівень перенаправлення

Клієнтське тегування GA4 через gtag.js або GTM - це база атрибуції, яку більшість команд використовує за замовчуванням. Це добре працює в ідеальних умовах: користувач Chrome на десктопі зі швидким з'єднанням, без блокувальника реклами, сесія в Safari, яка не активувала обмеження ITP на 24-годинний життєвий цикл скриптових cookie. Ідеальні умови охоплюють приблизно 65-75% трафіку ЄС у 2026 році.

Решта - користувачі uBlock Origin, вбудоване блокування Brave, Intelligent Tracking Prevention від Safari на iOS, зростаюча когорта блокувальників на рівні мережі, таких як NextDNS та Pi-hole - надсилають події, які або зникають до того, як досягнуть www.google-analytics.com, або надходять без придатного клієнтського ідентифікатора, оскільки cookie _ga було видалено. Типовий розрив для аудиторій з великою часткою користувачів з ЄС становить 25-35% подій конверсії. Для деяких галузей - фінтех, інструменти приватності, інструменти для розробників - він вищий, оскільки демографія користувачів корелює з використанням блокувальників реклами.

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

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

Стисло (TL;DR)#

• Клієнтський gtag.js у GA4 втрачає 25-35% подій конверсії на типовому трафіку ЄС через блокувальники реклами (uBlock, Brave) та ITP (обмеження часу життя cookie в Safari); Measurement Protocol обходить усе це, оскільки запит ініціюється вашим сервером.
• Вам потрібні два облікові дані: Measurement ID (G-XXXXXXXX) з вашого потоку даних та секрет API, згенерований у меню Admin → Data Streams → Measurement Protocol API secrets. Обидва вставляються в налаштування робочого простору Elido менш ніж за дві хвилини.
• client_id - це те, що прив'язує серверну подію до сесії GA4; Elido встановлює першосторонню (first-party) UUID cookie під час перенаправлення за коротким посиланням і включає її в кожне пересилання конверсії, тому вам не потрібно зчитувати cookie _ga з браузера.
• Валідація займає близько десяти хвилин: DebugView у GA4 показує події Measurement Protocol, що надходять приблизно протягом десяти секунд; стандартні звіти заповнюються ретроспективно протягом 24-48 годин.

Два облікові дані, які вам потрібні#

Для Measurement Protocol у GA4 потрібні дві частини інформації, обидві з консолі адміністратора 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 вказані невірно.

Форма події#

Довідка Measurement Protocol GA4 (доступ від 2026-05-12) визначає формат запиту. Кінцева точка:

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

Тіло запиту містить client_id, необов'язковий user_id та масив events. Ось корисне навантаження для події покупки (purchase):

{
  "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 (доступ від 2026-05-12) містить рекомендовані назви подій: purchase, sign_up, generate_lead, add_to_cart. Надсилання Purchase (з великої літери P) створить окрему подію у звітах GA4 замість об'єднання з вашими подіями purchase, запущеними через gtag. Платформа не попереджає вас; подія просто відобразиться як дивна кастомна подія.

engagement_time_msec має бути присутнім і встановленим у значення позитивного цілого числа. Без нього GA4 зараховує подію, але не зараховує залученість сесії (session engagement), а деякі моделі атрибуції виключають події без часу залученості. Встановлення значення 1 достатньо для задоволення вимоги.

event_params обмежено 25 параметрами на подію. Measurement Protocol відхилить корисне навантаження, яке перевищує цей ліміт. Відхилення за замовчуванням відбувається мовчки - запит повертає 204 без тіла незалежно від того, чи була подія прийнята. Використовуйте кінцеву точку налагодження (описану в розділі валідації), щоб відстежити переповнення.

user_id є необов'язковим, але цінним. Якщо у вас є постійний ідентифікатор користувача на стороні сервера - ID клієнта в таблиці замовлень, ID підписника у вашій CRM - надішліть його. GA4 використовує його для крос-девайс атрибуції, і це покращує відповідність між серверними та клієнтськими подіями.

Зшивання client_id: чому це важливо та як Elido з цим справляється#

client_id - це поле, яке GA4 використовує для прив'язки серверної події до сесії браузера. Коли gtag.js запускається на сторінці, він зчитує cookie _ga і використовує її UUID як client_id для всіх подій, які він запускає. Якщо ваша серверна подія містить той самий client_id, GA4 може зшити ці події в єдиний шлях користувача та сесію.

Складність полягає в тому, щоб отримати цей UUID на стороні сервера. Cookie _ga - це першостороння (first-party) cookie на вашому домені, тому ваш сервер може зчитати її під час оформлення замовлення і включити в корисне навантаження конверсії. Але це працює лише в тому випадку, якщо в браузері користувача встановлено _ga, а це саме та частина аудиторії, яку ви втрачаєте через ITP та блокувальники реклами.

Elido вирішує це на рівні перенаправлення. Коли користувач натискає на коротке посилання, edge-обробник Elido генерує UUID і встановлює його як першосторонню cookie _elido_cid у відповіді на перенаправлення - ще до того, як користувач потрапить на ваш сайт. UUID також додається до цільової URL-адреси як ?elido_click=<uuid> (налаштовується для кожного робочого простору). Процес:

Ваша цільова сторінка або менеджер тегів зчитує elido_click з URL-адреси та записує його в кастомні атрибути замовлення. У момент конверсії ваш webhook замовлення містить цей UUID. Elido шукає його, створює корисне навантаження Measurement Protocol із встановленим client_id для цього UUID і пересилає в GA4.

Це надійніше, ніж зчитування _ga з браузера, оскільки UUID фіксується в момент кліку, до того, як сесія браузера користувача визначить, чи приймаються cookie. Навіть якщо ITP видалить cookie _ga протягом 24 годин, cookie _elido_cid від Elido збережеться як першостороння cookie під вашим доменом коротких посилань - а атрибут замовлення збережеться у вашій базі даних у будь-якому випадку.

Посібник GA4 з надсилання подій (доступ від 2026-05-12) описує, як 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 не був записаний у замовлення під час конверсії - перевірте тег цільової сторінки або обробник webhook.

Неправильний формат назви події. 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 на цільовій сторінці, підключення webhook замовлення - займає півдня для більшості команд. Крок валідації в DebugView додає ще тридцять хвилин. Результатом є дані про конверсії в GA4, які відображають те, що насправді приносять ваші кампанії, а не ті 65-75%, які виживають після клієнтського шляху.

Джерела

• Google Analytics 4: Measurement Protocol overview. developers.google.com/analytics/devguides/collection/protocol/ga4 (доступ від 2026-05-12)
• GA4 Measurement Protocol: Event reference. developers.google.com/analytics/devguides/collection/protocol/ga4/reference/events (доступ від 2026-05-12)
• GA4 Measurement Protocol: Sending events. developers.google.com/analytics/devguides/collection/protocol/ga4/sending-events (доступ від 2026-05-12)