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.

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.comgeçişi, çoğu durumda alt alan adı yönetimidir.www.domain.com->booking.domain2.comgeç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.

En pratik kurulum akışı şöyledir:
- Tüm domainlerde aynı GA4 mülkünü kullanın. Farklı mülkler veya farklı Measurement ID’ler zinciri kırar.
- Data Streams içinden domain yapılandırmasını açın.
domain.com,shop.domain.com,booking.domain2.comgibi gerçek geçiş alanlarını ekleyin. - 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ı.
- Geçiş linklerini test edin. Kullanıcı bir alandan diğerine giderken hedef URL’de kısa süreliğine
_glparametresini görmelisiniz. - 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.
- 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:
| Konu | Cross-domain tracking | Referral exclusion / unwanted referrals |
|---|---|---|
| Ana amaç | Oturumu ve kullanıcıyı alanlar arasında birleştirmek | Belirli yönlendirmeleri kaynak raporundan temizlemek |
| Teknik dayanak | Linker ve _gl parametresi | İstenmeyen referral alanlarını hariç tutma |
| Session continuity | Korur | Tek başına korumaz |
| Self-referral çözümü | Çoğu durumda evet | Bazı rapor kirlenmelerini azaltır |
| Kullanım örneği | www.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.

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.
_glparametresi 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.