GA4 kurulumu genellikle çok dilli bir sitenin dil boyutunu hiç görmez. Tek bir property, tek bir veri akışı, Türkçe ve İngilizce sürümdeki tüm trafiği aynı raporda eritir. Kurulum sırasında kimse yanlış bir şey yapmamıştır; GA4 varsayılan olarak sayfa yolunu kaydeder ama bu yolun hangi dile ait olduğunu ayrı bir boyut olarak işaretlemez. Sonuç, İngilizce sayfaların dönüşüm oranını Türkçe sayfalarla karıştıran, hangi dil versiyonunun gerçekten işe yaradığını göstermeyen bir gösterge paneli olur.
Sorunun köküne inildiğinde iki ayrı karar görülür: dil bilgisinin hangi teknik yolla yakalanacağı ve bu bilginin raporlama katmanında nasıl bir segmente dönüştürüleceği. Bunlardan ilki bir kere kurulur ve nadiren değişir; ikincisi ise her analiz oturumunda tekrar tekrar kullanılır. Kurulum aşamasında yapılan küçük bir eksiklik, aylar sonra "hangi dil versiyonu daha iyi performans gösteriyor" sorusuna doğru cevap verilemeyen bir veri setine dönüşür.
Aşağıda ele alınan altı karar noktası, dil versiyonlarını tek bir GA4 mülkü içinde ayrıştırma, dil bilgisini doğru boyuta yerleştirme, URL yapısının segmentasyonu nasıl kolaylaştırdığı, Explore raporlarında karşılaştırma kurma, hangi metriklerin dil bazında gerçekten anlamlı olduğu ve kurulum sırasında sık yapılan hatalar etrafında sıralanıyor.
GA4'te dil versiyonları tek property içinde nasıl ayrışır?
İlk karar, her dil versiyonu için ayrı bir GA4 mülkü mü kurulacağı, yoksa tek mülk içinde dil boyutunun ayrıştırılacağı sorusudur. Ayrı mülk yaklaşımı ilk bakışta temiz görünür: Türkçe sürüm için bir mülk, İngilizce sürüm için başka bir mülk, veri hiç karışmaz. Ama bu yapı kullanıcı yolculuğunu böler. Bir ziyaretçi Türkçe sayfada başlayıp dil seçiciyle İngilizce sürüme geçtiğinde, bu tek oturum iki farklı mülkte iki ayrı ziyaret olarak kaydedilir; toplam kullanıcı sayısı şişer, gerçek katılım oranı bozulur.
Tek mülk içinde dil ayrımı yapmak, çoğu site için daha sağlıklı sonuç üretir. Aynı kullanıcının dil değiştirme davranışı tek oturum içinde görülebilir, kanal atfı bozulmaz, dönüşüm hunisi dil geçişlerini de kapsar. Bu yaklaşımın maliyeti, dil bilgisinin ayrı bir boyut olarak açıkça tanımlanması gerekliliğidir; GA4 bunu otomatik yapmaz.
Yüksek trafikli, tamamen bağımsız iş birimleri gibi çalışan çok dilli projelerde (örneğin her dil için ayrı pazarlama ekibi, ayrı bütçe, ayrı hedef) ayrı mülk kurmak tercih edilebilir; burada kullanıcı yolculuğunun dil sınırını aşması zaten beklenmez. Ama bir blog, kurumsal site veya küçük-orta ölçekli e-ticaret için tek mülk, dil bazlı boyut kombinasyonu genellikle daha doğru bir tablo çizer.
Dil bilgisini custom dimension olarak yakalamak: content_group mu, page_language mi?
Dil bilgisini yakalamak için iki yaygın yöntem vardır: sayfanın <html lang> özniteliğini bir event parametresi olarak göndermek, veya GA4'ün yerleşik içerik gruplama özelliğini kullanmak. İkisi de çalışır, ama farklı esneklik seviyeleri sunar.
HTML lang özniteliğini Google Tag Manager üzerinden okuyup language adında bir event parametresi olarak her sayfa görüntülemesine eklemek, en doğrudan yoldur. Bu parametre GA4 arayüzünde "özel boyut" (custom dimension) olarak kayıt edilmelidir; kayıt edilmeden gönderilen parametreler yalnızca ham olay verisinde görünür, standart raporlarda ve Explore'da kullanılamaz. GA4'ün olay kapsamlı özel boyut limiti elliyi bulur, bu sınırın büyük çoğunluğu genellikle boş kalır; dil boyutu için bir slot ayırmak maliyetli değildir.
İçerik gruplama (content grouping) yöntemi ise sayfa yolunu bir kural kümesine göre otomatik sınıflandırır: yol /en/ ile başlıyorsa grup "İngilizce", /tr/ ile başlıyorsa grup "Türkçe" gibi. Bu yöntem URL yapısı zaten dil öneki taşıyan sitelerde ek geliştirme gerektirmeden çalışır, ama HTML lang özniteliği ile URL öneki her zaman birebir örtüşmeyen sitelerde (örneğin hatalı yönlendirme sonucu yanlış dilde açılan bir sayfa) gerçek durumu yanlış yansıtabilir. İki yöntemi birlikte kurmak, biri diğerinin doğruluğunu kontrol eden bir çift katman oluşturur.
URL yapısı GA4 segmentasyonunu nasıl kolaylaştırır, nasıl zorlaştırır?
Çok dilli URL yapısı kararı, GA4 segmentasyonunun ne kadar zahmetsiz kurulacağını doğrudan belirler. Alt dizin yapısı (site.com/en/, site.com/tr/) kullanılıyorsa, sayfa yolu üzerinde basit bir regex eşleşmesiyle dil segmenti kurulabilir; ek bir parametre göndermeye gerek kalmadan bile kabaca bir ayrım elde edilir. Bu, en az mühendislik eforu isteyen senaryodur.
Alt domain yapısında (en.site.com, tr.site.com) durum biraz karmaşıklaşır: aynı mülkte birden fazla alt domain izleniyorsa, GA4'ün "cross-domain measurement" ayarı doğru yapılandırılmalı, aksi halde alt domainler arası geçişlerde oturum kopar ve kullanıcı sayısı gerçekte olduğundan yüksek görünür. Ayrı ccTLD kullanan projelerde (site.de, site.com.tr) ise segmentasyon artık URL üzerinden değil, ölçüm kimliğinin (measurement ID) hangi alan adına bağlı olduğu üzerinden yapılmak zorunda kalır; bu, dil parametresi yaklaşımını neredeyse zorunlu hale getirir.
URL yapısı ne olursa olsun, dil segmentasyonunu tek bir sinyale (yalnızca URL, yalnızca parametre) bağlamak kırılgan bir kurulum üretir. Sağlam bir kurulum, URL yapısından gelen kaba sinyali özel boyuttan gelen kesin sinyalle çapraz doğrular.
Explore raporlarında dil bazlı karşılaştırma nasıl kurulur?
Dil boyutu doğru şekilde kaydedildikten sonra, günlük analiz işi Explore modülünde "comparisons" (karşılaştırmalar) özelliği üzerinden yürütülür. Standart raporlarda dil boyutunu ikincil boyut olarak eklemek de mümkündür, ama bu yalnızca tek bir metriği tek bir tabloda gösterir; Explore'da birden fazla dil segmentini yan yana, birden fazla metrikle aynı anda karşılaştırmak çok daha hızlı bir okuma sağlar.
Pratik kurulum şu şekilde işler: Explore'da yeni bir keşif oluşturulur, boyut olarak dil özel boyutu eklenir, satırlara bu boyut yerleştirilir, sütunlara ilgilenilen metrikler (etkileşimli oturum sayısı, ortalama etkileşim süresi, dönüşüm oranı) sıralanır. Karşılaştırma özelliği kullanılarak üstteki filtre çubuğuna her dil için ayrı bir segment eklenirse, aynı grafik veya tablo üzerinde dil bazlı eğilim değişimi tek bakışta görülür.
Uluslararası SEO metriklerinin nasıl yorumlanacağı konusundaki genel ilke burada da geçerlidir: tek bir toplam rakam yerine segment bazlı okuma, hangi dil versiyonunun büyüme, hangisinin durgunluk gösterdiğini ayırt eder. Explore'da kurulan bu görünüm bir kere hazırlandıktan sonra kaydedilip düzenli olarak yeniden açılabilir; her analiz oturumunda sıfırdan kurulmasına gerek kalmaz.
Hangi metrikler dil versiyonu bazında gerçekten anlam taşır?
Ham oturum sayısını dil bazında karşılaştırmak, çoğu zaman yanıltıcı bir sıralama üretir; çünkü diller arasındaki pazar büyüklüğü, arama hacmi ve marka bilinirliği farklıdır. Türkçe sürümün oturum sayısı İngilizce sürümden yüksek olması, Türkçe sürümün daha iyi çalıştığı anlamına gelmez; sadece hedef pazarın büyüklüğünü yansıtabilir.
Oransal metrikler bu çarpıklığı büyük ölçüde ortadan kaldırır. Etkileşim oranı (engagement rate) ve ortalama etkileşim süresi, dil versiyonunun içerik kalitesini ve kullanıcı uyumunu pazar büyüklüğünden bağımsız gösterir. Dönüşüm oranı, hedef sayfaya ulaşan kullanıcıların hangi dilde daha kolay ikna olduğunu ortaya koyar. Giriş sayfası (landing page) performansı dil bazında incelendiğinde, aynı içeriğin farklı dil sürümlerinin arama sonuçlarında farklı davranış çektiği görülebilir; bu fark, Search Console'daki uluslararası hedefleme raporundaki tıklama oranı verisiyle birlikte okunduğunda daha net bir tanı sağlar.
Trafik kaynağı dağılımının dil bazında ayrı izlenmesi de önemlidir. Bir dil sürümü ağırlıklı olarak organik aramadan, diğeri ağırlıklı olarak doğrudan trafikten besleniyorsa, bu ikisine aynı pazarlama stratejisini uygulamak farklı sonuçlar üretir. Dil bazlı kanal karışımı, hangi pazara hangi kanaldan yatırım yapılacağı kararını doğrudan besler.
Sık yapılan kurulum hataları: veri neden dil bazında yanıltıcı görünür?
En yaygın hata, hreflang etiketlerinin GA4'e otomatik olarak veri beslediği yanılgısıdır. Hreflang tamamen Google'ın arama motoru tarafında çalışan bir sinyaldir; GA4'ün hangi dil versiyonunun görüntülendiğini bilmesiyle hiçbir bağlantısı yoktur. Bounce ve dil uyumsuzluğu ayrı bir tanı ister; geçiş sonrası bounce rate GA4 dil segmentiyle birlikte okunur. Hreflang kurulu olsa da olmasa da, dil boyutu GA4'e ayrıca ve açıkça gönderilmelidir.
İkinci hata, özel boyut değerlerinde büyük-küçük harf tutarsızlığıdır. Bir sayfa Turkish değerini gönderirken başka bir sayfa turkish veya TR gönderiyorsa, GA4 bunları farklı segmentler olarak sayar ve toplam rakamlar bölünmüş görünür. Değer kümesinin baştan sabitlenmesi (örneğin her zaman ISO dil kodu, her zaman küçük harf) bu sorunu kökten önler.
Üçüncü hata, düşük trafikli dil versiyonlarında GA4'ün eşiklendirme (thresholding) uyguladığının fark edilmemesidir; belirli bir kullanıcı eşiğinin altında kalan segmentlerde bazı demografik ve ilgi alanı verileri gizlenir, rapor boş görünür ama aslında veri eksik değil, gizlenmiştir. Az konuşulan bir dil sürümünde bu durumla karşılaşıldığında sorun kurulumda değil, örneklem büyüklüğündedir.
Dördüncü hata, otomatik dil yönlendirmesinin GA4 oturum sayacını nasıl etkilediğinin göz ardı edilmesidir. Bir ziyaretçi konum tahminiyle otomatik olarak başka bir dile yönlendirildiğinde, bu yönlendirme GA4'te ayrı bir sayfa görüntülemesi olarak kaydedilebilir; giriş sayfası raporu, ziyaretçinin gerçekte tıkladığı sayfa yerine yönlendirildiği sayfayı gösterir. Bu, hangi arama sonucunun gerçekte trafik çektiğini anlamayı zorlaştırır ve genellikle log dosyası analiziyle çapraz kontrol edilmeden fark edilmez; log verisiyle GA4 verisinin farklı sorulara cevap verdiği ilkesi burada da geçerlidir, ikisi birbirinin yerine geçmez.
Dil bazlı GA4 kurulumu bir kere doğru temellendirildiğinde, sonraki her yeni dil sürümü aynı boyut şemasına eklenir; kurulumun tekrar sıfırdan tasarlanmasına gerek kalmaz. Asıl emek, ilk dil versiyonunu ekleme aşamasında değil, ikinci ve üçüncü dilin devreye girdiği noktada harcanır: burada boyut değerlerinin tutarlılığı ve segment tanımlarının genişleyebilirliği test edilir.
Kurulumun doğruluğunu düzenli aralıklarla kontrol etmenin en pratik yolu, her yeni dil sürümü yayına alındığında Explore raporunu açıp o dilin segmentinin gerçekten veri topladığını, boş veya sıfır görünmediğini doğrulamaktır. Bu küçük kontrol, aylar sonra fark edilecek bir veri boşluğunun erkenden yakalanmasını sağlar.