Google Analytics 4 Rehberi: Kurulum, Raporlar ve Analiz (2026)

Google Analytics 4 (GA4), web siteleri ve mobil uygulamalardaki kullanıcı etkileşimlerini olaylar üzerinden ölçen Google analiz platformudur. Hangi kanalların ziyaretçi getirdiğini, ziyaretçilerin içerikle nasıl etkileştiğini ve hangi adımlarda form ya da satın alma işlemini tamamladığını anlamak için kullanılır. Standart sürümü ücretsizdir; doğru sonuç almak ise etiketi eklemekten fazlasını gerektirir.

Bu rehberde önce kurulumu ve veri doğrulamasını, ardından başarılı bir form gönderimini ölçmeyi ele alacağız. Sonra raporları iş kararlarına bağlayacak; huni, kohort, izin yönetimi ve BigQuery gibi ileri konulara geçeceğiz. Sayısal örnekler temsilidir; bir müşteri hesabının performansını temsil etmez.

Teknik kontrol: 21 Eylül 2026. Google arayüzündeki menü adları, mülkün rapor koleksiyonuna, dile ve kademeli ürün güncellemelerine göre değişebilir. İlgili resmî belgeler bölüm içinde bağlantılıdır.

GA4 nedir, Universal Analytics'ten farkı ne?

GA4'te bir sayfanın açılması da ürünün sepete eklenmesi de birer olaydır. Olayın adı ne olduğunu; parametreleri ise nerede, hangi ürünle veya hangi formla gerçekleştiğini açıklar. Örneğin generate_lead başarılı bir potansiyel müşteri talebini, form_id=teklif_formu bunun hangi formdan geldiğini anlatabilir.

Universal Analytics'in standart mülkleri 1 Temmuz 2023'te yeni veri işlemeyi durdurdu; 360 mülklerinin geçişi 1 Temmuz 2024'e uzandı. Eski UA ekranlarına göre hazırlanmış hedef, görünüm ve rapor talimatlarını GA4'e birebir taşımayın. GA4 ayrı bir veri modelidir; UA geçmişi kendiliğinden GA4 raporlarına dönüşmez. Universal Analytics geçiş takvimi.

GA4 bir muhasebe sistemi veya bütün ziyaretçileri eksiksiz gören bir kayıt değildir. Kullanıcı izinleri, tarayıcı kısıtları, reklam engelleyiciler ve uygulama hataları ölçümü etkiler. Sipariş yönetimi sistemini finansal doğruluk için; Analytics'i kullanıcı davranışını ve pazarlama performansını anlamak için kullanın.

Hesap yapısı: hesap, mülk, veri akışı

Hesap sahiplik ve erişim çerçevesini, mülk analiz edilen işi, veri akışı ise web veya uygulama kaynağını temsil eder. Web akışının ölçüm kimliği G- ile başlar. Google Tag Manager kapsayıcı kimliği olan GTM- koduyla aynı şey değildir.

Aynı markanın sitesi ve uygulaması ortak analiz için aynı mülkte tutulabilir. Birbirinden bağımsız işletmeleri veya farklı veri erişimi gerektiren işleri ayırmak daha uygundur. Ajans yönetiminde hesabın işletmeye ait olması, ajansın gerekli rol ile davet edilmesi sahiplik sorunlarını azaltır. Canlı siteye yapılacak ölçüm denemeleri için ayrı test mülkü kullanmak raporları temiz tutar.

Mülkü açarken raporlama saat dilimini ve para birimini işinizle uyumlu seçin. Türkiye odaklı bir iş için İstanbul saat dilimi ve TRY genellikle mantıklıdır; çok ülkeli işletmede ise raporu kullanan ekibin ortak standardı belirleyici olabilir. Yetkileri göreve göre verin; yalnızca rapor okuyacak kişiye yönetim erişimi vermeyin. Hesap ve mülk oluşturma, erişim rolleri.

Google Analytics 4 nasıl kurulur?

Önce neyi ölçmek istediğinizi belirleyin

Bir hizmet sitesinde başarı, ziyaretçinin teklif talebi bırakması olabilir; e-ticarette sipariş tamamlaması; içerik sitesinde ise ilgili bir sonraki içeriğe veya aboneliğe geçmesi. Kurulumdan önce tek cümleyle ana hedefinizi yazın. Ardından hangi olayın bu hedefin gerçekten gerçekleştiğini kanıtladığını seçin.

Birincil uygulama yolunu seçin; aynı ölçümü birkaç kanaldan paralel göndermeyin. Otomatik entegrasyonun kapsamadığı özel etkileşimleri sonradan eklemek, her şeyi ikinci kez kurmaktan daha kontrollüdür.

GTM ile web kurulumu

1. Analytics'te hesap ve mülkü oluşturun; web veri akışına site adresini girin. G-XXXXXXXXXX biçimindeki ölçüm kimliğini alın.
2. Google Tag Manager web kapsayıcısını sitenin tüm ilgili sayfalarına, GTM'nin verdiği kurulum talimatıyla ekleyin. Önceden kurulu olup olmadığını kontrol edin.
3. Çerez yönetim platformunu (CMP) ve varsayılan izin durumunu ölçüm etiketlerinden önce çalışacak şekilde yapılandırın. Aşağıdaki basic/advanced ayrımını uygulayın.
4. GTM'de Google etiketi oluşturun, etiket kimliğine web akışının kimliğini girin. Google'ın başlangıç önerisi Initialization – All Pages tetikleyicisidir; onay başlangıcı bundan önce ele alınmalıdır.
5. Önizleme ile sayfanızı açın; doğru kapsayıcının, doğru ölçüm kimliğinin ve beklenen izin durumunun kullanıldığını denetleyin.
6. İlk sayfa yüklemesinin bir kez ölçüldüğünü doğrulayın. Doğrudan etiket, eklenti veya ikinci kapsayıcı aynı olayı gönderiyorsa mükerrer kaynağı bulun.
7. Testler tamamlanınca kapsayıcı sürümünü açıklayıcı bir adla yayınlayın. Sürüm notuna neyin değiştiğini ve hangi testlerin yapıldığını yazın.

Initialization tetikleyicisi, her tür uygulama kodunun kesinlikle ardından çalışacağı bir garanti değildir. Etiket sırası, izin başlangıcı ve uygulamanın veri hazırlama zamanı birlikte düşünülmelidir. Ayrıntılar için Google'ın GTM kurulum belgesini ve başlangıç kavramları için Google Tag Manager rehberini kullanabilirsiniz.

Shopify'da GA4 kurulumu

Shopify'ın önerdiği akış Google & YouTube kanalı üzerinden mevcut GA4 mülkünü bağlamak veya yeni mülk oluşturmaktır. Bu bağlantı belirli e-ticaret olaylarının otomatik ölçümünü sağlar. Yine de bağlantının kurulması, her mağazada bütün parametrelerin doğru olduğunun kanıtı değildir. Ürün görüntüleme, sepete ekleme, ödeme başlangıcı ve satın almayı test edin. Shopify'ın güncel GA4 kurulum adımları.

purchase olayında siparişe özgü transaction_id, doğru currency, sayısal value ve ürünleri taşıyan items alanlarını kontrol edin. Temada eski Analytics kodu veya ayrıca kurulmuş bir satın alma etiketi varsa iki kez gönderim olabilir. Shopify özel piksel ortamı kısıtlı bir çalışma alanıdır; normal sayfada çalışan her GTM/DOM yaklaşımını checkout'a aynen taşımayın.

Kurulumu nasıl doğrularsınız?

Üç ayrı kontrol yapın: GTM önizlemesi etiketin tetiklenmesini, tarayıcıdaki istekler verinin gönderimini, GA4 DebugView ise hata ayıklama modundaki olayların alınmasını gösterir. Birinin başarılı olması diğer ikisinin mutlaka doğru olduğu anlamına gelmez. Gerçek zamanlı rapor da son trafiğin genel kontrolü için yararlıdır; ayrıntılı parametre testi için DebugView daha uygundur.

Test cihazını seçin; page_view olayında sayfa adresini, özel olaylarda parametreleri açın. İzin reddedildiğinde hangi etiketlerin çalıştığını ayrıca test edin. DebugView'da görünmeyen bir olay için önce doğru mülkü, debug modunu, izin durumunu ve engelleyicileri kontrol edin. Standart raporların aynı anda güncellenmesini beklemeyin.

Tek sayfa uygulamasında (SPA) ilk açılışı ve sanal sayfa geçişini ayrı sınayın. Geliştirilmiş ölçümün tarayıcı geçmişi değişikliklerini takip etmesi ile uygulamanın manuel page_view göndermesi birlikte açıksa çift sayım oluşabilir. İlgili geçişin hangi yöntemle ölçüleceğini açıkça belirleyin.

Uygulama: başarılı teklif formunu GA4'te ölçmek

Örneğimiz bir hizmet sitesindeki teklif formu. Hedef, butona basılmasını değil, sunucunun kabul ettiği başarılı başvuruyu ölçmek. Boş form, doğrulama hatası veya sunucu hatası generate_lead üretmemeli. Bu ayrım özellikle AJAX ile gönderilen formlarda önemlidir.

1. Ölçüm planını yazın

2. Başarı yanıtından sonra veri katmanını besleyin

Aşağıdaki fonksiyon bir entegrasyon örneğidir; forma ait sunucu isteğinin yerine geçmez. Geliştirici, bunu yalnızca uygulamanın doğrulanmış başarı geri çağrısında çalıştırmalıdır. submissionToken, aynı yanıtın iki kez işlenmesini önlemek için uygulamanın ürettiği kişisel veri içermeyen geçici bir anahtardır; GA4'e gönderilmez.

const measuredSubmissions = new Set();

function recordLeadSuccess(submissionToken) {
  if (typeof submissionToken !== 'string' ||
      submissionToken.length === 0 ||
      measuredSubmissions.has(submissionToken)) {
    return false;
  }

  measuredSubmissions.add(submissionToken);
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({
    event: 'lead_form_success',
    form_id: 'teklif_formu'
  });
  return true;
}

// Yalnızca sunucunun kabul ettiği başvurunun başarı
// geri çağrısında: recordLeadSuccess(submissionToken);

Bu koruma sadece mevcut sayfanın belleğinde çalışır; sayfa yenilemesini veya farklı sekmeleri kapsayan kalıcı bir tekilleştirme sistemi değildir. Formun kendisi de yinelenen başvuruları sunucu tarafında yönetmelidir. Ölçüm kodunu genel buton tıklamasına veya her ziyaret edilebilen bir teşekkür sayfasına bağlamak, başarı sayısını şişirebilir.

3. GTM'den generate_lead gönderin

1. Veri Katmanı Değişkeni oluşturun. Veri katmanı anahtarı form_id, değişken adı örneğin DLV - form_id olsun.
2. Özel Etkinlik tetikleyicisi oluşturun. Olay adını tam olarak lead_form_success yazın. Gerekirse form kimliğiyle kapsamı daraltın.
3. Google Analytics: GA4 Etkinliği etiketi oluşturun. Ölçüm kimliğini ilgili web akışına bağlayın; olay adını generate_lead yapın.
4. Olay parametrelerine form_id ekleyip değerini {{DLV - form_id}} değişkeninden alın. Bir önceki adımın tetikleyicisini seçin.
5. Etiketin onay davranışını seçilen Consent Mode uygulamasıyla tutarlı tutun. Temel Google etiketinin doğru kimlikle yapılandırılmış olduğunu doğrulayın.

Olay adlarının ve parametrelerin yazımı tutarlı olmalıdır. generate_lead, Google'ın önerilen olaylarından biridir; rastgele bir olay adı yerine standart adı kullanmak raporların anlaşılmasını kolaylaştırır. GTM'de GA4 olay etiketi oluşturma, generate_lead olay referansı.

4. Başarılı ve başarısız senaryoları test edin

Sonra Analytics'te bu olayı temel etkinlik olarak seçin. Form bazlı kırılım için form_id parametresini olay kapsamlı özel boyut olarak kaydedin. Raporlama için işlenmesini bekleyin; DebugView'da parametrenin görünmesi, özel boyutun standart raporda hemen hazır olduğu anlamına gelmez.

5. Başvurunun değerini gelirle karıştırmayın

Temsili olarak bir müşterinin beklenen değeri 5.000 TL, başvuruların satışa dönüşme oranı %10 ise beklenen lead değeri 500 TL olur. İhtiyacınız varsa value: 500 ve currency: 'TRY' gönderebilirsiniz. Bu değer gerçek tahsilat değil, varsayımlarınıza bağlı bir beklentidir. Form örneğinde bu nedenle gelir alanlarını varsayılan olarak eklemedik.

generate_lead değerini satış geliri olarak raporlamayın. Satın alma gelirini e-ticaret olayları, iade ve ilgili gelir metrikleri üzerinden değerlendirin. Lead kalitesini anlamak için CRM'deki kabul edilmiş, nitelikli ve satışa dönüşmüş başvurularla ayrıca karşılaştırma yapın. GA4 gelir metriklerinin kapsamı.

Çerezler, Consent Mode ve gizlilik

GA4 web ölçümünde birinci taraf çerezleri kullanabilir; fakat “birinci taraf” olması tarayıcı sınırlamalarından etkilenmeyeceği anlamına gelmez. Saklama süresi ve kullanıcı sürekliliği tarayıcıya, izin durumuna ve uygulamaya bağlıdır. Bütün tarayıcılar için tek bir çerez ömrü varsaymayın. GA4 çerez kullanımı.

Basic ve advanced aynı kurulum değildir

Consent Mode, kullanıcı tercihlerine göre Google etiketlerinin davranışını değiştirir. analytics_storage analiz depolamasını; ad_storage reklam depolamasını; ad_user_data reklam amacıyla kullanıcı verisi gönderimini; ad_personalization kişiselleştirilmiş reklam kullanımını kontrol eder. CMP izin toplar, Consent Mode ise bu durumu etiketlere iletir. Consent Mode'un çalışma mantığı.

• Temel mod (basic): İlgili Google etiketleri kullanıcı izin verene kadar engellenir. İzin verilmezse bu etiketlerden veri gönderilmez.
• Gelişmiş mod (advanced): Etiketler uygun varsayılan izin durumu ile yüklenir; izin reddinde çerezsiz sinyaller gönderebilir, izin verilince davranışını günceller.

Gelişmiş mod amaçlanıyorsa GA4 etiketlerine ayrıca “analytics_storage mutlaka granted olmalı” şartı eklemek etiketi tamamen bloke edebilir. Google etiketlerinin yerleşik izin kontrolleriyle ek engelleme kurallarını karıştırmayın. CMP'nin varsayılan durumu etiketlerden önce ayarlaması ve kullanıcının sonraki seçimini doğru iletmesi gerekir. Engellenen etiketler ve onay ayarları.

Consent Mode kurulumu tek başına KVKK uyumu sağlamaz. Çerez amaçları, bilgilendirme, uygun hukuki dayanak, gerektiğinde açık rıza ve rızanın geri alınması ayrıca ele alınmalıdır. Hangi modun işletmeniz için uygun olduğuna yalnızca daha çok veri sağlayacağı için karar vermeyin. KVKK Çerez Uygulamaları Hakkında Rehber bu değerlendirme için temel kaynaktır; bu bölüm hukuki görüş yerine geçmez.

Modelleme her hesapta çalışır mı?

Hayır. Davranış modellemesi için gelişmiş kurulumun yanında trafik uygunluğu gerekir. Google'ın koşulları arasında en az 7 gün boyunca günlük 1.000 analytics_storage=denied olayı ve son 28 günün en az 7'sinde günlük 1.000 analytics_storage=granted kullanıcısı bulunur. İlk eşik olay, ikincisi kullanıcıdır. Bunları sağlamak uygunluğu garanti etmez. Modellenmiş veriyi doğrudan gözlenmiş kişi kaydı gibi yorumlamayın. Davranış modellemesi koşulları.

Alan adları arası ölçüm ve ödeme yönlendirmeleri

Bir kullanıcı size ait birden fazla alan adı arasında tek yolculuk izliyorsa alan adları arası ölçüm (cross-domain) gerekebilir. Örneğin ana site ile ayrı alan adındaki rezervasyon uygulaması. Aynı GA4 web akışının ilgili sayfalarda tutarlı kurulması, alan adı ayarları ve bağlantılarda kullanılan _gl parametresinin korunması birlikte kontrol edilmelidir. Cross-domain kurulumu.

Ödeme sağlayıcısından dönüş ise farklı bir sorundur. Sağlayıcı alan adını istenmeyen yönlendirmelere eklemek kaynak ilişkilendirmesini düzeltmeye yardımcı olabilir; ancak üçüncü taraf sitede ölçüm kurduğunuz veya kayıp bütün oturumları geri getirdiğiniz anlamına gelmez. Kontrolünüzdeki alan adları ile kontrolünüzde olmayan ödeme alan adlarını aynı yöntemle ele almayın. İstenmeyen yönlendirmeleri belirleme.

Testte ana siteden başlayın, diğer alana geçin ve geri dönün. Çerez/kimlik sürekliliğini, yönlendirmelerin parametreleri silip silmediğini ve ödeme sonrası olayları denetleyin. GA4'te kampanya veya yönlendirme değişmesi tek başına her zaman yeni oturum başlatmaz; kaynak, kimlik ve oturum süresi ayrı kontrollerdir.

GA4 metrikleri: kullanıcı, oturum ve etkileşim

GA4'te rapor başlığına bakmak yetmez; seçilen metriğin tam adını kontrol edin. Özellikle etkin kullanıcı ile toplam kullanıcı farklıdır. Oturum sayısı da benzersiz oturum kimliklerinin tahminine dayanır; session_start sayısıyla her koşulda aynı çıkması beklenmez. Kullanıcı metrikleri, oturumların hesaplanması.

Etkileşim ve hemen çıkma oranı

Etkileşimli oturum varsayılan olarak 10 saniyeden uzun sürer, bir temel etkinlik içerir veya en az iki sayfa/ekran görüntülemesine ulaşır. Web akışında süre eşiği ayarlanabilir. first_visit, first_open ve session_start gibi bazı olaylar temel etkinlik olsa da bu amaçla etkileşim sayılmaz. Hemen çıkma oranı, etkileşim oranının tersidir: etkileşim %65 ise hemen çıkma %35'tir. Resmî etkileşim tanımı.

Bir telefon numarasını bulup ayrılan kullanıcı işini tamamlamış olabilir. Bu yüzden yüksek hemen çıkma oranını otomatik olarak kötü içerik saymayın; sayfanın amacı ve ilgili iş olaylarıyla değerlendirin. Eski UA oranıyla doğrudan performans karşılaştırması da yapmayın. Kavramsal arka plan için hemen çıkma oranı rehberine bakabilirsiniz.

Ortalama etkileşim süresi, sayfanın tarayıcıda odakta veya uygulamanın ön planda olduğu süre üzerinden değerlendirilir; açık bırakılan bütün sekmelerdeki duvar saati süresi değildir. Rapordaki paydanın etkin kullanıcı mı, oturum mu olduğunu ayrıca okuyun. Kullanıcı etkileşimi ve süre.

Olay modeli ve özel boyutlar

Olayları dört grupta düşünün: otomatik toplananlar, geliştirilmiş ölçümle gelenler, Google'ın önerdiği standart olaylar ve size özel olaylar. Önce mevcut ölçümü kontrol edin; zaten gönderilen bir olayı yeniden üretmeyin. Örneğin geliştirilmiş ölçümdeki scroll olayı bütün kaydırma yüzdelerinin kaydı değildir; sayfanın yaklaşık %90 derinliğine ilk ulaşımı ölçer. Geliştirilmiş ölçüm olayları.

İsimlendirmede küçük harf ve alt çizgi gibi ortak bir standart seçin. Olay adları büyük/küçük harfe duyarlıdır, harfle başlamalıdır; ayrılmış isimleri kullanmayın. Hata sayfası için page_not_found kullanılabilir, 404_hata kullanılamaz. Hata olayı kendiliğinden oluşmaz; gerçek 404 durumuna göre ayrıca uygulanmalıdır. Olay adı kuralları.

Parametre göndermek ile rapor boyutu oluşturmak farklıdır

form_id gibi bir parametre DebugView'da görünebilir. Bunu normal raporlarda boyut olarak kullanmak için Yönetici → Özel tanımlar bölümünde uygun kapsamla kaydetmeniz gerekir. Olay kapsamı gerçekleşen etkileşimi, kullanıcı kapsamı kullanıcı özelliğini, öğe kapsamı ise ürün/öğe bilgisini temsil eder. Olay kapsamlı özel boyut oluşturma.

Yeni özel boyutun kullanılabilir olması genellikle 24–48 saat sürebilir. Daha önce gönderilmiş parametrelerin özel boyut raporlarını geriye dönük otomatik dolduracağını varsaymayın. Her yeni fikir için özel boyut açmak yerine “Bu alanla hangi kararı vereceğiz?” sorusunu sorun. Serbest metin mesajları veya benzersiz başvuru kimlikleri iyi rapor boyutları değildir; hem gizlilik hem yüksek kardinalite riski taşırlar.

Sayfa URL'sinin sorgu kısmına e-posta veya telefon yazan formları da denetleyin. Hassas bilgi yalnızca olay parametrelerinden değil, otomatik toplanan adres ve başlıklardan da sızabilir. user_id kullanılıyorsa doğrudan kimliği açığa çıkarmayan bir değer olmalı; e-posta adresi gibi bilgiler kullanılmamalıdır. Kişisel bilgi göndermeyi önleme.

Temel etkinlikler ile Google Ads dönüşümleri

Bir olayın işiniz için önemli olduğunu GA4'te temel etkinlik olarak işaretlersiniz. Reklam ölçümü ve teklif optimizasyonu için Google Ads'te dönüşüm işlemi kullanılır. Her GA4 temel etkinliği otomatik olarak Ads'te teklif verilen bir dönüşüm değildir. İki taraftaki tanım, sayım ve kullanım amacını bilinçli eşleştirin. Olay, temel etkinlik ve dönüşüm ayrımı.

Bir hizmet sitesi için nitelikli başvuru, randevu tamamlanması veya teklif isteği öncelikli olabilir. Her kaydırmayı, video başlangıcını ve menü tıklamasını temel etkinlik yapmak başarı sinyalini bulanıklaştırır. Bunları davranış ölçümü olarak tutup ana iş sonucunu ayrı izlemek genellikle daha anlaşılırdır.

Sayım yöntemini de hedefe göre seçin: aynı oturumdaki iki başarılı formun bir mi iki mi sayılmasını istediğinizi tanımlayın. Bu karar ile “en az bir başvuru içeren oturum oranı” farklı konulardır. Ads'te hem yerel satın alma dönüşümü hem GA4'ten aktarılan aynı satın alma birincil hedef olarak kullanılıyorsa mükerrer optimizasyon riskini kontrol edin.

GA4 ile Ads neden aynı sayıyı göstermeyebilir?

Önce aynı dönüşüm işlemini ve kapsamı karşılaştırdığınızdan emin olun. Saat dilimi, etkileşim tarihi ile dönüşüm tarihi, sayım yöntemi, dönüşüm penceresi, ilişkilendirme modeli ve uygun kanallar fark yaratabilir. Google Ads her durumda son tıklama modeli kullanmaz; veriye dayalı ilişkilendirme çoğu dönüşüm işlemi için varsayılandır. Ads ilişkilendirme modelleri, dönüşüm verisinin raporlanması.

“Fark şu yüzdeye inerse doğrudur” gibi evrensel bir eşik yoktur. Aynı hedefi, aynı tarih mantığını ve aynı sayımı eşleştirdikten sonra kalan farkı izinler, işlem gecikmesi ve modelleme yönünden inceleyin. Reklam stratejisi bağlamı için Google Ads teklif stratejileri yazısından yararlanabilirsiniz.

UTM parametreleri ve kanal gruplama

Kaynak, trafiğin geldiği yeri; araç (medium), türünü; kampanya ise pazarlama çalışmasını tanımlar. Google dışındaki kampanyalarda ortak bir UTM sözlüğü kullanın. Örneğin aynı kampanyayı bir yerde eylul_teklif, başka yerde EylulTeklif yazmak analizi parçalar.

https://example.com/teklif?utm_source=instagram&utm_medium=paid_social&utm_campaign=eylul_teklif&utm_id=cmp_2026_09&utm_content=video_a

Bu temsili adres dış kampanya içindir. Site içindeki blog → hizmet sayfası bağlantısına UTM eklemeyin; iç promosyonları uygun olay ve parametrelerle ölçün. URL oluşturmak için UTM bağlantı oluşturucuyu kullanabilirsiniz. Kaynak ve araç değerlerini ekipçe standardize edin; maliyet içe aktarımındaki eşleşme de buna dayanır.

Varsayılan kanal grubu kaynak, araç ve başka sinyalleri Google'ın kurallarıyla sınıflandırır. Organic Search, Paid Search, Organic Social, Paid Social, Email ve Direct gibi gruplara ek olarak güncel tanımlarda AI Assistant da bulunur. Bu, bütün yapay zekâ kaynaklı ziyaretlerin eksiksiz tanındığı anlamına gelmez; yönlendirme bilgisi kaybolabilir. Varsayılan kanal tanımları.

Unassigned büyürse yalnızca UTM yazımını suçlamayın. Kaynak/araç değerlerini, olayların oturum bilgilerini ve kanal kuralına uyumu inceleyin. Direct de yalnızca adresi elle yazanlardan oluşmaz; tanınabilir kaynak bilgisi olmayan ziyaretler dahil olabilir.

İşinize özel ayrımlar için özel kanal grubu oluşturabilirsiniz. Standart mülkte iki özel kanal grubu hakkı vardır. Kuralların sırası önemlidir; geniş bir kural dar bir grubu yutabilir. Organik aramayı kampanya adına bakarak markalı/markasız ayırmayın; bu soru için Search Console sorguları daha uygundur. Özel kanal grupları.

GA4 raporları nasıl okunur?

Rapor açmadan önce iş sorusunu yazın. “Trafik nasıl?” yerine “Son dört haftada teklif başvurusu getiren oturumların kaynak dağılımı nasıl değişti?” sorusu, boyutu ve metriği seçmeyi kolaylaştırır. Menüde hazır rapor görünmüyorsa mülkün rapor koleksiyonunu ve erişim yetkinizi kontrol edin.

Bir kişi ilk kez Google organik aramadan, ertesi gün e-postadan gelirse ilk kullanıcı kaynağı ile ikinci oturumun kaynağı aynı olmaz. Kullanıcı, oturum ve olay kapsamlı kaynak boyutlarını aynı soruya cevap veriyormuş gibi karıştırmayın. Trafik kaynağı boyutlarının kapsamları.

Temsili analiz: fazla trafik mi, daha iyi başvuru mu?

Teklif formu örneğinde aşağıdaki verileri gördüğümüzü varsayalım. “Başvurulu oturum”, en az bir başarılı generate_lead içeren oturumdur; toplam form olayı değildir.

İlk gözlem organiğin daha yüksek oranla başvuru ürettiğidir. Buradan “sosyal reklamı kapatalım” sonucu çıkmaz. Önce aynı tarih aralığını, landing page'leri, cihaz dağılımını, ölçüm kapsamını ve CRM'deki başvuru kalitesini karşılaştırın. Reklamın maliyeti ve satışa dönüşen başvurular bilinmeden kârlılık kararı verilemez.

İkinci adımda ücretli sosyal trafiğin çoğunun mobilde olduğunu ve kaybın form alanında toplandığını görürseniz, mobil formun hata mesajlarını ve yüklenmesini test etmek somut bir hipotezdir. Değişiklikten sonra aynı başarı tanımıyla karşılaştırın; trafik karması değişmişken yalnızca önce/sonra yüzdesine bakarak nedensellik iddia etmeyin.

Huni keşfi: kullanıcılar hangi adımda ayrılıyor?

Huni keşfi, belirlediğiniz adımlardan geçen kullanıcıları analiz eder. E-ticaret örneği: view_item → add_to_cart → begin_checkout → purchase. Hizmet sitesi örneği: ilgili hizmet sayfası → form başlangıcı → başarılı başvuru. Önce her adımın gerçekten ve tutarlı ölçüldüğünü doğrulayın.

1. Keşfet içinde Huni keşfi açın; tarih aralığını seçin.
2. Adımları olay adı ve gerekirse sayfa/form parametresiyle tanımlayın.
3. Açık veya kapalı huniyi araştırma sorusuna göre seçin: kapalı hunide başlangıç adımı gerekir; açık hunide sonraki adımlardan giriş mümkündür.
4. Doğrudan ya da dolaylı takip koşulunu ve gerekiyorsa adımlar arası süreyi belirleyin.
5. Cihaz kategorisi gibi anlamlı bir kırılım ekleyin; örneklem büyüklüğünü ve veri kalite göstergesini okuyun.

Aynı olay listesini kullanmak aynı huniyi oluşturmaz; açık/kapalı seçimi, adım sırası ve zaman koşulu sonucu değiştirir. “Satın alma her zaman kapalı huni olmalı” gibi bir kural yoktur. Huni keşfi ayarları.

Sepetten ödemeye kayıp varsa kargo ücretleri, toplam bedel veya hesap zorunluluğu araştırılabilir. Ancak önce olayın ilgili sayfalarda eksik kalıp kalmadığını test edin. Ölçüm hatasını kullanıcı deneyimi sorunu sanmayın. Davranışsal bağlam için sepet terk etme oranı yazısına bakabilirsiniz.

Kohort analizi: aynı dönemde gelenler geri dönüyor mu?

Kohort, ortak bir koşulu paylaşan kullanıcı grubudur. Örneğin aynı hafta ilk kez gelenler. Keşfet'teki kohort analiziyle bu grubun sonraki dönemlerde geri dönmesini veya belirli bir olayı yapmasını inceleyebilirsiniz. Önce gruba giriş koşulunu, geri dönüş koşulunu ve gün/hafta/ay ayrıntısını seçin. Google'ın keşif ve kohort uygulama örnekleri.

Bir eğitim içeriği sitesi için “ilk ziyaret haftasından sonra tekrar içerik okuma”, bir mağaza için “ilk alışverişten sonra yeniden satın alma” farklı sorulardır. Kullanıcı sayısını gösteren tabloyla yüzdeyi, dönemsel değerle kümülatif değeri birbirine karıştırmayın.

Temsili örnekte bir haftada edinilen 200 kullanıcının 40'ı sonraki hafta dönmüşse ilgili geri dönüş oranı %20'dir. Ancak henüz ikinci haftasını tamamlamamış yeni kohortu, aylar önceki kohortla aynı sütunda kıyaslamak yanıltır. Tamamlanmış dönemleri karşılaştırın; kampanya, sezon ve kullanıcı kalitesi gibi etkenleri not edin. Düşüşün mutlaka düzenli veya her gösterimde monoton olmasını beklemeyin.

Regex: birden çok değeri tek kuralla seçmek

Düzenli ifadeler, benzer sayfa yollarını veya kaynakları filtrelemek için kullanılabilir. GA4'ün regex desteği RE2 tabanlıdır; kullandığınız alandaki tam eşleşme/kısmi eşleşme davranışını kontrol edin. Başka bir regex motorunda çalışan her ifade GA4'te çalışmayabilir. Google Analytics regex kuralları.

Deseni önce eşleşmesini istediğiniz iki değerle, ardından eşleşmemesi gereken bir değerle sınayın. Sayfa yolu bekleyen ifadeye protokol ve alan adı içeren tam URL verirseniz sonuç alamayabilirsiniz. Nokta karakterini gerçek nokta için \. olarak kaçırın; büyük/küçük harf davranışını da gözden geçirin.

Hesaplanan metrikler: doğru pay ve paydayı seçmek

Hesaplanan metrikler mevcut standart veya özel metrikleri bir formülde birleştirir. Yönetici → Özel tanımlar → Hesaplanan metrikler alanında oluşturulur. Formüldeki metrikleri arayüzün öneri listesinden seçin; dil ve kullanılabilirlik nedeniyle adları tahmin ederek yazmayın. Standart mülkte beş hesaplanan metrik oluşturulabilir. Hesaplanan metrikler.

Örneğin kargo tutarının satın alma gelirine oranı için İngilizce metrik adlarıyla {Shipping amount} / {Purchase revenue} kullanılabilir. Yüzde olarak göstermek istiyorsanız birim ve çarpanı tutarlı seçin; sıfır paydalı dönemleri kontrol edin. Bu oranı kâr marjı diye adlandırmayın; ürün maliyeti veya diğer giderleri içermez.

{generate_lead} yazmak olay adını kendiliğinden metrik yapmaz. Olay bazlı adet için olay filtresiyle rapor kurun; oturum bazlı başarı oranı için ilgili temel etkinliğin oturum oranını kullanın. Tek oturumda iki form gönderimi olabileceği için form olayları / oturumlar ile başvurulu oturumlar / oturumlar aynı metrik değildir.

Özel içgörüler ve veri takibi

Özel içgörüler, belirlediğiniz değişimleri izlemek için kullanılabilir. Günlük kullanıcı, temel etkinlik veya gelirde beklenmeyen değişimlere bakabilirsiniz. İzlenecek alanı, kontrol sıklığını ve koşulu iş hacmine göre seçin; bildirimin kime gideceğini belirleyin. Analytics içgörüleri.

Yeni bir sitede bir başvurunun eksilmesi büyük yüzde değişimi yaratabilir. Bu nedenle her hesap için sabit bir “%40 düşüş” kuralı kullanmayın. Haftanın günü, kampanya takvimi ve normal hacmi dikkate alın. Özel bir page_not_found olayı uygulanmışsa hata sayfalarındaki artışı olay filtresiyle değerlendirebilirsiniz; uygulanmamış olay için uyarı beklemeyin.

Bir uyarı geldiğinde sıralama şu olsun: önce etiket/izin/entegrasyon değişikliği, sonra site veya ödeme hatası, ardından trafik ve kampanya değişimi. GA4 içgörüleri kesintisiz erişilebilirlik izlemesinin yerine geçmez; kritik form ve checkout akışları ayrıca teknik olarak izlenmelidir.

Kampanya maliyetlerini GA4'e aktarma

Google dışındaki kampanyaların maliyet, tıklama ve gösterim verilerini Campaign data import ile birleştirebilirsiniz. CSV, Google Sheets, BigQuery ve SFTP gibi kaynaklar desteklenir. Kaynak, araç ve tarih eşleşmesi önemlidir; kampanya kimliği ve adı da önerilir. Tarih YYYY-MM-DD, maliyet varsa para birimi ISO kodu, örneğin TRY, olmalıdır. Para birimi eşlemede sabit değer olarak da tanımlanabilir. Kampanya içe aktarma şeması.

Aşağıdaki satır temsili bir dosyadır; başlıkları kendi içe aktarma kaynağınızın alan eşlemesiyle ilişkilendirin:

utm_source,utm_medium,utm_campaign,utm_id,date,currency,cost,clicks,impressions
instagram,paid_social,eylul_teklif,cmp_2026_09,2026-09-01,TRY,1500.00,300,24000

Önce küçük bir tarih aralığı aktarın. Yükleme başarısıyla eşleşme oranını ayrı kontrol edin; dosyanın kabul edilmesi maliyetin doğru kampanyaya bağlandığı anlamına gelmez. Aynı maliyeti birden fazla bağlantıyla tekrar içe aktarmayın. Sonuçlar Google dışı kampanya raporunda ve Reklam çalışma alanındaki kanal karşılaştırmalarında değerlendirilebilir.

SFTP seçeneği Analytics'in size bir dosya sunucusu vermesi değildir; erişebildiğiniz mevcut kaynağın bağlantı bilgileri ve dosya yolu kullanılır. Kaynağın güncellenme sıklığını ve erişim sahibini belgelendirin. İçe aktarma kaynak bağlantıları.

Google Ads, Search Console, Data Studio ve BigQuery

Reklam ve arama performansı bağlantıları

Google Ads bağlantısı reklam verisini Analytics analiziyle ilişkilendirmek ve uygun dönüşüm/kitle akışları için kullanılır. Doğru Ads hesabını bağlayın; otomatik etiketleme, dönüşüm seçimi ve izin ayarlarını ayrıca kontrol edin. Bağlantı tek başına kampanyaları doğru optimize ettiğiniz anlamına gelmez. Google Ads bağlantısı.

Search Console bağlantısı organik sorgular ve açılış sayfaları üzerinden arama görünürlüğünü anlamayı kolaylaştırır. Tıklama ile GA4 oturumu farklı tanımlardır; birebir eşitlenmeleri beklenmez. Markalı/markasız sorgu analizinde uygun yer burasıdır. Search Console entegrasyonu.

Data Studio (önceki adıyla Looker Studio), ekip için ortak rapor düzeni kurmakta kullanılabilir. Ürünün adı Nisan 2026'da yeniden Data Studio oldu. Fakat bir rapor aracı, kaynağı yanlış ölçülmüş veriyi doğru hale getirmez. Her kartın tarihini, filtresini, kapsamını ve yenilenme davranışını açık tutun; veriyi hangi anahtarlarla birleştirdiğinizi belgeleyin. Güncel ürün adı, GA4 bağlantısı.

BigQuery ne zaman gerekli?

BigQuery olay düzeyinde sorgular, CRM/sipariş verisiyle kontrollü birleştirme ve size ait veri saklama politikası için uygundur. Küçük bir sitenin başlangıç raporlarını okuyabilmek için zorunlu değildir. Standart GA4 mülkleri bağlantı kurabilir; BigQuery depolama, sorgu ve özellikle akış aktarımı maliyetlerini ayrıca değerlendirin. Sandbox ile faturalandırmasız deneme mümkündür, ancak sınırları vardır. BigQuery bağlantısı kurma, dışa aktarım seçenekleri.

Kurarken proje erişimini, veri konumunu, aktarılacak akışları ve günlük/akış ihtiyacını belirleyin. Günlük analiz yapan bir iş için otomatik olarak streaming açmayın. Bütçe uyarısı ve tablo saklama politikası oluşturun. Bağlantının standart olarak geçmişin tamamını geriye dönük dolduracağını varsaymayın; erken kurulum ileriye dönük veri birikimini sağlar.

Ham olay tablosuyla GA4 arayüzündeki her toplamın aynı çıkması beklenmez. Raporlama kimliği, modelleme, ilişkilendirme ve hesaplama yöntemi farklı olabilir. Önce sorgunun aynı tarih, saat dilimi ve kapsamı kullandığını kontrol edin; ardından rapor farklarını inceleyin. Analytics raporlama yüzeylerini karşılaştırma.

Veri kalitesi, saklama ve raporlama kimliği

Veri saklama ve filtreler

Standart GA4 mülklerinde kullanıcı ve olay düzeyindeki saklama seçenekleri 2 veya 14 aydır. Bu ayar özellikle keşiflerde kullanılan ayrıntılı veriyi etkiler; standart toplulaştırılmış raporların tamamının 14 ay sonra silindiği anlamına gelmez. Demografik veriler gibi istisnalar vardır. Analiz ihtiyacınıza ve veri minimizasyonu politikanıza uygun süreyi seçin. Veri saklamanın kapsamı.

İç trafik ve geliştirici trafiği filtrelerini etkinleştirmeden önce test edin. Aktif dışlama, gelecekte gelen veriyi kalıcı olarak rapor dışında bırakabilir; bir rapor filtresini kaldırmak gibi geri alınabilecek bir işlem değildir. Ofis IP'si, uzaktan çalışanlar ve dinamik bağlantıların kapsamını düşünün. Veri filtreleri.

Raporlama kimliği ve 2026 Signals değişikliği

GA4'ün karma (blended) kimliği sırasıyla User-ID, cihaz kimliği ve modellemeyi kullanabilir. Gözlemlenen (observed) kimlik modellemeyi içermez; cihaz tabanlı yaklaşım cihaz kimliğine dayanır. Google Signals'ı bu sıralamaya eklemeyin. User-ID için kullanıcı giriş sisteminizle doğru entegrasyon gerekir; ayarı seçmek tek başına kişiler arası cihaz eşleştirmesi sağlamaz. Raporlama kimliği.

Google'ın 2026 duyurusuna göre 15 Haziran'dan itibaren Signals ayarı, Analytics kaynaklı verinin oturum açmış kullanıcı bilgileriyle davranışsal raporlama için ilişkilendirilmesini kontrol eder; Google Ads çerez ve kimlik kontrolleri Consent Mode tarafında ele alınır. Aynı duyurudaki reklam kişiselleştirme ve IP kontrollerinin sonraki değişiklikleri için kesin takvim ayrıca açıklanacaktır. Bütün planlanan değişiklikleri tamamlanmış saymayın. Google Analytics Data Controls güncellemesi.

Eşikleme, örnekleme, (other) ve (not set)

• Eşikleme: Bazı düşük hacimli kırılımlarda gizlilik gerekçesiyle veri gösterilmeyebilir.
• Örnekleme: Özellikle geniş keşif sorgularında verinin bir alt kümesi kullanılabilir. Veri kalitesi simgesini okuyun.
• (other): Boyut kombinasyonlarının tablo kapasitesini zorladığı durumlarda satırlar birleştirilebilir. Günlük 500 farklı değer kesin kesilme sınırı değildir; yüksek kardinalite göstergesidir.
• (not set): İlgili boyut için bilgi bulunmadığını gösterebilir. Hangi boyutta oluştuğuna göre oturum bilgisi, etiket ve parametreleri inceleyin.

Bu işaretlerin hepsi aynı problem değildir. Tarihi daraltmak, gereksiz yüksek kardinaliteli boyutu çıkarmak veya uygun başka bir rapora geçmek yardımcı olabilir; kalıcı çözüm için asıl nedeni bulun. (other) satırı, rapor ve keşif farkları.

GA4 kurulum ve bakım kontrol listesi

İlk yayın öncesinde ve önemli site/etiket değişikliklerinden sonra aşağıdaki listeyi uygulayın:

1. Hesap sahipliği işletmede, ekip erişimleri ihtiyaçla sınırlı.
2. Doğru mülk, saat dilimi, para birimi ve web akışı seçili.
3. Aynı olay tema, eklenti, kanal ve GTM tarafından mükerrer gönderilmiyor.
4. İzin varsayılanı etiketlerden önce uygulanıyor; kabul, ret ve tercih değişikliği test edilmiş.
5. İlk sayfa açılışı ve varsa SPA geçişi ayrı ayrı doğrulanmış.
6. Başarılı form ölçülüyor; hatalı form ve başarısız sunucu yanıtı başarı sayılmıyor.
7. Satın alma varsa transaction_id, currency, value ve items kontrol edilmiş; yinelenen işlem denetlenmiş.
8. URL'lerde ve parametrelerde isim, e-posta, telefon veya serbest metin yok.
9. Özel boyutlar doğru kapsamla kayıtlı; rapor işleme süresi dikkate alınmış.
10. Temel etkinlik ve Ads birincil dönüşüm seçimi iş hedefiyle uyumlu.
11. Dış kampanya UTM'leri tutarlı; iç bağlantılar UTM ile etiketlenmiyor.
12. Gerekli cross-domain ve istenmeyen yönlendirme ayarları gerçek yolculukla test edilmiş.
13. Veri saklama ve filtreler bilinçli seçilmiş; kalıcı filtre önce test edilmiş.
14. Başvuru/sipariş toplamları kaynak sistemle düzenli karşılaştırılıyor; farklar açıklanıyor.
15. BigQuery kullanılıyorsa bütçe, veri erişimi ve saklama politikası tanımlı.
16. Ölçüm planı, değişiklik tarihi ve test sonucu ekipçe erişilebilir bir yerde tutuluyor.

Haftalık kontrolde kanal → açılış sayfası → temel etkinlik ilişkisine; aylık kontrolde CRM/sipariş kalitesine ve maliyetlere bakın. Amaç daha çok grafik üretmek değil, ölçüm hatasını gerçek performans değişiminden ayırıp uygulanabilir bir karar vermektir.

Google Analytics 4 hakkında sık sorulan sorular

Google Analytics 4 ücretsiz mi?

Standart GA4 ücretsizdir. Analytics 360 ücretli kurumsal sürümdür. Kurulum hizmeti, üçüncü taraf bağlantılar veya BigQuery'nin ücretli kullanımı ayrıca maliyet doğurabilir.

GA4 kurmak için kod bilmek gerekiyor mu?

Temel kurulum birçok platformun entegrasyonuyla yapılabilir. Başarılı AJAX formunu, özel uygulama durumlarını veya karmaşık checkout akışlarını doğru ölçmek için geliştirici desteği gerekebilir. GTM kullanmak, test ihtiyacını ortadan kaldırmaz.

GA4 veri toplamıyorsa ilk neye bakmalıyım?

Doğru mülk ve ölçüm kimliğini, etiketin yayınlanmasını, izin durumunu ve tarayıcı engelleyicilerini kontrol edin. Ardından önizleme ve DebugView ile olay/parametre akışını sınayın. Standart rapor gecikmesini veri gönderilememesiyle karıştırmayın.

GA4 kurulumdan önceki ziyaretleri gösterir mi?

Kurulmadan önce ölçülmemiş ziyaretleri geriye dönük oluşturmaz. UA geçmişi de otomatik olarak GA4 geçmişine çevrilmez. Eski sistemden alınmış arşiv varsa ayrı veri kaynağı olarak değerlendirilir.

Google Analytics ile Google Tag Manager aynı mı?

Hayır. Analytics veriyi analiz ettiğiniz platformdur. GTM, Analytics dahil ölçüm etiketlerini yönetmek ve belirli koşullarda çalıştırmak için kullanılır. GA4, GTM olmadan da kurulabilir.

Form tıklamasını dönüşüm saysam yeterli mi?

Tıklama niyeti gösterir, başarılı başvuruyu kanıtlamaz. Gerçek hedef başvuruysa sunucunun kabul ettiği başarı durumunu ölçün. Buton tıklamasını ayrı davranış olayı olarak tutabilirsiniz.

Shopify satışlarıyla GA4 satışları neden farklı?

İzinler, engelleyiciler, eksik veya çift satın alma olayları, saat dilimi, iade ve gelir tanımı fark yaratabilir. Önce aynı tarih ve gelir kapsamını karşılaştırın; ardından örnek siparişleri işlem kimliği üzerinden inceleyin. Finansal kayıt için sipariş sistemi esas alınmalıdır.

Google Signals'ı açmak her kullanıcıyı birleştirir mi?

Hayır. Raporlama kimliği, User-ID uygulaması, cihaz kimlikleri, izinler ve modelleme uygunluğu ayrı konulardır. Signals'ı eksik veriyi tamamen geri getiren bir anahtar gibi düşünmeyin.

Başlangıçta hangi üç rapora bakmalıyım?

Trafik edinme, açılış sayfası ve iş hedefinize ait temel etkinlik raporuyla başlayın. E-ticarette ürün ve satın alma raporlarını ekleyin. Önce az sayıda güvenilir metriği düzenli okuyun, sonra daha ileri keşiflere geçin.

Sonuç: İyi bir GA4 kurulumu, etiketin çalışmasından ibaret değildir. İş hedefinin doğru olayla tanımlanması, izinlere uygun veri gönderimi, hatalı ve başarılı senaryoların test edilmesi ve raporların doğru kapsamla okunması gerekir. Önce güvenilir ölçüm, ardından analiz ve optimizasyon gelir.