Google Analytics 4 (GA4) İleri Düzey Kurulum

İçindekiler

Okuma Süresi: 8 Dakika

ga4 kurulum

Google Analytics 4 üzerinde trafik ve event verilerinin görünmesi, ölçüm altyapısının hatasız çalıştığını göstermez. GA4 ileri düzey kurulum sürecinde eventlerin doğru anda tetiklenmesi, trafik kaynağının kullanıcı yolculuğu boyunca korunması ve raporlanan sonuçların CRM ya da satış sistemiyle açıklanabilmesi gerekir.

Property oluşturma, data stream tanımlama ve temel etiketleme adımları GA4 kurulumunun başlangıç seviyesini oluşturur. Platformun event modeli ve standart raporlama özellikleri hakkında ayrıntılı bilgiye Google Analytics 4 nedir? içeriğinden ulaşabilirsiniz. Bu yazıda aktif bir kurulumun veri kalitesi, kullanıcı izinleri ve teknik doğrulama tarafına odaklanacağız.

İleri Düzey GA4 Kurulumu Hangi Projelerde Gerekir?

Tek alan adına ve birkaç temel kullanıcı aksiyonuna sahip web sitelerinde standart bir etiketleme planı yeterli olabilir. Ödeme, rezervasyon veya başvuru sürecinin farklı sistemlere taşınmasıyla ölçüm hatalarının kapsamı genişler.

İleri düzey GA4 kurulumu özellikle şu projelerde öne çıkar:

Web sitesi ve mobil uygulamanın birlikte ölçüldüğü platformlar
Ödeme veya başvuru sürecinin farklı alan adında tamamlandığı siteler
Birden fazla marka ya da ülkenin ortak Analytics hesabından yönetildiği projeler
CRM ve çevrimdışı satış verilerinin raporlamaya dahil edildiği şirketler
Consent Mode ve çerez yönetim platformu kullanan siteler
Aynı GTM konteynerinde birden fazla ekip veya ajansın çalıştığı projeler

Bu ölçekteki projelerde sorun çoğu zaman veri eksikliğinden kaynaklanmaz. Aynı başvurunun farklı event adlarıyla gönderilmesi veya ödeme geçişinde trafik kaynağının değişmesi, raporlar çalışıyor görünürken sonuçların hatalı yorumlanmasına yol açabilir.

Aynı İşlem Neden Farklı Event Adlarıyla Ölçülmemeli?

Event isimleri ortak bir kurala bağlanmadığında aynı iş sonucu farklı adlarla kaydedilebilir. Teklif formu bir sayfada form_submit, başka bir sayfada generate_lead, üçüncü bir alanda ise request_quote olarak gönderildiğinde toplam başvuru sayısını tek raporda izlemek zorlaşır.

Kurulumdan önce hazırlanacak ölçüm sözlüğü, her eventin iş tanımını ve tetiklenme koşulunu açık biçimde göstermelidir.

Alan	Tanım
Event adı	GA4’e gönderilecek standart event
İş karşılığı	Eventin temsil ettiği kullanıcı aksiyonu
Tetiklenme koşulu	Eventin hangi anda çalışacağı
Parametreler	Event ile gönderilecek ek bilgiler
Sorumlu ekip	Kurulumu ve veri doğruluğunu takip eden ekip
Test senaryosu	Eventin nasıl doğrulanacağı

İncelediğimiz projelerde başarılı form gönderimleri ile doğrulama hatalarının aynı event altında toplandığı örneklerle sık karşılaşıyoruz. Event teknik olarak çalışmasına rağmen raporlanan lead sayısı gerçek başvuruları yansıtmıyor.

Hangi eventlerin ticari hedef olarak ele alınacağı ayrı bir planlama gerektirir. Bu konu GA4 dönüşüm takibi rehberinde performans ve bütçe yönetimi açısından ele alınmaktadır.

Tek Property Her Proje İçin Doğru Mu?

Birden fazla web sitesini aynı property altında toplamak, ortak kullanıcı yolculuğuna sahip markalarda anlamlı olabilir. Birbirinden bağımsız ülkelerin, markaların veya iş birimlerinin aynı veri alanında bulunması ise erişim ve raporlama sorunları doğurabilir.

Property kararı verilirken dijital varlıkların aynı müşteri yolculuğunu paylaşıp paylaşmadığına, ekiplerin hangi verilere erişmesi gerektiğine ve raporların ortak saat dilimiyle hazırlanıp hazırlanamayacağına bakılır. Web ve mobil uygulama verilerinin birlikte analiz edilme ihtiyacı da bu kararı etkiler.

Çok markalı hesaplarda sorunlar teknik ayarlarla sınırlı kalmaz. Tüm kullanıcılara yönetici yetkisi verilmesi, yapılan değişikliklerin takibini ve veri güvenliğini zorlaştırır. Hesap mimarisi hazırlanırken erişim seviyeleri de çalışma kapsamına dahil edilmelidir.

Enhanced Measurement Eventleri Neden Test Edilmeli?

Enhanced Measurement, scroll, site içi arama, dosya indirme ve dış bağlantı tıklaması gibi bazı etkileşimleri otomatik olarak ölçebilir. Buna rağmen otomatik çalışan her event, kullanıcı davranışını doğru yorumlamaz.

Özel geliştirilen bir formda gönder butonuna basılması, form tamamlanmadan event üretebilir. Kullanıcı zorunlu alanları doldurmadığı halde işlem başarılı başvuru gibi kaydedilebilir. Benzer biçimde hem Enhanced Measurement hem GTM üzerinden gönderilen bir event iki kez çalışabilir.

Otomatik eventlerin tetiklenme anı, tekrar sayısı ve taşıdığı parametreler gerçek kullanıcı senaryolarıyla test edilmelidir. E-ticaret projelerinde dataLayer, GTM değişkenleri ve event sıralaması farklı bir teknik kapsam taşır. Bu adımlar GA4 e-ticaret event kurulumu içeriğinde ayrıntılı olarak incelenebilir.

Alan Adı Geçişleri Trafik Kaynağını Nasıl Bozar?

Bir kullanıcı reklam üzerinden ana siteye geldikten sonra farklı bir alan adındaki ödeme veya rezervasyon ekranına geçebilir. Alan adları arasındaki ölçüm bağlantısı doğru kurulmadığında ilk oturum sona erer ve işlem ikinci alan adına referral olarak yazılabilir.

Örneğin kullanıcı ücretli arama reklamından siteye gelir, ürünü sepete ekler ve ödeme kuruluşunun ekranına yönlendirilir. İşlem sonrasında ana siteye döndüğünde GA4 yeni bir oturum başlatırsa satın alma reklam kampanyası yerine ödeme kuruluşuyla ilişkilendirilebilir.

Purchase event’i doğru çalışıyor olabilir. Sorun, eventin kendisinden çok oturumun ve kaynak bilgisinin yolculuk sırasında değişmesidir. Kampanya geliri eksik, referral kanalının katkısı ise gerçekte olduğundan yüksek görünür.

Cross-Domain ve Unwanted Referrals Aynı Ayar Değildir

Markaya ait veya aynı ölçüm sisteminin çalıştığı alan adları arasında kullanıcı kimliğini ve oturumu korumak için cross-domain ölçümleme kullanılır.

Banka, ödeme kuruluşu veya kimlik doğrulama servisi gibi kısa süreli üçüncü taraf geçişleri ise unwanted referrals kapsamında ele alınabilir. Tüm referral alan adlarını listeye eklemek doğru olmaz. Gerçek iş ortaklarından ve yönlendirme kaynaklarından gelen trafik de bu şekilde raporlardan çıkarılabilir.

Test sırasında alan adları arasındaki geçiş, linker parametresinin korunması ve oturum kaynağının değişip değişmediği birlikte incelenmelidir.

Dahili Trafik Raporları Ne Kadar Değiştirebilir?

Çalışanlar, yazılım ekipleri ve ajans kullanıcıları web sitesinde gerçek ziyaretçilerden daha yoğun hareket edebilir. Trafiği sınırlı bir B2B sitesinde birkaç çalışanın günlük kontrolleri bile en çok görüntülenen sayfaları ve etkileşim oranlarını etkileyebilir.

Sabit ofis IP’leri dahili trafiği ayırmak için kullanılabilir. Uzaktan çalışan ekiplerde VPN, çalışan oturumu veya özel cookie değerleri gibi ek yöntemlere ihtiyaç duyulabilir. IP dışında kalan çözümler çoğunlukla GTM ya da yazılım tarafında ek kurulum gerektirir.

Veri filtresini doğrudan aktif etmek yerine önce test durumunda çalıştırmak daha güvenlidir. Yanlış tanımlanan aktif bir filtre, gerçek kullanıcı verilerini kalıcı biçimde veri setinin dışında bırakabilir.

Staging Trafiği Gerçek Kullanıcı Verisini Nasıl Bozar?

GA4 etiketi geliştirme ve staging ortamlarına da eklendiğinde teknik ekibin testleri üretim property’sine gönderilebilir. Sayfa görüntülemeleri, form eventleri ve test siparişleri gerçek kullanıcı verisine karıştığında raporlanan hacim yükselir.

Hostname raporunda ana alan adının yanı sıra staging, demo, ön izleme ve geliştirme URL’leri aranmalıdır. Bu ortamların ayrı data stream ya da property üzerinden ölçülmesi daha temiz bir ayrım sağlar. Aynı property’nin kullanıldığı projelerde hostname bazlı segment veya filtre planlanabilir.

Filtreleme yöntemi seçilirken geliştiricilerin DebugView üzerinden test yapmaya devam etmesi de hesaba katılmalıdır. Üretim verisini temizlemek adına teknik doğrulama sürecini kullanılamaz hale getiren bir kurgu oluşturulmamalıdır.

Consent Mode Kurulumunda Sıralama Neden Önemlidir?

Çerez banner’ının ekranda görünmesi, izin sinyallerinin Google etiketlerine doğru aktarıldığı anlamına gelmez. CMP kullanıcının tercihini toplarken Consent Mode bu tercihin Google etiketleri tarafından nasıl uygulanacağını belirler.

Sayfa açıldığında varsayılan izin durumu, GA4 ve reklam etiketlerinden önce çalışmalıdır. Kullanıcı tercihini değiştirdiğinde analytics_storage, ad_storage, ad_user_data ve ad_personalization sinyalleri aynı sayfada güncellenir.

Sık karşılaşılan hatalardan biri, GA4 etiketinin varsayılan consent durumu belirlenmeden önce çalışmasıdır. Banner birkaç saniye sonra yüklense bile, ilk veri isteği kullanıcı tercihi işlenmeden gönderilmiş olabilir.

GA4 teknik denetimi sırasında consent akışı Tag Assistant üzerinde zaman sırasıyla kontrol edilmelidir. CMP panelinde iznin kaydedildiğini görmek, etiketlerin aynı tercihe uygun davrandığını kanıtlamaz.

User-ID Kullanılırken Hangi Veriler Gönderilmemeli?

Oturum açma özelliği bulunan platformlarda User-ID, aynı kullanıcının farklı cihazlardaki davranışlarını ilişkilendirmeye yardımcı olur. Kullanılan değer kişiyi doğrudan tanımlamamalıdır.

E-posta adresi, telefon numarası, ad-soyad veya kimlik numarası User-ID olarak gönderilmemelidir. Şirket sisteminde üretilen anonim bir kullanıcı anahtarı daha uygun bir seçimdir.

Değerin kullanıcı giriş yaptıktan sonra sonraki eventlerde korunması ve çıkış işleminde temizlenmesi gerekir. Web sitesi ile uygulamanın aynı kimlik kuralını kullanmaması, cihazlar arası analizi parçalayabilir. Giriş öncesindeki anonim hareketlerin giriş sonrasındaki User-ID verileriyle her koşulda eksiksiz birleşeceği de varsayılmamalıdır.

Parametre İsimleri Nasıl Standartlaştırılır?

Aynı bilgi farklı eventlerde ayrı parametre adlarıyla gönderildiğinde, raporlama da parçalanır. Ürün kategorisinin bir eventte item_category, başka bir eventte product_category olarak kullanılması buna örnektir.

Her parametre için hangi raporda kullanılacağı, değer formatı ve mevcut GA4 boyutlarıyla çakışıp çakışmadığı belirlenmelidir. Analiz amacı bulunmayan alanları eklemek, kurulumu genişletirken raporların kullanımını zorlaştırır.

Sipariş numarası, kullanıcı kimliği, tam URL ve zaman damgası gibi çok sayıda benzersiz değer üreten alanların custom dimension olarak tanımlanması da GA4 arayüzünde cardinality sorunlarına yol açabilir. Tekil işlem detaylarını arayüz raporlarına taşımak yerine BigQuery üzerinde analiz etmek daha uygun olabilir.

BigQuery Bağlantısı Ne Zaman Kurulmalı?

BigQuery bağlantısını ham event verisine ihtiyaç ortaya çıktıktan sonra açmak, geçmiş veriye erişimi sınırlar. Bağlantı tarihinden önce oluşan ham eventler geriye dönük olarak dışa aktarılmaz.

Kurulum aşamasında veri setinin bölgesi, erişim yetkileri, saklama süresi ve CRM ya da sipariş verileriyle eşleştirme yöntemi belirlenebilir. Her eventin kontrolsüz biçimde aktarılması ise depolama ve sorgu maliyetlerini artırabileceği için veri planı ölçüm sözlüğüyle birlikte ilerlemelidir.

BigQuery, bu yazının ana konusu olan GA4 veri kalitesinin yerine geçmez. Hatalı eventler ham veri katmanına aktarıldığında, daha ayrıntılı ancak yine hatalı bir veri seti oluşur.

GA4 Kurulumu Nasıl Test Edilir?

GA4 kurulum kontrolü, Realtime raporunda eventin göründüğü noktada tamamlanmaz. Etiket, kullanıcı yolculuğu ve kaynak sistem verileri ayrı seviyelerde doğrulanmalıdır.

Etiket ve Parametre Kontrolü

İlk aşamada Google etiketinin gerekli sayfalarda bir kez çalıştığı, eski GTM etiketleriyle çakışmadığı ve eventlerin doğru kullanıcı aksiyonundan sonra gönderildiği kontrol edilir. Boş, undefined veya null parametreler ile para birimi ve gelir formatındaki tutarsızlıklar bu aşamada görülebilir.

Kullanıcı Yolculuğu Kontrolü

Alan adları arasında oturumun korunup korunmadığı, ödeme sonrasında trafik kaynağının değişip değişmediği ve consent tercihinin etiket davranışına yansıyıp yansımadığı gerçek senaryolarla test edilir. Üyelik bulunan projelerde giriş ve çıkış sonrasında User-ID akışı da aynı teste dahil edilir.

Kaynak Sistemlerle Mutabakat

Sipariş eventleri arka ofis kayıtlarıyla, form gönderimleri ise CRM verileriyle karşılaştırılır. GA4 ile kaynak sistem arasında consent tercihleri, reklam engelleyiciler, saat dilimi, iadeler ve client-side veri kaybı nedeniyle fark oluşabilir.

Amaç her sistemde birebir aynı sayıya ulaşmak değildir. Farkın nedenini, yönünü ve yaklaşık büyüklüğünü açıklayabilmek gerekir.

GA4 Kurulumu Hangi Değişikliklerden Sonra Yeniden Test Edilmeli?

Web sitesi üzerinde yapılan her güncelleme ölçüm planını etkilemez. Form, ödeme, kullanıcı izni ve alan adı geçişine dokunan değişiklikler ise GA4 veri doğrulama sürecini yeniden gündeme getirir.

Şu değişikliklerin ardından uçtan uca test yapılmalıdır:

Form veya başarı sayfası değişiklikleri
Yeni ödeme kuruluşu ya da rezervasyon sistemi
Site taşıma ve alan adı değişikliği
Çerez yönetim platformu güncellemesi
GTM konteynerinde kapsamlı yayın
Mobil uygulama veya üyelik sistemi değişikliği
Yeni CRM ve satış sistemi entegrasyonu

Rutin kontrollerde event hacmindeki beklenmeyen artışlar, yeni referral alan adları, hostname dağılımı, boş parametreler ve erişim yetkileri takip edilebilir.

GA4 Verisine Ne Kadar Güvenebilirsiniz?

İleri düzey GA4 kurulumu, ölçülen event sayısını artırmak için yapılmaz. Amaç, satış ve lead raporlarının hangi teknik akıştan geldiğini ve gerçek iş sonuçlarını ne kadar doğru temsil ettiğini görebilmektir.

Yürüttüğümüz denetimlerde sorun çoğu zaman eksik eventten kaynaklanmıyor. Aynı eventin yanlış anda veya birden fazla kez tetiklenmesi daha sık karşılaşılan bir durum. Alan adı geçişleri ve consent sıralaması da veriler normal görünürken kanal performansını değiştirebiliyor.

Yönetici açısından temel soru GA4’te veri olup olmadığı değildir. Raporlanan sonuçların satış, CRM ve reklam platformu kayıtlarıyla açıklanıp açıklanamadığına bakılmalıdır. Bu bağlantı kurulamıyorsa, bütçe kararları güvenilir olmayan bir veri seti üzerinden verilebilir.

Adsera’nın veri analizi ve raporlama çalışmalarında GA4, reklam platformları ve satış verileri aynı çerçevede incelenir. Teknik kurulum ile ticari sonuçlar arasındaki fark böylece daha açık görülebilir.

SIKÇA SORULAN SORULAR

GA4 ileri düzey kurulumu nedir?

GA4 ileri düzey kurulum; temel etiketlemenin ardından cross-domain, Consent Mode, dahili trafik, User-ID ve event standardının düzenlenmesidir. Süreç, toplanan verinin iş sonuçlarını doğru temsil edip etmediğini de kapsar.

GA4 verilerinin doğru olduğu nasıl anlaşılır?

Eventlerin tetiklenme anı, parametreleri ve trafik kaynağı gerçek kullanıcı senaryolarıyla test edilir. Sonuçlar CRM, sipariş veya başvuru kayıtlarıyla karşılaştırılarak veri farklarının nedeni belirlenir.

Cross-domain ölçümleme ne zaman gerekir?

Kullanıcı yolculuğu birden fazla alan adında devam ettiğinde cross-domain ölçümleme gerekebilir. Ödeme, rezervasyon, başvuru ve müşteri paneli geçişleri bu kapsama girebilir.

GA4’te dahili trafik nasıl ayrıştırılır?

Sabit IP adreslerinin yanı sıra VPN, çalışan oturumu ve özel cookie değerleri kullanılabilir. IP dışında kalan yöntemler GTM veya yazılım tarafında ek kurulum gerektirir.

GA4 kurulumu ne sıklıkla denetlenmelidir?

Temel veri kalite kontrolleri aylık olarak yapılabilir. Form, ödeme akışı, GTM, Consent Mode veya site altyapısı değiştiğinde kurulum yeniden test edilmelidir.

Oğuz Sezer

Oğuz Sezer, Adsera bünyesinde Growth marketing team lead olarak görev alıyor. Takımını yönetmenin yanında, markaların dijitalde büyümesi için stratejik çözümler sunarak ve veri analitiğini kullanarak kampanyaları optimize edip markaların daha geniş kitlelere ulaşmalarını sağlamak amaçlı dijital trendleri yakından takip ediyor. Markaların hedeflerine ulaşmalarına tüm ekibiyle birlikte yardımcı olmak en önemli hedefi.

Satış Temsilcilerimizle İletişime Geç

0850 304 37 10