GA4 Measurement Protocol Debug: 2xx Hiçbir Şey Kanıtlamaz

GA4 Measurement Protocol, kendisine gönderdiğiniz hemen her şey için 2xx durumu döndürür: geçerli bir olay, yanlış yazılmış bir olay, client_id olmayan bir olay, uydurduğunuz bir gizli anahtar. Bu yüzden durum kodu hata ayıklamada işe yaramaz. GA4 Measurement Protocol çağrılarında hata ayıklamak için aynı gövdeyi /debug/mp/collect adresindeki doğrulama sunucusuna gönderin, döndürdüğü validationMessages alanını okuyun, adını verdiği şeyi düzeltin ve ancak sonra DebugView ya da Realtime'da varışı doğrulayın.

Son adım insanların beklediğinden daha önemli. Neden? Doğrulama sunucusu API gizli anahtarınızı kontrol etmez; yani bir yük doğrulamadan geçebilir, gerçek uçtan 204 alabilir ve yine de mülkünüze hiç ulaşmayabilir. Gizli anahtarı yeniden kopyalamayı kimse düşünene kadar bir ekibin tam da bu yüzden bir hafta kaybettiğini gördüm.

Kampanyaları izlemek için sunucu tarafı olaylar bağlıyorsanız, UTM'leri uçtan uca izleme temel rehberi bunlardan önce bağlantıda neyin olması gerektiğini anlatır. Bu yazı, olayı gönderdiğiniz ve hiçbir şeyin görünmediği an hakkında.

Measurement Protocol Neden Her Şeye 2xx Yanıtı Verir

Google'ın protokol başvurusu bu konuda açık sözlü: uç nokta, HTTP isteği alındıysa 2xx durum kodu döndürür ve yük hatalıysa ya da veri işlenmediyse hata döndürmez. Toplama, gönder ve unut biçimindedir. Sunucunuz işlemeyi hiçbir zaman beklemez.

Bunu kendimiz denedik. /mp/collect adresine {"garbage":true} gövdesi, sahte bir ölçüm kimliği ve uydurma bir gizli anahtarla yapılan bir POST, boş gövdeli HTTP 204 olarak döndü. Kusursuz bir olayla aynı.

Durum kodlarına bağlı yeniden deneme mantığı ağ hatalarını yakalar. Başka hiçbir şeyi değil. GA4'ün olaylarınızı düşürdüğünü size söyleyemez. Bunun için ikinci uç noktaya ihtiyacınız var.

/debug/mp/collect Adresindeki Doğrulama Sunucusu Nasıl Kullanılır

Measurement Protocol doğrulama sunucusu aynı ana makinede durur. Aynı sorgu dizesi, aynı gövde:

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

Boş yerine JSON gövdeli 200 ile yanıt verir. Bu test yükünün üç sorunu var ve sunucu karşılaştığı ilkini bildirir:

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

Bir client_id ekleyin; session_start için NAME_RESERVED hatasına geçer. Olayı yeniden adlandırın; sırada firebase_ öneki gelir. Her ileti bir fieldPath, insan okunur bir açıklama ve bir kod taşır. Google'ın belgelediği kodlar arasında VALUE_INVALID, VALUE_REQUIRED, NAME_INVALID, NAME_RESERVED, VALUE_OUT_OF_BOUNDS, EXCEEDED_MAX_ENTITIES ve NAME_DUPLICATED bulunur.

Boş bir dizi, "validationMessages": [ ], yapının iyi olduğu anlamına gelir. /debug/mp/collect adresine gönderilen hiçbir şey saklanmaz. Geliştirme sırasında istediğiniz kadar yüklenin; yalnızca bir debug çağrısının verinin ulaştığını asla kanıtlamadığını unutmayın.

Doğrulama Sunucusunun Kontrol Etmedikleri

Çoğu eğitim bu kısmı atlar. Google'ın olay doğrulama sayfası, doğrulama sunucusunun api_secret değerini doğrulamadığını açıkça söyler. 22 Eylül 2026'daki testimizde ölçüm kimliğini de kontrol etmedi: nonsense gizli anahtarlı G-FAKE123, boş bir validationMessages dizisi döndürdü.

Yanlış bir gizli anahtar geçer. İptal edilmiş olan da, başka bir veri akışından gelen de, G- içindeki bir yazım hatası da geçer. Measurement Protocol api_secret, "geçerli yük, veri yok" durumunda gördüğüm en yaygın nedendir ve bunu ancak bir olayın ulaştığını görerek doğrulayabilirsiniz.

İkinci boşluk doğrulama modudur. Varsayılan olarak sunucu RELAXED modunda çalışır ve bu modda Google'ın kendi sınırlarının yasakladığı iki şeye izin verdi: 26 parametreli bir olay ve 120 karakterlik bir parametre değeri. Debug gövdesine "validation_behavior": "ENFORCE_RECOMMENDATIONS" ekleyin; ikisi de sırasıyla EXCEEDED_MAX_ENTITIES ve VALUE_TOO_LONG ile başarısız olur. Üretim gevşek kalsa bile ben her zaman katı modda doğrulardım. Bir denetleyici ile bir lastik damga arasındaki fark budur.

Sunucu Olaylarını GA4 DebugView ve Realtime'da Görme

Yük doğrulandıktan sonra gerçek uca gönderin ve ulaşmasını izleyin. Sunucu olayları için iki görünüm işe yarar ve standart raporlar bunlardan biri değil, çünkü 24 ile 48 saat geriden gelebilir.

DebugView, olay başına bir onay ister. Google'ın doğrulama rehberi, olayın parametrelerinde "debug_mode": 1 (ya da true) ve pozitif bir engagement_time_msec ister. Yalnızca bayrağı taşıyan olaylar görünür; bu yüzden birinde bayrak eksik olan bir toplu istek yarı boş görünür. Admin, ardından DebugView'ı açın ve bir dakika tanıyın.

Realtime ekstra bir şey gerektirmez. "Event count by Event name" kartına kaydırın ve olayınızı arayın. Google, session_id ve engagement_time_msec alanlarının Realtime'da kullanıcı etkinliğinin görünmesi için önemli olduğunu not eder; bu yüzden bir olay doğrulanıyor ama Realtime boş kalıyorsa önce bu ikisini kontrol edin.

Aynı rehberden bir uyarı daha: web akışları için geçerli bir olayın, gtag.js'in zaten kullandığı bir client_id kullandığını söyler. Sentetik kimlikler yine sayılır, her biri kendi kullanıcısı olarak, ama hiçbir tarayıcı oturumuna katılmaz ve oturum odaklı kurulan bir raporda bu, nereden geldiğini öğrenene kadar açıklayamayacağınız bir tek olaylı kullanıcılar kuyruğu olarak görünür. Sonraki bölümde bunun devamı var. Eksik olan olaylar değil de kampanya verisiyse, GA4'te görünmeyen UTM parametreleri o sorunun DebugView tarafını adım adım anlatır.

Yaygın Yük Hataları ve Doğrulayıcının Söyledikleri

Çoğu bozuk olay bir avuç örüntüye girer. İşte 22 Eylül 2026'da her birini gönderdiğimizde doğrulama sunucusunun döndürdükleriyle birlikte:

İki satır yorum hak ediyor. Başvuruya göre ga_ öneki ayrılmıştır, yine de doğrulayıcı denediğimizde ga_session_id değerini her iki modda da kabul etti; bu yüzden boş bir diziyi izin saymayın. Ve 100 karakterlik değer sınırı tam hedef URL'lere sürekli takılır: beş UTM etiketli bir iniş sayfası çoğu zaman bundan uzundur.

client_id'nin kendisi ince nokta. Herhangi bir dize gevşek doğrulamayı geçer, ama katı mod hem c1 hem elido-12-4711 değerini "It should be in . format" ile reddetti. Olaylarınızın tarayıcı oturumlarına bağlanması gerekiyorsa gerçek _ga değerini gönderin; GA4 sunucu tarafı izleme rehberi bu bağlamayı ayrıntılı anlatır.

Elido'nun GA4 İleticisi ve Bağlantıyı Sına Düğmesi Bunu Nasıl Kullanır

Elido kısa bağlantı tıklamalarını GA4'e sunucu tarafında iletir. Entegrasyonlar altındaki GA4 kartına bir Measurement ID ve bir Measurement Protocol API gizli anahtarı yapıştırırsınız ve o andan itibaren o çalışma alanındaki her tıklama bir link_click olayına dönüşür:

{
  "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> biçimindedir; böylece bir bağlantıdaki her tıklama aynı GA4 kullanıcısı gibi okunur ve hiçbiri bir tarayıcı oturumuna katılmaz. Bunu çerez olmadan yapmanın dürüst ödünleşimi budur: toplamlar ve slug, ülke ve cihaza göre dökümler çalışır; kullanıcı sayıları ve oturum hunileri çalışmaz. Ülke ve cihaz düz olay parametreleridir. Önce onları özel boyut olarak kaydedin. Ve 100 karakteri aşan bir destination, yukarıdaki tablodaki sınıra takılır; bu yüzden slug ya da link_id üzerinden raporlayın.

Bağlantıyı sına düğmesi bu yazının önerdiği sırayı izler:

Önce elido_test: true ile işaretlenmiş sentetik bir link_click gönderir, /debug/mp/collect adresine. validationMessages boş değilse test başarısız olur ve Google'ın açıklamalarını olduğu gibi gösterir. Dizi boşsa aynı olay gerçekten /mp/collect adresine gider. Düğmenin altında satıcı yanıtını (HTTP durumu, ölçüm kimliğinizi içeren ama gizli anahtarı asla içermeyen debug ucu ve Google'ın gövdesi) ve Measurement Protocol'ün API gizli anahtarını doğrulamadığını söyleyen bir not görürsünüz.

Yani yeşil, "geçerli ve Google aldı" demektir. "Mülkünüzde var" demek değil. Test olayı debug_mode: 1 ve elido_test: true taşır, bu yüzden DebugView'da link_click olarak görünür; Realtime de çalışır. Her iniş sayfasında etiket olmadan GA4'te tıklama olayları istiyorsanız, bir çalışma alanı başlatın ve GA4 kartını önce bir test mülküne yöneltin.

İşe Yarayan Bir GA4 Measurement Protocol Hata Ayıklama Sırası

GA4 olayları görünmüyorsa şu sırayla ilerleyin ve ilk başarısızlıkta durun:

1. Gövdeyi validation_behavior değeri ENFORCE_RECOMMENDATIONS olarak /debug/mp/collect adresine gönderin. Her iletiyi düzeltin.
2. API gizli anahtarını Admin, Data streams, web akışınız, Measurement Protocol API secrets altından yeniden kopyalayın. G- kimliğiyle aynı akıştan olduğunu kontrol edin.
3. debug_mode: 1 ile /mp/collect adresine bir olay gönderin ve DebugView'ı iki dakika izleyin.
4. Bayrağı kaldırın ve Realtime'ı kontrol edin, sonra standart raporlara bir iki gün tanıyın.

Kendi hata ayıklamalarımın çoğu 2. adımda biter. Google'ın sorun giderme sayfası aynı üç soruyla açılır: doğru gizli anahtar, hâlâ geçerli, tam kopyalanmış. Rakamlar sonunda aktığında ve yine bağlantı sayılarınızla uyuşmadığında, kısa bağlantı tıklamaları ve GA4 oturumları farkı açıklar, sunucu tarafı dönüşüm izleme ise genellikle ardından gelen dönüşüm olaylarını kapsar. Aynı doğrula-sonra-teyit-et alışkanlığı dönüşüm izleme sayfasındaki diğer hedefler için de geçerlidir.

Blogda İlgili Yazılar

• Yönlendirmelerle GA4 sunucu tarafı izleme - kimlik bilgileri, yük biçimi ve client_id bağlama.
• Bağlantı analitiği için Mixpanel ve GA4 - tıklama verinizi hangi araç tutmalı.
• Mixpanel bağlantı izleme - Mixpanel'e yöneltilmiş aynı ileticide, kendi "her şeye 200" tuhaflığıyla.
• GA4'te görünmeyen UTM parametreleri - bu hata ayıklama sorununun kampanya verisi sürümü.
• Sunucu tarafı dönüşüm izleme - GA4, Meta CAPI ve TikTok yan yana.