Blog details

GA4 Cross-Domain Takibi Web Sitelerinde Nasıl Kurulur

Kullanıcı ana siteden rezervasyon alanına geçtiğinde oturum kopuyorsa, raporlarınız size eksik hikaye anlatır. GA4 cross-domain takibi, tam da bu kopuşu önlemek için vardır.

Özellikle birden fazla alan adı, alt alan adı ya da harici ödeme sayfası kullanan yapılarda sorun sık görülür. Satın alma varmış gibi görünür ama kaynak raporları bozulur, self-referral artar ve dönüşüm yolu parçalanır. Doğru kurulumla bu zinciri yeniden birleştirebilirsiniz.

GA4 cross-domain takibi neyi çözer?

GA4’te cross-domain tracking, kullanıcının www.domain.com sitesinden booking.domain2.com veya shop.domain.com alanına geçerken aynı kullanıcı ve aynı oturum mantığıyla izlenmesini sağlar. Ama bunun çalışması için yalnızca iki sitede GA4 olması yetmez. Asıl kritik nokta, aynı Google tag veya aynı GTM mantığı, doğru domain listesi ve link taşıma davranışıdır.

Modern illustration of a web analyst at a desk with multiple browser tabs and GA4 dashboard showing unified sessions across domains like example.com.

GA4 bunu çoğunlukla URL’ye eklenen _gl parametresi ile yapar. Bu parametre, alanlar arası geçişte birinci taraf tanımlayıcı bilgisini taşır. Yani kullanıcı bir kapıdan çıkıp diğerine geçerken kimliğini yanında götürür. Bu yüzden linker davranışı bozulursa session continuity de bozulur.

2026 itibarıyla temel ekran yolu şudur: Admin -> Data Streams -> web akışı -> Configure tag settings -> Configure your domains. Burada alan adlarını tanımlarsınız. Google’ın önerdiği alanları körü körüne kabul etmeyin. Sadece gerçek geçiş yapılan domainleri ekleyin.

Şu üç senaryoyu ayırın:

  • www.domain.com -> shop.domain.com geçişi, çoğu durumda alt alan adı yönetimidir.
  • www.domain.com -> booking.domain2.com geçişi, gerçek cross-domain senaryosudur.
  • www.domain.com -> ödeme partneri alanı geçişi, her zaman tam cross-domain kurulacak bir alan değildir.

Eğer harici ödeme partnerinde kendi tag’lerinizi çalıştıramıyorsanız, orada tam cross-domain beklemeyin. Bu durumda en azından dönüşüm geri dönüşü, teşekkür sayfası ölçümü ve unwanted referrals temizliği üzerinde durun. Consent tarafında veri kaybı yaşıyorsanız, GA4 veri doğruluğu için sunucu tarafı etiketleme yaklaşımı da ayrı bir çözüm alanı açar.

Adım adım kurulum, ekran mantığıyla

Kurulumun temiz olması için tüm ilgili alanlarda aynı GA4 Measurement ID kullanılmalı. Ayrıca linkler gerçek HTML linki, yönlendirme butonu ya da form sonrası geçiş şeklinde çalışıyorsa linker bilgisinin taşınabildiğinden emin olmalısınız.

Step-by-step diagram of Google Tag Manager interface showing GA4 configuration tag with linker parameters enabled for example.com and booking.com domains, arrows indicating data flow from main site to subdomain.

En pratik kurulum akışı şöyledir:

  1. Tüm domainlerde aynı GA4 mülkünü kullanın. Farklı mülkler veya farklı Measurement ID’ler zinciri kırar.
  2. Data Streams içinden domain yapılandırmasını açın. domain.com, shop.domain.com, booking.domain2.com gibi gerçek geçiş alanlarını ekleyin.
  3. Google Tag Manager kullanıyorsanız linker davranışını kontrol edin. GA4 tag’i ya da Google tag ayarlarında cross-domain alan listesi tanımlı olmalı.
  4. Geçiş linklerini test edin. Kullanıcı bir alandan diğerine giderken hedef URL’de kısa süreliğine _gl parametresini görmelisiniz.
  5. Tüm sayfalarda consent durumu tutarlı olsun. İlk domainde analytics_storage granted iken ikinci domainde denied olursa kullanıcı devam ediyor görünse de GA4 için zincir kopar.
  6. Yayın sonrası DebugView ve Realtime ile doğrulayın.

Buradaki kilit nokta, _gl parametresinin geçiş anında taşınmasıdır. Eğer JavaScript yönlendirmesi, ara güvenlik sayfası, link kısaltıcı veya agresif banner script’i URL parametrelerini siliyorsa linker boşa düşer. Özellikle bazı cookie banner çözümleri sayfa ilk yüklenmeden sonra URL’yi yeniden yazdığı için cross-domain takibini sessizce kırar.

Pratik bir referans isterseniz, GA4 detaylı kurulum rehberi genel GA4 ekranları için iyi bir yardımcıdır. Yine de cross-domain tarafında asıl karar, hangi alanların gerçekten tek yolculuğun parçası olduğudur.

Referral exclusion ile cross-domain tracking aynı şey değildir

Bu ikisi sık karıştırılır. Oysa biri kaynak temizliği yapar, diğeri kullanıcı oturumunu taşır.

Aşağıdaki farkı net tutmak gerekir:

KonuCross-domain trackingReferral exclusion / unwanted referrals
Ana amaçOturumu ve kullanıcıyı alanlar arasında birleştirmekBelirli yönlendirmeleri kaynak raporundan temizlemek
Teknik dayanakLinker ve _gl parametresiİstenmeyen referral alanlarını hariç tutma
Session continuityKorurTek başına korumaz
Self-referral çözümüÇoğu durumda evetBazı rapor kirlenmelerini azaltır
Kullanım örneğiwww.domain.com -> booking.domain2.comÖdeme sağlayıcısı dönüşleri, ara yönlendirmeler

Referral exclusion eklemek, cross-domain kurulumu yapılmış anlamına gelmez.

GA4’te “unwanted referrals” ayarı, örneğin ödeme partnerinden geri gelen trafiğin kaynak olarak görünmesini engeller. Fakat kullanıcı partner alana giderken linker bilgisi taşınmıyorsa oturum zaten bölünmüş olabilir. Sonuçta self-referral azalır ama gerçek kaynak zinciri yine eksik kalır.

shop.domain.com gibi sizin kontrol ettiğiniz alanlarda önce cross-domain mantığını kurun. Harici payment partner alanında ise kontrol sizde değilse unwanted referrals ayarı daha anlamlı olabilir. Bu farkı atlayan ekipler, “referral sorunu çözüldü” sanırken dönüşüm yolunu hâlâ parçalı okur. Uygulama mantığını sade anlatan cross-domain tracking kurulumu örneği bu ayrımı görmek için faydalıdır.

Kurulumu nasıl doğrularsınız, hangi hata ne anlatır?

Yayın aldıktan sonra ilk durak DebugView olmalı. Bir kullanıcı akışını başlatın, ana siteden ikinci alana geçin. Aynı kullanıcı akışında event’lerin devam ettiğini görmelisiniz. Session baştan açılıyorsa bir kopuş vardır.

Modern illustration of GA4 DebugView screen displaying a session crossing from domain1.com to domain2.com with unified user ID and active realtime report icon, emphasizing session continuity in a desk setup with monitor.

Realtime raporunda kontrol edeceğiniz şey, kullanıcı alan değiştirdiğinde ikinci bir bağımsız kullanıcı gibi görünmemesidir. Ardından Traffic acquisition raporunda kendi domaininizin veya bağlı alanınızın referral kaynak olarak yükselip yükselmediğine bakın. Eğer domain.com / referral ya da booking.domain2.com / referral görüyorsanız, self-referral sorunu sürüyor olabilir.

En sık görülen bozukluk belirtileri şunlardır:

  • Kendi domaininiz referral kaynağı olarak görünür.
  • Dönüşüm sayısı var ama ilk trafik kaynağı anlamsız dağılır.
  • _gl parametresi hiç oluşmaz ya da geçişte silinir.
  • Consent banner ikinci domainde farklı çalıştığı için oturum bölünür.
  • Payment partner dönüşlerinde yeni session başlar.

Çözüm tarafında önce temel üçlüyü doğrulayın: aynı mülk, doğru domain listesi, geçerli linker aktarımı. Sonra consent akışına bakın. İlk domainde onay verilip ikinci domainde varsayılan red çalışıyorsa, teknik kurulum doğru olsa bile veri zinciri kırılır. Özellikle CMP entegrasyonu olan yapılarda bu sorun sanıldığından daha yaygındır.

Conversions raporunda da şuna dikkat edin: satın alma veya lead event’i ikinci domainde oluşuyorsa, kaynak ataması ilk girişi koruyor mu? Koruyorsa kurulum büyük ölçüde doğrudur. Korunmuyorsa sorun çoğu zaman linker, consent veya yönlendirme zincirindedir.

GA4 cross-domain takibi, raporları güzelleştiren bir ayar değil, kullanıcı yolculuğunu tek parça okumayı sağlayan teknik bir gerekliliktir. Doğru kurulumda oturum kopmaz, kaynak bozulmaz ve dönüşüm yolu anlam kazanır.

İşin püf noktası tek cümlede özetlenir: unwanted referrals temizliği ile yetinmeyin, session continuity’yi gerçekten test edin. DebugView’da, Realtime’da ve edinim raporlarında aynı hikayeyi görmüyorsanız kurulum tamamlanmış sayılmaz.