Chrome, üçüncü taraf çerezleriyle ilgili kullanıcı tercihine yönelik yeni bir deneyim öneriyor. Sitenizi, üçüncü taraf çerezleri olmadan gezinmeyi tercih eden kullanıcılar için hazırlamanız gerekir.
Bu sayfada, yaklaşan değişikliklerden hangilerinin etkilenebileceği hakkında bilgiler yer almaktadır.
Sık kullanılan kullanıcı yolculukları
Birçok ödeme ve alışveriş iş akışı, üçüncü taraf çerezlerinden yararlanır. Aşağıdaki tabloda, üçüncü taraf çerezleri devre dışı bırakılırsa etkilenebilecek bazı kullanıcı yolculukları listelenmiştir ve geliştiricilerin kesintileri önlemek için kullanabileceği alternatif API'ler önerilmektedir. Bu liste tam kapsamlı olmayabilir ve daha fazla Özel Korumalı Alan çözümü kullanıma sunulduğunda güncellenebilir. Etkilenen başka senaryolarla karşılaşırsanız geri bildiriminizi paylaşmanızı öneririz.
Ödemelerle ilgili kullanıcı yolculuklarınızı test etme
Kullanıcı akışlarınızın üçüncü taraf çerez kısıtlamalarından etkilenip etkilenmediğini test etmenin en iyi yolu, üçüncü taraf çerez testi işareti etkinken bu akışları incelemektir.
Web sitenizin beklendiği gibi çalıştığından emin olmak için aşağıdaki akışı üçüncü taraf çerezleri kısıtlanmış şekilde test edin:
- Siteler arası ödeme: Üçüncü taraf ödeme sağlayıcıya (ör. <example-provider> ile Öde) dayalı ödeme akışlarını test edin. Aşağıdakilerden emin olun:
- Yönlendirme başarıyla gerçekleşir.
- Ödeme ağ geçidi doğru şekilde yüklenir.
- Ödeme işlemi hatasız şekilde tamamlanabilir.
- Kullanıcı, beklendiği gibi web sitenize geri yönlendirilir.
- Ödeme kontrol panelleri: Üçüncü taraf çerezleri kısıtlandığında işlem kontrol paneli widget'larının beklendiği gibi çalışıp çalışmadığını test edin. Kullanıcının şunları yapabileceğini doğrulayın:
- Kontrol paneline erişin.
- Tüm ödemelerin beklendiği gibi yapıldığını görebilirsiniz.
- Kontrol panelinin farklı bölümleri (ör. işlem geçmişi, ödeme ayrıntıları) arasında hatasız şekilde gezinme
- Ödeme yöntemlerini yönet: Ödeme yöntemi yönetimi widget'larının beklendiği gibi çalışıp çalışmadığını test edin. Üçüncü taraf çerezleri engellendiğinde aşağıdakileri test edin:
- Ödeme yöntemi ekleme veya silme işlemi beklendiği gibi çalışıyor.
- Daha önce kaydedilmiş ödeme yöntemleriyle yapılan ödemeler bu değişiklikten etkilenmez.
- Dolandırıcılık algılama: Dolandırıcılık algılama çözümünüzün üçüncü taraf çerezleri ile ve olmadan nasıl çalıştığını karşılaştırın.
- Üçüncü taraf çerezlerini engellemek, ek adımlara neden olarak kullanıcı deneyimini olumsuz yönde etkiliyor mu?
- Tarayıcıda üçüncü taraf çerezleri engellendiğinde şüpheli kalıpları yine de algılayabilir mi?
- Kişiselleştirilmiş ödeme düğmesi: Üçüncü taraf çerezleri kısıtlandığında ödeme düğmelerinin doğru şekilde oluşturulup oluşturulmadığını test edin.
- Kişiselleştirilmiş düğmede tercih edilen yöntem gösterilmese bile kullanıcı satın alma işlemini tamamlayabilir mi?
Siteler arası ödemeler
Bazı ödeme sağlayıcılar, kullanıcıların yeniden kimlik doğrulaması yapmadan birden fazla satıcı sitesinde hesaplarına erişmesine izin vermek için üçüncü taraf çerezlerinden yararlanabilir. Bu kullanıcı yolculuğu, üçüncü taraf çerezleri olmadan gezinmeyi seçenler için etkilenebilir.
Yerleştirilmiş ödeme formları
Aşağıdaki alanları göz önünde bulundurun:
payment-provider.example
, satıcı sitelerine ödeme hizmetleri sağlar ve kullanıcı ödeme ve oturum verilerini saklar.merchant.example
,payment-provider.example
tarafından sağlanan bir ödeme formu yerleştiren bir web sitesidir.
Kullanıcı payment-provider.example
'e yeni giriş yaptı (örneğin, başka bir sitede ödeme işlemini tamamlarken). Kullanıcı, merchant.example
'te ödeme işlemi başlatır.
Üçüncü taraf çerezleri kullanılabilir durumdayken merchant.example
'a yerleştirilmiş payment-provider.example
ödeme formu, üst düzey bağlamda payment-provider.example
'te ayarlanan kendi üst düzey oturum çerezine erişebilir.
Ancak üçüncü taraf çerezleri engellenirse yerleşik öğe kendi üst düzey çerezlerine erişemez.

FedCM ile özelleştirilebilir bir çözüm
payment-provider.example
, kimlik sağlayıcı olarak hareket etmek için FedCM'yi uygulamayı düşünmelidir. Bu yaklaşım, aşağıdaki durumlarda uygun olabilir:
payment-provider.example
, alakasız üçüncü taraf sitelere yerleştirilmiştir.payment-provider.example
, beşten fazla ilgili siteye yerleştirilmiş.
FedCM'nin en önemli avantajı, kullanıcı arayüzünün kullanıcılara seçimleriyle ilgili daha fazla bağlam bilgisi sunabilmesidir. FedCM, kullanıcı izniyle güvenen taraf (merchant.example
) ile kimlik sağlayıcı (payment-provider.example
) arasında özel verilerin paylaşılmasına olanak tanır. Güvenen taraf, bir veya daha fazla kimlik sağlayıcıyı desteklemeyi seçebilir ve FedCM kullanıcı arayüzü yalnızca koşullu olarak görüntülenir.
Geliştiriciler, ihtiyaçlara bağlı olarak FedCM istemi kullanıcı kimlik sağlayıcısıyla oturum açtığında otomatik olarak görünmesi için pasif modu veya kullanıcının ödeme düğmesini tıklaması gibi bir işlemden sonra oturum açma işleminin tetiklenmesi için etkin modu seçebilir.
FedCM, Storage Access API (SAA) için güven sinyali olarak da işlev görür. Bu sayede, kullanıcı yerleşik öğenin sağlayıcısıyla oturum açmayı kabul ettikten sonra ek kullanıcı istemi gerekmeden yerleşik öğenin üst düzey bölümlenmemiş çerezlerine erişmesine izin verilir.
Depolama alanı erişimine odaklanan çözüm
Kullanabileceğiniz bir diğer API ise Storage Access API (SAA)'dir.
SAA ile kullanıcıdan, kendi üst düzey çerezlerine erişmek için payment-provider.example
embed'ine izin vermesi istenir. Kullanıcı erişimi onaylarsa form, üçüncü taraf çerezleri kullanılabilirken olduğu gibi oluşturulabilir.
FedCM'de olduğu gibi, kullanıcının payment-provider.example
'nin yerleştirildiği her yeni sitede isteği onaylaması gerekir. API'nin işleyiş şeklini anlamak için SAA demosuna göz atın.
Varsayılan SAA istemi ihtiyaçlarınıza uygun değilse daha özelleştirilmiş bir deneyim için FedCM'yi kullanmayı düşünebilirsiniz.
Az sayıda ilgili sitede kullanıcı deneyimini kolaylaştırma
Hem satıcı sitesi hem de ödeme sağlayıcı aynı şirkete aitse alanlar arasındaki ilişkileri tanımlamak için İlgili Web Sitesi Kümeleri (RWS) API'sini kullanabilirsiniz. Bu, kullanıcı deneyimini iyileştirmeye yardımcı olabilir: Örneğin, insurance.example
ve payment-portal-insurance.example
aynı RWS'deyse payment-portal-insurance.example
, payment-portal-insurance.example
yerleşiminde depolama alanı erişimi istendiğinde kendi üst düzey çerezlerine otomatik olarak erişir.
Diğer deneysel çözümler
Bu senaryoda faydalı olabilecek başka bir deneysel API de Bölünmüş Pop-up'lar'dır. API şu anda etkin bir geliştirme aşamasındadır.
Bölünmüş pop-up'larda, kullanıcıdan merchant.example
tarafından açılan bir pop-up'ta payment-provider.example
'de oturum açmak için kimlik bilgilerini girmesi istenebilir. Depolama alanı, merchant.example
tarafından bölümlenir. Bu durumda, payment-provider.example
yerleştirilen öğe, pop-up'ta ayarlanan depolama değerlerine erişebilir. Bu çözümde, kullanıcının her sitede ödeme sağlayıcıda oturum açması gerekir.
Ödeme bağlantısı ile ödeme
Bazı ödeme sağlayıcılar, satıcının sitesi için özel bir ödeme sayfası oluşturan bir ödeme bağlantısı oluşturan bir hizmet sunar. Ödeme sağlayıcı için ödeme bağlantısı hizmeti ve kullanıcı portalı genellikle farklı alanlarda (ör. payment-provider.example
ve payment-link.example
) uygulanır.
payment-link.example
, payment-provider.example
tarafından sağlanan bir ödeme formu yerleştirir. Bu, yerleşik ödeme formu modelinin bir varyasyonudur.
FedCM,
SAA
ve
RWS
bu durumda da değerlendirilebilecek iyi seçeneklerdir.
Ödeme kontrol panelleri
Bazı uygulamalar, kullanıcılarına birden fazla sitede işlem kontrol panelleri göstererek finansal etkinliklerine dair merkezi bir görünüm sunar. Bunun için kontrol panelinin birden fazla alandaki kullanıcıya özgü verilere erişmesi gerekir.
Aşağıdaki alanları göz önünde bulundurun:
earnings.example
, çeşitli web uygulamalarına yerleştirilebilecek bir ödeme kontrol paneli sağlar. Bu hizmet, kullanıcı kazanç verilerini ve oturum bilgilerini depolar.catsitting.example
vedogsitting.example
,earnings.example
kontrol panelini yerleştiren ayrı web siteleridir.
Kullanıcı earnings.example
hesabında oturum açar. Kullanıcılar catsitting.example
veya dogsitting.example
adresini ziyaret ederek kazançlarını görüntüleyebilir. Yerleşik earnings.example
kontrol paneli, üst düzey çerezleri kullanır ve kullanıcının kişiselleştirilmiş kazanç bilgilerini gösterir.
Diğer örneklerde olduğu gibi, üçüncü taraf çerezleri devre dışıyken earnings.example
yerleşimi üst düzey çerezlerine erişemez.

Birinci taraf kontrol panelleri
Üç alanın da aynı tarafa ait olduğu durumlarda RWS ile birlikte SAA kullanmayı düşünebilirsiniz.
SAA sayesinde earnings.example
, kullanıcı izniyle üst düzey çerezine erişebilir. Bu taraf, earnings.example
'yi dört veya daha az alanda kullanıyorsa RWS ile aralarındaki ilişkileri tanımlamak daha sorunsuz bir kullanıcı deneyimi sağlayabilir.
RWS yalnızca bir birincil ve beş ilişkili site olmak üzere bir sette en fazla altı siteyi desteklediğinden, aynı taraf widget'ı beşten fazla alana yerleştirirse tüm yerleşik siteler ile widget'ın alanı arasındaki ilişkileri beyan edemez.
Ölçeklendirilmiş kontrol panelleri dağıtımı
Aşağıdaki durumlarda SAA ve RWS optimum çözüm olmayabilir:
- Üçüncü taraf siteler için bir kontrol paneli çözümü dağıtırsınız.
- Kontrol paneli widget'ınızın yerleştirildiği beşten fazla siteniz varsa
Bu durumda earnings.example
, kimlik sağlayıcı olarak FedCM'yi uygulamayı düşünmelidir. Bu durumda kullanıcının earnings.example
tarafından yönetilen bir hesapla dogsitting.example
'e giriş yapması gerekir.
FedCM, kullanıcıya hangi bilgilerin paylaşıldığını net bir şekilde iletmeye yardımcı olabilecek özelleştirilebilir bir kullanıcı arayüzü sunar. FedCM ile dogsitting.example
, earnings.example
'den özel izinler paylaşmasını isteyebilir (ör. işlem verilerine erişmek için).
FedCM, Storage Access API için güven sinyali olarak da işlev görür ve earnings.example
yerleştirilmesine, SAA API çağrısında ek bir kullanıcı istemi olmadan kendi üst düzey çerezlerine depolama erişimi verilir.
Siteye özgü kontrol paneli ayarları
Verilerin birden fazla sitede paylaşılması gerekmiyorsa çerezlerinizi CHIPS ile bölümlendirebilirsiniz. CHIPS, kontrol paneli düzeni veya filtreler gibi siteye özgü tercihleri depolamak için yararlı olabilir.
Ödeme yöntemlerini yönet
Sık kullanılan bir başka akış da kullanıcının, barındıran siteden ayrılmadan ödeme yöntemlerini bir yerleşik içinde görüntülemesi ve düzenlemesidir.
Aşağıdaki akışı düşünün:
payments.example
, web sitelerine yerleştirilebilecek bir ödeme yönetimi aracı sağlar. Bu hizmet, kullanıcı ödeme verilerini ve oturum bilgilerini saklar.shop.example
, kullanıcılarınshop.example
hesaplarıyla ilişkili tercih edilen ödeme yöntemlerini görüntülemelerine, düzenlemelerine veya seçmelerine olanak tanımak içinpayments.example
aracını yerleştiren bir web sitesidir.
Ödeme yöntemleri yönetimini uygulayan ödeme sağlayıcılar, FedCM ile kimlik sağlayıcı olmayı da düşünmelidir. FedCM ile kullanıcı, kimlik sağlayıcı (payments.example
) tarafından yönetilen hesabı kullanarak güvenen tarafa (shop.example
) giriş yapabilir.
FedCM, kullanıcı izniyle güvenen taraf ile kimlik sağlayıcı arasında özel verilerin paylaşılmasına olanak tanır. FedCM'nin temel avantajı, kullanıcı arayüzünün kullanıcılara seçimleriyle ilgili daha fazla bağlam bilgisi sunabilmesidir. Ayrıca, Storage Access API için güven sinyali görevi görür. Bu sinyal, yerleşik içeriğin üst düzey çerezlerine erişmesine olanak tanır.
Üçüncü taraf çerezleri devre dışı bırakıldığında payments.example
yerleşimi, üst düzey çerezlerine erişemez. Bu durumda SAA, depolama alanı erişimi isteyerek düzgün çalışmayı sağlayabilir.
Bazen, yerleştirilen içeriğe ayarlanan bilgilerin diğer yerleştirilen sitelerle paylaşılması gerekmez. payments.example
'nin yalnızca her bir yerleşik site için farklı kullanıcı tercihlerini depolaması gerekebilir. Bu durumda, CHIPS'i kullanarak çerezleri bölümlendirmeyi düşünebilirsiniz. CHIPS ile, shop.example
'a yerleştirilmiş payments.example
içinde ayarlanan çerez, another-shop.example
'ye yerleştirilmiş payments.example
tarafından erişilemez.
Bu kullanıcı akışında kullanılabilecek başka bir deneysel API de Bölümlendirilmiş Pop-up'lar'dır.
Kullanıcı, shop.example
tarafından açılan bir pop-up'ta payments.example
'e giriş yaptığında depolama alanı, açan kullanıcı tarafından bölümlere ayrılır ve payments.example
yerleşimi, pop-up'ta ayarlanan depolama alanı değerlerine erişebilir. Ancak bu yaklaşım, kullanıcıların her sitede ödeme sağlayıcıda oturum açmak için kimlik bilgilerini girmesini gerektirir.
Sahtekarlık algılama
Risk analizi sistemleri, normalden farklı olan kalıpları belirlemek için çerezlerde depolanan verileri analiz edebilir. Örneğin, bir kullanıcı aniden gönderim adresini değiştirir ve yeni bir cihaz kullanarak birkaç büyük satın alma işlemi yaparsa olası sahtekarlık puanı artabilir. Sahtekarlık algılama çerezleri genellikle ödeme sağlayıcılar veya sahtekarlık önleme hizmetleri widget'ları tarafından satıcı sitelerinde ayarlanan üçüncü taraf çerezleridir.
Üçüncü taraf çerez kısıtlamaları, sahtekarlık algılama sistemlerini etkilemese de kullanıcılar için ek zorluklar oluşturabilir. Sistem, engellenen çerezler nedeniyle kullanıcının meşru olduğunu güvenle doğrulayamazsa kimlik doğrulamasının tamamlanması gibi ek kontroller gerekebilir.
Üçüncü taraf çerezleri engellendiğinde sahtekarlığı algılamayı desteklemek için Gizlilik Jetonları (PST) API'sini sahtekarlığı algılama çözümünüze entegre edebilirsiniz. PST ile ödeme sağlayıcılar jeton veren olarak kaydolabilir ve kullanıcılara üçüncü taraf çerezlerine dayanmayan jetonlar verebilir. Bu jetonlar daha sonra satıcı sitelerinde kullanılarak kullanıcının güvenilir olup olmadığı kontrol edilebilir. Uygulama ayrıntıları için PST geliştirici belgelerine bakın.
Özel Korumalı Alan, diğer sahtekarlık önleme API'leriyle de denemeler yapmaktadır.
Kişiselleştirilmiş ödeme düğmesi
Satıcı sitelerine yerleştirilmiş ödeme düğmeleri (ör. <tercih edilen ödeme yöntemiyle> öde), genellikle ödeme sağlayıcı tarafından ayarlanan siteler arası bilgilere dayanır. Bu sayede kişiselleştirme yapılabilir ve kullanıcılar tercih ettikleri ödeme yöntemiyle sorunsuz bir şekilde ödeme yapabilir. Kullanıcının tarayıcısında üçüncü taraf çerezleri engellenmişse bu durum kişiselleştirilmiş ödeme düğmesinin oluşturulmasını etkileyebilir.
SAA, depolama alanına erişim sağlayabilir ancak istenen istem, ideal bir kullanıcı deneyimi sunmayabilir.
Özellikle bu kullanım alanını hedefleyen potansiyel bir çözümü araştırıyoruz: Bölünmemiş yerel verilere erişimi olan çitli çerçeveler. API şu anda aktif bir geliştirme aşamasındadır ve geleceğini siz şekillendirebilirsiniz. Siz de deneyip geri bildirim gönderin.
Yardım alın
Karşılaştığınız kesintileri goo.gle/report-3pc-broken adresine bildirin. Ayrıca geri bildirim formu gönderebilir veya Privacy Sandbox geliştirici destek deposunda GitHub'da sorun bildirebilirsiniz.