Sunucu taraflı etiketleme nedir ve nasıl kurulur

Sunucu taraflı etiketleme, ölçüm etiketlerinizi ziyaretçinin tarayıcısında çalıştırmak yerine sizin kontrolünüzdeki bir sunucuda çalıştırma yöntemidir. Tarayıcı tek bir istek gönderir, o istek sizin alan adınız altındaki bir kapsayıcıya düşer, veriyi Meta'ya, Google'a veya analitik aracınıza oradan siz iletirsiniz. Bu yazı kavramı tanıtmakla yetinmiyor: barındırmayı nerede yapacağınızı, kendi alan adınız altında çalıştırmanın neyi değiştirdiğini, çerez ömrü meselesini, maliyetin nasıl hesaplanacağını ve hangi hesap büyüklüğünde bu işe hiç girmemenin daha doğru olduğunu anlatıyor.

Tarayıcı tarafındaki ölçüm neden yetmiyor

Sayfaya yerleştirdiğiniz ölçüm kodu, çalışmak için ziyaretçinin tarayıcısına bağımlıdır. O tarayıcıda bir reklam engelleyici varsa istek hiç çıkmaz. Tarayıcının kendi izleme koruması dışarıdaki alan adlarına giden istekleri kısıtlıyorsa istek çıkar ama karşılığı kalıcı olmaz. Ağ koptuğunda, kullanıcı sayfayı erken kapattığında veya cihaz yavaş olduğunda olay yarım kalır. Bunların hiçbiri sizin kurulum hatanız değildir, ortamın kendisi böyledir.

Sunucu tarafı bu bağımlılığı ikiye böler. Tarayıcı yalnızca tek bir işi yapar: kendi alan adınıza tek bir istek gönderir. Geri kalan her şey, yani hangi platforma hangi olayın hangi alanlarla gideceği, sizin sunucunuzda olur. Tarayıcı tarafındaki kurulumu yine de bilmeniz gerekir; Meta Pixel'in temel mantığını anlamadan sunucu katmanına geçmek, bozuk bir kurulumu daha pahalı bir yere taşımaktan başka işe yaramaz.

Sunucu taraflı etiketleme hangi parçalardan oluşur

Üç parça var. Birincisi sayfada duran ve isteği toplayan istemci: bu genelde mevcut web kapsayıcınızdır, tek farkı veriyi doğrudan platformlara değil sizin uç noktanıza göndermesidir. İkincisi sunucu kapsayıcısının kendisi: gelen isteği tanıyan ve standart bir olay biçimine çeviren bir uygulama. Üçüncüsü o olayı ilgili platforma ileten etiketler.

Atlanan bir nokta şu: sunucu kapsayıcısı bir veri deposu değildir. Gelen isteği alır, dönüştürür, gönderir ve unutur. Kalıcı kayıt istiyorsanız onu ayrıca kurmanız gerekir. Bu yapı aynı satın almanın hem tarayıcıdan hem sunucudan gitmesi durumunda çift sayım riski doğurur; tekilleştirme olay kimliği eşleştirmesiyle çözülen ayrı bir konudur ve burada ayrıntısına girmiyorum.

Barındırma seçenekleri ve hangisi kime uyar

Sunucu kapsayıcısı bir yerde çalışmak zorunda. Bu "bir yer" kararı işin en çok atlanan ve sonradan en pahalıya patlayan kısmı.

Sağlayıcının otomatik kurulumu

Google'ın kendi kurulum akışı, sunucu kapsayıcınızı kendi bulut altyapısında otomatik olarak ayağa kaldırır. En hızlı yol budur ve kendi sunucu yönetiminizi gerektirmez. Karşılığında altyapı faturası doğrudan size gelir ve ölçek ayarlarını izlemek sizde kalır. Güncel fiyatlandırmayı sağlayıcının kendi belgelerinden kontrol edin, bu rakamlar zamanla değişiyor.

Yönetilen üçüncü taraf barındırma

Aylık abonelikle sunucu kapsayıcınızı sizin adınıza çalıştıran hizmetler var. Avantajı ölçeklemeyi, güncellemeyi ve izlemeyi devretmeniz. Değerlendirirken şu dört şeye bakın: verinin hangi ülkede işlendiği, sözleşmede veri işleyen sıfatının nasıl tanımlandığı, istek hacmi arttığında fiyatın nasıl değiştiği ve hizmet kesildiğinde ölçümünüzün ne olacağı.

Kendi altyapınızda çalıştırma

Kapsayıcıyı kendi bulut hesabınızda ya da kendi sunucunuzda çalıştırabilirsiniz. Maliyet üzerinde en fazla kontrolü bu verir ama sürekli bir sahibi olmasını gerektirir: sürüm güncellemeleri, sertifika yenilemeleri, kapasite planı ve uyarı kurulumu sizdedir. İçeride bunu üstlenecek biri yoksa bu seçenek en ucuz görünüp en pahalı biten yoldur.

Kendi alan adınız altında çalıştırmak

Sunucu kapsayıcısı sağlayıcının verdiği rastgele bir adreste de çalışabilir, ama işin asıl faydası onu kendi alan adınızın altına aldığınızda ortaya çıkar. Pratikte bu, ölçüm isteklerini karşılayacak bir alt alan adı tanımlamak demek: DNS tarafında kayıt açıp sertifika bağlıyorsunuz.

Neden önemli? Çünkü tarayıcılar bir isteğin birinci taraf mı yoksa dışarıdan mı olduğuna alan adına bakarak karar verir. İstek sitenizle aynı kök alan adı altındaysa birinci taraf muamelesi görür. Farklı bir kök altındaysa, adı ne olursa olsun görmez. Bu yüzden alt alan adının hangi kök altında durduğu, kurulumun teknik ayrıntısı değil kurulumun ta kendisidir.

Burada bir tuzak var: alt alan adını başka bir sağlayıcıya yönlendirdiğinizde tarayıcılar bunu tespit edebiliyor ve o alt alan adından yazılan çerezlere ayrı bir kural uygulayabiliyor. Apple'ın WebKit ekibi bu konuda kendi belgelerinde ayrı bir politika tanımladı. Kurulum kararını vermeden önce hedef tarayıcıların güncel politikasını resmî kaynaktan doğrulayın; bu alan sık değişiyor ve iki yıl önceki bir blog yazısına göre kurulan yapı bugün beklediğiniz gibi çalışmayabilir.

Çerez ömrü tam olarak neyi çözüyor

Sunucu tarafına geçmenin en somut teknik kazancı çerez ömründedir. Sayfada çalışan JavaScript ile yazılan birinci taraf çerezlerinin ömrü bazı tarayıcılarda birkaç günle sınırlanır. Bu sınır, ziyaretçi ilk gelişinde tanımlanan kimliğin, aynı kişi iki hafta sonra dönüp satın aldığında hâlâ duruyor olmasını engeller. Karar süresi uzun olan işlerde bu, gelirin ilk temasla ilişkilendirilememesi anlamına gelir.

Sunucudan HTTP başlığıyla yazılan çerezler bu sınıra aynı biçimde tabi değildir. Kapsayıcınız kendi alan adınız altında çalışırken çerezi tarayıcıdaki koda değil sunucuya yazdırırsınız ve ömrünü siz belirlersiniz. Kesin gün sınırları tarayıcıdan tarayıcıya ve sürümden sürüme değiştiği için buraya bir rakam yazmıyorum; WebKit ve kullandığınız diğer tarayıcıların kendi yayımladığı belgelerden güncel değeri kendiniz doğrulayın.

Neyi çözmediğini de söyleyeyim. Çerez ömrünün uzaması, kullanıcı onay vermediyse veri toplama hakkı yaratmaz; onay yönetimi bağımsız bir katmandır ve sunucu tarafına geçmek onu atlamanın yolu değildir. Cihazlar arası kopukluğu da çözmez: masaüstünde görüp telefonda satın alan kişi hâlâ iki ayrı kimliktir.

Maliyeti hesaplayın, sonra karar verin

Bu kurulumun bir aylık toplam maliyeti vardır: barındırma faturası, varsa abonelik ve bakıma ayırdığınız zaman. Aşağıdaki hesapta bu toplamı aylık 1.500 TL kabul ediyorum. Rakam sizin aldığınız tekliflerle değişir, önemli olan yöntem.

Bir kere yıllığa çevirelim: 1.500 × 12 = 18.000 TL. Bundan sonraki bütün hesapları aylık tutuyorum.

Bu maliyetin kendini ödemesi için ne kadar ek ciro gerekir? Katkı marjınız %30 ise her 100 TL ek cironun 30 TL'si size kalır. O hâlde 1.500 TL'yi karşılamak için 1.500 ÷ 0,30 = 5.000 TL ek aylık ciro gerekir.

Şimdi bu 5.000 TL'yi iki farklı hesap büyüklüğüne oranlayın. Aylık 50.000 TL harcayan ve ROAS'ı 4 olan bir hesap ayda 50.000 × 4 = 200.000 TL ciro üretir; gereken iyileşme 5.000 ÷ 200.000 = 0,025, yani %2,5. Aynı ROAS ile aylık 300.000 TL harcayan bir hesap ayda 300.000 × 4 = 1.200.000 TL ciro üretir; gereken iyileşme 5.000 ÷ 1.200.000 ≈ 0,0042, yani yaklaşık %0,4. Harcama altı katına çıkınca eşik de yaklaşık altıda birine iniyor.

Kendi ROAS'ınızı ROAS hesaplayıcısıyla çıkarıp aynı işlemi kendi marjınızla tekrarlayın. Çıkan yüzde küçükse karar kolaydır. Ama %2,5 civarında veya üstünde bir iyileşme gerekiyorsa dürüst cevap şudur: sunucu tarafına geçmenin size bu kadar iyileşme getireceğini kimse taahhüt edemez. O bütçeyi önce kreatif üretimine, açılış sayfasına veya mevcut kurulumun onarımına koymak daha savunulabilir bir karardır. Küçük harcamalı hesaplarda bu katmanı atlamak eksiklik değil, doğru sıralamadır.

Kurmadan önce şu sırayı izleyin

• Mevcut kurulumu onarın. Tarayıcı tarafında eksik veya yanlış tetiklenen olaylar sunucuya taşındığında düzelmez, sadece yer değiştirir. Piksel verilerinin neden yanlış geldiğini önce orada çözün.
• Taban çizginizi yazın. Geçişten önceki bir aylık dönüşüm sayısını, olay eşleşme kalitesini ve panel ile mağaza raporu arasındaki farkı kaydedin. Bu kayıt yoksa geçişin işe yarayıp yaramadığını sonradan söyleyemezsiniz.
• Alan adı kararını önce verin. Hangi alt alan adını kullanacağınız, DNS'e kimin eriştiği ve sertifikayı kimin yenileyeceği kurulumdan önce netleşmeli.
• Onay altyapısını ayrı tutun. Sunucu tarafı, kullanıcı onayı olmadan veri işleme sorununu çözmez; onay yönetimi bağımsız olarak ayakta durmalıdır.
• Sahibini belirleyin. Bu katman sessizce bozulur ve panelde kırmızı bir uyarı çıkmaz. Düzenli olarak bakacak biri yoksa kurmayın.

Sunucu tarafı ölçüm sihirli bir düzeltme değil, ölçüm altyapısının kontrolünü tarayıcıdan alıp kendi tarafınıza taşıyan bir mühendislik kararıdır. Karşılığında daha temiz ve daha uzun ömürlü bir sinyal alırsınız; o sinyal de yapay zekâ destekli hedefleme tarafında verdiğiniz her kararın girdisidir. Girdinin kalitesi kadar, o girdiyi ayakta tutacak bir sahibinin olması da gerekir.