Web Vitals Verilerini Google Analytics 4'te Nasıl Görürsünüz?

web-vitals.js kütüphanesi GA4'e nasıl bağlanır

web-vitals.js, Google tarafından geliştirilen ve npm üzerinden yayımlanan küçük bir JavaScript kütüphanesidir. Temel kullanımı için iki adım yeterlidir: kütüphaneyi projeye dahil etmek ve ölçüm sonuçlarını GA4'e iletmek.

npm install web-vitals

Kütüphaneyi yükledikten sonra her metrik için ayrı bir callback tanımlayabilirsiniz. Her callback, name, value, rating ve id alanlarını içeren bir nesne döner. rating alanı "good", "needs-improvement" veya "poor" değerlerinden birini alır; bu alan sonradan GA4'te filtre kurarken doğrudan kullanılacak.

import { onLCP, onCLS, onINP } from 'web-vitals';

function sendToGA4(metric) {
  gtag('event', metric.name, {
    value: Math.round(metric.name === 'CLS' ? metric.value * 1000 : metric.value),
    metric_id: metric.id,
    metric_value: metric.value,
    metric_rating: metric.rating,
  });
}

onLCP(sendToGA4);
onCLS(sendToGA4);
onINP(sendToGA4);

value alanını gtag'in beklediği tam sayıya dönüştürürken CLS için 1000 ile çarpmak, ondalıklı değeri kayıpsız saklamayı sağlar. metric_id her oturuma özgü tekil bir kimlik taşıdığından çift sayımı önler; aynı id iki kez gelirse ikincisi güncelleme olarak yorumlanır.

cdn.jsdelivr.net gibi harici bir kaynak üzerinden <script type="module"> ile de yüklenebilir. Tek sayfalık uygulamalarda NPM kurulumu daha güvenilir davranır, çünkü route değişimlerinde metrik yeniden başlatılabilir. Kütüphaneyi mümkün olduğunca erken yüklemek için <link rel="modulepreload"> bildirimi eklemek, LCP ölçümünün kaçırılmasını önler.

LCP, CLS ve INP için event parametrelerini yapılandırmak

GA4'e gönderilen her event adı otomatik olarak bir rapor kalemini oluşturur. LCP, CLS, INP adlarıyla gelen eventler "Events" ekranında görünür. Asıl fayda ise custom parametreler aracılığıyla gelir.

Yukarıdaki kodda metric_rating, metric_value ve metric_id üç custom parametre olarak tanımlandı. Bu parametrelerin GA4 arayüzünde görünmesi için her birini ayrıca Custom Dimension (özel boyut) ya da Custom Metric (özel metrik) olarak kaydetmek gerekir. GA4 Admin panelinde "Custom definitions" bölümüne gidin; metric_rating için bir boyut, metric_value için de bir metrik açın. metric_id tekil sayım amacıyla gönderildiğinden boyut tanımı zorunlu değildir.

Boyutu tanımlarken kapsam için "Event" seçin, çünkü her ölçüm tek bir event olayına bağlıdır. Oturum veya kullanıcı kapsamı yanlış toplamaları tetikler ve değerler anlamsızlaşır.

Kritik bir pratik nokta: GA4, boyut etkinleştirmeden önce gelen parametreleri geriye dönük işlemez. Boyutu tanımladıktan sonra gelen veri görünür; öncesi sessiz kalır. Kurulumu mümkün olduğunca erken yapmak bu yüzden önemlidir. page_location parametresini de event'e eklemek hangi URL'den geldiğini gösterir; gtag bu parametreyi her event'e otomatik eklemiyorsa aşağıdaki gibi dahil edin:

function sendToGA4(metric) {
  gtag('event', metric.name, {
    value: Math.round(metric.name === 'CLS' ? metric.value * 1000 : metric.value),
    metric_id: metric.id,
    metric_value: metric.value,
    metric_rating: metric.rating,
    page_location: window.location.href,
  });
}

GA4 Explorer'da metrikleri segmentlere ayırmak

GA4'ün standart raporları event sayılarını gösterir; performans verisini anlamlandırmak için Explore (Keşfet) bölümü gerekir. Boş bir "Free form" raporu açıp boyutlara metric_rating, device_category ve page_location eklerken metriklere event_count ve metric_value girdiğinizde tablonun şekli netleşir.

Önce cihaz bazlı ayrımı yapın. Masaüstü ve mobil kullanıcılar aynı URL'de çoğu durumda farklı LCP değerleri üretir; masaüstü "Good" eşiğinin altında kalırken mobil "Poor" sınırını aşabilir. İki segment birlikte toplandığında ortalama değer aldatıcı biçimde iyi görünür, sorunun boyutu gizlenir.

Ardından metric_rating = "poor" filtresi ekleyin ve sayfaları event sayısına göre sıralayın. En çok "Poor" event üreten sayfalar listenin üstüne çıkar. Etki boyutu - kaç kullanıcının o deneyimi yaşadığı - doğrudan görünür hale gelir; bu sıralama hangi sayfaya önce bakacağınızı söyler. Düzenli ölçüm döngüsü kurduğunuzda bu Explorer raporunu deploy öncesi ve sonrası karşılaştırma olarak kullanabilirsiniz.

Tarih karşılaştırması değerlidir. Explore raporunda karşılaştırma dönemini açın; bir deploy öncesi ve sonrasını yan yana koyun. LCP değeri kötüleştiyse "Poor" eşiğini aşan event yüzdesi artar. Kötüleşmenin hangi sayfada ve hangi rating dağılımında gerçekleştiği bu yolla izlenir.

Hangi sayfalar gerçekten sorunlu: sayfa bazlı alan verisi

Ortalama değer yanıltıcı olabilir. Yüksek trafikli bir anasayfa iyi LCP üretirken düşük trafikli ürün sayfaları "Poor" eşiğini sürekli aşıyor olabilir; ortalama ikinci grubu gömer, sorun görünmez hale gelir.

Explorer'da page_location boyutunu kullanın ve satırları metric_value ortalamasına göre değil, toplam event içindeki "Poor" oranına göre değerlendirin. Bunu hesaplamanın pratik yolu şudur: önce filtreyi yalnızca "Poor" eventlere kurun ve event sayısını not edin, ardından filtreyi kaldırarak toplam event sayısıyla karşılaştırın. Oran yüksek ve mutlak sayı da büyükse o sayfa önceliklidir.

Peki az trafik alan ama yüksek dönüşüm değeri taşıyan sayfalar? GA4'ün segment özelliği burada devreye girer. Checkout, ödeme veya potansiyel müşteri formu gibi kritik sayfaları "Audience" bazlı bir segment olarak tanımlayın, performans raporunu bu segmentle filtreleyin. Kullanıcı sayısı az olsa da bu sayfalardaki CLS veya INP sorunu dönüşüm kaybına doğrudan yol açabilir. Tanılama sırasını belirlerken segment kırılımı hangi sayfaya önce bakacağınızı gösterir.

INP için segment kurmak daha karmaşıktır, çünkü INP değerinin yüksek olduğu durumlarda kullanıcının hangi etkileşimi gerçekleştirdiği bilgisi event içinde yer almaz. INP değerini cihaz ve sayfa boyutlarıyla kesmek, büyük JavaScript paketleri veya üçüncü taraf widget'ları olan sayfaları öne çıkarmak açısından yeterli bir başlangıç noktası sunar.

Search Console verisiyle karşılaştırma: iki kaynak aynı anda nasıl okunur

Search Console'un Core Web Vitals raporu CrUX (Chrome User Experience Report) verisini kullanır. GA4 kurulumunuz ise yalnızca sitenizde çalışan kodu çalıştıran kullanıcılardan gelen veriyi toplar. İki kaynak aynı gerçeği farklı merceklerle gösterir.

CrUX, tüm Chrome kullanıcılarının genel tarayıcı geçmişini içerir ve örnekleme politikasını Google belirler. GA4 verisi yalnızca JavaScript kodunuzun çalıştığı oturumları kapsar; reklam engelleyici kullananlar, JavaScript'i kapatan kullanıcılar veya sayfadan hızla çıkanlar bu kümede yer almayabilir.

Karşılaştırmanın pratik yolu şudur: Search Console'da "Poor" olarak işaretlenen bir URL grubunu alın, bu URL'leri GA4 Explorer'da page_location filtresiyle sorgulayın. GA4 verisi de aynı URL'yi "Poor" gösteriyorsa sorun gerçek ve yaygın demektir. Eğer GA4 verisi "Good" gösterirken Search Console "Poor" diyorsa, CrUX örneklemesindeki eski veri veya GA4 kurulumunuzun yakalamadığı bir kullanıcı segmenti söz konusu olabilir.

Search Console raporu URL grubu bazlı çalıştığından tek tek sayfaları ayırt etmek güçtür. GA4 bu konuda çok daha esnek bir tablo sunar. Search Console ise SEO değerlendirmesini görmek açısından hala birincil kaynaktır; lab skoru ile alan verisi arasındaki farkı bilen ekipler bu iki kaynağı birlikte kullanmayı tercih eder.

Tarih hizalaması da önemlidir. CrUX 28 günlük yuvarlayan pencere kullanır; GA4 verisi ise birkaç saatlik gecikmeyle gerçek zamanlıya yakındır. Kısa vadeli bir değişikliği karşılaştırırken CrUX henüz onu yansıtmamış olabilir; bu durumda GA4 verisi daha güncel bir tablo sunar.

Bu kurulumun işe yaradığı ve gereksiz kaldığı durumlar

Yüksek trafikli siteler için bu kurulum ciddi değer taşır. Kullanıcı verisi zenginleştikçe segment kırılımı anlamlı hale gelir; CLS değeri mobilde masaüstünün iki katıysa bunu görmek müdahale önceliğini değiştirir. Veri toplandıkça sayfa bazlı sıralamalar netleşir ve hangi sayfanın önce ele alınacağı açıkça ortaya çıkar.

Düşük trafikli siteler için tablonun değeri azalır. Günlük birkaç yüz oturum, sayfa bazlı kırılımda istatistiksel güven oluşturmak için yetersiz kalabilir. Ortalama değerler tutarsız dağılır; "Poor" olarak görünen bir sayfa belki yalnızca iki ziyaret almıştır. Bu durumda Search Console'un URL grubu raporu çoğu zaman yeterlidir.

E-ticaret siteleri bu kurulumdan doğrudan yararlanır. GA4 zaten dönüşüm akışını izlemektedir; INP verisi ödeme sayfasıyla ilişkilendirildiğinde sepet terk oranıyla birlikte değerlendirilebilir. E-ticaret performans önceliklerini belirlerken bu ilişki özellikle yönlendirici olur.

Çok sayıda sayfanın aynı şablonu paylaştığı içerik sitelerinde URL bazlı analiz yerine şablon bazlı analiz daha pratik sonuç verir. Bu durumda page_location yerine page_path boyutunu parçalayarak sayfa tiplerini gruplandırmak mümkündür.

LCP, CLS ve INP değerlerini GA4'te doğru yorumlamak

Üç metrik için farklı okuma mantıkları geçerlidir. LCP için 2500 ms altı Good, 4000 ms üzeri Poor sayılır. GA4'te LCP eventlerini milisaniye cinsinden saklarsınız; ortalama değer tek başına yanıltıcıdır. Google'ın alan verisi değerlendirmesinde kullandığı eşik 75. yüzdelik değere karşılık gelir. GA4 doğrudan percentile hesabı sunmaz; ancak 2500 ms üzerindeki event oranını hesaplamak pratik bir başlangıç noktası oluşturur.

CLS için 0,1 Good, 0,25 Poor eşiğidir. Kütüphane bu değeri 1000 ile çarptığından GA4'te 100 ve 250 bu sınırları temsil eder. Sayfa yüklendikten sonra gerçekleşen layout shift'leri de otomatik ölçülür; kullanıcı herhangi bir etkileşim yapmaksızın reklam veya embed yüklenince CLS yükselir.

INP için 200 ms Good, 500 ms Poor eşiğidir. INP, oturumda gerçekleşen en yavaş etkileşimi temsil eder ve sayfa kapatılırken raporlanır. Mobilde klavye açma, açılır menü tıklama ve form alanı odaklanması yaygın kaynaklardır. LCP öğesini tespit ederken kullandığınız yaklaşım INP için geçerli değildir; INP'nin hangi etkileşimden kaynaklandığını bulmak için Performance Observer ile ayrı bir izleme katmanı kurmanız gerekir.

Üç metriği birlikte okurken önce LCP ve INP'ye bakın; bu iki metrik kullanıcı deneyimini doğrudan etkiler. CLS genellikle yerleşim sorunlarına işaret eder ve düzeltmesi daha öngörülebilir adımlarla yapılır. Render zincirindeki gecikmelerin LCP üzerindeki etkisini anlamak, GA4 verisiyle tespit ettiğiniz sayfaların neden yavaş olduğunu açıklamaya yardımcı olur.