İki Farklı İş

Bir ziyaretçi bir izin tercihi yaptığında, iki ayrı şeyin gerçekleşmesi gerekir. Birincisi, banner'ın her sayfada yeniden görünmemesi ve etiketlerin neye izinleri olduğunu bilmesi için tarayıcının tercihi hatırlaması gerekir. İkincisi, tercihin yapıldığını, ziyaretçiye ne gösterildiğini ve ne zaman olduğunu daha sonra kanıtlamanız gerekebilir. Bu işler çoğu zaman farklı depolama mekanizmalarıyla ele alınır ve bunları karıştırmak gerçek sorunlara yol açar: sürekli yeniden görünen banner'lar, bazı tarayıcılarda kaybolan tercihler veya biri sorduğunda gösterilecek bir kaydın olmaması.

Bu karşılaştırma üç yaygın seçeneğe — birinci taraf çerezler, localStorage gibi tarayıcı depolaması ve sunucu tarafı izin kayıtları — ve her birinin nereye uyduğuna bakar.

Seçenek 1: Birinci Taraf Çerezler

Çerezler izin durumunun geleneksel yuvasıdır. TCF CMP'leri izin dizesini yaygın olarak birinci taraf bir çerezde saklar ve birçok CMP kendi tercih verilerini de bir çerezde tutar.

Güçlü Yönler

• Sunucu tarafından okunabilir. Çerez her istekle gönderilir; böylece sunucu tarafı kod, uç mantığı ve sunucu tarafı etiketleme, JavaScript'i beklemeden tercihi okuyabilir.
• Alt alan adları arasında paylaşılabilir. Kayıt edilebilir alan adınızda ayarlanan bir çerez www, blog ve shop alt alan adlarını kapsayabilir.
• Yaygın olarak beklenir. Birçok reklam teknolojisi entegrasyonu izni çerezlerde arar.

Zayıf Yönler

• Boyut sınırları. Tarayıcılar çerez boyutunu yaklaşık 4 KB ile sınırlar ve çok sayıda tedarikçi içeren bir TCF dizesi artı diğer değerler bu sınıra yaklaşabilir.
• İstek yükü. Alan adınıza yapılan her istek, görüntü ve komut dosyası istekleri dahil, çerezi taşır.
• Bazı tarayıcılarda ömür sınırları. Safari'nin Intelligent Tracking Prevention özelliği, JavaScript ile oluşturulan çerezleri en fazla yedi günlük bir ömürle sınırlar. Kendi sunucunuzun bir HTTP yanıtında ayarladığı çerezlere genellikle daha cömert davranılır, ancak istisnalar vardır.

Seçenek 2: localStorage ve Diğer Tarayıcı Depolaması

Bazı CMP'ler ayrıntılı tercihleri localStorage'da, bazen daha küçük bir çerezin yanında saklar.

Güçlü Yönler

• Daha fazla alan. Köken başına birkaç megabayt; tedarikçi düzeyinde ayrıntılı tercihler için yeterli.
• İstek yükü yok. Sunucuya otomatik olarak hiçbir şey gönderilmez.

Zayıf Yönler

• Sunucu tarafından görülemez. Sunucu tarafı kod ve uç mantığı onu okuyamaz; bu yüzden sunucu tarafındaki her karar tarayıcıyı beklemek zorundadır.
• Tek bir kökene bağlı. www.example.com üzerindeki depolama shop.example.com üzerinde kullanılamaz; bu yüzden bir ziyaretçi banner'ı her alt alan adında yeniden görebilir.
• Silinmeye tabi. Safari, kullanıcının yedi günlük tarayıcı kullanımı boyunca etkileşim kurmadığı siteler için localStorage dahil komut dosyasıyla yazılabilir depolamayı kaldırabilir ve gizli göz atma modları genellikle oturum bittiğinde onu temizler.

Seçenek 3: Sunucu Tarafı İzin Kayıtları

Sunucu tarafı kayıt, bir tercih yapıldığında sizin veya CMP sağlayıcınızın sakladığı bir girdidir. Genellikle takma adlı bir tanımlayıcı, zaman damgası, tercihler, gösterilen banner veya politika sürümü ve bölge gibi bağlamı içerir.

Güçlü Yönler

• Kalıcı kanıt. Çerez temizlemeden ve tarayıcı kısıtlamalarından etkilenmez; bu da iznin alındığını göstermek için doğru araç olmasını sağlar.
• Denetlenebilir. Tercihleri zaman içinde raporlayabilir ve belirli olaylar hakkındaki sorulara yanıt verebilirsiniz.
• Cihazlar arası potansiyel. Oturum açmış okurlar için sunucu kaydı, bunu onlara açıklarsanız, tercihleri cihazlar arasında senkronize edebilir.

Zayıf Yönler

• Yerel durumun yerine geçmez. Tarayıcıdaki etiketlerin yine de hızlı, yerel bir sinyale ihtiyacı vardır; izni aramak için her sayfa görüntülemede sunucuyu çağırmak gecikme ekler.
• Kendisi kişisel veridir. Kayıtların bir saklama süresine, erişim kontrollerine ve gizlilik bildiriminizde bir yere ihtiyacı vardır.
• Tanımlayıcı bağımlılığı. Anonim ziyaretçiler bir kayıtla yalnızca cihazlarında saklanan bir tanımlayıcı aracılığıyla eşleştirilebilir; bu da sizi yerel depolamaya geri getirir.

Yan Yana Özet

• Webde tercihi hatırlamak için en iyisi: birinci taraf çerezler, ideal olarak kararlı bir ömür için sunucunuz tarafından ayarlananlar.
• Tarayıcıda ayrıntılı tercih verileri için en iyisi: localStorage, sunucunun okuyabileceği bir çerezle eşleştirilmiş.
• Tercihi kanıtlamak için en iyisi: sunucu tarafı kayıtlar.
• Tek başına en kötü seçim: yalnızca localStorage'a güvenmek; bu, sunucuyu kör bırakır ve tercihi bazı tarayıcılarda kırılgan yapar.

Pratik Bir Birleşik Yaklaşım

1. Yetkili yerel sinyali — örneğin TCF dizesini ve kompakt bir tercih kaydını — kayıt edilebilir alan adınızla sınırlı birinci taraf bir çerezde saklayın.
2. localStorage'ı yalnızca sunucuya ulaşması gerekmeyen tamamlayıcı veriler için kullanın.
3. Gösterilen banner ve politika sürümü dahil her tercih için bir sunucu tarafı kayıt yazın.
4. Saklanan bir tercih kaybolursa, önceki bir yanıtı varsaymak yerine banner'ı yeniden gösterin.
5. Saklanan tercihler için bir yeniden sorma süresi belirleyin ve bunu politikanıza kaydedin.

Ziyaretçinin izin tercihinin kendisini saklamak, genellikle ziyaretçinin istediği hizmeti sunmak için gerekli kabul edilir — kararını hatırlamak — ancak ana pazarlarınızda geçerli olan rehberliği kontrol edin.

Önemli Çıkarımlar

• Bir tercihi hatırlamak ile kanıtlamak, farklı depolama gerektiren farklı işlerdir.
• Çerezler sunucu tarafından okunabilir ve alt alan adları arasında paylaşılabilir, ancak boyutları ve Safari'de komut dosyasıyla ayarlandıklarında ömürleri sınırlıdır.
• localStorage alan sunar ancak sunucuya görünmezdir ve tarayıcılar tarafından temizlenebilir.
• Sunucu tarafı kayıtlar kanıt katmanıdır, yerel sinyalin yerine geçmez.
• Sunucu tarafından ayarlanan birinci taraf bir çerezi, isteğe bağlı tarayıcı depolamasını ve sunucu kayıtlarını birleştirin.