Sunucu taraflı ölçüme ne zaman geçmeli: dört koşul, üç gereksiz durum

Sunucu taraflı ölçümü satan herkes aynı cümleyi kurar: “Tarayıcıda verinizin bir kısmı kayboluyor, sunucuya geçin.” Cümlenin ilk yarısı doğru. İkinci yarısı ise her firma için doğru değil; çünkü kaybolan verinin boyutu, o veriyle verilen kararın büyüklüğü ve geçişin maliyeti firmadan firmaya değişiyor. Ayda birkaç form alan bir site için sunucu taraflı etiketleme bir yatırım değil, bakım yüküdür.

Bu yazı Ölçümleme Danışmanlığı çalışmamda en sık karşılaştığım karardan çıktı: “Ajans sunucu taraflıya geçmemizi öneriyor, gerekli mi?” Cevabım hiçbir zaman evet ya da hayır olmadı; cevap, önce kaybın kendi hesabınızda ölçülmesine bağlı. Aşağıda tarayıcıda neyin kaybolduğunu, kaybı 30 dakikada nasıl ölçeceğinizi, geçmeyi gerektiren dört koşulu ve gerekmeyen üç durumu yazdım.

Bir not: sunucu taraflı kurulum yapmıyorum, satmıyorum. Kurulumu ekibiniz ya da ajansınız yapar; ben gerekip gerekmediğini ve doğru kurulup kurulmadığını denetlerim. Bu yazıyı satıcı olmadan yazabilmemin sebebi bu.

Tarayıcıda ne kaybediliyor?

Tarayıcı taraflı ölçümde veri dört yerde kaybolur: reklam engelleyiciler, Safari’nin çerez ömrü sınırı, rıza reddi ve erken çıkan ziyaretçi. Sunucu taraflı ilk ikisini büyük ölçüde çözer, son ikisini çözmez.

Mekanizma şöyle: klasik kurulumda Google Tag Manager kapsayıcısı ziyaretçinin tarayıcısında çalışır ve her etiket, veriyi doğrudan tarayıcıdan Google’a, Meta’ya ve diğer platformlara gönderir. Google’ın istemci tarafı ve sunucu tarafı etiketleme karşılaştırması sunucu taraflı düzeni iki kapsayıcıyla tanımlıyor: sitede kalan hafif bir web kapsayıcısı ve sizin bulut ortamınızda çalışan bir sunucu kapsayıcısı. Tarayıcı tek bir istek gönderir, dağıtımı sunucu yapar; veri sizin alan adınızda birinci taraf bağlamında kalır.

Kayıp kaynağı	Neyi etkiler	Sunucu taraflı çözer mi
Reklam engelleyici	Üçüncü taraf alanlarına giden istekler kesilir; Meta pikseli ve reklam etiketleri hiç çalışmaz	Büyük ölçüde; istek kendi alan adınıza gider
Safari çerez sınırı	Reklamdan gelen ziyaretçinin çerezi kısa ömürlü olur; sonraki günlerdeki dönüşüm reklama bağlanamaz	Kısmen; birinci taraf çerez ömrü uzar
Rıza reddi	Kullanıcı hayır dediyse etiket çalışmaz	Hayır; çalışmamalıdır da
Erken çıkış	Sayfa yüklenmeden çıkan ziyaretçi hiç sayılmaz	Kısmen; tek istek daha erken tamamlanır

Safari tarafı en az bilinen kalem. WebKit’in Intelligent Tracking Prevention 2.3 yazısına göre, izleme yapan bir alan adından sorgu parametresiyle gelen ziyarette tarayıcıda oluşturulan kalıcı çerezlerin ömrü 24 saate iniyor; kullanıcı yedi gün siteyle etkileşmezse sitenin çerez dışı verisi de siliniyor. Pratikte şu demek: reklamı Safari’de tıklayan biri üç gün sonra dönüp satın aldığında, tarayıcı ölçümü bu satışı reklama bağlayamaz. iPhone payı yüksek bir müşteri kitlesinde bu kayıp tek başına kararı değiştirebilir.

Meta kendi dokümanında da aynı şeyi söylüyor: Conversions API ile gönderilen veri, piksele göre tarayıcı yükleme hatalarından, bağlantı sorunlarından ve reklam engelleyicilerden daha az etkileniyor; Meta bunun pikselle birlikte kullanılmasını öneriyor, pikselin yerine değil.

Kaybın boyutunu kendi hesabınızda nasıl ölçersiniz?

Kaybın boyutu, gerçek dönüşüm sayısı ile ölçülen dönüşüm sayısı arasındaki farktır ve bu fark 30 dakikada kendi hesaplarınızdan çıkar. Satıcının söylediği genel yüzdeler sizin hesabınız değildir.

Sırayla:

1. Gerçek sayıyı bulun. Son 30 günün sipariş listesi, form kayıtları ya da CRM’e düşen talepler. Bu sayı ölçümden bağımsızdır; doğrunun kendisidir. Kayıt tutulmuyorsa ölçüm tartışmasından önce bu eksik kapatılır.
2. GA4’teki önemli etkinlik sayısını aynı dönem için alın. Raporlar altında etkinlik raporunu açın; satın alma ya da form gönderimi etkinliğinin toplamını yazın.
3. Google Ads ve Meta’daki dönüşüm sayısını alın. Aynı 30 gün, aynı dönüşüm tanımı. Meta’da Olaylar Yöneticisi’ndeki olay sayısına ve olay eşleşme kalitesi puanına bakın; puan düşükse Meta gelen olayı kişiye bağlayamıyor demektir.
4. Farkı yüzdeye çevirin. Gerçek sayı 200, GA4 170, Google Ads 150 ise analiz kaybı yüzde 15, reklam kaybı yüzde 25’tir. Reklam tarafındaki kayıp her zaman daha büyüktür; kararı o belirler.
5. Cihaz kırılımına bakın. GA4’te cihaz ve tarayıcı raporunda iOS ve Safari payını yazın. Pay yüksekse kaybın çoğu Safari’den geliyordur ve sunucu taraflı bunun bir kısmını geri getirir.
6. Kaybı paraya çevirin. Aylık reklam bütçesini reklam kaybı yüzdesiyle çarpın. Teklif algoritması o kadar veriyi görmeden çalışıyor; bu, bütçenin o kısmının daha az bilgiyle harcandığı anlamına gelir.

Altıncı adımın sonucu kararın hammaddesidir. Aşağıdaki dört koşul ve üç durum bu sayıya göre okunur.

Geçmeyi gerektiren dört koşul hangileri?

Dört koşuldan en az ikisi sizde varsa geçiş karşılığını verir: reklam kaybının maliyeti kurulumu geçiyor, Safari ve iOS payı yüksek, etiket kalabalığı hız sorunu yaratıyor, veriyi göndermeden önce süzmeniz gerekiyor.

• Kaybın maliyeti kurulumu geçiyor. Altıncı adımdaki sayı aylık bir rakam; on iki ayla çarpıp kurulum artı bir yıllık sunucu ve bakım maliyetiyle karşılaştırın. Reklam bütçesi büyüdükçe bu koşul tek başına yeter.
• Safari ve iOS payı yüksek. Beşinci adımda çıkan pay üçte bire yaklaşıyorsa çerez ömrü sınırı dönüşümlerinizin önemli kısmını reklamdan koparıyordur. Tüketiciye satan ve mobil ağırlıklı markalarda bu pay çoğu zaman yüksektir.
• Sayfada etiket kalabalığı hız sorunu yaratıyor. On beş yirmi pazarlama etiketi taşıyan bir sitede her etiket tarayıcıda ayrı istek açar. Google’ın dokümanı sunucu taraflı düzende istemcinin daha az kod çalıştırdığını ve daha az istek gönderdiğini yazıyor; sayfa hızı ölçülebilir biçimde düzelir.
• Veriyi göndermeden önce süzmeniz gerekiyor. Kişisel veriyi pazarlama platformlarına iletmeden önce kaldırmak istiyorsanız bunu tarayıcıda yapamazsınız; sunucu kapsayıcısı tam bu iş için var. Bu koşul teknik değil, veri politikası kaynaklıdır ve tek başına gerekçe olabilir.

Dört koşulun hiçbiri “ajans önerdi” ya da “rakip geçti” değil. İkisi de gerekçe değildir.

Hangi üç durumda gerekmez?

Üç durumda sunucu taraflı etiketleme yalnızca maliyet ve bakım yükü getirir: dönüşüm hacmi düşükse, tarayıcı ölçümü zaten yanlış kuruluysa ya da geçişin tek gerekçesi bir öneriyse.

Dönüşüm hacmi düşükse. Ayda birkaç form ya da birkaç sipariş alan bir sitede yüzde 20 kayıp, birkaç dönüşüm demektir. O birkaç dönüşümü geri getirmek için sunucu kiralamak, kurulum yaptırmak ve her etiket değişikliğini iki yerde yönetmek karşılığını vermez. Bu firmada bütçe, ölçüm altyapısına değil dönüşüm sayısını artıracak işe gider.

Tarayıcı ölçümü zaten yanlışsa. Denetimlerde en sık bulduğum durum bu: dönüşüm iki kez tetikleniyor, form gönderimi sayfa görüntülemesiyle karışmış, önemli etkinlik olarak işaretlenen şey iş değeri taşımıyor. Yanlış ölçümü sunucuya taşımak yanlışı daha güvenilir hale getirmez, yalnız daha pahalı hale getirir. Önce tarayıcı kurulumu düzeltilir; sunucu taraflı, doğru ölçümün üstüne kurulur.

Tek gerekçe bir öneriyse. Ajansın, satıcının ya da bir yazının önerisi, kendi hesabınızda ölçülmüş bir kayıp olmadan gerekçe değildir. Yukarıdaki altı adımı atlayıp geçen firmalar, geçtikten sonra da rakamlarının neden hâlâ tutmadığını sorar; çünkü sorun hiç orada değildi.

Tek soru: “Bu geçişle geri gelecek dönüşüm sayısı ne ve bunu hangi hesaptan çıkardınız?”

Bu sorunun cevabı bir sayı değilse geçiş bir altyapı kararı değil, bir satış kararıdır.

Maliyet kalemleri neler?

Sunucu taraflı etiketlemenin maliyeti dört kalemden oluşur: sunucu, kurulum, bakım ve test. Rakam firmaya göre değişir; kalemler değişmez ve teklifte dördü de yazılı olmalıdır.

Kalem	Ne içerir	Sık atlanan kısım
Sunucu	Bulut ortamında çalışan sunucu kapsayıcısı; aylık ücret, trafik arttıkça artar	Kapsayıcının kimin bulut hesabında olduğu
Kurulum	Web kapsayıcısının sadeleştirilmesi, sunucu kapsayıcısı, alan adı ayarı, her platform için istemci ve etiket	Rıza yönetiminin sunucu tarafına taşınması
Bakım	Her yeni etiket ve her dönüşüm değişikliği artık iki kapsayıcıda yapılır	Bakımı kimin yapacağı ve saatlik bedeli
Test	Tarayıcı ile sunucu olaylarının tekilleştirilmesi ve geçiş öncesiyle karşılaştırma	Testin tamamen atlanması

Sunucu satırındaki “sık atlanan kısım” en pahalı hata olabilir. Kapsayıcı ajansın bulut hesabında kurulduysa ayrıldığınız gün ölçüm altyapınız da gider; hesap sahipliğini ölçüm için de sözleşmeye yazdırın. Aynı kural reklam hesapları için Google Ads Danışmanlığı sayfasında yazıyor; ölçüm hesapları için de geçerli.

Geçtikten sonra neyi yeniden doğrularsınız?

Geçişten sonra ilk 30 günde dört şey doğrulanır: tekilleştirme, dönüşüm sayısının önceki dönemle karşılaştırması, rıza davranışı ve kapsayıcı sahipliği. Bu dört kontrol yapılmadan geçiş bitmiş sayılmaz.

Tekilleştirme. Aynı olay hem tarayıcıdan hem sunucudan gönderildiğinde platform ikisini tek olay olarak saymalı. Meta’nın tekilleştirme dokümanı bunun yapılmadığında dönüşüm sayısının yapay olarak yükseldiğini ve bütçe kararlarını yanılttığını yazıyor. Kontrol yeri Olaylar Yöneticisi: aynı olayın iki kaynaktan gelip birleştirildiği orada görünür. Google Ads’de de kontrol basit: geçişten sonraki haftanın dönüşüm sayısı önceki haftanın iki katına yakınsa tekilleştirme yoktur.

Önceki dönemle karşılaştırma. Geçişten önceki ve sonraki 30 günün dönüşüm sayısını gerçek sayıyla yan yana koyun. Beklenen sonuç, ölçülen sayının gerçeğe yaklaşmasıdır; gerçeği geçiyorsa çift sayım, hiç değişmediyse kurulum çalışmıyor demektir.

Rıza davranışı. Rızayı reddeden bir kullanıcıyla siteyi gezin ve sunucu kapsayıcısına hangi isteklerin ulaştığına bakın. Ret durumunda pazarlama etiketleri sunucuda da çalışmamalı. Sunucu taraflı kurulumların bir kısmı bu kontrolü atlıyor; rıza bandı tarayıcıda çalışıyor, sunucu ise her şeyi gönderiyor.

Kapsayıcı sahipliği. Bulut hesabı, alan adı kaydı ve Tag Manager sunucu kapsayıcısı firmanın hesabında mı; ajans kullanıcı olarak mı ekli. Bu kontrol beş dakika sürer ve ayrılık anında en pahalı kalem olur.

Meta reklamı tarafında bu doğrulamanın kreatif ve hedefleme kararlarını nasıl etkilediğini Meta Reklam Danışmanlığı sayfasında anlattım; ölçüm yanlışsa test sonuçları da yanlıştır.

Kararı kim vermeli?

Kararı, kaybı kendi hesabında ölçmüş olan firma vermeli; satıcı, ajans ya da danışman değil. Satıcının işi geçişi yapmak, ajansın işi kampanyayı yürütmek; ikisinin de gerekli olmadığını söylemekte çıkarı yok.

Ben iki tarafta da değilim. Sunucu taraflı kurulum yapmıyorum ve satmıyorum; bu yüzden “gerekmez” diyebiliyorum ve söylediğim oluyor.

Kararı vermek için yukarıdaki altı adımı kendiniz uygulayabilirsiniz; çoğu firma bu kadarıyla cevabı bulur. Kayıp yüzdesi yüksek çıkıp da kaynağı belirsizse ya da ajansın kurulumunun doğru olup olmadığından emin değilseniz, mevcut ölçüm kurulumunu tek seferlik denetliyor ve dört kontrolü yazılı veriyorum. Sitenin yenilenmesi ya da taşınması gündemdeyse ölçüm devri o işin parçası; onu Web Sitesi Danışmanlığı sayfasında ayrıca anlattım.

Sunucu taraflı etiketleme iyi bir araçtır; sorun araçta değil, ölçülmemiş bir kayba çözüm olarak satılmasında. Önce kaybı ölçün, sonra karar verin. Sıra tersine döndüğünde para hep aynı yere gider: satana.