Depanare GA4 Measurement Protocol: 2xx nu dovedește nimic

GA4 Measurement Protocol returnează o stare 2xx pentru aproape orice îi trimiți: un eveniment valid, un eveniment cu nume greșit, un eveniment fără client_id, un secret inventat. Deci codul de stare este inutil la depanare. Ca să depanezi apelurile GA4 Measurement Protocol, trimite același corp la serverul de validare de la /debug/mp/collect, citește validationMessages pe care îl returnează, repară ce numește și abia apoi confirmă sosirea în DebugView sau în Realtime.

Ultimul pas contează mai mult decât se așteaptă lumea. De ce? Serverul de validare nu verifică API secretul tău, deci un payload poate trece validarea, poate primi un 204 de la endpointul real și tot să nu ajungă niciodată în proprietatea ta; am văzut o echipă pierzând o săptămână exact așa, până să se gândească cineva să copieze din nou secretul.

Dacă îți conectezi evenimentele de server ca să urmărești campanii, ghidul-pilon despre urmărirea UTM cap-coadă explică ce trebuie să fie în link înainte de toate acestea. Articolul de față este despre momentul în care trimiți evenimentul și nu apare nimic.

De ce răspunde Measurement Protocol cu 2xx la orice

Referința protocolului Google e tranșantă: endpointul returnează o stare 2xx dacă cererea HTTP este primită și nu returnează o eroare dacă payloadul este malformat sau datele nu sunt procesate. Colectarea este „trimite și uită". Serverul tău nu așteaptă niciodată procesarea.

Am verificat și noi. Un POST la /mp/collect cu corpul {"garbage":true}, un measurement ID fals și un secret inventat a revenit ca HTTP 204 cu corp gol. La fel ca pentru un eveniment perfect.

Logica de retry bazată pe coduri de stare prinde erorile de rețea. Nimic altceva. Nu îți poate spune că GA4 ți-a aruncat evenimentele. Pentru asta ai nevoie de al doilea endpoint.

Cum folosești serverul de validare de la /debug/mp/collect

Serverul de validare al measurement protocol se află pe același host. Același query string, același corp:

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}}]}'

Răspunde cu 200 și cu un corp JSON, nu cu unul gol. Payloadul de test de mai sus are trei probleme, iar serverul o raportează doar pe prima:

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

Adaugă un client_id și trece mai departe la NAME_RESERVED pentru session_start. Redenumește evenimentul și urmează prefixul firebase_. Fiecare mesaj conține un fieldPath, o descriere scrisă pentru om și un cod. Codurile documentate de Google includ VALUE_INVALID, VALUE_REQUIRED, NAME_INVALID, NAME_RESERVED, VALUE_OUT_OF_BOUNDS, EXCEEDED_MAX_ENTITIES și NAME_DUPLICATED.

Un array gol, "validationMessages": [ ], înseamnă că structura e în regulă. Nimic din ce trimiți la /debug/mp/collect nu este stocat. Bombardează-l cât vrei în dezvoltare; ține minte doar că un apel de depanare nu dovedește niciodată că datele au ajuns.

Ce nu verifică serverul de validare

Majoritatea tutorialelor sar peste asta. Pagina Google despre validarea evenimentelor spune direct că serverul de validare nu validează api_secret. În testul nostru din 22 septembrie 2026 nu a verificat nici measurement ID-ul: G-FAKE123 cu secretul nonsense a returnat un array validationMessages gol.

Un secret greșit trece. La fel unul revocat, unul din alt flux de date sau o greșeală de tastare în G-. API secretul measurement protocol este cel mai frecvent motiv pe care îl văd pentru „payload valid, zero date", iar îl poți confirma doar văzând un eveniment sosind.

A doua lacună este modul de validare. Implicit, serverul rulează în modul RELAXED, iar în acel mod a lăsat să treacă două lucruri pe care limitele Google le interzic: un eveniment cu 26 de parametri și o valoare de parametru de 120 de caractere. Adaugă "validation_behavior": "ENFORCE_RECOMMENDATIONS" în corpul de depanare și ambele eșuează, cu EXCEEDED_MAX_ENTITIES și VALUE_TOO_LONG. Eu aș valida mereu în modul strict, chiar dacă producția rămâne relaxată. E diferența dintre un verificator și o ștampilă.

Cum vezi evenimentele de server în GA4 DebugView și Realtime

După ce payloadul se validează, trimite-l la endpointul real și urmărește-l cum ajunge. Pentru evenimentele de server funcționează două vederi, iar rapoartele standard nu sunt una dintre ele, pentru că pot întârzia 24 până la 48 de ore.

DebugView cere o activare per eveniment. Ghidul de verificare Google cere "debug_mode": 1 (sau true) în parametrii evenimentului plus un engagement_time_msec pozitiv. Apar doar evenimentele care poartă flagul, deci un lot în care unui eveniment îi lipsește pare pe jumătate gol. Deschide Admin, apoi DebugView, și dă-i un minut.

Realtime nu cere nimic în plus. Derulează la cardul „Event count by Event name" și caută evenimentul. Google notează că session_id și engagement_time_msec contează pentru ca activitatea utilizatorului să apară în Realtime, deci dacă un eveniment se validează, dar Realtime rămâne gol, verifică întâi aceste două.

Încă o rezervă din același ghid: pentru fluxurile web spune că un eveniment valid folosește un client_id pe care gtag.js l-a folosit deja. ID-urile sintetice sunt tot numărate, fiecare ca utilizator separat, dar nu se alătură niciodată unei sesiuni din browser, iar într-un raport construit pe sesiuni asta apare ca o coadă lungă de utilizatori cu un singur eveniment, pe care nu o poți explica până nu știi de unde vine. Mai multe despre asta în secțiunea următoare. Dacă ceea ce lipsește sunt datele de campanie, nu evenimentele, parametrii UTM care nu apar în GA4 parcurge partea de DebugView a acelei probleme.

Erori frecvente de payload și ce spune validatorul

Majoritatea evenimentelor stricate cad în câteva tipare. Iată-le, cu ce a returnat serverul de validare când le-am trimis pe fiecare, pe 22 septembrie 2026:

Două rânduri merită un comentariu. Prefixul ga_ este rezervat conform referinței, dar validatorul a acceptat ga_session_id în ambele moduri când l-am încercat, deci nu trata un array gol ca pe o permisiune. Iar limita de 100 de caractere pentru valori prinde mereu URL-urile complete de destinație: o pagină de destinație cu cinci etichete UTM e adesea mai lungă de atât.

client_id în sine este partea subtilă. Orice șir trece validarea relaxată, dar modul strict a respins și c1, și elido-12-4711 cu „It should be in . format". Dacă evenimentele tale trebuie să se lege de sesiunile din browser, trimite valoarea reală _ga; ghidul GA4 server-side tracking explică în detaliu această legare.

Cum folosesc aceasta forwarderul GA4 Elido și butonul Test connection

Elido redirecționează clicurile pe linkuri scurte către GA4 de pe server. Lipești un Measurement ID și un API secret Measurement Protocol în cardul GA4 din Integrations, iar de atunci fiecare clic din acel workspace devine un eveniment 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 este elido-<workspace>-<link>, deci fiecare clic pe un link se citește ca același utilizator GA4 și niciunul nu se alătură unei sesiuni din browser. Acesta e compromisul onest al faptului că faci asta fără cookie: totalurile și defalcările pe slug, țară și dispozitiv funcționează; numărul de utilizatori și pâlniile de sesiuni nu. Țara și dispozitivul sunt parametri simpli de eveniment. Înregistrează-i mai întâi ca dimensiuni personalizate. Iar un destination de peste 100 de caractere se lovește de limita din tabelul de mai sus, așa că raportează după slug sau link_id.

Butonul Test connection urmează ordinea pe care o recomandă acest articol:

Mai întâi trimite un link_click sintetic, marcat cu elido_test: true, la /debug/mp/collect. Dacă validationMessages nu e gol, testul eșuează și afișează descrierile Google exact cum sunt. Dacă array-ul e gol, același eveniment merge pe bune la /mp/collect. Sub buton vezi răspunsul furnizorului (starea HTTP, endpointul de depanare cu measurement ID-ul tău, dar niciodată secretul, și corpul Google) plus o notă care spune că Measurement Protocol nu verifică API secretul.

Deci verde înseamnă „valid, iar Google l-a primit". Nu „proprietatea ta îl are". Evenimentul de test poartă debug_mode: 1 și elido_test: true, deci apare în DebugView ca link_click; funcționează și Realtime. Dacă vrei evenimente de clic în GA4 fără un tag pe fiecare pagină de destinație, creează un workspace și îndreaptă mai întâi cardul GA4 spre o proprietate de test.

O ordine de depanare GA4 Measurement Protocol care funcționează

Când evenimentele GA4 nu apar, parcurge în ordinea asta și oprește-te la primul eșec:

1. Trimite corpul la /debug/mp/collect cu validation_behavior setat la ENFORCE_RECOMMENDATIONS. Repară fiecare mesaj.
2. Copiază din nou API secretul din Admin, Data streams, fluxul tău web, Measurement Protocol API secrets. Verifică dacă e din același flux cu ID-ul G-.
3. Trimite un eveniment la /mp/collect cu debug_mode: 1 și urmărește DebugView două minute.
4. Scoate flagul și verifică Realtime, apoi dă rapoartelor standard o zi sau două.

Pasul 2 e locul unde se termină cea mai mare parte din depanările mele. Pagina de depanare Google începe cu aceleași trei întrebări: secretul corect, încă valid, copiat exact. Când cifrele încep în sfârșit să curgă și tot nu se potrivesc cu numărul tău de clicuri pe linkuri, clicurile pe linkuri scurte vs sesiunile GA4 explică diferența, iar urmărirea conversiilor pe server acoperă evenimentele de conversie care urmează de obicei. Același obicei de validare urmată de verificare se aplică și celorlalte destinații de pe pagina de urmărire a conversiilor.

Pe același subiect pe blog

• GA4 server-side tracking prin redirecționări - credențiale, forma payloadului și legarea client_id.
• Mixpanel vs GA4 pentru analiza linkurilor - ce unealtă ar trebui să dețină datele tale de clic.
• Urmărirea linkurilor cu Mixpanel - același forwarder îndreptat spre Mixpanel, cu propriul lui răspuns 200 la orice.
• Parametrii UTM care nu apar în GA4 - versiunea cu date de campanie a acestei probleme de depanare.
• Urmărirea conversiilor pe server - GA4, Meta CAPI și TikTok, unul lângă altul.