Safari, Sunucu Tarafı Etiketlemenizi (Server-Side Tagging) Baltalıyor mu?

Dijital pazarlama dünyasında son iki yılın en büyük "kurtarıcısı" olarak lanse edilen teknoloji şüphesiz Sunucu Tarafı Etiketleme (Server-Side Tagging - SST) oldu. Üçüncü taraf çerezlerin (third-party cookies) yok oluşu, reklam engelleyicilerin yükselişi ve iOS güncellemeleri karşısında, veriyi kullanıcının tarayıcısından değil, kendi sunucumuzdan göndermek, veri kaybını önlemenin "kesin çözümü" olarak görüldü.

Peki sizlere, yaptığınız o pahalı ve zahmetli Sunucu Tarafı GTM kurulumunun, Safari tarafından "standart bir kurulum" yaptıysanız neredeyse tamamen etkisiz hale getirildiğini söylesek?

Apple’ın Safari tarayıcısı ve onun arkasındaki WebKit motoru, sadece çerezleri engellemekle kalmıyor. Artık sunucu tarafı etiketleme yapılarını da aktif olarak tespit edip baltalıyor.

1. Yanılgı: "Sunucu Tarafına Geçtik, Artık Güvendeyiz"

Pazarlama ekiplerinin çoğu şu varsayımla hareket ediyor: "Veriyi kendi alt alan adımızdan (örn: metrics.siteadi.com) topladığımız için, tarayıcılar bunu 'birinci taraf' (first-party) veri olarak görür ve dokunmaz."

Teorik olarak doğru olması gereken bu varsayım, Apple mühendislerinin ITP algoritmalarını güncellemesiyle geçerliliğini yitirdi. Safari artık bir çerezin "kimden" geldiğine bakarken sadece alan adına güvenmiyor. Ağ seviyesinde (Network Layer) analizler yaparak, o sunucunun gerçekten size mi ait olduğunu, yoksa sadece maskelenmiş bir izleme sunucusu mu olduğunu sorguluyor.

Eğer Safari, sunucu tarafı kurulumunuzu bir "izleme aracı" olarak işaretlerse (ki standart kurulumlarda bunu çok hızlı yapar), çerezlerinizi 7 gün, hatta bazı durumlarda 24 saat sonra siliyor.

Bu durumun pazarlama kararlarına etkisi yıkıcıdır:

• Yanlış Attribution (İlişkilendirme): Pazartesi günü reklama tıklayıp siteye gelen, ancak Çarşamba günü satın alan bir kullanıcıyı "Organik Trafik" olarak görürsünüz.
• Düşük ROAS: Reklam platformları (Google Ads, Meta), dönüşümleri kendi kampanyalarıyla eşleştiremez.
• Kayıp LTV (Yaşam Boyu Değer): Sadık müşterileriniz, her hafta siteye geldiklerinde "Yeni Kullanıcı" olarak sayılır.

2. Safari Etiketlemenizi Nasıl Tespit Ediyor?

Safari'nin sunucu tarafı etiketlemeyi baltalamak için kullandığı üç ana silahı vardır. Bu üç nokta genellikle gözden kaçırılıyor.

A. IP Adresi Uyuşmazlığı (The IP Mismatch)

Bu, en sık karşılaşılan ve en az bilinen tuzaktır.

Web siteniz (www.siteadi.com) örneğin Amazon AWS sunucularında barınıyor. Ancak Sunucu Tarafı GTM konteyneriniz (sgtm.siteadi.com) genellikle Google Cloud ya da farklı bir altyapı üzerinde çalışıyor olsun.

Safari'nin bakış açısı "Bir dakika, bu iki alan adı birbirine aitmiş gibi görünüyor ama biri Amazon'un IP bloğundan, diğeri Google'ın IP bloğundan yayın yapıyor. Bu şüpheli."

Bu durumda, Safari, sgtm sunucunuzdan gelen çerezleri "birinci taraf" olarak kabul etse bile, IP blokları eşleşmediği için çerez ömrünü 7 güne indirir. Ve bu nedenle 1-2 yıllık çerez hayalleri suya düşer.

B. CNAME Gizlemesi (Cloaking) Tespiti

Bazı pazarlamacılar, üçüncü taraf izleme araçlarını (örneğin Oracle veya Adobe sunucularını) kendi alt alan adları gibi göstermek için DNS yönlendirmesi (CNAME) kullanır.

Safari, DNS sorgusunun köküne iner. Eğer arka planda bu yönlendirmenin bilinen bir reklam teknolojisi firmasına gittiğini görürse, bunu "CNAME Cloaking bir izleyici" olarak işaretler.

Bu durumda, Safari, çerez ömrünü yine 7 gün ile sınırlayacaktır.

C. Link İzleme Koruması (Link Tracking Protection - LTP)

Belki de en tehlikeli olanı budur çünkü sunucuya veri gitmeden önce devreye girer. iOS 17 ile birlikte Safari; Mail, Mesajlar ve "Özel Gezinme" modunda (yakında tüm modlarda olması bekleniyor) URL'lerin sonundaki reklam parametrelerini siliyor.

Kullanıcı siteadi.com?gclid=123xyz adresine tıklar. Safari, gclid=123xyz kısmını siler ve siteyi siteadi.com olarak açar.

Bu durumda, sunucunuz ne kadar mükemmel olursa olsun, gclid parametresi sunucuya hiç ulaşmadığı için Google Ads dönüşümü eşleştiremez. Aynı şekilde Facebook CAPI, fbc verisini oluşturamaz.

3. Pazarlama Metriklerine "Matematiksel" Darbe

Safari'nin bu kısıtlamaları sadece teknik bir detay değildir. Pazarlama bütçenizin verimliliğini doğrudan etkileyen finansal bir sorun haline geliyor.

Senaryo: Bir kullanıcı Instagram reklamınıza tıklar (Pazartesi). Sitenizi inceler, çıkar. Karar verme süreci 3 gün sürer. Perşembe günü tekrar gelir ve satın alır.

Standart (Kısıtlanmış) Senaryo: Safari, bağlantı dekorasyonu (reklam tıklaması) olduğu ve IP uyuşmazlığı tespit ettiği için çerezi 24 saat sonra silmiştir. Perşembe günü gelen kullanıcı "Yeni ve Organik" bir kullanıcıdır. Instagram bu satışı raporlayamaz. Siz de "Instagram çalışmıyor, bütçeyi kısalım" dersiniz. Oysa satış oradan gelmiştir.

Araştırmalar, Safari trafiğindeki dönüşümlerin %13 ile %40'ının, ITP kısıtlamaları nedeniyle yanlış raporlandığını veya kaybolduğunu göstermektedir.

4. Çözüm Stratejileri: Safari'yi Kendi Oyununda Yenmek

Peki, bu engellemeler sonucu havlu mu atacağız? Kesinlikle hayır. Safari'nin bu önlemlerini aşmak ve veriyi kurtarmak için "Standart Kurulum"dan "Gelişmiş Mühendislik Kurulumuna" geçmeniz gerekiyor.

1. Cloudflare Proxy veya Load Balancer Kullanımı

Safari'nin "IP Uyuşmazlığı" kuralını aşmanın en etkili yolu, hem web sitenizi hem de etiketleme sunucunuzu (sGTM) aynı IP bloğu arkasına gizlemektir.

Örneğin, Cloudflare gibi bir CDN kullanarak, her iki sunucunun da dış dünyaya aynı IP adresinden yayın yapmasını sağlamak. Safari, iki sunucuyu ayırt edemez ve çerezlere uyguladığı 7 gün kısıtlamasını kaldırır. Çerezleriniz 2 yıla kadar yaşayabilir.

2. "Same-Origin" (Aynı Köken) Yapısına Geçiş

Alt alan adı (metrics.siteadi.com) kullanmak yerine, etiketleme sunucusunu ana sitenizin bir alt klasörü (siteadi.com/metrics) gibi çalıştırmak en güvenli yoldur.

Sunucu tarafında "Reverse Proxy" kuralları yazarak trafiği yönlendirmek. Bu durum tarayıcı için bu işlem tamamen site içi bir trafik olduğu için CNAME ve IP kontrollerinin tamamını bypass eder. %100 birinci taraf veri akışı sağlanır.

3. "Yedek Parametre" (Decoy Parameter) Stratejisi

Link Tracking Protection (LTP) gclid veya fbclid parametrelerini siliyor demiştik. Çözüm, bu parametreleri Safari'nin tanımadığı bir isimle maskelemektir.

Örneğin, Google Ads ve Meta ayarlarında URL sonuna ?c_id={gclid} gibi, Safari'nin "zararsız" sanacağı bir yedek parametre ekleyin. Safari gclid'yi silse bile, c_id parametresi sunucuya ulaşır. Sunucu tarafında bu parametreyi tekrar gclid olarak işleyip Google'a gönderirsiniz. Attribution kurtarılır.

4. Custom Loader (Özel Yükleyici)

gtm.js veya analytics.js gibi dosya isimleri, reklam engelleyicilerin kara listesindedir. Bu scriptleri sunucudan çağırırken isimlerini rastgele karakterlerle (örn: x9k3m.js) değiştiren bir "Custom Loader" kullanmak. Böylece veri toplama oranınız %30-%40 civarında artar çünkü AdBlocker kullanan kitleyi de ölçümlemeye başlarsınız.

5. Veri Kalitesi Yeni Rekabet Avantajıdır

"Safari sunucu tarafı etiketlemeyi baltalıyor mu?" sorusunun cevabı; eğer kutudan çıktığı haliyle kullanıyorsanız EVET.

Ancak dijital pazarlama artık sadece reklam paneli yönetmek değil, veri mimarlığı yönetmektir. Rakipleriniz Safari trafiğindeki dönüşümleri göremezken ve algoritmaları yanlış sinyallerle beslenirken, sizler yukarıda bahsettiğimiz optimizasyonları yaptığınızda, algoritmaları (Google Smart Bidding, Meta Advantage+) daha kaliteli ve uzun vadeli verilerle besleyebileceksiniz.

Son Olarak Sizlere Aksiyon Planı Önerimiz:

• Analytics verilerinizde "Direct / None" trafiğinin Safari özelinde artıp artmadığını kontrol edin.
• Teknik ekibinize sGTM kurulumunun "IP eşleşmesi" ve "Same-origin" prensiplerine uygun olup olmadığını sorun.
• URL parametrelerinizi korumak için "Yedek Parametre" (Decoy) stratejisini devreye alın.