Налагодження GA4 Measurement Protocol: чому 2xx нічого не доводить

GA4 Measurement Protocol повертає статус 2xx майже на все, що ви до нього надсилаєте: валідну подію, подію з помилкою в назві, подію без client_id, вигаданий вами секрет. Тож код статусу марний для налагодження. Щоб налагоджувати виклики GA4 Measurement Protocol, надішліть те саме тіло на сервер валідації за адресою /debug/mp/collect, прочитайте повернуті validationMessages, виправте те, що вони називають, і лише потім підтверджуйте появу в DebugView або Realtime.

Останній крок важливіший, ніж багато хто очікує. Чому? Сервер валідації не перевіряє ваш API secret, тому дані можуть пройти валідацію, отримати 204 від справжньої кінцевої точки і все одно ніколи не потрапити у вашу властивість. Я бачила, як команда втратила на цьому тиждень, перш ніж хтось здогадався знову скопіювати секрет.

Якщо ви підключаєте серверні події для відстеження кампаній, базовий гайд про відстеження UTM від початку до кінця пояснює, що має бути в посиланні до всього цього. Ця стаття про момент, коли ви надсилаєте подію, а нічого не з'являється.

Чому Measurement Protocol відповідає 2xx на все

Довідник протоколу Google говорить прямо: кінцева точка повертає код статусу 2xx, якщо HTTP-запит отримано, і не повертає помилку, якщо дані мають неправильну структуру або їх не оброблено. Збирання працює за принципом "надіслав і забув". Ваш сервер ніколи не чекає на обробку.

Ми перевірили це самі. POST до /mp/collect з тілом {"garbage":true}, фальшивим measurement ID і вигаданим секретом повернув HTTP 204 з порожнім тілом. Так само, як і ідеальна подія.

Логіка повторних спроб, прив'язана до кодів статусу, ловить мережеві збої. І нічого більше. Вона не скаже вам, що GA4 відкинула ваші події. Для цього потрібна друга кінцева точка.

Як використовувати сервер валідації на /debug/mp/collect

Сервер валідації measurement protocol розміщений на тому самому хості. Той самий рядок запиту, те саме тіло:

curl -s -X POST \
  "https://www.google-analytics.com/debug/mp/collect?measurement_id=G-XXXXXXXXXX&api_secret=YOUR_SECRET" \
  -H "Content-Type: application/json" \
  -d '{"events":[{"name":"session_start","params":{"firebase_x":1}}]}'

Він відповідає 200 з JSON-тілом замість порожнього. У цьому тестовому наборі даних є три проблеми, і сервер повідомляє про першу, на яку натрапляє:

{
  "validationMessages": [
    {
      "fieldPath": "client_id",
      "description": "Measurement requires a client_id.",
      "validationCode": "VALUE_REQUIRED"
    }
  ]
}

Додайте client_id, і він перейде до NAME_RESERVED для session_start; перейменуйте подію, і наступним стане префікс firebase_. Кожне повідомлення містить fieldPath, опис для людини та код. Серед задокументованих Google кодів є VALUE_INVALID, VALUE_REQUIRED, NAME_INVALID, NAME_RESERVED, VALUE_OUT_OF_BOUNDS, EXCEEDED_MAX_ENTITIES і NAME_DUPLICATED.

Порожній масив, "validationMessages": [ ], означає, що зі структурою все гаразд. Нічого, надіслане до /debug/mp/collect, не зберігається. Навантажуйте його під час розробки скільки завгодно; просто пам'ятайте, що debug-виклик ніколи не доводить, що дані дійшли.

Чого сервер валідації не перевіряє

Більшість навчальних матеріалів пропускають цю частину. На сторінці про валідацію подій Google прямо сказано, що сервер валідації не перевіряє api_secret. У нашому тесті 22 вересня 2026 року він не перевіряв і measurement ID: G-FAKE123 із секретом nonsense повернув порожній масив validationMessages.

Неправильний секрет проходить. Так само проходить відкликаний секрет, секрет з іншого потоку даних або друкарська помилка в G-. Measurement protocol api_secret - найчастіша причина "дані валідні, даних у GA4 немає", яку я бачу, і підтвердити її можна тільки побачивши, що подія прийшла.

Друга прогалина - режим валідації. За замовчуванням сервер працює в режимі RELAXED, і в цьому режимі він пропустив дві речі, які забороняють власні ліміти Google: подію з 26 параметрами та значення параметра довжиною 120 символів. Додайте "validation_behavior": "ENFORCE_RECOMMENDATIONS" до debug-тіла, і обидва випадки не пройдуть, з EXCEEDED_MAX_ENTITIES і VALUE_TOO_LONG. Я завжди перевіряла б у суворому режимі, навіть якщо в продакшені лишається м'який режим. Це різниця між перевіркою та формальною печаткою.

Як бачити серверні події в GA4 DebugView і Realtime

Коли дані пройшли валідацію, надішліть їх до справжньої кінцевої точки і подивіться, чи вони доходять. Для серверних подій працюють два подання, і стандартні звіти не серед них, бо можуть відставати на 24-48 годин.

DebugView потребує явного ввімкнення для кожної події. Гайд із перевірки Google просить "debug_mode": 1 (або true) у params події плюс додатний engagement_time_msec. Показуються лише події з цим прапорцем, тому пакет, де одній події його бракує, виглядає напівпорожнім. Відкрийте Admin, потім DebugView, і дайте йому хвилину.

Realtime не потребує нічого додаткового. Прокрутіть до картки "Event count by Event name" і знайдіть свою подію. Google зазначає, що session_id і engagement_time_msec важливі для показу активності користувача в Realtime, тож якщо подія проходить валідацію, але Realtime лишається порожнім, спершу перевірте ці два поля.

Ще одне застереження з того самого гайда: для веб-потоків там сказано, що валідна подія використовує client_id, який gtag.js уже використовував. Синтетичні ID все одно зараховуються, кожен як окремий користувач, але вони ніколи не приєднуються до браузерної сесії, і у звіті, побудованому навколо сесій, це виглядає як довгий хвіст користувачів з однією подією, який ви не зможете пояснити, доки не знатимете, звідки він узявся. Про це докладніше в наступному розділі. Якщо бракує не подій, а даних кампанії, UTM-параметри не показуються в GA4 розбирає цю проблему з боку DebugView.

Типові помилки в даних і що каже валідатор

Більшість зламаних подій вкладається в кілька шаблонів. Ось вони разом з тим, що повернув сервер валідації, коли ми надсилали кожну з них 22 вересня 2026 року:

Два рядки потребують коментаря. Префікс ga_ зарезервований згідно з довідником, але валідатор прийняв ga_session_id в обох режимах, коли ми це пробували, тож не сприймайте порожній масив як дозвіл. А ліміт значення у 100 символів постійно зачіпає повні URL призначення: цільова сторінка з п'ятьма UTM-мітками часто довша за це.

Сам client_id - тонкий момент. Будь-який рядок проходить валідацію в м'якому режимі, але суворий режим відхилив і c1, і elido-12-4711 з повідомленням "It should be in . format". Якщо ваші події мають зшиватися з браузерними сесіями, надсилайте справжнє значення _ga; гайд із серверного відстеження GA4 детально пояснює це зшивання.

Як GA4 Forwarder і Test Connection в Elido використовують це

Elido пересилає кліки коротких посилань до GA4 на серверному боці. Ви вставляєте Measurement ID і Measurement Protocol API secret у картку GA4 в розділі Integrations, і відтоді кожен клік у цьому робочому просторі стає однією подією link_click:

{
  "client_id": "elido-12-4711",
  "events": [
    {
      "name": "link_click",
      "params": {
        "workspace_id": 12,
        "link_id": 4711,
        "slug": "spring-26",
        "country": "DE",
        "device": "mobile",
        "destination": "https://shop.example/spring?utm_source=newsletter",
        "engagement_time_msec": 100
      }
    }
  ]
}

client_id має вигляд elido-<workspace>-<link>, тому кожен клік за одним посиланням читається як той самий користувач GA4, і жоден з них не приєднується до браузерної сесії. Це чесний компроміс, коли ви робите це без cookie: підсумки та розбивки за slug, country і device працюють; кількість користувачів і сесійні воронки - ні. Country і device - звичайні параметри подій. Спершу зареєструйте їх як спеціальні параметри. А destination довше за 100 символів упирається в ліміт з таблиці вище, тому звітуйте за slug або link_id натомість.

Кнопка Test connection дотримується порядку, який радить ця стаття:

Спершу вона надсилає синтетичний link_click, позначений elido_test: true, до /debug/mp/collect. Якщо validationMessages не порожній, тест завершується помилкою і показує описи Google дослівно. Якщо масив порожній, та сама подія справді йде до /mp/collect. Під кнопкою ви бачите відповідь постачальника (статус HTTP, кінцеву точку для налагодження з вашим measurement ID, але ніколи не секретом, і тіло Google) плюс примітку, що Measurement Protocol не перевіряє API secret.

Тож зелений колір означає "валідно, і Google це отримала". Не "це є у вашій властивості". Тестова подія містить debug_mode: 1 і elido_test: true, тому вона з'являється в DebugView як link_click; у Realtime її теж видно. Якщо хочете події кліків у GA4 без тегу на кожній цільовій сторінці, створіть робочий простір і спершу спрямуйте картку GA4 на тестову властивість.

Робочий порядок налагодження GA4 Measurement Protocol

Коли події GA4 не з'являються, пройдіть цей порядок і зупиніться на першому збої:

1. Надішліть тіло до /debug/mp/collect з validation_behavior, встановленим у ENFORCE_RECOMMENDATIONS. Виправте кожне повідомлення.
2. Знову скопіюйте API secret з Admin, Data streams, вашого веб-потоку, Measurement Protocol API secrets. Перевірте, що він з того самого потоку, що й G- ID.
3. Надішліть одну подію до /mp/collect з debug_mode: 1 і дві хвилини дивіться DebugView.
4. Приберіть прапорець і перевірте Realtime, а потім дайте стандартним звітам день або два.

Крок 2 - місце, де закінчується більшість мого власного налагодження. Сторінка усунення проблем Google починається з тих самих трьох питань: правильний секрет, ще чинний, скопійований точно. Коли цифри нарешті течуть, але все одно не збігаються з кількістю кліків за посиланнями, кліки коротких посилань проти сесій GA4 пояснює розрив, а серверне відстеження конверсій покриває події конверсій, які зазвичай ідуть далі. Та сама звичка "спершу валідувати, потім перевіряти" стосується й інших напрямків на сторінці відстеження конверсій.

Пов'язане в блозі

• Серверне відстеження GA4 через перенаправлення - облікові дані, форма даних і зшивання client_id.
• Mixpanel проти GA4 для аналітики посилань - який інструмент має зберігати ваші дані про кліки.
• Відстеження посилань у Mixpanel - той самий модуль пересилання, спрямований на Mixpanel, з його власною дивиною 200-на-що-завгодно.
• UTM-параметри не показуються в GA4 - версія цієї проблеми налагодження для даних кампанії.
• Серверне відстеження конверсій - GA4, Meta CAPI і TikTok поруч.