Kazım Gökay Çiftci · 22 Ekim 2026

Server-Side Etiketleme Nedir? Reklam Engelleyici ve Çerez Kaybına Karşı Ne Kazandırır

Server-side etiketleme (sunucu tarafı etiketleme), reklam ve analitik etiketlerinin bir kısmını ziyaretçinin tarayıcısından alıp sizin kontrol ettiğiniz bir sunucuya taşır. Kısa tez şu: bu yöntem veri kalitesini ve çerez ömrünü iyileştirebilir, ama reklam engelleyiciyi sihirli biçimde aşan, onay kurallarını ortadan kaldıran ya da her siteye ilk gün lazım olan bir çözüm değildir. Hangi sorunu çözdüğünü, neye mal olduğunu ve ne zaman beklemenin daha mantıklı olduğunu aşağıda Google'ın kendi dokümanlarına dayanarak anlatıyoruz.

Yazı, e-ticaret ve lead toplayan sitelerde reklam ölçümünü yöneten işletmeler için. Etiket yönetimi ya da çerez onayı konusunda temel bilginiz varsa rahat takip edersiniz; yoksa önce çerez banneri ve Google izin modu rehberimize göz atabilirsiniz.

Normal etiketleme ile sunucu tarafı etiketleme arasındaki fark ne?

Klasik kurulumda Google Etiket Yöneticisi (GTM) kapsayıcısı ziyaretçinin tarayıcısında çalışır. Sayfa yüklenince GA4, Google Ads, Meta ve diğer reklam platformlarının etiketleri tarayıcıda tetiklenir ve her biri kendi sunucusuna ayrı ayrı istek gönderir. Ziyaretçinin tarayıcısı yüklenen her etiketin kodunu indirir ve çalıştırır.

Sunucu tarafında ise ayrı bir sunucu kapsayıcısı vardır. Google'ın tanımıyla bu kapsayıcı, ziyaretçinin tarayıcısında ya da telefonunda değil, sizin kontrol ettiğiniz bir sunucuda çalışır ve etiket, tetikleyici, değişken modelini aynen kullanır. Tarayıcıdan tek bir veri akışı sizin sunucunuza gelir; sunucu bunu istemciler (clients) aracılığıyla olaya çevirir, kapsayıcıdan geçirir ve etiketler aracılığıyla ilgili platformlara iletir. Google Analytics ve Measurement Protocol istemcileri hazır gelir.

Pratikte ortaya çıkan değişiklik şu: platformlara giden isteğin kaynağı artık ziyaretçinin tarayıcısı değil, sizin sunucunuz. Veriyi gönderilmeden önce siz süzersiniz, düzeltirsiniz ya da bazı alanları hiç göndermezsiniz.

Hangi sorunu gerçekten çözer?

Google'ın sunucu tarafı etiketleme sayfası üç fayda sayıyor: sayfa performansının iyileşmesi, daha ayrıntılı kullanıcı gizliliği kontrolü ve daha iyi veri kalitesi. Bunları e-ticaret gözüyle açalım:

Sayfa performansı: Birden çok reklam etiketinin kodunu tarayıcıda çalıştırmak yerine bu işin ağır kısmı sunucuya kayar. Etiketi çok olan mağaza sayfalarında tarayıcıya binen yük azalır.
Veri kontrolü: Google, verinin yalnızca siz başka yere göndermeyi seçene kadar sunucunuzda kaldığını söylüyor. Kişisel veri sayılabilecek alanları (örneğin e-posta ya da tam IP) platforma ulaşmadan çıkarabilirsiniz.
Veri kalitesi: Sunucuda olayı doğrulayabilir, tarayıcıdan tarayıcıya değişen biçim farklarını düzeltebilir, eksik alanları tamamlayabilirsiniz. Satın alma olayına sipariş sisteminizden gelen kesin tutarı eklemek buna örnektir.
Daha dayanıklı çerezler: Sunucuyu kendi alan adınızın bir alt alan adında (ya da aynı alan adının bir yolunda) çalıştırırsanız Google'ın ifadesiyle birinci taraf bağlamının "daha dayanıklı çerezler" gibi yararlarını alırsınız. Sunucu tarafından atılan çerezler bu kurulumda güvenlik ve dayanıklılık avantajından tam yararlanır.

Reklam engelleyiciye karşı ne kazandırır, ne kazandırmaz?

Bu başlık yazının en çok yanlış anlaşılan kısmı. Satıcıların bir kısmı sunucu tarafı etiketlemeyi "engelleyicileri aşma yolu" olarak anlatıyor. Google'ın sayfaları ise faydaları sayarken reklam engelleyicilere karşı bir güvence vermiyor.

Mantığı şöyle düşünün. Engelleyicilerin bir bölümü, bilinen üçüncü taraf etiket adreslerine giden istekleri keser. Sunucu kapsayıcınız kendi alan adınızdaysa tarayıcıdan çıkan istek sizin alan adınıza gider ve bu tür bir kesme olasılığı düşer. Ancak iki sınır var. Birincisi, tarayıcıda hâlâ bir ilk etiketin (yükleyici kodun) çalışması gerekir ve bazı engelleyiciler onu da hedefler. İkincisi, engelleyiciler zamanla kendi kurallarını günceller; bugün işleyen bir kurulumun yarın aynı sonucu vereceğini söyleyemezsiniz.

Bu yüzden doğru beklenti şudur: veri kaybının bir kısmı geri gelebilir, ne kadarının geleceği sitenizin ziyaretçi profiline ve kurulumun kalitesine bağlıdır. Kurulumdan önce ve sonra GA4 verisini sipariş sisteminizle kıyaslayın; sayıyı vaat etmek yerine ölçün.

Çerez ömrü ve birinci taraf bağlamı nasıl çalışır?

Google'ın özel alan adı sayfası şunu söylüyor: sunucu tarafı etiketlemeyi sitenizle aynı birinci taraf bağlamında barındırmak istiyorsanız etiketleme sunucusu ve web siteniz aynı alan adı üzerinde çalışmalı. İki yol sayılıyor:

Alt alan adı (örneğin metrics.siteniz.com): DNS kayıtlarını güncellersiniz. Sunucu tarafından atılan çerezler için güvenlik ve dayanıklılık avantajının tamamı geçerli olur.
Aynı kaynak yolu (örneğin www.siteniz.com/metrics): Aynı avantajlar geçerli, ama bir CDN ya da yük dengeleyici üzerinden isteklerin yönlendirilmesi gerekir; DNS değişikliği de gerekebilir.

Varsayılan olarak gelen run.app adresi ise birinci taraf değildir. Yani yalnızca sunucuyu açmak çerez avantajını getirmez; özel alan adı adımı şarttır. Google'ın dokümanında çerezlerin tam ömrüne dair bir gün sayısı verilmiyor, yalnızca "daha dayanıklı" deniyor; bu yüzden kesin bir gün sayısı vaat etmeyin.

Onay ve KVKK açısından ne değişir?

Sunucu tarafı etiketleme, verinin nereden toplandığını değiştirir; ziyaretçinin onayıyla ilgili yükümlülüklerinizi değiştirmez. Çerez banneri ve aydınlatma metni gereksinimi, etiket tarayıcıda da çalışsa sunucuda da çalışsa aynı mantıkla geçerlidir. Sunucuya taşımanın size kazandırdığı şey kontrol: hangi alanın platforma gideceğine siz karar verirsiniz. Bu kontrolü, onay vermeyen ziyaretçinin verisini sessizce toplamak için kullanmak hem hukuki risk hem itibar riskidir.

Doğru kullanım tersidir: onay durumunu sunucuya da taşırsınız, onay vermeyen ziyaretçi için reklam platformlarına giden alanları kısarsınız. Bu konuyu KVKK uyumlu e-ticaret sitesi rehberimizde ayrıca ele aldık.

Kurulum için neye ihtiyaç var, maliyeti ne?

Google, sunucuyu Google Cloud'da ya da seçtiğiniz başka bir platformda çalıştırmanızı öneriyor; Cloud Run, App Engine ve elle kurulum için kılavuzlar var. İhtiyaç listesi kısaca şu:

Bir sunucu kapsayıcısı (GTM içinde oluşturulur).
Kapsayıcıyı çalıştıran bir bulut hesabı ve faturalandırma.
Özel alan adı ve DNS ya da CDN yapılandırması.
Tarayıcı tarafında verinin sunucuya yönlenmesi (GA4 etiketinde sunucu adresinin tanımlanması).
Önizleme sunucusuyla test, sonra canlı trafiğe geçiş.

Maliyet için Google'ın Cloud Run kılavuzundaki rakamlar bir fikir veriyor: her sunucunun aylık yaklaşık 45 ABD doları olduğu tahmin ediliyor (1 vCPU, 0,5 GB bellek, CPU sürekli ayrılmış fiyatlandırma varsayımıyla). Kılavuz, veri kaybı riskini azaltmak için en az iki sunucu çalıştırmayı öneriyor ve örnek dağıtımda en az 2, en çok 10 sunucu kullanıyor. Google'ın beklentisi 2-10 sunucunun otomatik ölçeklenmesiyle saniyede 35-350 isteğin karşılanması; etiket sayısı ve etiketlerin yaptığı işe göre değişebileceğini de ekliyor. Yani maliyetin tabanı sabit, tavanı trafiğe bağlı. Bu rakamlar Google'ın kılavuzdaki örnek varsayımları; kendi trafiğiniz için Google Cloud fiyat hesaplayıcısıyla ayrıca hesap yapın.

Bir de insan maliyeti var: sunucuyu izlemek, etiket güncellemelerini test etmek ve bir şeyler bozulduğunda neyin bozulduğunu bulmak, tarayıcı tarafında yaptığınızdan daha fazla teknik bilgi ister.

Kime lazım, kim için erken?

Upjen olarak reklam ölçümü kurarken gördüğümüz tablo şu: sunucu tarafı etiketleme çoğunlukla ölçümün temeli sağlam olan işletmelere değer katıyor. Temel eksikse üstüne sunucu eklemek eksikleri büyütür.

Şu durumlarda mantıklı bir yatırım olabilir:

Reklam bütçeniz yeterince büyük ve dönüşüm verisindeki küçük kayıplar kampanya kararlarını etkiliyor.
Sayfada çok sayıda etiket çalışıyor ve sayfa hızı bundan etkileniyor.
Sipariş sisteminizdeki kesin tutarı, iade ve iptal bilgisini reklam platformlarına göndermek istiyorsunuz.
Hangi alanın hangi platforma gideceğini kendi elinizde tutmak zorunda olan bir veri politikanız var.

Şu durumlarda önce başka işleri yapın:

GA4 e-ticaret olayları (sepete ekle, satın alma) henüz doğru çalışmıyor ya da transaction_id tekrarı var.
Reklam trafiği GA4'te "direct" görünüyor; önce UTM etiketlemesini düzeltin.
Çerez banneri onay durumunu etiketlere doğru aktarmıyor.
Reklam bütçeniz, sunucu maliyetini ve kurulum emeğini karşılayacak büyüklükte değil.

Kurulumdan sonra doğrulama nasıl yapılır?

Sunucu tarafı kurulum sessiz bozulabilir; sayfa çalışmaya devam eder, ama veri eksik gelir. Üç kontrolü düzenli yapın:

Önizleme modu: Sunucu kapsayıcısının önizleme özelliğiyle gelen istekleri ve hangi etiketin tetiklendiğini görün.
Sipariş sayısı kıyası: Aynı dönemde GA4'teki satın alma sayısı ile sipariş sisteminizdeki sayıyı karşılaştırın. Fark sabit bir bantta kalıyorsa kurulum sağlıklı; aniden açılıyorsa bir şey bozulmuştur.
Reklam platformu tarafı: Google Ads ve Meta'daki dönüşüm sayılarının kurulumdan sonra tutarlı olduğunu kontrol edin. Aynı satışın hem tarayıcı hem sunucu etiketiyle iki kez sayılması en sık yapılan hatadır.

Sunucuda veriyi zenginleştirmek ne demek?

Sunucu tarafının en somut katkısı, tarayıcının bilmediği bilgiyi olaya eklemek. Tarayıcıdaki satın alma olayı yalnızca sayfada görünen tutarı taşır. Sunucu tarafında ise sipariş sisteminizden gelen kesin tutarı, iptal ve iade durumunu ya da ürün maliyetini aynı olaya ekleyip platforma öyle iletebilirsiniz. GA4 olay referansında purchase olayı için transaction_id zorunlu; aynı kimliği hem tarayıcı hem sunucu tarafında kullanmak, aynı satışın iki kez sayılmasını engellemenin ilk adımı.

Bir başka örnek veriyi kısmaktır. Sunucuya gelen istekte e-posta ya da telefon gibi alanlar varsa, bunları hangi platforma hangi biçimde (örneğin özetlenmiş halde) göndereceğinize ya da hiç göndermeyeceğinize kapsayıcıda karar verirsiniz. Bu kontrol, tarayıcıda her etiketin kendi kafasına göre veri topladığı kurulumda mümkün değil. Karşılığında her alanın nereye gittiğini belgelemeniz ve değişiklik yapıldığında test etmeniz gerekir.

Geçişi hangi sırayla yapmak mantıklı?

Her şeyi bir gecede taşımak yerine tek bir etiketle başlamak daha güvenli. Önce GA4'ü sunucuya alın, bir süre iki kaynağın verisini kıyaslayın, sonra reklam platformlarının etiketlerini tek tek taşıyın. Her adımda önizleme sunucusunda deneyin; canlı trafiğe geçmeden önce Google'ın önerdiği gibi özel alan adını ve üretim modunu ayarlayın. Bir sorun çıkarsa tek etiketi geri almak, tüm kurulumu geri almaktan çok daha kolay.

Sıkça Sorulan Sorular

Server-side etiketleme reklam engelleyicileri tamamen aşar mı?

Hayır. Google'ın dokümanları böyle bir güvence vermiyor. Sunucuyu kendi alan adınızda çalıştırmak bazı kesintileri azaltabilir, ama tarayıcıdaki ilk etiket hâlâ gereklidir ve engelleyici kuralları değişebilir. Etkisini kendi verinizde ölçerek karar verin.

Çerez onayı gerekmeye devam eder mi?

Evet. Sunucu tarafı etiketleme verinin toplanma yerini değiştirir, onay yükümlülüğünü kaldırmaz. Onay durumunu sunucuya da aktarıp ona göre veri göndermek gerekir.

Aylık maliyeti ne kadar?

Google'ın Cloud Run kılavuzu, her sunucu için aylık yaklaşık 45 ABD doları tahmin ediyor ve en az iki sunucu öneriyor. Gerçek maliyet sunucu sayısına ve trafiğe göre değişir; kendi rakamınız için Google Cloud fiyat hesaplayıcısını kullanın.

Küçük bir e-ticaret sitesi için gerekli mi?

Çoğu zaman ilk adım değildir. Önce GA4 olaylarını, UTM düzenini ve onay yönetimini sağlam kurmak daha az maliyetle daha çok veri kurtarır. Bütçe büyüyüp ölçüm kaybı karar vermeyi zorlaştırınca sunucu tarafı gündeme gelir.

GTM kapsayıcısını silip sadece sunucuyu mu kullanırım?

Hayır. Tarayıcıdaki web kapsayıcısı veriyi toplayıp sunucuya gönderir; sunucu kapsayıcısı onu alıp platformlara dağıtır. İki kapsayıcı birlikte çalışır.

Sonuç

Sunucu tarafı etiketleme veriyi daha kontrollü, daha temiz ve potansiyel olarak daha dayanıklı toplamanın bir yolu; ama bir reklam engelleyici çözümü ya da onay kurallarını aşma aracı değil. Karar verirken sıranız şu olsun: önce temel ölçümü doğrulayın, sonra onay yönetimini düzeltin, ardından sunucu maliyetini reklam bütçenizle kıyaslayın. Bugün yapabileceğiniz en faydalı iş, GA4'teki satın alma sayınızı sipariş sisteminizle bir ay boyunca günlük karşılaştırıp farkın ne kadar olduğunu görmek.

Kurulumun denetlenmesini ya da sıfırdan planlanmasını isterseniz martech ve analitik danışmanlığı sayfamızdan bize ulaşabilirsiniz. Diğer yazılar için blog sayfamıza da bakın.