GA4’te (not set) landing page oranı neden artıyor ve nasıl düzeltilir?

GA4’te (not set) landing page oranı, içinde geçerli bir page_view olayı olmayan ya da ilk olayında page_location taşımayan session sayısı arttığı için büyür. Bunun en yaygın kaynakları zaman aşımından sonra page_view dışı bir olayla açılan session’lar, consent onayından önce kaçırılan page_view’lar, Measurement Protocol ve server-side tagging tarafında kimliği eksik gönderilen olaylar ve SPA’larda yanlış bağlanmış history change dinleyicileridir. Çözüm raporda filtre uygulamak değil, session’ı hangi olayın başlattığını bulup o olayın toplanma şeklini düzeltmektir.

Landing page boyutu aslında neye bakıyor

Universal Analytics’ten gelen ekiplerin çoğu landing page değerini session’ın ilk isabetinden okunan sabit bir alan gibi düşünür. GA4’te durum biraz farklı. Landing page, session içindeki ilk sayfa görüntüleme olayının page_location ve page_title bilgisinden türetilir. Session’ın başladığını GA4’e söyleyen şey ise otomatik toplanan session_start olayıdır ve bu olay kendi başına bir sayfa görüntülemesi değildir. Hangi olayların otomatik toplandığını ve hangi koşullarda tetiklendiğini Google’ın otomatik toplanan olaylar dokümanında görebilirsiniz.

Buradan çıkan pratik sonuç şu: bir session teknik olarak var olabilir, kullanıcıya atanabilir, hatta dönüşüm üretebilir, ama içinde tek bir page_view yoksa landing page boyutu doldurulacak bir değer bulamaz. GA4 bu durumda boş bırakmak yerine (not set) yazar. Yani (not set) bir hata mesajı değil, “bu session için sayfa bilgisi toplanmadı” demenin raporlama dilindeki karşılığıdır.

Bu ayrımı netleştirmek teşhisin yarısıdır. Oranın arttığını gördüğünüzde soru “GA4 neden landing page’i bilmiyor” değil, “hangi session’lar page_view olmadan açılıyor ve bunları hangi olay başlatıyor” olmalıdır.

(not set) oranını büyüten yaygın nedenler

Sahada karşılaştığımız vakaların neredeyse tamamı aşağıdaki başlıklardan birine giriyor. Çoğu projede tek bir neden değil, ikisi ya da üçü aynı anda çalışıyor, bu yüzden birini bulup durmamak gerekiyor.

Session zaman aşımı ve gece yarısı kesilmesi

GA4’te varsayılan session zaman aşımı 30 dakikadır. Kullanıcı sekmeyi açık bırakıp kahve almaya gidiyor, 40 dakika sonra dönüp sayfayı kaydırıyor. Bu noktada tetiklenen ilk olay bir scroll, user_engagement ya da sizin tanımladığınız bir zamanlayıcı olayı olabilir. GA4 yeni bir session açar, ama bu session’da sayfa yeniden yüklenmediği için page_view gönderilmez. Sonuç: landing page değeri olmayan yeni bir session.

Uzun okuma süresi olan içerik sitelerinde, açık bırakılan ürün sayfalarında ve arka planda periyodik olay gönderen video oynatıcılarında bu desen belirgin şekilde büyür. Zamanlayıcıyla tetiklenen “sayfada 60 saniye kaldı” tipi olaylar özellikle risklidir, çünkü kullanıcı hiçbir şey yapmasa bile yeni session açabilirler.

Gece yarısı konusu ise sık yanlış anlaşılır. GA4, UA’nın aksine session’ı gece yarısında ya da kampanya parametresi değiştiğinde sıfırlamaz. Ancak 23:50’de başlayıp 00:20’de biten bir session’ın olayları iki ayrı günün BigQuery tablosuna düşer. Yalnızca ikinci günün tablosunu sorgularsanız, o günün verisinde session_start ve ilk page_view görünmez ve kendi hesapladığınız landing page boş kalır. Arayüzde de yalnızca ikinci günü içeren dar tarih aralıklarında benzer bir etki görülebilir.

Consent Mode ve gecikmeli page_view

Türkiye’de KVKK sonrası consent banner kurulumları yaygınlaştıkça bu neden listenin başına oturdu. Tipik hatalı kurulum şöyle: GA4 page_view etiketi GTM’de yalnızca sayfa yüklenirken, analytics_storage onaylıysa tetiklenecek şekilde ayarlanmış. Kullanıcı banner’ı sayfa yüklendikten birkaç saniye sonra onaylıyor. Page_view tetikleyicisi zaten geçmiş olduğu için tekrar çalışmıyor, ama sonraki tıklama ve kaydırma olayları onaylı olarak gidiyor. GA4 açısından bu, page_view içermeyen bir session demektir.

Advanced Consent Mode kullanıyorsanız onay öncesi cookieless ping’ler de devreye girer ve modelleme açık olduğunda rapor tarafında davranış biraz daha karmaşık hale gelir. Kurulumun teorik çerçevesi için Google’ın Consent Mode geliştirici rehberi iyi bir başlangıçtır, ama pratikte yapmanız gereken şey basittir: onay güncellendiğinde, o sayfa için page_view’un onaylı durumda en az bir kez gittiğinden emin olmak.

Measurement Protocol ve server-side tagging

Measurement Protocol ile CRM’den, ödeme sağlayıcısından ya da backend’den olay gönderen ekiplerde (not set) oranı çoğu zaman sessizce büyür. Olayı gerçek tarayıcı session’ına ait client_id ve session_id olmadan, ya da süresi dolmuş bir session kimliğiyle gönderdiğinizde GA4 bu olayı sayfa bilgisi olmayan bir session’a bağlar. engagement_time_msec eksikse olay bazı raporlarda hiç görünmezken bazılarında session sayısını şişirebilir. Parametrelerin nasıl gönderilmesi gerektiği Measurement Protocol dokümantasyonunda açıkça tarif edilmiş durumda.

Server-side GTM geçişlerinde ise sorun genellikle dönüşüm katmanındadır. Bir e-ticaret projesinde, kişisel veri temizliği için yazılan bir transformation kuralının URL’deki sorgu parametrelerini temizlerken page_location alanını tamamen sildiğini gördük. Bir başka vakada sunucu konteynerindeki GA4 etiketinin tetikleyicisi yalnızca e-ticaret olaylarını kapsıyordu ve page_view hiçbir zaman GA4’e ulaşmıyordu. İki durumda da istemci tarafı Tag Assistant her şeyi doğru gösterirken rapordaki oran bir gecede katlanmıştı.

SPA’larda history change

React, Vue veya Next.js tabanlı sitelerde sayfa geçişleri tam yükleme olmadan gerçekleşir. Enhanced measurement içindeki tarayıcı geçmişi olaylarına dayalı sayfa değişikliği seçeneği ile GTM’de elle kurulmuş bir History Change tetikleyicisi aynı anda açıksa çift page_view görürsünüz. Tam tersi durumda, Google tag yapılandırmasında send_page_view kapatılmış ve rota dinleyicisi yalnızca sonraki geçişlere bağlanmışsa, ilk rota için hiç page_view gönderilmez. Tek sayfa görüp çıkan kullanıcılar bu durumda doğrudan (not set) landing page olarak raporlanır.

Nedenler, belirtiler ve düzeltmeler tek tabloda

Aşağıdaki tablo, ilk teşhis toplantısında hangi hipotezin öne alınacağını belirlemek için kullandığımız özet. Belirti sütunu, oranın artışıyla birlikte genellikle görülen yan işareti gösteriyor.

Neden	Tipik belirti	İlk kontrol	Düzeltme
Zaman aşımı sonrası olay	Uzun içerik sayfalarında ve masaüstünde yüksek oran	Session’ın ilk olayı scroll veya user_engagement mi	Zamanlayıcı olaylarını yeniden tasarlamak, gerekiyorsa session zaman aşımını uzatmak
Consent sonrası kaçan page_view	Banner değişikliğinden hemen sonra sıçrama	Onay anında page_view tekrar gidiyor mu	Consent update olayında onaylı page_view göndermek
Measurement Protocol	Kanal olarak Direct veya Unassigned ağırlığı	Session’da page_location hiç var mı	İstemciden client_id ve session_id taşımak
Server-side dönüşüm hatası	sGTM geçiş tarihiyle birebir çakışan artış	Sunucu önizlemesinde page_location değeri	Transformation ve tetikleyici kurallarını düzeltmek
SPA ilk rota eksikliği	Tek sayfalı session’larda yoğunlaşma	İlk yüklemede page_view sayısı	İlk rota için page_view’u açıkça tetiklemek
Gün sınırı etkisi	Yalnızca günlük BigQuery sorgularında görülen boşluk	Session’ın önceki gün tablosunda başlayıp başlamadığı	Sorgu penceresini bir gün geriye genişletmek

BigQuery ile teşhis

Arayüzde (not set) satırına tıklayıp detaya inmek çoğu zaman yeterli bilgi vermez, çünkü sorunlu session’ların ortak özelliği tam olarak eksik boyutlardır. BigQuery export’u açık bir property’de en hızlı yol, session’ları ilk olaylarına ve page_view içerip içermediklerine göre gruplamaktır.

Aşağıdaki sorgu bir aylık pencerede her session için ilk olayı, session_start ve page_view varlığını çıkarır. Aylık pencere seçmemizin nedeni gün sınırı etkisini minimize etmek.

WITH events AS (
  SELECT
    user_pseudo_id,
    (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id') AS session_id,
    event_name,
    event_timestamp
  FROM `project.analytics_123456789.events_*`
  WHERE _TABLE_SUFFIX BETWEEN '20260801' AND '20260831'
),
sessions AS (
  SELECT
    user_pseudo_id,
    session_id,
    ARRAY_AGG(event_name ORDER BY event_timestamp LIMIT 1)[OFFSET(0)] AS first_event,
    COUNTIF(event_name = 'session_start') > 0 AS has_session_start,
    COUNTIF(event_name = 'page_view') > 0 AS has_page_view
  FROM events
  WHERE session_id IS NOT NULL
  GROUP BY user_pseudo_id, session_id
)
SELECT
  first_event,
  has_session_start,
  has_page_view,
  COUNT(*) AS sessions,
  ROUND(100 * COUNT(*) / SUM(COUNT(*)) OVER (), 2) AS pct_of_sessions
FROM sessions
GROUP BY first_event, has_session_start, has_page_view
ORDER BY sessions DESC

Sonucu okurken has_page_view = false olan satırlara odaklanın. İlk olay scroll veya bir zamanlayıcı olayıysa zaman aşımı hipotezi güçlenir. İlk olay purchase veya backend’den gelen özel bir olaysa Measurement Protocol akla gelmelidir. has_session_start = false ve has_page_view = false birlikte görünüyorsa, büyük ihtimalle session’ın başlangıcı sorgu penceresinin dışında kalmıştır ya da olaylar geçerli bir session bağlamı olmadan gelmiştir.

Bir sonraki adım olarak aynı sorguya device.category, platform ve collected_traffic_source alanlarını eklemek genellikle nedeni tek bir cihaz tipine, uygulama sürümüne veya kanala indirger. Oranın belirli bir tarihte sıçradığı durumlarda sorguyu gün bazında kırıp deploy takvimiyle yan yana koymak da çoğu zaman tartışmayı birkaç dakikada bitirir.

Landing page (not set) bir raporlama sorunu değil, bir veri toplama sorunudur. Önce session’ı hangi olayın başlattığını bulun, filtreye ancak neden anlaşıldıktan sonra dokunun.

Düzeltme sırası

Nedenleri bulduktan sonra hepsine aynı anda saldırmak, hangi değişikliğin işe yaradığını ölçmeyi imkansız hale getirir. Pratikte işe yarayan sıralama şu şekilde:

1. Consent kurulumunu düzeltin. Etkisi en büyük ve en hızlı ölçülebilen değişiklik genellikle budur, çünkü her yeni ziyaretçinin ilk sayfasını etkiler.
2. SPA ilk rota davranışını doğrulayın. Tag Assistant ile sayfayı soğuk açıp ilk yüklemede tam olarak bir page_view gittiğini görün, sonra birkaç rota geçişinde sayının doğru arttığını kontrol edin.
3. Server-side konteynerde page_location alanının olay verisinde korunduğunu ve GA4 etiketinin page_view için de tetiklendiğini sunucu önizlemesinde teyit edin.
4. Measurement Protocol akışlarını gözden geçirin. Backend olaylarında istemciden taşınan client_id ve session_id yoksa bu olayların ayrı session üretmesini engelleyecek yapıyı kurun.
5. Zamanlayıcı ve arka plan olaylarını en son ele alın. Gerekirse bu olayları yalnızca kullanıcı etkileşimi sonrasında tetiklenecek şekilde değiştirin ya da property ayarlarından session zaman aşımını iş modelinize göre uzatın.

Her adımdan sonra en az bir hafta bekleyip BigQuery sorgusunu tekrar çalıştırmak, değişikliğin etkisini diğer nedenlerden ayırmanıza yardım eder. Haftalık sezonsallığı olan sitelerde karşılaştırmayı aynı haftanın günleriyle yapmak önemli.

Kabul edilebilir oran ve sürekli izleme

(not set) oranını sıfıra indirmek hem gerçekçi değil hem de gerekli değil. Zaman aşımı sonrası dönen kullanıcılar ve bazı bot trafiği her zaman küçük bir pay bırakacaktır. Önemli olan oranın stabil olması ve bir değişiklik olduğunda hızlıca fark edilmesidir. Bunun için izleme tarafında şu kontrolleri rutin hale getirmenizi öneririz:

• Landing page raporunda (not set) session payını haftalık olarak bir Looker Studio kartında ya da planlanmış bir BigQuery sorgusunda takip etmek.
• Consent banner, GTM konteyner yayını veya sGTM değişikliği sonrasında 48 saat içinde oranı ayrıca kontrol etmek.
• Page_view içermeyen session’ların ilk olay dağılımını aylık olarak gözden geçirip yeni bir olay adının listeye girip girmediğine bakmak.
• Measurement Protocol ile gönderilen olayları ayırt etmek için özel bir parametre ekleyip bu session’ları analizde ayrı segment olarak tutmak.
• Dönüşüm raporlarında (not set) landing page’e atanan gelir payını izlemek, çünkü attribution ve ROAS yorumlarını en çok bu satır bozar.
• SPA tarafında her frontend sürümünden sonra ilk yükleme page_view testini QA kontrol listesine eklemek.

Bu kontroller oturduğunda (not set) satırı bir sürpriz olmaktan çıkar ve kurulumunuzun sağlığını gösteren erken uyarı sinyaline dönüşür. Oranın bir anda yükseldiği gün, çoğu zaman o gün yayına alınan bir değişikliği işaret eder ve sorunu kaynağında yakalamak için size birkaç günlük değil birkaç saatlik bir pencere bırakır.