Server-side tagging: kurulum kararları ve maliyet
Server-side tagging kararı: hangi kurulum biçimi, hangi maliyet kalemleri ve hangi durumda kurmamak daha doğru. Fiyat verilmez.
Yazan Roozbeh Nazari · CEO
Server-side tagging, Türkiye’deki ekiplerde son iki yılda "kurmalı mıyız" sorusundan "neden hâlâ kurmadık" sorusuna geçen bir başlık oldu. Bu geçiş, kararın kendisini kolaylaştırmadı. Kurulum bir yazılım tercihi değil, işletme kararıdır: sürekli çalışan bir sunucu, onu izleyecek biri ve bozulduğunda ölçümün durduğu bir bağımlılık anlamına gelir. Bu yazı, kararı verirken bakılması gereken kalemleri sıralıyor.
Ölçüm tarafındaki çerçeveyi analitik ve veri stratejisi hizmetimizde anlatıyoruz. Çok dilli sitelerde raporlamanın nasıl kurulduğunu ise GA4 locale bazlı funnel analizi yazısında ele almıştık; server-side tagging, o raporlamanın veri toplama katmanındaki karşılığıdır.
Bir uyarıyla başlayalım: bu yazıda hiçbir fiyat rakamı verilmiyor. Bulut sağlayıcı fiyatları bölgeye, kullanım biçimine ve zamana göre değişir; bugün yazılan bir rakam altı ay sonra yanlış olur. Bunun yerine maliyeti oluşturan kalemler ve bu kalemleri kendi trafiğinizle nasıl hesaplayacağınız anlatılıyor. Rakamı kendi sağlayıcınızın güncel fiyat sayfasından, kendi trafik hacminizle çarparak siz üretirsiniz.
Server-side tagging aslında neyi değiştirir
Klasik kurgu tarayıcıdan doğrudan ölçüm platformlarına istek gönderir. Server-side kurguda tarayıcı tek bir adrese istek gönderir; o adresteki sunucu isteği alır, işler ve ilgili platformlara kendisi dağıtır. Değişen şey verinin nereye gittiği değil, kimin gönderdiğidir.
Bu değişimin üç sonucu vardır. Birincisi, tarayıcıda çalışan betik sayısı azalır ve sayfa yükü hafifler. İkincisi, hangi verinin hangi platforma gideceği tek bir yerde kontrol edilebilir hale gelir. Üçüncüsü ve pratikte en belirleyicisi, çerez ömrünün ve veri kalitesinin tarayıcı kısıtlarına daha az bağımlı olmasıdır.
Bu üç sonucun hiçbiri otomatik kazanç değildir. Kurulum yanlış yapıldığında sayfa yükü azalmaz, kontrol tek yerde toplanmaz ve veri kalitesi düşer. Server-side tagging bir ölçüm mimarisi tercihidir; kurulduğu için değil, doğru kurulduğu için çalışır.
Kurulum biçimi: üç yol, üç farklı bağımlılık
Etiketleme sunucusunu ayağa kaldırmanın birden fazla yolu var ve seçim, ekibin işletme kapasitesine göre yapılmalı.
- Yönetilen bulut hizmeti üzerinden otomatik sağlama. En hızlı yol; ölçekleme ve yama yönetimi büyük ölçüde sağlayıcıya kalır. Karşılığında sağlayıcıya bağımlılık ve kullanım bazlı bir gider kalemi doğar.
- Kendi altyapınızda elle kurulum. Docker imajı üzerinden kurulur ve tam kontrol sağlar. Ölçekleme, izleme ve güncelleme sizin sorumluluğunuza geçer.
- Hiç kurmamak. Gerçek bir seçenektir ve düşük trafikli, tek pazarlı sitelerde çoğu zaman doğru olanıdır. Kurulmayan bir sunucunun işletme maliyeti sıfırdır.
Elle kurulumda dikkat edilmesi gereken teknik bir kısıt var: sağlanan sunucuların en fazla bir sanal işlemciye sahip olması öneriliyor. Ek işlemciler kullanılmıyor ve otomatik ölçeklemeyi olumsuz etkiliyor. Yani "daha güçlü tek makine" yaklaşımı burada işe yaramaz; ölçekleme yukarı değil, yana doğru yapılır. Erişilebilirlik ve performans için küme kurulumu öneriliyor.
Maliyeti oluşturan kalemler
Toplam maliyeti tek bir sunucu ücretine indirgemek, kararın en sık yapılan hatasıdır. Gerçekte en az beş kalem vardır ve bunların üçü faturada görünmez:
- Sürekli çalışan örneklerin bedeli. Etiketleme sunucusu, trafik olmadığında da ayakta kalmalıdır; ilk istekte soğuk başlatma yaşayan bir kurgu veri kaybeder.
- Trafikle ölçeklenen ek örnekler. Kampanya dönemlerinde bu kalem taban maliyetin katları olabilir; hesabı yıllık ortalamayla değil, en yoğun ayla yapmak gerekir.
- Ağ çıkışı. Sunucudan platformlara giden trafik ücretlendirilir ve çok platformlu kurgularda tek bir olay birden fazla çıkışa dönüşür.
- Alan adı ve sertifika yönetimi. Etiketleme sunucusunun sitenizle aynı alan adı altında çalışması gerekir; bu, DNS ve sertifika tarafında sürekli bir bakım kalemi doğurur.
- Mühendislik zamanı. En büyük ve en çok göz ardı edilen kalem. Kurulum bir kerelik, izleme ve arıza müdahalesi süreklidir.
Bu kalemleri doldururken kullanılacak pratik yöntem, tek bir ayın gerçek olay sayısını almak ve her kalemi o sayıyla çarpmaktır. Olay sayısını GA4 tarafındaki mevcut raporlarınızdan okuyabilirsiniz; tahmin etmeye gerek yoktur. Aylık olay sayısı bilinmeden yapılan her maliyet hesabı, sağlayıcının örnek senaryosunu kendi sitenize uydurmaktan ibarettir ve genellikle gerçek rakamın altında kalır.
Son kalem kararı belirleyendir. Ölçüm durduğunda bunu fark edecek bir uyarı kurgusu ve müdahale edecek bir kişi yoksa, server-side tagging ölçümü iyileştirmez; ölçümün sessizce durabileceği yeni bir tek nokta ekler.
Hangi durumda kurmamak doğru
Kurmamanın doğru olduğu durumlar somuttur. Tek dilli, tek pazarlı ve düşük hacimli bir sitede kazanç, işletme yüküne değmez. Ölçüm kurgusu hâlihazırda tutarsızsa, veri toplama katmanını değiştirmek tutarsızlığı taşımaktan başka bir işe yaramaz; önce olay şeması düzeltilir. Teknik bakımı üstlenecek kimse yoksa, kurulum bir süre sonra bakımsız kalır ve bakımsız bir etiketleme sunucusu, hiç olmamasından daha risklidir.
Kurmanın açıkça doğru olduğu durum ise çok pazarlı, yüksek hacimli ve reklam yatırımının anlamlı olduğu kurgulardır. Burada veri kalitesindeki iyileşme doğrudan bütçe kararlarına yansır ve işletme maliyeti, yanlış atıfla harcanan reklam bütçesinin yanında küçük kalır.
Karar sırası şudur: önce ölçüm şemasını düzeltin, sonra hacminizi ve pazar sayınızı yazın, sonra beş maliyet kalemini kendi rakamlarınızla doldurun, en sonunda bakımı kimin üstleneceğini isimlendirin. Bu dördü yazılı hale gelmeden verilen "kuralım" kararı, teknik bir karar değil, bir temennidir.
Kurulum sonrası: ölçümün sessizce durmasını engellemek
Server-side kurgunun en tehlikeli arıza biçimi, sunucunun tamamen çökmesi değildir; çöken bir sunucu hemen fark edilir. Asıl risk kısmi arızadır: sunucu ayaktadır, isteklere yanıt verir, ancak bir platforma giden dağıtım hata almaktadır. Raporlarda görünen şey bir hata mesajı değil, sadece daha az veridir. Ekipler bunu genellikle haftalar sonra, bir kampanya sonucu beklenenden düşük çıktığında fark eder.
Bu yüzden kurulumun parçası sayılması gereken üç kontrol var. Birincisi, sunucunun sağlık kontrolü uç noktasının dışarıdan izlenmesi ve yanıt vermediğinde uyarı üretmesi. İkincisi, platform bazında günlük olay sayılarının izlenmesi; tek bir platformun sayısı düşerken diğerleri sabitse, sorun sitede değil dağıtımdadır. Üçüncüsü, sunucu imajının düzenli olarak güncellenmesi — çalışan sürüm zamanla geride kalır ve periyodik yeniden başlatma öneriliyor.
Bu üç kontrolün kurulması, kurulumun kendisinden daha az zaman alır ve server-side tagging kararını geri alınabilir bir karar haline getirir. Kontrolsüz bir kurgu ise, ölçüme duyulan güveni tek bir sessiz arızayla tüketebilir; bu güven yeniden kazanılırken harcanan zaman, kurulumdan tasarruf edilen zamanın çok üstündedir.