UTM’siz SEO Metriği: Chat Topluluğunda CTR & Dwell Time’ı Sunucu Loglarından Nasıl Eşleştirirsiniz?

Chat topluluğusunda ölçülebilir CTR ve dwell time için UTM yerine sunucu log metrikleri nasıl bağlanır sorusunun cevabı aslında tek bir “etiket” meselesi değil; doğru event taksonomisini kurmak ve bunu doğru sessionization mantığıyla birleştirmekle ilgili. UTM kullanmayınca attribution tarafında boşluklar ortaya çıkar; parametre karmaşası, eksik yönlendirme sinyalleri ve kullanıcıların farklı akışlarda dağılması raporları güvenilmez yapar.

Bu rehberde, chat topluluğunda ölçülebilir CTR ve dwell time için UTM yerine sunucu log metrikleri nasıl bağlanır vaadini, log tabanlı pratik bir modelleme yaklaşımına dönüştürüyoruz: log → sessionization → oda/landing event → SEO raporu. Böylece hem canlı (websocket/long-poll) akışlarda hem de klasik HTTP sayfa akışlarında CTR ve dwell time’ı daha tutarlı şekilde yakalayabilirsiniz.

Neden UTM şart değil? Problem tanımı (parametre karmaşası, attribution boşlukları)

UTM’ler çoğu zaman “hangi kampanya çalıştı?” sorusuna cevap vermek için kullanılır; ancak chat topluluğu gibi dinamik bir üründe kullanıcı yolculuğu çoğunlukla tek bir kampanyaya sıkışmaz. Bir kullanıcı arama sonucuna tıklar, oda girişini yapar, mesaj akışı içinde kalır, bağlantısı kopabilir; sonra geri döner. Bu süreçte kampanya parametreleri ya hiç taşınmaz ya da parçalı şekilde taşınır.

UTM kullanmadığınızda iki ana problem büyür. Birincisi “tıklama” sinyalini güvenilir biçimde nasıl bulacağınız (CTR). İkincisi de “kullanıcının içerikte ne kadar kaldığı”nı nasıl ölçeceğiniz (dwell time). Chat ürünlerinde bunun üstüne bir de websocket/live streaming gerçeği eklenir; HTTP istekleri sayfa görüntülemesiyle birebir eşleşmez.

Log tabanlı yaklaşım burada ayrışır: UTM taşımadan bile request/response, referer, path, status code ve sunucu zamanlaması gibi alanlar olayları bağlayacak bir “kanıt zinciri” sunar. Bu kanıt zincirini doğru bir ID sürekliliği ve sessionization ile örerseniz UTM’siz ölçüm yapılabilir.

Log tabanlı metrik modelleme: CTR/dwell time hangi log alanlarından türetilir?

Önce hedef metriklerin hangi ham sinyallerden türetileceğini netleştirin. CTR genellikle “SERP’den gelmiş mi ve ardından landing/oda erişimi gerçekleşti mi?” sorusudur. Dwell time ise “kullanıcı bir oda sayfasına/erişimini başlattıktan sonra etkileşim/aktif bağlantı ne kadar sürüyor?” sorusudur.

Loglardan türetirken odaklanmanız gereken şeyler şunlar: (1) landing/room join gibi erişim noktaları, (2) kullanıcıyı oturum içinde birleştiren kimlik/teknik ID, (3) referer ya da hedef URL’ye giden yolun göstergesi, (4) bağlantı ve son aktivite zamanları, (5) bot/yeniden deneme gibi gürültüyü azaltmak için kalite sinyalleri.

Aşağıdaki veri sözlüğü, bu yaklaşımı daha somut hale getirir. Bu alanlar doğru event tasarımının temelidir; eksik kalırsa CTR ve dwell time ya tahmine düşer ya da farklı raporlarda tutarsızlık üretir.

Uygulanacak veri sözlüğü: request_id, timestamp, user/session id (varsa), referer, path/room_id, status code, bytes, upstream timing

Loglarınızda bu alanları en azından “event üretimi” aşamasında kullanabiliyor olmalısınız. Aşağıdaki sözlük pratik bir başlangıç setidir; chat platformunuza göre genişletebilirsiniz.

Log alanı	Örnek	Kullanım amacı (CTR / dwell time)
request_id	req_9f3a2c…	Event korelasyonu, aynı kullanıcı akışında adımları birleştirme
timestamp (UTC)	2026-04-21T09:22:10Z	Sessionization, oda giriş/çıkış ve dwell time penceresi hesabı
user/session id (varsa)	uid_1234 / sid_9a7c	Oturum sürekliliği; cookie yoksa alternatif ID stratejileri
referer	https://www.google.com/search?q=…	SERP’den tıklama olasılığı; landing/room join event eşleştirme
path / room_id	/rooms/abc123	Oda bazlı segmentleme; dwell time’ı doğru oda üzerinde hesaplama
status code	200 / 304 / 302	Başarılı erişim mi var? CTR/landing için filtreleme
bytes	sent=… recv=…	ETL kontrolü; bağlantı kalitesi; “gerçek etkileşim” olasılığı
upstream timing	ttfb_ms, upstream_ms	Latency analizi; anomali tespiti; “dwell time düşer mi?” etkisini ayırt etme

CTR’yi loglardan türetme: ‘SERP’den tıklama’ sinyalini nasıl kurarsınız (referrer/landing page heuristikleri)

CTR’yi UTM’siz kurmak için, iki parçayı aynı çatı altında eşleştirmeniz gerekiyor: (1) SERP’den gelmiş olma ihtimali (impression/click mantığına yaklaşan bir sinyal), (2) kullanıcının gerçekten landing/oda erişimi yapması.

En pratik heuristik: referer tabanlı “SERP tıklaması” sinyali ve landing/room join event’i. Örneğin referer alanı google/bing gibi bir arama alanını içeriyorsa ve path bir landing ya da /rooms/{id} join endpoint’ine gidiyorsa bu bir “tıklama” adayıdır. Ardından status code ile başarılı join oldu mu diye doğrulama yaparsınız (ör. 200/204 gibi).

1. SERP referer sınıflandırması: referer URL içinde arama motoru domain/parametre kalıpları (ör. /search?q=, bing search vb.) varsa “SERP kaynaklı” etiketi üretin.
2. Landing/room erişim event’i: /rooms/{id}, /room/{id}, ya da oda join endpoint’inde başarılı status code (ör. 200) ile “tıklama sonrası erişim” event’i oluşturun.
3. Sessionization ile bağlama: aynı user/session id yoksa IP+User-Agent+yakın zaman penceresi ile bu iki event’i tek oturuma bağlayın.

Dwell time’ı loglardan türetme: oda giriş-çıkış, long-poll/websocket persistence, son aktivite pencere yaklaşımı

Dwell time, chat’te “sayfada kalma” gibi görünse de aslında “bağlantı/etkileşim sürmesi”dir. HTTP tabanlı sayfa akışında giriş/çıkış endpoint’leriyle hesap yapmak daha kolaydır. Ancak websocket veya long-poll kullanılıyorsa, “sayfa kapandı” sinyali her zaman net olmayabilir.

Bu yüzden iki katmanlı bir yaklaşım önerilir: (1) oda giriş-çıkış zamanlarını mümkünse gerçek giriş/çıkışla hesaplayın, (2) gerçek çıkış sinyali yoksa “son aktivite + X dakika” pencere yaklaşımı ile dwell time türetin. Son aktivite; websocket’te mesaj/ack/heartbeat, long-poll’de yanıtın geldiği zaman ya da belirli aralıklarla gelen “keepalive” event’leri üzerinden çıkarılabilir.

Örnek 2’de bu mantığı pencereli şekilde uyguluyoruz; ayrıca örnek 3’te room bazında segmentleme yapmanın neden kritik olduğunu daha net görürsünüz.

Chat özelinde ölçüm zorlukları: websocket/live akış, mesajlar arası sessizlik, otomatik yeniden bağlanmalar

Chat ürününde kullanıcı aynı anda hem “görüntülemede” hem de “beklemede” olabilir. Mesaj yokken dwell time yine de akmalıdır; çünkü kullanıcı oda içinde kalıyordur. Sadece mesaj sayısı baz almak dwell time’ı sistematik olarak düşük ölçer.

Websocket/long-poll tarafında bir başka tuzak otomatik yeniden bağlanmalardır. Client bağlantısı kısa süre kopabilir; aynı kullanıcı tekrar join edebilir. Dwell time hesabında bunları ayrı oturum gibi sayarsanız dwell time parçalanır; tek bir oda deneyimi gibi ele alırsanız daha doğru olur. Burada sessionization penceresi (örn. 60-180 saniye gap toleransı) belirleyicidir.

Bu nedenle dwell time türetirken “aktif bağlantı” eşiğini gerçek kullanıcı davranışına yakın olacak şekilde tanımlayın. Heartbeat/keepalive varlığı ve sunucu tarafında “room_user_presence” güncellemesi bu ayrımı kolaylaştırır.

Eşleştirme stratejileri: log → sessionization → page/room event → SEO raporu (örnek akış diyagramı)

Asıl değer, loglardan tek tek metrik çıkarmaktan değil; bu metrikleri SEO raporlamasına bağlamaktan gelir. Önerilen akış: her request/connection log’unu normalize edin, ardından sessionization yapın, sonra page/room event’lerine çevirin. Son adımda ise bu event’leri GSC (impression/click) mantığıyla hizalayarak CTR’yi doğrulayın.

Aşağıdaki örnek akış mantığını zihninizde canlandırın: “SERP referer gördüm” sinyali tek başına yeterli değildir; bunun bir “oda join” veya “oda landing” sonrası gerçekleştiğini kanıtlamalısınız. Benzer şekilde dwell time tek bir istekten hesaplanmaz; oda join anı + son aktivite + X dakika penceresi gerekir.

Örnek 1: /rooms/{id} landing + referer üzerinden session kurup CTR eşleştirme

Varsayalım loglarınızda şu iki event var: (a) kullanıcı /rooms/abc123 endpoint’ine geliyor, (b) referer alanında google.com/search mevcut. Bu durumda sessionization kurmak için aynı user/session id yoksa “yakın zaman + aynı IP + benzer UA” eşleşmesini devreye alın.

Uygulama fikri: referer “SERP kaynaklı” olarak işaretlenir, ardından aynı oturumun ilk oda giriş isteği (200 status code ile) “tıklama sonrası landing” event’i olarak kaydedilir. Bu landing’i bir “log türetilmiş click” sayın. Böylece CTR’yi (türetilmiş click / türetilmiş impression yaklaşımı) ya da en azından “türetilmiş click oranı” olarak raporlayabilirsiniz.

Örnek 2: websocket/long-poll için giriş-çıkış zamanlarından dwell time hesaplama penceresi (son aktivite + X dk)

Websocket senaryosunda client /ws/rooms/abc123 ile bağlantı kurar ve ardından mesajlar seyrek gelebilir. Dwell time’ı “bağlantı süresi” olarak alırsanız, bağlantı kopuşu anlaşılamadığı için ya şişer ya da kırpılır. Bunun yerine son aktivite temelli bir pencere kullanın.

Örneğin: oda join time’ı olarak “ilk websocket connected” zamanını kaydedin. Son aktivite için de sunucudan gelen herhangi bir kullanıcı kaynaklı event (mesaj gönderme, ack, heartbeat yanıtı) zamanını alın. Son aktivite üzerinden “son etkinlikten sonraki X dakika içinde yeni aktivite yoksa dwell time finalize” kuralını çalıştırın. X değerini cihaz/konfigürasyonza göre 2-10 dakika aralığında kalibre etmek genellikle iyi sonuç verir.

Örnek 3: aynı kullanıcı oda içinde sayfalar arasında gezince dwell time’ı room bazında doğru segmentleme

Chat deneyiminde kullanıcı aynı oturum içinde birden fazla oda gezebilir. Dwell time’ı sadece “session” bazında hesaplayıp toplam süreyi oda bazına dağıtamazsanız, room bazlı SEO çıkarımları hatalı olur. Bu yüzden dwell time segmenti room_id ile ayrılmalıdır.

Örneğin kullanıcı oda abc123’te 3 dakika durur, sonra abc456’ya geçer. Loglarda referer/room join event’leri her oda için ayrı tutulmalı; websocket URL veya join payload’inde room_id açıkça yer almalıdır. Dwell time finalize ederken “aktif pencere”yi her room segmenti için ayrı uygulayın. Bu yaklaşım CTR eşlemesini de güçlendirir: SERP tıklamasının hangi oda deneyimine dönüştüğünü daha net ayırırsınız.

Örnek 4: GSC tıklaması (impression/click) ile log türetilmiş ‘tıklama’ metriklerini nasıl çapraz doğrularsınız

Loglardan türettiğiniz “tıklama” metriklerini GSC ile kıyaslamak, yaklaşımınızın doğruluğunu sınayan en iyi kontrol mekanizmasıdır. Yine de şunu unutmayın: farklı kaynaklar aynı şeyi birebir ölçmez. GSC tıklama raporlar; loglar ise sunucunuza ulaşan istek/erişimleri ölçer. Bu fark normaldir.

Çapraz doğrulama için pratik yöntem: GSC’deki query + landing page URL eşleşmesini alın; loglardaki /rooms/{id} landing hitlerini aynı URL veya canonical mapping üzerinden filtreleyin; sonra referer “SERP kaynaklı” olduğunda log türetilmiş click sayısını hesaplayın. GSC ve log farkı büyükse; bot trafiği, yanlış referer filtreleri, time zone kayması veya yönlendirme (302) zinciri gibi nedenler araştırılmalıdır.

Bot/trafik kalite filtresi ve iç trafik dışlama (UA/IP/known crawler listeleri, rate-limit yaklaşımı)

UTM’siz log tabanlı ölçümde botlar daha görünür hale gelir. Botlar SERP refereri taklit edebilir ya da doğrudan landing’e istek atabilir. Bu da CTR ve dwell time’ı çarpıtır: dwell time kısa görünür (hızlı crawl) veya CTR sahte şişer (landing hit var ama kullanıcı deneyimi yok).

Kalite filtresi kurmak için UA/IP ve bilinen crawler listelerini kullanın. Ayrıca rate-limit ve anormal request pattern’ları (çok kısa aralıklarla aynı IP’den çok sayıda oda join) ile şüpheli trafiği dışarı alın. Ek olarak “başarılı oda erişimi” için minimum etkileşim eşiği (ör. websocket connected sonrası en az 1 presence event) koymak güveni artırır.

Gerçek zamanlı vs batch hesaplama (log pipeline, ETL, gecikme ve veri kaybı riskleri)

Loglar genellikle gecikmeli gelir. Gerçek zamanlı rapor istiyorsanız stream pipeline (ör. Kafka benzeri) ile event üretin; batch hesaplamada ise günlük/saatlik ETL ile türetin. Batch yaklaşımında gecikme düşük olsa bile dwell time “son aktivite pencere” tamamlanmadan hesaplanırsa yanlış sonuçlar doğurur.

Bu nedenle iki mod düşünün: “provisional dwell” ve “final dwell”. Provisional, son aktivite pencere X dakika dolana kadar geçici hesaplanır; final ise pencere tamamlandığında kesinleştirilir. Ayrıca log pipeline içinde request_id kaybolursa korelasyon kırılır. Bu yüzden ETL sırasında ID sürekliliğini ve eksik alan oranını izlemek kritik bir adımdır.

Hata ayıklama: beklenen dağılımlar ve anomali işaretleri (aniden düşük dwell, CTR spike vb.)

Başlangıçta beklenen dağılımları tanımlayın. Dwell time dağılımı genellikle ağır kuyrukludur (çok kısa kalışlar + az sayıda uzun kalış). CTR spike görüldüyse bunun nedeni referer sınıflandırması hatası, redirect zinciri veya bot trafiği olabilir. Tersi yönde dwell time aniden düşüyorsa sessionization penceresi çok dar kalmış olabilir.

Kontrol için basit bir anomali paneli kurun: (1) oda bazında giriş sayısı, (2) türetilmiş click oranı, (3) oda bazında medyan dwell time, (4) bot dışlama sonrası kalan oran. Bir değişiklik yaptığınızda (ör. websocket heartbeat aralığı), bu grafikler birlikte hareket etmelidir. Kaymıyorsa metrik üretiminde bir kırılma var demektir.

Yaygın hatalar

1) Referer tabanını tek sinyal sanmak: referer çoğu zaman gizlenir veya redirect ile değişir. Bu nedenle referer “SERP kaynaklı” olsa bile landing event’i bağlamadan CTR türetmeyin. Aksi halde iç trafik veya kampanya yönlendirmeleri SERP tıklaması gibi raporlanır.

2) Dwell time’ı sadece mesaj sayısından hesaplamak: kullanıcı mesaj yazmasa bile room içinde kalır. Sadece mesaj bazlı “aktif süre” ölçümü dwell time’ı sistematik biçimde düşürür ve SEO optimizasyonu için yanlış kararlar doğurur.

3) Sessionization penceresini kalibrasyonsuz kullanmak: yeniden bağlanmalarda gap toleransı çok kısa olursa tek deneyim parçalanır; çok uzun olursa farklı room deneyimleri birleşir. Bu iki uç, room bazlı SEO raporlarını bozabilir.

Nasıl kontrol edilir? Adım adım doğrulama (kontrol listesi)

Aşağıdaki doğrulama adımları hem veri kalitesini hem de SEO ile eşleşmeyi aynı anda test eder. Özellikle ilk hafta bu adımları sık tekrar edin.

• 1) Zaman senkronu kontrolü: log timestamp’lerini UTC’ye çekin; NTP drift var mı ve zaman zonu yanlışsa dwell time nasıl sapıyor test edin.
• 2) ID sürekliliği doğrulaması: request_id ve session/user id alanlarının oranını ölçün; eksik alan varsa fallback kuralını (cookie yoksa IP+UA+pencere) loglarda simüle edin.
• 3) Heuristik eşleşme örneklemesi: rastgele 50 oturum seçin; “SERP referer → landing/oda join → final dwell” zincirinin gerçekten doğru çalıştığını manuel gözden geçirin.
• 4) GSC ile korelasyon testi: GSC’de en iyi performans gösteren landing sayfaları için log türetilmiş click oranını karşılaştırın; farkın büyüklüğünü ve bunun nedenini sınıflandırın.

İç bağlantılarla tamamlayın (opsiyonel)

Log tabanlı yaklaşımı kurduktan sonra, chat’te indekslenme/ölçüm sapmalarını da yönetmek için bazı tamamlayıcı konulara göz atmak iyi olur. Örneğin crawl/indeks kararları CTR ve dwell time raporlarınızın anlamını doğrudan etkileyebilir.

Şu rehberler bu kurulumun yanına iyi oturur: Chat’te Beğenilenler & Cevaplarım Sayfaları Crawl Edilsin mi? CTR–Dwell Time Ölçümüyle İndeks Kararı Rehberi ve Chat Sitelerinde Oda Index Sitemap Eşik Kuralı: Son 24 Saat mi, 7 Gün mü? Mantık, Segmentasyon ve Ölçüm Planı.

Sık sorulan sorular (FAQ)

Referer tabanlı CTR türetimi ne zaman güvenilir, ne zaman yanıltıcı olur?

Referer güvenilir olur; kullanıcı aramadan gelir ve landing’e kısa bir redirect zinciriyle giderken referer korunur. Yanıltıcı olduğu durumlar; referer strip eden ara katmanlar, SPA yönlendirmeleri, üçüncü taraf embed’ler ve bazı gizlilik odaklı tarayıcı ayarlarıdır. Bu yüzden refereri tek başına karar verici yapmayın; landing/room join event ile birlikte doğrulayın.

Websocket’te dwell time nasıl ölçülür? Son aktivite mi, connection süresi mi?

Connection süresi “bağlantı kopmadığı sürece” doğru görünür ama kopuş tespiti her zaman net olmayabilir. Bu nedenle çoğu durumda son aktivite + X dakika pencere daha dayanıklıdır. Connection süresini ise yalnızca yardımcı sinyal (örn. uzun bağlantı ama sessizse) olarak kullanın.

Sessionization için hangi ID’ler gerekir? Cookie yoksa nasıl yapılır?

En ideal ID’ler kullanıcı/session id veya auth oturum id’sidir. Cookie yoksa, IP + User-Agent + zaman penceresi (ve mümkünse device fingerprint benzeri tutarlı sinyaller) ile oturumlaştırma yapılır. Ancak NAT aralığı nedeniyle IP tek başına yanıltabilir; bu yüzden pencereyi ve eşleşme koşullarını kalibre edin.

Bot trafiğini dışlamak CTR ve dwell time sonuçlarını nasıl etkiler?

Botlar içeriğe “hızlı” giriş yapıp çıkabilir; dwell time’ı düşürür. Ayrıca arama refererini taklit ederek CTR’yi şişirebilir. Bot dışlama doğru kurulursa hem medyan dwell hem de CTR stabil hale gelir; özellikle düşük dwell time kuyruklarında belirgin bir iyileşme görürsünüz.

Loglarda saat senkronu (NTP) ve zaman zonları yanlışsa ne olur?

Zaman kayması giriş/çıkış sıralamasını ters gösterebilir, sessionization pencere kuralını bozar ve dwell time negatif ya da çok yüksek değerler olarak görünebilir. Ayrıca batch hesaplamalarda pencereler yanlış gün/saat diliminde kapanır. Sonuç: raporlar “çalışıyor gibi” görünür ama anlamlı olmayabilir.

Batch hesaplama ile gerçek zamanlı rapor arasındaki farkı nasıl yönetirsiniz?

Gerçek zamanlıda pencere dolmadığı için “final dwell” oluşmayabilir. Batch’te ise final hesaplanır ama gecikir. Bu farkı yönetmek için iki metrik yayınlayın: provisional ve final. Yöneticilere hangi metrik türünün hangi gecikmeyle güncellendiğini net anlatın.

GSC (Search Console) ile log tabanlı CTR neden farklı çıkabilir?

GSC tıklama, tarayıcıya ulaşan tüm kullanıcı tıklamalarını yansıtabilir; loglar ise sunucuya ulaşan başarılı landing/oda join isteklerini ölçer. Botlar, redirectler, referer kaybı ve consent/JS ile geciken akışlar fark yaratır. Bu farkı minimize etmek için URL eşleştirme ve referer heuristiğini birlikte kalibre edin.

Uygulama kontrol listesi ve danışmanlık başlangıcı

Kurulumun kritik kısmı, log alanlarını tutarlı bir event şemasına çevirmek ve sessionization penceresini ürün davranışınıza göre ayarlamaktır. Başarılı olduğunuzda UTM’siz de SERP tıklaması benzeri sinyali ve room bazlı dwell time’ı raporlayabilirsiniz; böylece büyüme/SEO kararlarınız daha “kanıta dayalı” hale gelir.

Son olarak, log alanı eşleştirme şablonunu ve doğrulama kontrol listesini hazırlayın; ekiplerle paylaşmadan önce küçük bir veri örneğinde (ör. bir günlük trafik) simülasyon yapın. Beklediğiniz metrik eğrileri (CTR stabilitesi, dwell time kuyruk dağılımları) oluştuğunda üretime geçin ve anomali panelini 1-2 hafta aktif tutun.