Özel Korumalı Alan teklifleri ve Chrome'un yanıtı hakkında alınan ekosistem geri bildirimlerini özetleyen 2024 1. çeyrek için üç aylık rapor.
Google, CMA'ya verdiği taahhütler kapsamında, Özel Korumalı Alan teklifleriyle ilgili paydaş etkileşim süreciyle ilgili üç aylık raporları herkese açık olarak yayınlamayı kabul etmiştir (Taahhütler'in 12. ve 17(c)(ii) paragraflarına bakın). Bu Gizlilik Korumalı Alan geri bildirim özet raporları, Chrome'un geri bildirime genel bakış bölümünde listelenen çeşitli kaynaklardan aldığı geri bildirimler (GitHub Issues, privacysandbox.com adresinde kullanıma sunulan geri bildirim formu, sektör paydaşlarıyla yapılan toplantılar ve web standartları forumları dahil ancak bunlarla sınırlı olmamak üzere) toplanarak oluşturulur. Chrome, ekosistemden gelen geri bildirimleri memnuniyetle karşılar ve edinilen bilgileri tasarım kararlarına entegre etmenin yollarını etkin bir şekilde araştırır.
Geri bildirim temaları, API başına yaygınlığa göre sıralanır. Bu işlem, Chrome ekibinin belirli bir temayla ilgili aldığı geri bildirim miktarının toplanması ve miktara göre azalan düzende düzenlenmesiyle yapılır. Ortak geri bildirim temaları, herkese açık toplantılardaki (W3C, PatCG, IETF) tartışma konuları, doğrudan geri bildirimler, GitHub ve Google'ın şirket içi ekipleri ile herkese açık formlar üzerinden gelen sık sorulan sorular incelenerek belirlendi.
Daha ayrıntılı belirtmek gerekirse, web standardı kuruluş toplantılarının tutanakları incelendi ve doğrudan geri bildirim için Google'ın paydaşlarla bire bir toplantı kayıtları, mühendislerin aldığı e-postalar, API posta listesi ve herkese açık geri bildirim formu dikkate alındı. Ardından Google, her API ile ilgili olarak ortaya çıkan temaların göreceli yaygınlığını belirlemek için bu çeşitli tanıtım etkinliklerine katılan ekipler arasında koordinasyon sağladı.
Chrome'un geri bildirimlere verdiği yanıtlarla ilgili açıklamalar, yayınlanan SSS'lerden, paydaşların gündeme getirdiği sorunlara verilen gerçek yanıtlardan ve bu herkese açık raporlama çalışması için özel olarak belirlenen bir duruştan geliştirilmiştir. Geliştirme ve testin mevcut odağını yansıtan sorular ve geri bildirimler özellikle Topics, Protected Audience ve Attribution Reporting API'leri ile ilgili olarak alındı.
Geçerli raporlama döneminin sona ermesinden sonra alınan geri bildirimler henüz Chrome yanıtı olarak değerlendirilmeyebilir.
Kısaltmalar sözlüğü
- ARA
- Attribution Reporting API
- CHIPS
- Bağımsız Bölümlendirme Durumuna Sahip Çerezler
- DSP
- Talep Tarafı Platformu
- FedCM
- Federated Credential Management
- FPS
- Birinci Taraf Gruplar
- IAB
- Interactive Advertising Bureau
- IDP
- Kimlik Sağlayıcı
- IETF
- Internet Mühendisliği Görev Gücü
- IP
- İnternet Protokolü adresi
- openRTB
- Gerçek zamanlı teklif verme
- uzatma
- Origin Deneme Sürümü
- PAT API
- Protected Audience API (eski adıyla FLEDGE)
- PatCG
- Private Advertising Technology Community Group
- RP
- Bağlı Taraf
- RWS
- İlişkili Websitesi Grupları (eski adıyla Birinci Taraf Gruplar)
- SSP
- Arz tarafı platformu
- TEE
- Güvenilir Yürütme Ortamı
- UA
- Kullanıcı aracısı dizesi
- UA-CH
- Kullanıcı Aracısı İstemci İpuçları
- W3C
- World Wide Web Konsorsiyumu
- WIPB
- İstençli IP Körlüğü
Belirli bir API veya teknolojiyle ilgili olmayan genel geri bildirimler
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Yönetim | Özel Korumalı Alan'daki yönetim güncellemeleri için herkese açık bir yorum dönemiyle ilgilenme | Özel Korumalı Alan'ın gelecekteki yönetimi de dahil olmak üzere Özel Korumalı Alan ile ilgili önemli gelişmeler hakkında makul paydaş geri bildirimlerini kabul etmeye hazırız. |
| Test | Mevcut% 1 Chrome destekli testlere ek olarak 3PCD için ek test aşamaları. | Ocak ayının başlarından beri etkin olan Chrome trafiğinin mevcut% 1'inin ötesinde Chrome tarafından desteklenen test sunmayı planlamıyoruz. |
| Web'den Uygulamaya | Mobil cihazlarda 3PCD, web ile uygulama arasında tam birlikte çalışabilirlik sağlanmadan önce gerçekleşmemelidir. | Uygulama ve web birlikte çalışabilirliğini desteklemenin istendiğini kabul ediyoruz. Uygulamalar arası ve web ilişkilendirme ölçümünü kullanıma sunduk ve web'den uygulamaya hedefleme çözümlerini araştırıyoruz. Ancak mobil web'de 3. taraf çerezleri için desteğin sonlandırılmasını ertelemeyi düşünmüyoruz. 3PCD'nin sonunda% 100 kapsama hedefimiz yok. Bunun yerine, uygulama ve web arasında ölçüm için Android'de uyumluluğun 3PCD'de makul düzeyde yüksek olmasını ve kullanıcılar telefonlarını güncelledikçe zaman içinde artmasını bekliyoruz. |
| Tarayıcının Rolü | Chrome, reklam sunucusu veya STP rolünü üstleniyor. | Chrome, reklam sunucusu veya SSP rolünü üstlenmiyor. Chrome, PA API ile reklam sunucuları, STP'ler, TTP'ler ve diğer reklam teknolojilerinin kendi teklif verme ve puanlama mantıklarını getirebileceği bir kapsayıcı sağlar. |
| Kullanım Alanı Rehberi | Özel Korumalı Alan API'leri tarafından hangi kullanım alanlarının destekleneceği konusunda daha net bir kılavuz. | Özel Korumalı Alan projesinin başlangıcında geliştirici dokümanları, geliştiricileri tüm tekliflerle ilgili tartışma ve geri bildirim süreçlerine dahil etmeye odaklanıyordu. Bu, içeriğin genellikle projenin arkasındaki motivasyonu ve kavramları anlama, ardından her teklifin erken geliştirme ve test ayrıntılarını anlama etrafında yapılandırıldığı anlamına geliyordu. Bu, teklifleri geliştirirken gerçek ekosistem işbirliği oluşturmada etkili oldu, ancak API'ler genel kullanıma sunulduğundan, temel geliştirmelerine katkıda bulunmak yerine öncelikle API'leri geliştirmek için burada olan yeni bir geliştirici kitlesi var. Kısa süre önce Privacy Sandbox geliştirici sitesinin gezinme menüsünü, IAB Tech Lab'in son Privacy Sandbox Task Force raporundakine benzer sınıflandırmalar kullanarak kullanım alanı odaklı olacak şekilde güncelledik. Dokümanlara yönelik kullanım alanına dayalı yaklaşımı kullanmaya devam edeceğiz. |
| Yerel Geliştirme Ortamı | Çerez SameSite=Secure olduğunda ve arka uç bir CDN tarafından desteklendiğinde ön uçumuzu http://localhost adresinde yerel olarak geliştirmeye ve test etmeye nasıl devam edebiliriz? | Bu konuyu buradan ele alıyoruz ve ekosistemden daha fazla geri bildirim almaktan memnuniyet duyarız. |
| 3PCD azaltma | Üçüncü taraf çerezlerinin engellenip engellenmediğini veya sezgisel kuralların ne zaman etkin olduğunu öğrenmenin programatik bir yolu var mı? | Chrome'da hem özellik algılama hem de bir iFrame'de çağrılan document.hasStorageAccess, geliştiricinin iFrame'deki kaynağın 3. taraf çerezlerine erişip erişemediğini bilmesine olanak tanır. |
| Video Testi | Video reklamlar şu anda Özel Korumalı Alan'da test edilememektedir. | Chrome, PA API ile videonun kullanılabileceği çeşitli olası yöntemlerle ilgili bir tartışma ve gösterim yayınladı (GitHub'daki demo depomuzda 242 ve 254 numaralı makalelere bakın). Bu örneklerin, reklam teknolojilerinin topluca benimseyeceği örnek kodlar olarak değil, PA API ile VAST video oluşturmayı destekleyebilecek tekniklerin bir kavram kanıtı ve gösterimi olarak tasarlandığını unutmayın. Bu tartışma sırasında, video oluşturma işleminin günümüzde zaten mümkün olduğu ancak Chrome'un PA API ile uygulamayı basitleştirecek değişiklikler yapabileceği de ortaya çıktı. Örneğin, üçüncü taraf reklam doğrulayıcı marka güvenliği kullanım alanları hakkındaki geri bildirimler doğrultusunda ele almayı planladığımız makro değiştirmeyle ilgili güncellemeler ( burada ele alınmıştır), alıcının oluşturma işleminde hangi satıcı makrolarını kullanacağını aradığı video kullanım alanındaki geri bildirimleri de ele alacaktır. Bugüne kadar yapılan tartışmaların çoğu özellikle VAST video reklamlarının oluşturulmasına odaklanıyordu. Yerel reklamların oluşturulması için aynı yaklaşımlar kullanılabilir ve bu işlem birçok açıdan daha kolaydır. Yerleşik reklamlar şu anda videodan daha az ilgi görüyor gibi görünse de bu durum, uygulamayla ilgili teknik bir engelden değil, reklam teknolojisi sektörünün önceliklerinden kaynaklanıyor. |
| Reklam dışı ölçüm | 3PCD, reklamlarla ilgili olmayan kitle ölçüm çözümlerini etkileyebilir. | Ölçüm API'leri, kullanım alanının reklamlarla ilgili olmasını gerektirmez. ARA,tipik bir reklamcılık yolculuğuna daha özgüyken özel toplama genel amaçlıdır. Bu iki yapı taşı, çok çeşitli ölçüm etkinliklerini ele almak için kullanılabilir. |
| İçerik Üreticiler | Özel Korumalı Alan, içerik üreticileri kendi sitelerinde daha az, YouTube için daha fazla içerik üretmeye teşvik edecek şekilde tasarlanmıştır. | Özel Korumalı Alan girişimi, kullanıcıların açık ve özgür bir internette etkinliklerini gizli tutmaya odaklanır. Yayıncıların içerik üretmek ve bu içerikleri mümkün olduğunca geniş bir kitleye sunmak için reklamlardan yararlandığını biliyoruz. Reklamverenler, kullanıcıların aradıkları yeni ürünleri veya fırsatları keşfetmelerine yardımcı olur. Özel Korumalı Alan özellikleri, içerik üreticilerle çalışanlar da dahil olmak üzere her tür web sitesinin, kullanıcının kimliğini bu taraflara göstermeden kullanıcılara farklı taraflarla olan etkinliklerine göre faydalı reklamlar göstermesini sağlar. |
| Daha net zaman çizelgeleri | Özel Korumalı Alan teknolojileri için daha net ve ayrıntılı sürüm planları. | Privacy Sandbox API dokümanları, API durumu ve kullanılabilirlik sayfalarını içerir. Bu sayfalarda, yakında kullanıma sunulacak özellikler ve zaman çizelgeleri (ör. PA API, ARA) listelenir. Bu durumların merkezi bir görünümünü burada bulabilirsiniz. |
| Makine Öğrenimi | 3. taraf çerezleri %1'in üzerine çıkana kadar reklam teknolojileri, makine öğrenimi modellerini düzgün şekilde eğitemez. | 3PCD'nin test için daha fazla tarayıcıda kullanıma sunulması, API'lerin daha fazla kullanılacağını garanti etmez. Reklam teknolojilerinin, makine öğrenimi modellerini daha da eğitmek için aradığı şey de budur. Reklam teknolojisi uzmanlarının, makine öğrenimi modellerini daha da eğitmek için daha geniş bir ekosistem kullanımı istememesi durumunda 3. taraf çerezleri kapsamının genişletilmesinin bir nedeni yoktur. Çünkü modelleri daha fazla trafikte eğitmek isteyen reklam teknolojisi uzmanları, 3. taraf çerezleri kapsamını artırmadan da bunu yapabilir. Bu işlem, Chrome'un 3PCD'de hareket ediyormuş gibi görünmeden, Durma durumunun sona ermesinden önce yapılabilir. |
| Desteklenmeyen Kullanım Alanı | Self servis DSP kullanım alanları şu anda değerlendirilmemektedir. | API'ler hakkında düzenli olarak herkese açık geri bildirim sağlayan birden fazla self servis TTP vardır. Herkese açık olarak düzenli geri bildirim sağlayan DSP'lerden bazıları da kendilerini test kullanıcısı olarak listelemiştir. Ayrıca Chrome, video ve üçüncü taraf reklam sunucuları gibi tipik self servis TTP konularında aktif olarak etkileşim kurmaktadır. Son haftalık PA API çağrılarında bu konular ele alınmıştır. |
| Kaynak denemesi | 3PCD için daha agresif bir artış ve test kapsamı isteyen siteler için OT isteğinde bulunma | Chrome şu anda, kaynaklarının üçüncü taraf çerezlerini kullanımdan kaldırma davranışını etkinleştirmesine olanak tanıyacak bir birinci taraf OT geliştiriyor. Bu deneme sürümüne kaydolan ve jeton dağıtan üst düzey kaynaklarda, kullanıcı cihazında izleme koruması etkinmiş gibi 3PC'ler engellenir. Bu OT, CMA ile istişarede bulunulduktan sonra 3. taraf çerezlerin kullanımdan kaldırılması planlanan tarihten önce, sitelerin 3. taraf çerezlerine yönelik uzun vadeli alternatifleri daha geniş kapsamlı bir şekilde test etmeleri için değerli bir fırsat sunacaktır. OT'nin kullanıma sunulması için zaman çizelgesini kesinleştirmeye devam ediyoruz. |
| IAB Tech Lab Raporu | IAB Tech Lab raporundan alınan Özel Korumalı Alan ile ilgili geri bildirim. | IAB Tech Lab raporuna buradan ayrıntılı olarak yanıt verdik. Ayrıca, "Raporda, dağınık dokümanlar, ticari şartlar, üçüncü taraf denetimleri, endüstri onayı, ölçeklenebilirlik, şeffaflık ve gelecekteki yönetimle ilgili sorular gündeme getiriliyor. Bu konularla ilgili olarak ekosistemle etkileşime geçeceğiz ve herkese açık SSS'lerimizi buna göre güncelleyeceğiz." dedik. Daha önce parçalanmış dokümanları ele aldık. Ticari şartları burada "Veri Garantileri" bölümünde ele alıyoruz ve bazı Google Ads ürünleri yaklaşımlarını paylaşmıştır. Üçüncü taraf denetimleri hakkında daha fazla bilgiyi Algoritma Bütünlüğü Garantisi bölümünde bulabilirsiniz. Onaylama konusunda, bu kuruluşların teknolojilerin kendileri yerine, teknolojilerin kullanımı da dahil olmak üzere ürünleri onaylamaya devam etmesini bekleriz. Ölçeklenebilirlik konusunda, geliştiricilerin sorunları gösteren verilerine açık olmaya devam ediyoruz. Şeffaflık ve yönetişim konusunda, Taahhütler kapsamında CMA ile etkileşime geçerken GitHub'da ve W3C gibi forumlarda açık şekilde geliştirmeye devam ediyoruz. |
| Google ile Oturum Açma | Google oturum açma işlemleri, Google'ın Taahhütler'e aykırı olarak kimlik doğrulama arası giriş verilerini kullanmasına neden olur. | Google ile oturum açma özelliği, Google'ın Taahhütler'e aykırı verileri kullanmasına olanak tanımaz. |
| Uyumluluk | Özel Korumalı Alan API'leri desteği ve ileri / geri uyumluluk için planlar nelerdir? | Chrome'da genel kullanıma sunulan bir özellik için desteği sürdürmeyi amaçlıyoruz. Elbette geriye dönük uyumluluğu korumak her zaman mümkün değildir. Bu gibi durumlarda, mevcut özelliklerin desteğinin sonlandırılması ve kaldırılması için burada açıklanan net bir sürecimiz vardır. İyileştirilmiş destekten yararlanacak kullanım alanları hakkında ekosistemden gelen geri bildirimlere yanıt olarak zaman içinde Özel Korumalı Alan API'lerine daha fazla özellik eklemeye devam etmeyi planlıyoruz. Bu tür durumlarda, yeni bir özelliği denemek isteyen reklam teknolojisinin doğrudan tarayıcıya özelliğin desteklenip desteklenmediğini sorabilmesi için bir tür özellik algılama tekniği ekleme eğilimindeyiz. Bazı özellikler Chrome'un tüm kullanıcılarına aynı anda sunulmayabileceğinden, geliştiricilerden belirli bir Chrome sürüm numarasını kontrol etmelerini istemekten daha iyi bir yöntemdir. Örneğin, PA API'si için özellik algılama çalışmamızı burada bulabilirsiniz. |
| Sunucu Uygulaması | Chrome, kendi uygulamasını bağlamak yerine Güvenilir Sinyaller Sunucusu, Toplama Sunucusu ve tarayıcı dışındaki diğer gerekli bileşenlerin tatmin edici bir şekilde uygulanması için karşılanması gereken davranışları belirtmelidir. Bu sayede, kabul edilebilir gizlilik sınırları içinde yenilik yapılabilir. | Kuruluş dışından kişilerin yenilik yapma isteklerini takdir ediyor ve memnuniyetle karşılıyoruz. Tüm API'ler ve hizmetler için reklam teknolojisi şirketlerine işlevlerini uygulama konusunda esneklik sunmayı amaçlıyoruz. Örneğin, reklam teknolojilerinin açık artırmalar için teklif mantığını tasarlarken gizli işletme bilgilerini kullanmasına izin veririz. Ayrıca, reklam teknolojilerinden gelen geri bildirimleri sürekli olarak değerlendiriyor ve uygun olduğunda tasarımlarımıza dahil ediyoruz. Diğer kullanıcıların Güvenli Yürütme Ortamlarında kendi kodlarını çalıştırmasına izin vermek için Özel Korumalı Alan'ın, gizlilik garantilerini karşıladığını doğrulamak üzere kodu (ve tüm değişiklikleri) incelemesi gerekir. Bunun için Özel Korumalı Alan ekibinin önemli bir çaba göstermesi gerekecek. Bu nedenle, paydaşımızın elde etmek istediği ve şu anda karşılayamadığımız avantajları öğrenmek isteriz. |
| Buluşsal yöntemler | Heuristics için uzun vadeli planlar nelerdir? | Diğer tarayıcıların belirttiği gibi, alternatif çözümler yaygın olarak kullanılmaya başlandığında, daha fazla fizibilite analizine tabi olarak bu sezgisel kuralları kullanımdan kaldırmayı planlıyoruz. Bu konuyu burada paylaşmıştık. |
| Test Hacmi | Farklı boyutları karşılaştırırken farklı trafik hacmi. | %1 denemesinde, farklı Chrome istemci popülasyonları arasında denemeye uygunluk açısından farklılıklara neden olan hariç tutma ölçütleri vardır. Örneğin, deneme Chrome Enterprise kullanıcılarını hariç tutuyor. Bu nedenle, deneme etiketleri içeren trafiğin oranı hafta sonlarında daha yüksek olacaktır. Farklı veri dilimleri (coğrafi konum, tarih ve platform gibi) arasında farklı trafik yüzdeleri görmek normaldir ve bu durum Chrome verilerinde gördüğümüzle tutarlıdır. |
| 3 PC'yi Manuel Olarak Yeniden Etkinleştirme | 3PCD zorunlu kılındıktan sonra siteler, çerezleri manuel olarak yeniden etkinleştiren kullanıcıların yüzdesini öğrenebilecek mi? | Kullanıcılar, kesintiyle karşılaşırsa kullanıcı atlama özelliğini kullanarak site düzeyinde 3. taraf erişimini yeniden etkinleştirebilir. Üçüncü taraf çerezleri, Storage Access API gibi diğer önlemlerle de yeniden etkinleştirilebilir. Sitelerin 3PC'lerin etkin olup olmadığını algılamasına olanak tanıyan hasStorageAccess() gibi teknik önlemler vardır. Ancak Chrome, web sitelerinin yeniden etkinleştirme nedenlerini öğrenmesini sağlamaz. |
| İzlemeye Karşı Koruma | Chrome'un İzlemeye Karşı Koruma kullanıcı arayüzü özelliği ne kadar süreyle kullanılabilir olacak? | Adres çubuğundaki İzleme Koruması kullanıcı arayüzünün, 3PC'lerin desteği sonlandırıldıktan sonra da mevcut kalacağı tahmin edilmektedir. |
| (Önceki çeyreklerde de bildirilmiştir) Tarayıcı Arasında Destek |
Özel Korumalı Alan API'lerini benimseyen diğer tarayıcı tedarikçileri. | Apple, Mozilla ve Microsoft gibi diğer tarayıcı tedarikçileri, gizlilik ilkelerinin ve tarayıcı tabanlı yaklaşımların tartışıldığı herkese açık forumlarda etkin katılımcılardır. Yakın zamanda düzenlenen W3C Annual TPAC toplantısı ve devam eden W3C PATCG forumları gibi platformlarda ortak çalışmalarla ilgili yaptığımız görüşmelerden ve bu görüşmelerde yakınlaşma işaretleri görmemizden memnuniyet duyuyoruz. Örneğin, Microsoft Edge kısa süre önce PA API ile "söz dizimi uyumluluğunu en üst düzeye çıkarmayı amaçlayan planını ve geliştiricilere ek özellikler sunduğunu duyurdu. |
| 3PCD'den sonra uyumsuz yerleşimler için yedek seçenek | Bir üçüncü taraf iframe'inin / yerleşiminin 3PCD ile uyumlu olup olmadığını algılamak için API bağlantıları sağlayın. | İsteği burada tartışıyoruz ve ekosistemden daha fazla geri bildirim almaktan memnuniyet duyarız. |
| Test | Yönetilen Chrome örneklerine, özelleştirilmiş davranışları geçici olarak devre dışı bırakan ek işaretler ekleme isteğinde bulunun. | Chrome'un yönetilen örnekleri için bu isteği değerlendiriyoruz. Bu tür bir işaretin yararlı olacağını düşünüyorsanız ekosistemden ek girdiler almaktan memnuniyet duyarız. |
Kayıt ve Onay
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Onay Doğrulaması | Google, doğrulamaların gerçekliğini nasıl sağlayacak? | Tüm kaydedenlerin, API'leri kullanırken doğrulama dosyasını yerinde tutması gerekir. Google, dosyanın mevcut olduğunu ve söz dizisinin doğru olduğunu doğrular ancak reklam teknolojisinin doğrulama diliyle ilgili davranışını doğrulamaz. |
| Private Aggregation API Kayıt Süreci | Private Aggregation API kaydının durumunu kontrol etmenin bir yolu var mı? | Kayıt doğrulandıktan sonra, kayıt işlemi onaylanan tüm kullanıcılara Kayıt Destek Ekibi tarafından e-posta gönderilir. Kayıt işlemi sırasında sorularınız olursa destek ekibiyle (kayıt formunu gönderdikten sonra bağlanırsınız) iletişime geçebilirsiniz. Destek ekibi, soruları yanıtlar ve gerekli ek rehberliği sağlar. |
Alakalı İçerik ve Reklamlar Gösterme
Konular
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| (Önceki çeyreklerde de raporlanmıştır) Sınıflandırıcı Zaman Çizelgesi ve Dokümanları |
Sınıflandırmanın incelenmesi için bir mekanizma veya en azından sınıflandırma modunun kategorileri nasıl belirlediğiyle ilgili ek şeffaflık olmalıdır. | Yanıtımız önceki çeyreklerden farklı değil: "Sitelerin yanlış sınıflandırılması, Topics sinyalini genel olarak biraz daha az yararlı hale getirebilir ancak yanlış sınıflandırılan belirli siteler, bu durumdan diğer sitelerden daha fazla veya daha az zarar görmez. Bunun nedeni, bir sitenin bağlamsal bilgilerinin sitelerindeki açık artırmalar için her zaman kullanılabilmesidir. Bu sayede, yanlış sınıflandırma durumunda bile doğru konuyla ilgili benzer bilgiler sağlanır. Bu konuyla ilgili geri bildirimlerinizi buradan bizimle paylaşabilirsiniz." |
| Google Ad Manager | Google Ad Manager zaten çoğu siteye yerleştirilmiştir ve daha az sayıda sitede bulunan rakiplerine kıyasla kullanıcı konuları hakkında çok daha geniş bilgilere sahiptir. | Gözlem şartı, Topics API'nin kullanıcı verilerinin, API'nin yerini aldığı teknolojilerden (üçüncü taraf çerezleri dahil) daha fazla öğeyle paylaşılmasına neden olmamasını sağlamak için vardır. Prebid gibi diğer sektör çözümleri 10.000'lerce siteyle çalışır ve pazar katılımcılarının kendi teknolojileri aracılığıyla Topics API'yi çağırmasını sağlar. Ayrıca, birçok sitede bulunan ve 3 PC kullanarak 5'ten fazla konu eşdeğeri öğrenebilecek pazar katılımcıları 5 ile sınırlanacağından, haftada en fazla 5 popüler konu sınırının eşitleyici bir etkisi olabileceğini belirtmek isteriz. |
| (Önceki çeyreklerde de raporlanmıştır) Farklı paydaş türleri için kullanışlılık |
Oluşturulan değer ve bu değerin, sitelerin trafik düzeyine veya içeriğinin ne kadar uzmanlaştığına bağlı olarak dağıtımıyla ilgili endişeler. | Uzmanlaşmış sitelerin, genel ilgi alanlarına yönelik alanlardan daha ayrıntılı konulara katkıda bulunma olasılığının daha yüksek olduğunu biliyoruz. Ancak tüm uzmanlık siteleri ticari açıdan değerli konulara katkıda bulunmaz. Ayrıca bu dinamik, mevcut durumu yansıtır ve Chrome'da 3 PC'ler için desteğin sonlandırılmasından tamamen bağımsızdır. Ayrıca mevcut ortamda, bazı siteler 3. taraf tabanlı reklam alaka düzeyi sistemlerinde diğerlerinden daha fazla değer sağlar. Ayrıca, uzmanlaşmış siteler arasındaki konular birbirine faydalı olabilir. Bunun nedeni, farklı reklamverenlerin farklı konu gruplarında kampanya yayınlayabilmesi ve teklif verme mantığının çok çeşitli konularda değer gözlemleyebilmesidir. |
| Ana makine adları ve tam URL'ler | Web sitelerinin ana makine adlarına göre sınıflandırma yeterince etkili mi ve bu, tam URL'lere kıyasla gizlilik riskini azaltıyor mu? | Ana makine adlarına ek olarak bilgi URL'leri veya sayfa başlıkları kullanmayı düşündük ve olası avantajların, kullanıcı gizliliği ve güvenliğiyle ilgili risklerden ağır basacağını belirledik. Kullanıcı gizliliği risklerine örnek olarak, URL'de veya sayfa başlığında yer alan hassas bilgilerin kullanıcının ilgi alanlarına göre sınıflandırılması verilebilir. |
| Sinyal Olarak Konular | Topics'in diğer sinyallerle nasıl birleştirileceği ve hangi diğer sinyallerin yararlı olabileceği konusunda rehberlik isteğinde bulunun. | Reklam teknolojisi çözümleri, bağlamsal veriler, reklam öğesi verileri ve birinci taraf verileri ile birlikte makine öğrenimi ve gizliliği korumaya yönelik API'lerden alınan gizlilik açısından güvenli sinyaller gibi mevcut tüm araçları birleştirerek en iyi sonuçları elde edebilir. Bu konuda daha fazla bilgiyi burada bulabilirsiniz. |
Protected Audience API (eski adıyla FLEDGE)
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Test Trafik Hacmi | Test kullanıcıları, PA API açık artırması için düşük hacimli teklif yanıtı bildiriyorlar. | 1. Teklif yoğunluğu, PA API'ye ekosistem katılımıyla ilişkilidir. Bu katılımın 2024 ve sonrasında artmaya devam edeceğini tahmin ediyoruz. Kampanya bütçelerinin nasıl dağıtılacağını belirlemek nihayetinde reklamverenlere, ajanslarına ve teknoloji sağlayıcılarına bağlıdır. Bazı ekosistem katılımcılarının, PA API dahil olmak üzere çeşitli "çerezsiz" çözümlere yatırımlarını 3PCD'den sonraya ertelemesini bekliyoruz. Bu sırada, bu tür çözümlere ayrılan kampanya bütçesini artırabileceklerini tahmin ediyoruz. 2. PA API açık artırmalarındaki teklif isteklerinin hacmi, (1) nedeniyle etkilenebilir. Bunun nedeni, yayıncıların ve reklam teknolojisi sağlayıcılarının, talebin düşük olduğunu düşünüyorlarsa PA API açık artırmalarını başlatmamaya karar vermeleridir. Sayfalarını güncelleme ve programa katılma önceliğini belirlemek yayıncıların sorumluluğundadır. Yayıncıların bu nedenlerle trafiği test etmek ve kademeli olarak artırmak için zaman alabileceğini tahmin ediyoruz. Bu raporda, Google Ad Manager'ın PA API katılımı için yayıncı denetimleriyle ilgili yanıtı da yer alır. |
| (Önceki çeyreklerde de bildirilmiştir) Dolandırıcılık / Kötüye Kullanım |
Ekosistem, riskleri nasıl azaltabilir ve kötü niyetli kişilerin veya alıcıların kendilerini arzu edilen bir kitle olarak konumlandırmasını nasıl engelleyebilir? | PA API reklamlarının raporlama mekanizmaları, kullanıcıları bot trafiğinden ayırmak için kullanılan bilgileri korur. Ayrıca, alanları dahil etme veya hariç tutmayla ilgili mevcut alan tabanlı teknikler PA API'de kullanılabilir. Bu konu, IAB Tech Lab'in Özel Korumalı Alan raporuna verdiğimiz yanıtta daha ayrıntılı olarak açıklanmaktadır. |
| IG sahibi ve teklif verme mantığı URL'sinde aynı kaynak kısıtlaması | Aynı kaynak koşulu nedeniyle, bir IG sahibinin uç noktaları aynı yük dengeleyiciden geçmek zorunda kalır. Bu da yönlendirmelerin reddedilmesine neden olabilir. | Komut dosyası yükleme için aynı kaynak koşulu önemli bir güvenlik korumasıdır. Ekosistem geri bildirimlerini ve diğer hususları dengeleyen önerilen çözümle ilgili ayrıntıları burada bulabilirsiniz. |
| Çok Yuvalı Özel Açık Artırma | Gürültü ve mevcut reklam uygulamalarıyla daha sıkı entegrasyon kullanarak gizlilik sınırları içinde çok yuvalı özel açık artırmalara izin vermek için çok fazla alan var. | Bu geri bildirimi dikkate alıyoruz ve çok etiketli açık artırma isteğini, bu özellikle ilişkili artan karmaşıklık ve gizlilik riskleri açısından değerlendiriyoruz. Bu konuyu, PA API Web Incubator Community Group (WICG) toplantısında buradan daha ayrıntılı olarak ele aldık. |
| Üst düzey satıcılar | PA API'nin mevcut yapısı, üst düzey satıcılara gösterimlerin göreceli değeri hakkında yayıncılardan veya bileşen satıcılarından çok daha fazla veri ve bilgi sağlar. | Çok satıcılı açık artırmada her satıcının en iyi teklifi vardır. Ayrıca, ekosistemden, yayıncıların birlikte çalıştıkları her satıcının en iyi tekliflerinin yanı sıra doğrudan satılan talebi de dikkate almak isteyebileceğini öğrendik. Hangi reklamın yayınlanacağını belirlemek için tüm bu potansiyel para kazanma fırsatlarına bakmak gerekir. Bazı aktörlerin yayınlanacak bir reklam seçmek için seçeneklerin tamamını görmesi gerektiği bu durum, PA API'den öncedir. PA API, çok satıcılı açık artırmaları ve yayıncıların, doğrudan satılan reklam kampanyalarının yanı sıra her satıcının en iyi teklifini dikkate alma isteğini desteklemeyi amaçlar. Bu nedenle, bugün olduğu gibi bu para kazanma fırsatları arasından seçim yapabileceğiniz bir mekanizmaya ihtiyaç vardır. Hangi reklamın yayınlanacağını seçmenin tarayıcının rolü olmaması gerektiğini düşünüyorduk. Bu nedenle, birçok olasılık arasından kazanan bir reklamı seçmek için üst düzey satıcı kavramı gereklidir. Bu üst düzey satıcının mantığı, yayıncının birlikte çalışmayı seçtiği her satıcının en iyi tekliflerini dikkate alabilmelidir. Bu satıcının mantığı, bu bilgiler mevcut olduğunda yayıncının doğrudan satılan kampanyaları hakkında bilgi vermeyi seçebilir. Bu bilgilerin tümü üst düzey reklam seçim mantığında dikkate alınabilir. Bu, üst düzey mantığın bir kazananı belirlemek için PA API açık artırmasından en iyi teklifleri ve uygun olduğu durumlarda yayıncıdan doğrudan satılan tüm reklam seçeneklerini gördüğü anlamına gelir. Google Ad Manager, PA API'yi üst düzey satıcı olarak uygulama şeklini bu rapordaki "Bilgilere Erişim" teması altında ayrıntılı olarak açıklar. |
| Rekabet Reklamı Ayrımı | Rekabet halindeki markaların reklamlarının yan yana gösterilmesini engelleme gibi rekabetçi reklam ayırma isteği. | Günümüzde programatik, teklifli, çok satıcılı dijital reklamcılık ekosisteminde rekabetçi bir ayrım sağlamanın bir yolu olduğunu bilmiyoruz. Bununla birlikte, PA API, satıcıların reklam öğelerini puanlarken scoreAd() sırasında kullanılabilecek renderURL ve ana makine adının (yayıncının alanını temsil eder) bir kombinasyonuna dayalı olarak ek gerçek zamanlı sinyaller almasını sağlar. Yayıncının bu kuralı uygulamak istediği varsayıldığında, satıcılar bu özelliği kullanarak rakip markaların reklamlarının yan yana gösterilmesini önleyebilir. |
| Sınırlı Bilgi | PA API, reklam değeri, bileşen alıcısı adı, reklamveren adı, açılış sayfası URL'si, reklam öğesi boyutu, yanıt süresi ve teklif oranı gibi yayıncıların erişebildiği bilgilerin yanı sıra kaybedilen teklifleri azaltır. | Burada bazı olası çözümler önerdik ve ekosistemden ek geri bildirimler almayı bekliyoruz. |
| Etkinlik düzeyinde raporlama | Etkinlik düzeyinde raporlama PA API'sinin desteğinin sonlandırılmasından sonra yayıncılar, yayınlanan reklam hakkında yeterli bilgi alamıyor. | Etkinlik düzeyinde raporlama kullanımdan kaldırıldığında desteklemeye devam etmemiz gereken farklı raporlama kullanım alanlarını biliyoruz. Bu nedenle, etkinlik düzeyinde raporlamanın kullanımdan kaldırılma tarihini en erken 2026 olarak belirledik. Bu tarihe kadar, ekosistemle birlikte sürdürülebilir yollarda ilerlerken gizliliği korumaya yönelik yeni fikirler içerebilecek aktif katılıma davet ediyoruz. |
| Birden fazla STP | Birden fazla SSP'den elde edilen katma değer, yayıncılar için çok düşük olacaktır. | Bunun doğru olmadığını düşünüyoruz ve bu iddianın nedenini anlamak için ekosistemden ek geri bildirim almaktan memnuniyet duyarız. |
| İçerik Seçme Etkinlikleri | PA API ile içerik seçme işlemleri yapılamaz. | Satıcıların, PA API'yi kullanarak kitle bilgilerini web'deki alıcılara sunma (diğer adıyla kitle uzantısı) özelliğiyle ilgili geri bildirimler aldık. Bu, iş sözleşmeleriyle birlikte PA'nın yetkilendirme işlevini kullanarak günümüzde mümkün olduğuna inanıyoruz. Bu tür kullanım alanlarını daha iyi karşılayıp karşılayamayacağımızı ve nasıl karşılayabileceğimizi aktif olarak değerlendiriyoruz. |
| Alıcının kapsam dışında kalması | Alıcının varsayılan olarak kapsam dışında kalmayı seçmesi, bileşen açık artırmaları için daha düşük sonuçlara neden olabilir. | Tek satıcılı veya çok satıcılı PA açık artırması tanımlanırken satıcı, AuctionConfig'in interestGroupBuyers alanında alıcıları açıkça listelemelidir. Bu, satıcıların bazı alıcılarla sözleşmeli anlaşmaları olduğu ve bu nedenle açık artırmaya hangi alıcıların dahil edileceği konusunda açık bir kontrole ihtiyaç duyduğuna dair ekosistem geri bildirimlerine dayanır. GitHub'da daha fazla tartışmaya açığız. |
| Reklam boyutu | Reklam boyutuna ve reklam alanı boyutuna göre ön filtreleme yapılamıyor. | Bu özelliği eklemek için çalışmalarımızı sürdürüyoruz. Daha fazla bilgiyi burada bulabilirsiniz. |
| Negatif IG hedefleme desteği | Negatif IG hedeflemesini destekleyen bir API: Reklamları yalnızca kullanıcı bir IG'ye ait değilse gösterir. | Bu GitHub sorununda, tarayıcının doğrudan reklam sunucusuna belirli bir reklam isteği için hangi negatif hedefleme kurallarının geçerli olması gerektiğini söylediği, negatif hedeflemeyi uygulamanın alternatif bir yolu önerilmiştir. Bu cazip bir yaklaşım gibi görünse de araştırdığımız bu fikrin tüm sürümlerinin, sunucunun kullanıcıyı benzersiz şekilde tanımlamasına olanak tanıdığı ortaya çıktı. |
| Dijital Hizmetler Yasası | Bir yayıncı, Çitli Çerçeveler'i kullanırken aynı zamanda Dijital Hizmetler Yasası'na tabi bilgileri içeren yanıtların oluşturulmasını nasıl engelleyebilir? | Her yeni teknolojide olduğu gibi, Özel Korumalı Alan'ın kullanımının yasalara uygun olmasını sağlamak her şirketin sorumluluğundadır. Google, diğer şirketlere yasal tavsiye veremez. Her API için gerekli yasal değerlendirmeleri yapmanıza temel oluşturacak kapsamlı teknik dokümanlar yayınladık. Çitli çerçeveler, PA API'de 2026'dan önce kullanılamaz. Bu sayede, paydaşların bu teknolojiyi kullanmalarının ilgili tüm yasalara uygun olduğundan emin olmaları için ek süre tanınır. |
| Belgeler | updateAdInterestGroups() geçici mi? | updateAdInterestGroup işlevinin desteğinin sonlandırılmasıyla ilgili herhangi bir plan duyurmadık. Gelecekte, diğer IG güncelleme mekanizmaları için herkese açık olarak bahsettiğimize benzer gizlilik korumaları uygulayabiliriz (ör. proxy olarak IP adresi kullanma ve güncelleme gerçekleşmeden önce biraz gecikme ekleme). |
| DSP olmayanlar için alıcı tarafı meta veri ve mantık sahipliği desteği | TTP'ler için proxy olarak hareket etmenin bir yolunu isteyin. | DSP dışı segmentlerden gelen bu geri bildirimin farkındayız ve bu isteği değerlendiriyoruz. Ekosistemden ek geri bildirimler bekliyoruz. |
| Raporlama | Özel toplama raporlarında sinyal paketi / değeri için özel işleyici özelliği ekleme isteği. | Bu özelliğin farkındayız ve daha fazla keşif için bu özellik isteği listemizde yer alıyor. Ekosistemden buradan ek geri bildirimlerinizi bekliyoruz. |
| Belgeler | Reklamveren ve (yetki verilmiş) sahip alanı tarafından ayarlanması gereken tüm yanıt üstbilgilerinin görüntülenebileceği bir bağlantı var mı? | Bu konuyu açıklığa kavuşturmak için dokümanlarda güncelleme yapmayı planlıyoruz. Ekosistemden ek geri bildirimler de bekliyoruz. |
| Çok Kule Teklif Verme | PA API bağlamında çoklu kule yaklaşımının nasıl tasarlandığına dair bir mimari / blok şeması aracılığıyla iş akışının (eğitim ve çıkarım) açıklanmasını isteyin. | Geri bildiriminiz için teşekkür ederiz. Konuyla ilgili bazı sunumlarımız var ve bu sunumlardan ek dokümanlar oluşturmayı planlıyoruz. |
| Negatif hedefleme | Özel Korumalı Alan'ın hassas kitleleri ve reşit olmayanları uygunsuz reklamlardan (ör. kumar) koruma özelliği | PA API, gösterilen reklamların içeriğini dikkate almaz. Bu, PA'yı kullanan reklam teknolojisi geliştiricilerinin kontrolündedir. Genel olarak yayıncı ve reklam teknolojisi sağlayıcıları, sayfadaki bağlamsal bilgileri ve yayıncı kural kümelerini kullanarak Protected Audience açık artırmalarındaki reklam öğelerini engelleyebilir. Bu, ekosistemin günümüzde bu zorluklara yaklaşımını yansıtıyor. Alıcılara yönelik negatif IG hedefleme işlevi, bazı uygunluk kullanım alanları için de yararlı olabilir. |
| API Tasarımı | Google, reklam teknolojilerinin izin verilen farklı IG'lerde farklı biddingLogicURL'ler yerine gecikmeyi artıran bir Universal teklif verme işlevi kullanmasını istiyor. | Açık artırma gecikmesiyle ilgili görüşmelerimiz sırasında, bir alıcının tüm IG'lerinde aynı komut dosyasının yeniden kullanılmasının, söz konusu alıcının teklif vermesinin daha hızlı olmasını sağlayacağını vurguladık. Bu konu, PA API açık artırma gecikmesini iyileştirmeyle ilgili diğer önerilerimizle birlikte burada daha ayrıntılı olarak açıklanmıştır. |
| Hesaba dayalı pazarlama | PA API, hesap tabanlı pazarlama kullanım alanları için temiz bir API değildir. | Ekosistemdeki kullanıcıların, mümkün olmadığını düşündükleri belirli kullanım alanları hakkındaki geri bildirimlerini bekliyoruz. Ekosistem katılımcılarını, herkese açık GitHub depomuzu veya haftalık toplantılarımızı kullanarak bu tartışmaya devam etmeye teşvik ediyoruz. |
| A/B Testi | PA API, GAM'de bir yayıncı için yapılandırıldığında şu anda tüm envanter için veya hiçbir envanter için etkinleştirilmelidir. Bu durum, yayıncıların geçerli bir A/B testi çalıştırma kapasitesini sınırlandırır. | Google Ad Manager tarafından sağlanan yanıt: Google Ad Manager (GAM) içindeki PA API denetimleri, API'nin kullanılabilir olması koşuluyla GAM'ın API'yi kullanma yeteneğini etkiler. Bu nedenle yayıncılar, Chrome'un izin politikası işlevini kullanarak A/B testi için kontrol kolu olarak kullanılacak bir trafik alt kümesinde API'nin kullanımını devre dışı bırakarak A/B testleri çalıştırabilir. |
| Makine Öğrenimi | Yayıncıların, GAM'ın önerdiği makine öğrenimi kullanımı üzerinde daha fazla kontrole ihtiyacı vardır. | Google Ad Manager tarafından sağlanan yanıt: Ocak 2024'te, yayıncılara makine öğrenimi akış sınırlayıcımızı devre dışı bırakma ve tüm trafiklerinde Google dışı satıcılarla PA API açık artırmalarını etkinleştirme olanağı sunan bir denetim kullanıma sunduk. Bu denetimle ilgili daha fazla bilgiyi Yardım Merkezimizde bulabilirsiniz. |
| (Önceki çeyreklerde de raporlanmıştır) Üst düzey açık artırmalar |
Üst düzey PA API açık artırması üzerinde GAM'a kontrol vermeden Google'ın yayıncı reklam sunucusunu kullanma olanağı. | Google Ad Manager tarafından sağlanan yanıt: Google'ın 3. çeyrek 2023 raporunda açıklanan nedenlerden dolayı, GAM'ın PA API entegrasyonuyla ilgili planları, üst düzey açık artırmanın kontrolünü elinde tutmadan GAM'ı yayıncı reklam sunucusu olarak kullanan yayıncıları desteklemeyi içermiyor. |
| Bilgilere Erişim | GAM, bağlamsal açık artırma fiyatları, alıcılar tarafından PA API açık artırması için SSP'lere sağlanan sinyaller ve SSP'lerden gelen yapılandırma parametreleri dahil olmak üzere rakiplerden değerli bilgilere erişebilir. | Google Ad Manager tarafından sağlanan yanıt: Yıllardır açık artırma adaletine güçlü bir şekilde odaklanıyoruz. Bu kapsamda, garanti edilmeyen satır öğesi fiyatları da dahil olmak üzere yayıncının garanti edilmeyen reklamcılık kaynaklarından hiçbir fiyatın, açık artırmada teklif vermeden önce başka bir alıcıyla paylaşılmayacağı sözünü verdik. Bu sözümüz daha sonra Fransız Rekabet Kurumu'na verdiğimiz taahhütlerde de onaylanmıştı. PA API açık artırmalarında, sözleştiğimiz gibi, çok satıcılı açık artırmalarda açık artırma tamamlanmadan önce hiçbir açık artırma katılımcısının teklifini diğer açık artırma katılımcılarıyla paylaşmayacağız. Açıkça belirtmek gerekirse, bu güncellemede açıklandığı gibi bağlamsal açık artırmanın fiyatını kendi açık artırmamız da dahil olmak üzere hiçbir bileşen açık artırmasıyla paylaşmayacağız. Ayrıca, kendi açık artırmamız kapsamında, alıcılar tarafından SSP'lere sağlanan sinyaller de dahil olmak üzere bileşen açık artırması yapılandırmalarıyla ilgili bilgileri kullanmayız. Hatta PA API'de, bileşen satıcılarının bileşen açık artırma yapılandırmalarını üst düzey satıcıdan gizlenecek şekilde belirtmelerine olanak tanıyan değişiklikleri memnuniyetle karşılarız. |
| Bileşen Açık Artırmaları | Üst düzey açık artırma olarak GAM, her reklam fırsatı için hangi SSP'lerin bileşen açık artırmaları çalıştıracağını kontrol eder. | Google Ad Manager tarafından sağlanan yanıt: Yayıncı reklam sunucusu olarak GAM, bir yayıncının Google Yayıncı Etiketi (GPT) API'si aracılığıyla bileşen açık artırma yapılandırmalarını belirtmek için birlikte çalışabileceği STP'ler için hafif bir API sunar. Daha fazla ayrıntıyı burada bulabilirsiniz. Bir SSP bu API aracılığıyla bileşen açık artırması yapılandırması sağlarsa söz konusu reklam fırsatı için bileşen açık artırmaları listesine dahil edilir. GAM, dahil edilen bileşen açık artırmalarına herhangi bir kısıtlama uygulamaz. Yayıncının sayfasında gerekli kodu yürütmelerine izin vermesi koşuluyla, bileşen açık artırması yayınlamak isteyen tüm SSP'ler bunu yapabilir. |
| Bileşen Açık Artırmaları | GAM, her bileşen açık artırmasında kazanan teklife belirli ve açıklanmayan bir taban uygulayabilir. | Google Ad Manager tarafından sağlanan yanıt: GAM, yıllardır açık artırma adaletine güçlü bir şekilde odaklanmaktadır. Adil ve şeffaf bir açık artırma sürdürmek amacıyla, yalnızca belirli talep segmentleri için geçerli olan taban fiyatları desteklemeyiz. Bu, ürünümüzdeki tutarlı bir ilkedir ve PA API açık artırmaları için de geçerli olmaya devam edecektir. |
| Üçüncü Taraf Reklam Sunucuları | Üçüncü taraf reklam sunucuları, Google'ın üst düzey açık artırmaya katılımına erişemez. Bu da PA API bağlamında Google SSP talebinden yararlanma olanağını sınırlandırır. | Google Ad Manager tarafından sağlanan yanıt: GAM şu anda burada açıklanan API aracılığıyla GAM'de PA API'yi birden fazla satıcıyla test etmeyi desteklemektedir. GAM'in diğer üst düzey açık artırmalarda bileşen açık artırması olarak katılımı şu anda desteklenmemektedir. |
| (Önceki çeyreklerde de raporlanmıştır) PA API Açık Artırmalarının Performansı |
Test kullanıcılarından PA API açık artırmalarının yüksek gecikmeye sahip olduğuyla ilgili rapor. | Gecikmeyle ilgili endişeleri duyduk. Bu endişeler, PA API kapsamında bir dizi özellik geliştirmemizin nedenlerinden biridir. Bu özellikler, SSP'lerin hem DSP gecikmesiyle ilgili sınırlar belirlemesine hem de gecikmeyi azaltabilecek iyileştirmeler yapmasına olanak tanır. Bu özelliklerden nasıl yararlanacağınız hakkında daha fazla bilgi içeren gecikmeyle ilgili en iyi uygulamalar kılavuzumuzu kısa süre önce güncelledik. Ayrıca, gecikmeyle ilgili yeni iyileştirmeler geliştirmeye devam ediyoruz. Bunlardan bazılarını burada görebilirsiniz. |
| (Önceki çeyreklerde de raporlanmıştır) Video oluşturma |
PA API ve Çitli Çerçeveler kullanılarak video oluşturma desteği. | Ocak ayında, alternatif yaklaşımlarla ilgili ek ayrıntılar içeren yayın içi videonun PA açık artırmasında nasıl çalışabileceğini gösteren bir demo yayınladık. Ayrıca, ekosistemdeki oyuncuların, GAM'ın video uyumlu renderURL oluşturma önerileri veya tam uçtan uca süreç gibi, kendileriyle entegre olan iş ortakları için video oluşturmanın nasıl işlediğini önermeye başladığını görüyoruz. Ayrıca, kullanım oranını artırmak için yapabileceğimiz değişikliklerle ilgili ekosistemden gelen geri bildirimleri dinliyoruz. Bunlardan biri GitHub'da ayrıntılı olarak açıklanmıştır. Kullanım oranını artırmaya engel olabilecek diğer engelleri tespit etmek ve bunları zamanında gidermek için ekosistemle aktif olarak etkileşime devam ediyoruz. |
| (Önceki çeyreklerde de raporlanmıştır) Veri İşleme Politikası |
IG'ler / PA API için veri işleme politikası nedir? | PA API tasarımında, IG'lerde depolanan veya kullanıcıların hangi IG'lerde bulunduğuyla ilgili tüm veriler (i) cihaz üzerinde kalır veya (ii) Güvenli Yürütme Ortamı'nda (TEE) çalışan Teklif Verme ve Açık Artırma (B&A) Hizmetleri'nde işlenir. Her iki durumda da veriler başka taraflarca okunamaz veya açık artırmada teklif vermek dışında bir şekilde kullanılamaz. Chrome'un üzerinde çalıştığı bazı gizlilik geliştirmeleri, Google tarafından yönetilen bir k-anonimlik sunucusuyla etkileşimi içerir. Bu etkileşim, kullanıcılarla ilgili bilgilerin paylaşılmasını önlemek ve reklam ekosisteminde bilgi eşdeğerliğini sağlamak için TEE'de çalışacak şekilde dikkatlice tasarlanmıştır. Google, Privacy Sandbox tekliflerini Google'ın kendi işletmesini tercih ederek rekabeti bozmayacak şekilde tasarlayıp uygulamayı ve dijital reklamcılıktaki rekabeti, yayıncıları ve reklamverenleri etkileyen faktörleri dikkate almayı CMA'ya taahhüt etmiştir. Çalışmalarımızın bu yükümlülüklere uyduğundan emin olmak için CMA ile yakın bir şekilde çalışmaya devam ediyoruz. |
| (Önceki çeyreklerde de raporlanmıştır) IG kullanım süresi |
IG'lerin süresini 30 günden 90 güne uzatılmasını talep edin. | Bu tür bir değişikliğin, sektöre sağladığı avantajların Chrome kullanıcıları ve diğer paydaşlar üzerindeki etkisiyle karşılaştırılması için dikkatli bir değerlendirme yapılması gerekir. Bu isteği değerlendiriyoruz. Burada ek geri bildirimlerinizi bekliyoruz. |
| (Önceki çeyreklerde de raporlanmıştır) modelingSignals |
Yalnızca görüntülü reklam ve tıklama bilgilerini kodlayabilen modelingSignals'e ek olarak yeni bir alan isteyin. | Bu geri bildirime buradaki karşı teklifimizle yanıt verdik. Teklifimizle ilgili görüşlerini öğrenmek için sektörle aktif olarak iletişim kuruyoruz ve şu anda sektöre sağlayacağı faydaları Chrome kullanıcıları ve diğer paydaşlar üzerindeki etkiye karşı değerlendiriyoruz. |
| reportWin() işlevindeki ek bitler | 3PCD'den önce geçerli 12 bitlik sınırdan reportWin() işlevinde ek bitler sağlayın. | Şu anda bu kullanım alanını destekleyen yaklaşımları araştırıyoruz. Uzun vadeli bir gizlilik planımız olmasını sağlayacak yaklaşımlar da aradığımız için bu süreç biraz zaman alıyor. |
| Açık Artırma Tasarımı | İlgili puanlarıyla birlikte oluşturma URL'lerini döndüren tek bir açık artırma isteği. | Tek bir PA açık artırmasından birden fazla renderURL'yi ve ilgili puanlarını paylaşmayı düşündük ancak gizlilikle ilgili endişeler nedeniyle bunu uygulamadık. Aynı reklamın tek bir sayfada kullanıcıya birden çok kez gösterilmesini önlemek istediğinizi anlıyoruz ve GitHub'da daha fazla tartışmaya açığız. |
| reportWin | reportWin() işlevinde rastgele alanları günlüğe kaydedebilirsiniz. | Bu, test döneminde zaten uygulanmaktadır. Chrome, 3PC'ler için desteği sonlandırdıktan sonra API'nin forDebuggingOnly sürümü, burada belirtilen düşük örneklemeli hata ayıklama özelliğini etkinleştirmek için taşınacaktır. |
| Bileşen Satıcıları | Kendi gösterimlerini ve diğer etkinliklerini saymak için bağımsız bir mekanizmaya sahip olmalı ve yalnızca reklam teknolojilerinin raporlarına güvenmek zorunda kalmamalıdır. | Bu özellik isteği, daha ayrıntılı bir inceleme için bekleme listemizde yer alıyor. Bu sorunun Chrome'un sağladığı test döneminde ele alınması beklenmemektedir. |
| Tıklama Başına Maliyet Faturalandırması | PA API'de tıklama başına maliyet faturalandırmasını uygulayın. | Bu isteği burada değerlendiriyoruz ve şu anda bunu mevcut API yüzeyinde nasıl uygulayacağınızla ilgili öneri isteğinde bulunmuşsunuz gibi görüyoruz. |
| browserSignals | Satıcı için incomingBidInSellerCurrency değerini raporlama browserSignals spesifikasyonuna ekleyin. | Bu isteği değerlendiriyoruz. Burada ek geri bildirimlerinizi bekliyoruz. |
| DSP olmayanlar için alıcı tarafı meta veri ve mantık sahipliği desteği | API'nin mevcut tasarımı, kampanyaların hem DSP hem de DCO sağlayıcısı olarak hizmet veren platformlara taşınması gerekebilecek ürün düzeyinde yeniden hedefleme kampanyalarında önemli bir değişikliğe neden olabilir. | Bu konuyu görüşüyoruz ve buradan ek geri bildirimlerinizi bekliyoruz. |
| DSP olmayanlar için alıcı tarafı meta veri ve mantık sahipliği desteği | TTP'nin IG sahibi olmadığı örnekleri paylaşın. | Teklif vermeyen kullanıcıların, IG'lerin bazı işlevlerini kullanmak istediğini ancak bazılarını kullanmak istemediğinin farkındayız. Bu kullanım alanlarını ele alma seçeneklerini aktif olarak değerlendiriyoruz. Burada ek geri bildirimlerinizi bekliyoruz. |
| Zaman aşımı kontrolleri | Yayıncılar, etkinliğe katılabilecek IG sayısını ve üst düzey zaman aşımı / küresel zaman aşımı ayarlarını belirleyebilmelidir. | Üst düzey satıcı ile bileşen satıcısı arasında daha gelişmiş zaman aşımı kontrolleri ve görünürlük istendiğinin farkındayız ve bu talebi değerlendiriyoruz. |
| Çoklu Reklam Boyutu | Çoklu reklam boyutu kullanım alanları için PA API desteği. | Bu isteği değerlendiriyoruz ve ekosistemden ek geri bildirimler almak istiyoruz. |
| Belgeler | K-anon'a tabi olan IG özelliklerinin listesi var mı? | Bu soruyu burada yanıtladık. |
| Hata ayıklama | PA API için gelişmiş hata ayıklama özellikleri. | PA API ile çalışan geliştiriciler için güçlü hata ayıklama araçlarının öneminin farkındayız. .well-known dosya getirme işlemlerini geliştirici araçlarıyla daha iyi entegre etmenin yollarını araştırarak geliştirici deneyimini iyileştirmeye kararlıyız. Amacımız, geliştirme ortamında daha fazla görünürlük ve sorun giderme özelliği sunmaktır. Bu konuyu burada daha ayrıntılı olarak ele alıyoruz. Ek geri bildirimlerinizi bekliyoruz. |
| Etiketler | B modu işleme etiketlerindeki tüm kullanıcılar için Özel Korumalı Alan API'leri etkin mi? | Chrome deneme grubu atamaları rastgele belirlenir ve kullanıcı tarafından yapılandırılmış Chrome ayarlarından bağımsızdır. Bu API'ler belirli tedavi gruplarındaki (ör. treatment_1.*) kullanıcılar tarafından kullanılabilir olsa da işlevleri Chrome ayarları aracılığıyla değiştirilebilir veya devre dışı bırakılabilir. Mod B control_2 grubu: Bu gruba dahil edilmek, Özel Korumalı Alan alaka düzeyi ve ölçüm API'lerini doğal olarak devre dışı bırakır ve bu ayar kullanıcı tarafından Chrome ayarlarından geçersiz kılınamaz. |
| API Kullanımı | reportWin() çağrısı ve reklam oluşturma işlemi paralel olarak mı yoksa birbiri ardına mı gerçekleşiyor? | reportWin(), runAdAuction() işlevi tamamlandıktan hemen sonra çağrılır. Aynı zamanda, reklam oluşturma işlemi, açık artırma sonucu bir iframe veya çitle çevrili çerçeveye yerleştirildiğinde başlayabilir. Hem reportWin() yürütülmeyi tamamladıktan hem de reklam oluşturulmaya başladıktan sonra sendReportTo() işlevine sağlanan URL'ler getirilir. |
| (Önceki çeyreklerde de raporlanmıştır) A/B Testi Desteği |
PA API A/B testi için destek isteyin. | Bu isteği burada tartışıyoruz. Ek geri bildirimlerinizi bekliyoruz. |
| Trafik Şekillendirme | Google'ın KV sunucusu üzerinden gerekli karar verme sürecini yönetmek için sunduğu öneri, satıcıların arka uçlarıyla etkileşim kuramamaları nedeniyle trafik şekillendirmeyi zorlaştırdığı için faydalı değildir. | GitHub sorununda tartışıldığı gibi, tekil DSP'lerin IG'lere sahip olup olmadığının açıklanması, kullanıcı parmak izi almayla ilgili endişelere yol açabilir. Sorunla ilgili olarak başka alternatifler önerdik ve başka önerilere de açığız. |
| Trafik Şekillendirme | Önbelleğe alma mekanizmaları önemli bir karmaşıklık katmanı ekler ve DSP'lerin teklif verecekleri trafiğin gerçek şeklini bilmelerini engeller. | Önbelleğe alma mekanizması yalnızca öneri olarak sunulmuştur. Reklam teknolojileri, kullanım alanlarına uygun önerileri kullanmayı seçebilir. Burada daha fazla tartışmaya davetlisiniz. |
| Etiketler | Chrome, etiketi alıcı ve satıcı güvenilir sunucularına gönderilen isteklerde parametre olarak paylaşmalıdır. | Bu talep, sorumlu IG veri kullanımı hedefiyle büyük ölçüde uyumlu olduğu için makul görünüyor. Ancak isteği, dahili incelemeye tabi olarak değerlendiriyoruz ve görüşmeler ilerledikçe bu konuyla ilgili herkese açık güncellemeler yapacağız. |
| API Kullanımı | "Üçüncü taraflara yönelik testlerle ilgili ek CMA kılavuzu" belgesinde "control_1" grubunun açık tanımı netleştirildi. Özellikle, ifadedeki değişikliğin, tüm Özel Korumalı Alan API'lerinin control_1'den hariç tutulmasını gerektirdiği şeklinde yanlış yorumlanabileceğinden endişe duyuyoruz. | Bu konuyla ilgili görüşlerimizi bu GitHub ileti dizisinde ifade ettik. Bununla birlikte, CMA adına konuşamayız. Test yönergelerinin yorumlanmasıyla ilgili tüm sorunları doğrudan CMA ile görüşmenizi öneririz. |
| API Kullanımı | Chrome, başka bir kaynağa yönlendirirken boş bir sayfada joinAdInterestGroup() çağrısına izin verir mi? | Bir kullanıcı bir siteyi ziyaret ediyorsa site sahibi, joinAdInterestGroup çağrısını yapma yetkisini üçüncü bir tarafa devredebilir. Bu yetkilendirme, üçüncü tarafların boş bir sayfa üzerinden herhangi bir yönlendirme eklemesine gerek kalmadan IG oluşturmasına olanak tanır. Amaçlanan yetkilendirme mekanizmasını kullanmak yerine bir yönlendirmenin ortasında IG oluşturmanın belirli nedenleri hakkında geri bildirimlerinizi bekliyoruz. |
| API Kullanımı | Exchange'ler, birlikte çalıştıkları yayıncıların sahip olduğu sayfalara IG yazabilmeli ve ardından söz konusu IG için teklif verme iznini herhangi bir alıcıya veya DSP'ye devredebilmelidir. | Geri bildiriminizi aldık ve bu tür bir talebin desteklenip desteklenemeyeceğini değerlendiriyoruz. Ekosistemden ek geri bildirimler bekliyoruz. |
| API Kullanımı | PA API açık artırmasını kimse kazanamazsa hata ayıklama kaybı bildirimi gönderilmez. | Chrome'un reportWin ve reportResult işlevleri, Gizlilik Açık Artırması (PA) sistemi içinde etkinlik düzeyinde kazanç raporlaması için tasarlanmıştır. PA açık artırması sırasında tüm tekliflerin reddedilmesinin ardından kazanan belirlenmediği için bu işlevlerin çağrılması beklenmez. Chrome'da yapılan son bir güncelleme, forDebuggingOnly.reportAdAuctionLoss() işlevine iletilen URL'lerin DevTools Ağ panelinde görünmemesiyle ilgili tutarsızlıkları açıklayabilir. Bu işlevi, Chrome'un Canary veya Yeni Geliştirilenler kanalı sürümünü kullanarak doğrulamanızı öneririz. |
| API Kullanımı | generateBid'den döndürülen adCost negatif olabilir mi (zaten stokastik olarak 2 bayta yuvarlanır)? | AdCost, generateBid() işlevinden reportWin() işlevine iletilen reklamverenin tıklama veya dönüşüm maliyetidir. Bu değer Null veya double olabilir. Negatif değerler yoksayılır ve iletilmez. Değer, iletilirken stokastik olarak yuvarlanır. |
| API İyileştirmesi | Hedefleme / kohortlar / ilişkilendirme ve açık artırmaları işlemek için Chrome Tarayıcı yerine Güvenilir ve Şifrelenmiş Yürütme sunucuları kullanılabilir mi? | PA API'deki TEE tabanlı bileşenleri ve seçenekleri (ör. KV sunucuları ve B&A Hizmetleri) ve bu sorunu ele alan İlişkilendirme Raporlaması ile Özel Toplama'nın TEE tabanlı bileşenlerini (ör. Toplama Hizmeti) keşfetmenizi öneririz. |
| API İyileştirmesi | Özel Korumalı Alan açık artırma yanıtı, reklam yanıtı (reklam etiketleri gibi) yerine teklif yanıtı (başlıktan teklif alma gibi) olabilir mi? | Bu tür bir değişiklik, PA API'nin gizlilik özelliklerini temelden değiştireceğinden, üzerinde düşündüğümüz bir konu değildir. |
| Yayıncı Denetimleri | Yayıncılar, sayfalarında PA API reklam öğelerini engelleyebilir mi? | Chrome'da henüz test edilmeye uygun olmayan gerçek zamanlı reklam öğesi tarama teklifi vardır. Bu özellik henüz kullanıma sunulmamış olsa da çoğu SSP'nin bunu etkinleştirmeye yönelik çözümler oluşturduğunu gözlemledik. |
| API Kullanımı | perBuyerSignals için boyut sınırı nedir? | perBuyerSignals, klasik biçiminde Chrome'da doğal bir boyut sınırına sahip değildir. Birincil kısıtlamalar, verilerin JSON olarak serileştirilebilir kalması ve aşırı bellek tüketimine neden olmamasıdır. Ancak perBuyerSignals öğesinin çok büyük ve karmaşık olması performansı olumsuz yönde etkileyebilir. perBuyerSignals parametresini directFromSellerSignalsHeaderAdSlot üzerinden iletmek için alternatif bir yöntem vardır. Bu yaklaşım, üstbilgi yanıtının tamamı için 10 KB'lık maksimum boyut sınırına tabi olarak perBuyerSignals'i bir üstbilgi içinde iletir. Ayrıca, her sunucu maksimum üstbilgi boyutu için kendi kısıtlamalarını uygulayabilir. |
| Belgeler | generateBid içinden registerAdBeacon çağrısı ile ilgili dokümanların değiştirilmesi gerekiyor. | Bu dokümanı 17 Şubat'ta güncelledik. |
| API Kullanımı | reportEvent, birden fazla kayıtlı seçenek arasından doğru işaretçi URL'sini nasıl seçer? | Her açık artırma ayrı bir yapılandırmayla sonuçlanır ve bu da ayrı bir raporlama haritasıyla sonuçlanır. Teklifler (ve bunların oluşturduğu çerçeveler) birbirinden tamamen ayrıdır ve veri paylaşmaz. "Çitli çerçeve reklam raporları" başlıklı makalede bu konu hakkında daha fazla bilgi verilmektedir. |
| Chrome kullanıcı arayüzü | Chrome DevTools "Uygulama -> "İlgi alanı grupları" sekmesine filtre ekleyin. Bu filtre, IG sahibine (veya belki de IG adına) göre filtreleme yapmanıza olanak tanır. | Bu isteği değerlendiriyoruz ve ekosistemden ek geri bildirimler bekliyoruz. |
| Gözetimsiz Chrome | Gözetimsiz Chrome'da PA API desteği. | PA API'nin Chrome'a bağlı bazı bileşenleri vardır (ör. Google'ın sunucularına yapılan k-anon çağrıları). Bu bileşenler, "eski" Headless Chrome'da çalışmayabilir. Bu sorunun, Chrome 112'de yayınlanan Headless Chrome'un "yeni" sürümünde giderilebileceğini düşünüyoruz. |
| API Kullanımı | reportAdAuctionLoss ile kayıp raporlama söz konusu olduğunda, çoğu durumda "topLevelWinningBid=0" değerini görüyoruz. Bunun yorumu nedir? | topLevelWinningBid değeri, üst düzey satıcı bileşenindeki scoreAd() işlevinden gelir. Bu değer, üst düzey açık artırmanın sonucunu belirlemede rol oynar. Açıklayıcıya göre, sıfır veya herhangi bir negatif sayı olan bir topLevelWinningBid değeri, ilgili reklamın açık artırmayı kazanmaya uygun olmadığını gösterir. Bu mekanizma, örneğin, bağlama dayalı olarak hedeflenen bir adayı aşmayan ilgi alanı grubu hedeflenen reklamları filtrelemek için kullanılabilir. Sıfır değerli bir topLevelWinningBid, bağlamsal bir açık artırmanın kazandığını belirtebilir ancak PA API spesifikasyonu, bu sonuca diğer faktörlerin de katkıda bulunabileceğini kabul eder. |
| Mod A/B testi | B modu ve A modu trafik seçimi ve kapsam dışında kalma istemleri hakkında açıklama. | A modu ve B modu için dahil etme ölçütleri aynıdır. Amaç, bazı istemci yapılandırmaları uyumlu olmadığından, Özel Korumalı Alan API'lerini ve etiketleme yöntemini destekledikleri sürece normal Chrome trafiğini temsil eden gruplar oluşturmaktır. Deneme amacıyla, yalnızca etiketlenmiş trafiğin diğer etiketlenmiş trafikle karşılaştırılması önemlidir. B modundaki kullanıcıların İzleme Koruması özelliği etkindir ve bu nedenle bu özellik hakkında bildirim alırlar. |
| API İyileştirmesi | "lifetimeMs", joinAdInterestGroup çağrısı içinde doğrudan bir mülk olarak eklenebilir mi veya ayrı bir bağımsız değişken olarak yönetilebilir mi? | PA API teklifindeki "joinAdInterestGroup" işleviyle ilgili olarak web geliştirme topluluğundan gelen geri bildirimleri dikkatlice değerlendiriyoruz. Tartışmanın önemli noktalarından biri, IG yaşam sürelerini yönetmek için en uygun yönteme odaklanmaktadır. "lifetimeMs" parametresi için ayrı bir bağımsız değişkenin avantajlarını değerlendiriyoruz. Bu bağımsız değişken, gelecekte spesifikasyonda yapılacak olası iyileştirmeler için esnekliği ve uyarlanabilirliği destekler. Bu sorunu burada ele alıyoruz ve ek geri bildirimlerinizi bekliyoruz. |
| API Kullanımı | Düşük entropi değerine sahip tarayıcı kimlikleriyle çakışmalar nedeniyle PA API çerçevesinde yanlış negatif oranlarının artması olasılığı. | Chrome ekibi, PA API çerçevesinin sürekli olarak iyileştirilmesi için aktif olarak çalışmaktadır. Tarayıcı kimliği çakışmalarından kaynaklanan olası yanlış negatif oranlarla ilgili tartışma için teşekkür ederiz. Bu geri bildirimi dikkatlice değerlendiriyoruz ve güncellenen analizlerin tüm ilgili faktörleri kapsamlı bir şekilde yansıtmasını sağlamak için çalışıyoruz. Doğruluğu ve güvenilirliği korurken istenen gizlilik sonuçlarını sağlayan bir çözüm sunma konusunda kararlıyız. Bu sorunu burada ele alıyoruz ve ek geri bildirimlerinizi bekliyoruz. |
| API Kullanımı | Müşterilerin k-anonimlik sisteminde aynı nesne için tekrar tekrar "Birleştir" isteği göndermesini önlemek amacıyla düşük entropi değerine sahip bir tarayıcı tanımlayıcısı gerekli mi? | K-anonim sistemlerin uygulanmasında tarayıcı tanımlayıcılarının kullanımıyla ilgili devam eden tartışmayı kabul ediyor ve bu tartışmaya katkıda bulunanlara teşekkür ediyoruz. Bu tür tanımlayıcıların gizlilikle ilgili olası etkileriyle ilgili endişeleri anlıyoruz. İlk uygulamamızda, kötüye kullanım karşıtı bir mekanizma olarak düşük entropi değerine sahip bir tanımlayıcı kullanırken, sistemin bütünlüğünü korurken kullanıcı gizliliğine öncelik veren Anonymous Counting Tokens gibi alternatif teknikleri aktif olarak araştırıyoruz. Sorumlu veri kullanımı ile güçlü gizlilik korumaları arasında denge kuran çözümler bulmaya kararlıyız ve araştırma topluluğuyla olan diyaloğumuzu sürdürmekten memnuniyet duyarız. Bu konuyu buradan tartışıyoruz. Ek geri bildirimlerinizi bekliyoruz. |
| API Kullanımı | AMP (Accelerated Mobile Pages), PA API'yi destekler mi? | AMP şu anda PA API'yi doğal olarak desteklemiyor. AMP desteği sizin için önemliyse ekosistemden ek geri bildirim almaktan memnuniyet duyarız. |
| API İyileştirmesi | Türü k-anonimlik kontrollerinden kaldırabilirsiniz. | K-anonimlik istek yapılarının optimize edilmesiyle ilgili geri bildirimleri dikkatle değerlendiriyoruz. Süreci kolaylaştırmak için parametreleri birleştirme ve türleri birleştirme önerisini anlıyoruz. Amacımız verimlilik ve sürdürülebilirlik sağlamaktır. Gizlilik çözümlerimizi geliştirmeye devam ederken tüm seçenekleri değerlendiriyoruz. Bu sorunu burada ele alıyoruz ve ek geri bildirimlerinizi bekliyoruz. |
| Chrome kullanıcı arayüzü | Teknik bilgisi az olan kullanıcıların, kapsam dışında kalmayla ilgili web sitesi düzeyinde olası kontroller de dahil olmak üzere ait oldukları IG'leri kolayca görüntüleyip yönetmelerini sağlayacak bir mekanizma isteğinde bulunun. | IG'leri anlama ve yönetmek için kullanıcı dostu araçlar sunmanın öneminin farkındayız. Çeşitli yöntemleri dikkatlice inceledik ve IG'lerin, katıldıkları web sitesine göre tanımlanmasının netlik ve gizlilik koruması açısından en iyi dengeyi sağladığını tespit ettik. Şu anda IG'lerin genel yönetimi Chrome'un ayarlarında yer almaktadır. Bu alandaki kullanıcı deneyimini daha da iyileştirmenin yollarını sürekli olarak araştırıyoruz. Bu sorunu burada ele alıyoruz ve ek geri bildirimlerinizi bekliyoruz. |
| API Güvenliği | PA API, çitli çerçeveler bağlamında bile reklam öğesi etkileşimleri yoluyla gizlilik sızıntılarına karşı savunmasız mı? | Gelişmiş reklam etkileşimleri yoluyla bilgi sızıntısı olasılığını kabul ediyoruz. Çitli çerçeveler, PA API ve olası saldırı vektörleri arasındaki etkileşimi aktif olarak araştırıyoruz. Gizlilik risklerini azaltmak birinci önceliğimizdir. Yenilikçiliği kullanıcı korumasıyla dengeleyen güçlü çözümler geliştirmeye kararlıyız. Bu sorunu burada ele alıyoruz ve ek geri bildirimlerinizi bekliyoruz. |
| Gecikme | Alıcı teklif verme mantığı için varsayılan 50 ms zaman aşımı gerçekçi bir değer mi? | Teklif verme mantığıyla ilgili ağ isteklerinin zamanlaması ve spesifikasyon arasındaki olası tutarsızlıklarla ilgili endişeleri anlıyoruz. Doğruluğundan emin olmak için teknik özellikleri etkin bir şekilde inceliyoruz ve performans ile uygulanabilirliği dengelemek için optimum varsayılan zaman aşımı ayarlarını araştırıyoruz. Bu sorunu burada ele alıyoruz ve ek geri bildirimlerinizi bekliyoruz. |
| Belgeler | Bir web sitesinin, bir reklamın k-anonimlik eşiğini geçip geçmediğini anlayabileceği spesifikasyonda olası zamanlama sızıntısı ve siteler arası izlemeyle ilgili olası sonuçlar. | Olası bir zamanlama sızıntısı sorunuyla ilgili olarak bildirilen sorunun farkındayız. Spesifikasyonda bir tutarsızlık olduğunu doğruladık ve bu tür sızıntıları önlemek için reklamların k-anonimlik durumunun açık artırmadan önce belirlenmesini sağlamak üzere adımlar atıyoruz. Bu endişeleri ciddiye alıyoruz ve spesifikasyonu bu değişiklikleri yansıtacak şekilde güncelleyeceğiz. Bu sorunu burada ele alıyoruz ve ek geri bildirimlerinizi bekliyoruz. |
| API Kullanımı | PA API'sinde SSP engellenenler listesini uygulama yöntemleri. | SSP'ler tarafından reklam kısıtlamalarının yönetilmesine yönelik mekanizmalara ihtiyaç olduğunun farkındayız. Esneklik sağlarken kullanıcı gizliliğini korumak için cihaz üzerinde değerlendirmeye öncelik veren ve mevcut reklam meta verilerinden yararlanan çözümleri keşfetmenizi öneririz. PA API'de en uygun yaklaşımları belirlemek için geliştiricilerle birlikte çalışmaya kararlıyız. Bu sorunu burada ele alıyoruz ve ek geri bildirimlerinizi bekliyoruz. |
| API Kullanımı | Kullanıcılar, tarayıcılarına sitelerin algılayamayacağı bir şekilde PA API'yi kullanıyormuş gibi davranmasını söyleyebilir mi? | PA API'nin mevcut biçiminde devre dışı bırakılmasının web siteleri tarafından algılanabilir olabileceğini kabul ediyoruz. Gizliliği iyileştirmek ve algılanamayacak kapsam dışında kalma seçenekleri sunmak için Ek Teklifler ve Negatif Hedefleme gibi özelliklerin yanı sıra Çitli Çerçeve oluşturma üzerinde aktif olarak çalışıyoruz. Bu sorunu burada ele alıyoruz ve ek geri bildirimlerinizi bekliyoruz. |
| Mod A/B testi | 1.1 işleme olarak iddia edilen veri merkezi trafiği. | Chrome ekibi, GAM ekibiyle yaptığı görüşmede bu trafiğin artık denemeden filtrelendiğini doğruladı. Bu sorunu burada ele alıyoruz ve ek geri bildirimlerinizi bekliyoruz. |
| API Kullanımı | PA API'deki interestGroupBuyers uygulamasının verimliliği ve adaleti. | PA API açık artırmalarında "interestGroupBuyers" alanının verimliliği ve adaleti hakkında devam eden tartışmanın farkındayız. Verimlilik, gizlilik ve pazar adaleti arasında dengelerin olduğunun farkındayız. Satıcıların alıcılarla olan iş ilişkilerini yönetmesi gerekirken biz de eşleştirme sürecini optimize etmenin yollarını araştırıyoruz. Bunlar, gerçek zamanlı verilere ve karma modellere dayalı dinamik ayarlamalar içerebilir. Kullanıcı gizliliğine öncelik veren ve rekabetçi bir reklamcılık ekosistemini destekleyen çözümler bulmaya kararlıyız. Bu sorunu burada ele alıyoruz ve ek geri bildirimlerinizi bekliyoruz. |
| Chrome kullanıcı arayüzü | Chrome'da IG ile ilgili olası bellek sorunları ve kullanıcı arayüzü netliği. | Geliştirici Araçları'nda IG'lerin gösterilmesiyle ilgili endişeleri anlıyoruz. Mevcut görünüm, geçmiş izleme için tüm IG etkinliklerini yansıtsa da depolanan IG'lerin mevcut durumu hakkında daha net bir görünüm sunmanın değerini kabul ediyoruz. Geliştirici analizlerini iyileştirmek için optimizasyonlar ve potansiyel kullanıcı arayüzü iyileştirmeleri üzerinde çalışacağız. Bellek yönetimiyle ilgili olarak, IG uygulaması bellek sızıntılarını önlemek için tasarlanmıştır ancak kaynak kullanımını sürekli olarak izler ve optimize ederiz. Bu sorunu burada ele alıyoruz ve ek geri bildirimlerinizi bekliyoruz. |
| Belgeler | Orijinal poster, adlandırılmış reklam boyutlarını doğrudan "joinAdInterestGroup" işlevinin "sizeGroup" alanında kullanmaya çalışırken hatayla karşılaşıyor. Bu davranışın istenen bir davranış olup olmadığını öğrenmek isterler. | "joinAdInterestGroup" işlevinde reklam yapılandırmasını kolaylaştırmanın değerini anlıyoruz. Bu sınırlamayı gidermek için çalışmalarımızı sürdürüyoruz ve bu işlevi gelecekteki güncellemelerde etkinleştirmeyi planlıyoruz. Bu iyileştirme, geliştiricilere reklam yönetimi için esnek ve verimli araçlar sunma taahhüdümüzle uyumludur. Bu sorunu burada ele alıyoruz ve ek geri bildirimlerinizi bekliyoruz. |
| Chrome tarafından yönetilen test etiketi | Denemeyi tutarlı bir şekilde izleyebilmemiz için sendReportTo parametresinde A ve B modu hakkında doğrudan veri ve tam etiketler olmasını isteyin. | Bu isteği burada tartışıyoruz ve ek geri bildirimlerinizi bekliyoruz. |
| Belgeler | Satıcının alan adı, doğrulama amacıyla satıcının güvenilir sunucusuna gönderilen isteklere dahil mi? | Ana makine adı parametresinin Protected Audience KV Server API dokümanında ilk başta eksik bırakıldığını kabul ediyoruz. Geliştiricilerin, satıcının alan adının satıcının güvenilir sunucusuna gönderilen isteklere otomatik olarak dahil edildiğinden emin olmalarını isteriz. Bu işlev, güçlü reklam doğrulama süreçleri için gereklidir. Bu gözden kaçışı gidermek için dokümanları güncelledik. Geliştirici topluluğu için netlik ve şeffaflığa öncelik vermeye devam edeceğiz. Bu sorunu burada ele alıyoruz ve ek geri bildirimlerinizi bekliyoruz. |
| API Kullanımı | Raporlama amacıyla IG adını reklam gösterimi izleme çağrılarına dahil etmenin olası yöntemleri. | Güçlü raporlama mekanizmalarına duyulan ihtiyacı, kullanıcı gizliliğiyle ilgili temel ilkeyle dengelemeyi taahhüt ediyoruz. IG adlarının reklam gösterimi izlemeye dahil edilmesi, kişilerin kimliğinin belirlenmesini önlemek için tasarlanmış k-anonimlik önlemlerine tabidir. Bu gizlilik kısıtlamaları dahilinde yenilikçi raporlama çözümleri üzerinde çalışmaya devam edeceğiz. Bu sorunu burada ele alıyoruz ve ek geri bildirimlerinizi bekliyoruz. |
| API Özelliği | Alıcı güvenilir sunucusunun istemci ipuçları HTTP üst bilgilerini almasını isteyin. | Bu özellik isteğini burada takip ediyoruz. |
| API Kullanımı | Tarayıcı için IG üyelik davranışını belirlediği için yetkilendirme dosyasının "Access-Control-Allow-Origin" başlığının yüklenmesi gerekip gerekmediği? | Web güvenliğiyle ilgili en iyi uygulamalara uymaya kararlıyız. Yetkilendirme dosyaları için "Access-Control-Allow-Origin" başlığı şartı, CORS ilkeleriyle tutarlılık sağlar ve hassas bilgilerin istenmeden açığa çıkmasını önler. Güçlü bir güvenlik duruşunu korurken bu süreci optimize etmenin yollarını araştırıyoruz. Bu sorunu burada ele alıyoruz ve ek geri bildirimlerinizi bekliyoruz. |
| API Kullanımı | Reklam sunucularının PA API çerçevesi içinde reklam öğelerini kişiselleştirmesini etkinleştirin. | Reklam sunucularının reklam öğesi kişiselleştirmede oynayabileceği rolün farkındayız. PA API'de reklam sunucularını güçlendirecek çözümleri (ör. teklif verme ve reklam öğesi seçim mantığının birleştirilebileceği "ortak IG" modeli) etkin bir şekilde araştırıyoruz. Amacımız, güçlü reklam öğesi özellikleri sunma ve kullanıcı gizliliğini koruma arasında denge sağlamaktır. API'yi tüm paydaşların ihtiyaçlarını karşılayacak şekilde geliştirmek için daha fazla işbirliği ve geri bildiriminizi buradan bekliyoruz. |
| Gizlilikle İlgili Sorunlar | Alternatif tanımlayıcıların kullanılabilirliği (ör. RampID, ID5) içeriğe dayalı teklif isteklerinde kullanılması, siteler arası veri toplamayı kolaylaştırarak PA API'nin gizlilik hedeflerini zayıflatabilir. | Siteler arası tanımlayıcılar ile PA API'nin gizlilik hedefleri arasında olası bir gerilim olduğunun farkındayız. Yayıncılar bu tür tanımlayıcıları paylaşmayı seçebilir ancak PA API'nin tasarımı temel olarak reklam seçimini siteler arası izleme ihtiyacından ayırmayı amaçlar. Gizlilik odaklı bir reklamcılık ekosistemi oluşturma hedefine sıkı sıkıya bağlıyız ve geliştiricileri PA API yaklaşımına öncelik vermeye teşvik ediyoruz. Bu sorunu burada ele alıyoruz ve ek geri bildirimlerinizi bekliyoruz. |
| Önbelleğe alma | Teklif verme komut dosyalarının birden fazla açık artırmada yeniden kullanılmasını önlemenin bir yolu var mı? | PA API çerçevesi içindeki teklif komut dosyalarının gözlemlenen önbelleğe alma davranışını kabul ediyoruz. Standart HTTP önbelleğe alma mekanizmaları desteklenir ancak cihazın askıya alma davranışı ve teklif yürütücülerin tasarımı nedeniyle açık artırmalarda komut dosyasının yeniden kullanılması olasılığı vardır. Ekip, alıcıların teklif stratejilerini etkili bir şekilde yönetebilmeleri için komut dosyası önbelleğe alma üzerinde daha fazla kontrol sahibi olmalarını sağlayacak çözümleri araştırıyor. Bu sorunu burada ele alıyoruz ve ek geri bildirimlerinizi bekliyoruz. |
| API Kullanımı | Kullanıcı gizliliğine saygı duyarken bir TTP için tüm IG'lerde teklif verme etkinliğinin raporlamasını merkezileştirin. | PA API'yi tasarlarken kullanıcı gizliliğine öncelik veriyoruz. Siteler arası izleme riskleri nedeniyle tek tek teklif etkinliklerinin doğrudan raporlanması mümkün olmasa da Paylaşılan Depolama ve Özel Toplama gibi mekanizmalar sunuyoruz. Bu sayede DSP'ler, kullanıcı gizliliğini koruyacak şekilde teklif verme etkinliği hakkında toplu analizler elde edebilir. |
| API Kullanımı | reportResult() içindeki sendReportTo() işlevinden alınan getirme işlemi, forDebuggingOnly.reportAdAuctionWin() işlevine kaydedilen bir getirme işlemine kıyasla yalnızca% 94 oranında gerçekleşir. | Aynı zamanlamaya sahip olmasalar da her iki URL'nin de aynı anda getirilmesi mümkündür. Bazı durumlarda, bileşen satıcısının iş parçası kaldırılmıştır ve reportResult() işlevinin çalıştırılması için yeniden yüklenmesi gerekir. Ancak, puanlama mantığının getirilmesi için geçen süre veya iş parçasının yeniden yüklenmesi için geçen süre, reportResult() işlevinin 50 ms. zaman aşım süresini etkilemez. Chrome'un, iş parçasının yeniden yüklenmesi gereken durumlarda getirme davranışını tanımlamak için önbelleğe alma üstbilgilerini kullanacağını lütfen unutmayın. PA açık artırmasının aşamaları hakkında daha fazla bilgiyi burada bulabilirsiniz. |
| K-anonimliği | interestGroup adının, reklam sunumunun k-anonimliğini etkilemediğine dair onay isteği. | Bir reklam öğesinin k-anonim olarak kabul edilmesi için IG sahip URL'si, teklifli sistem komut dosyası URL'si, reklam öğesi URL'si ve reklam boyutu dörtlüsünün geçmiş bir dönemde (w) belirtilen eşiği (k) karşılaması gerekir. K-anonimlik durumu düzenli olarak güncellenir (p). |
| Chrome kullanıcı arayüzü | Birçok MVC, ORM vb. çerçevenin sunduğu "dahili görünürlük" türünü sağlama önerisi. Örneğin, Dev Tools --> Uygulama --> Uygulama bölümündeki yeni bir panele seçili dahili etkinlikleri basit bir şekilde günlüğe kaydetmeyle başlayın. | Teklifi burada tartışıyoruz ve ek geri bildirimlerinizi bekliyoruz. |
| Chrome kullanıcı arayüzü | Dev Tools IG birleştirme işlemi, öncelikle ilgili öğeleri göstermez. | Bu sorunu burada ele aldık. |
| API İyileştirmesi | Reklam öğesi reklam sunucusunun kendi etkinliklerini izlemesine izin vermek tercih edilir. İzin verilen izleme alanlarının listesi yapılandırılabilir mi? | Burada bir öneri paylaştık ve ekosistemden ek geri bildirimler almayı bekliyoruz. |
| API Özellik İsteği | PA API, RTB dışı medya işlemlerini desteklemek ve reklam sunma ve DCO gibi kritik kullanım alanlarını korumak için genişletilebilir mi? | Sorunu burada tartışıyoruz ve ek geri bildirimlerinizi bekliyoruz. |
| Yayıncı Açık Artırma Zaman Aşımı | Yayıncıların, özellikle reklamların sırayla seçildiği başlık teklifi kurulumlarında kayıp gösterimleri önlemek için açık artırma süresi üzerinde kontrol sahibi olması gerekir. | Yayıncılara reklam açık artırması zaman aşım süreleri üzerinde ayrıntılı kontrol sağlamanın öneminin farkındayız. Uç durumları dikkatlice göz önünde bulundurarak, olası "auctionConfig" nesnesi içinde bir global açık artırma zaman aşımı mekanizmasının nasıl uygulanacağını aktif olarak araştırıyoruz. Bu özellik, yayıncılar için gösterim doluluk oranlarını optimize etmeyi amaçlamaktadır. En iyi çözümü bulmak için toplulukla birlikte çalışmaya devam edeceğiz. Sorunu burada tartışıyoruz ve ek geri bildirimlerinizi bekliyoruz. |
| API İyileştirmesi | PA API'deki IG'lerin mevcut tasarımı, uzun renderURL'leri nedeniyle büyük meta veri boyutlarına neden oluyor. Test kullanıcıları, daha fazla verimlilik için bu URL'leri sıkıştırmanın bir yolunu arıyor. | Özellikle verimliliğe duyarlı reklam açık artırmaları için IG meta veri boyutunu optimize etmenin önemini biliyoruz. renderURL'leri sıkıştırmak için şablon tabanlı bir çözümün önemli bir potansiyel sunduğunu düşünüyoruz. Önerilen şablon tasarımlarını dikkatlice değerlendiririz ve uygulanan çözümlerin, tarayıcı kararlılığını korumak için güçlü kötüye kullanım önleme mekanizmaları içerdiğinden emin oluruz. Bu hususları göz önünde bulundurarak en uygun yaklaşımı geliştirmek için web standartları topluluğuyla işbirliği yapmak öncelikli olmaya devam etmektedir. Sorunu burada tartışıyoruz ve ek geri bildirimlerinizi bekliyoruz. |
| API Kullanımı | Doğal reklam biçimleriyle çalışan test kullanıcıları, ağ yükünü azaltmak ve reklam oluşturma hızını artırmak için tek bir çağrıda birden fazla reklam sonucu alarak Özel Korumalı Alan açık artırma sürecini optimize etmek ister. | Özel Korumalı Alan'da doğal reklam oluşturma ile ilgili performans endişelerini anlıyoruz. Verimlilikle güçlü kullanıcı gizliliği korumaları arasında dengeyi bulmaya kararlıyız. Tam puana sahip birden fazla reklam döndürülmesi gizliliği ihlal etse de açık artırma sürecini optimize etmenin yollarını etkin bir şekilde araştırıyoruz. Doğal reklam biçimleri için PA API desteğini geliştirmeye ve Özel Korumalı Alan'ın güçlü gizlilik kısıtlamaları dahilinde verimliliği artırmak için alternatif mekanizmalar araştırmaya kararlıyız. Sorunu burada tartışıyoruz ve ek geri bildirimlerinizi bekliyoruz. |
| API Kullanımı | Özellikle öncelik düzeylerini veya özel pazar yeri kurallarını temsil etmek için reklam tekliflerinin Özel Korumalı Alan'da nasıl puanlanacağı ve sıralanacağı konusunda esneklik. | Özellikle karmaşık teklif verme senaryolarında, Özel Korumalı Alan'da reklam puanlama ve sıralama üzerinde ayrıntılı kontrol sahibi olmanın gerekliliğini anlıyoruz. Kullanıcı gizliliğinden ödün vermeden çok boyutlu puanlama elde etmek için kümeler ve matematiksel işlevler kullanan önerilen çözümleri kabul ediyoruz. Bu yaklaşımlar geliştiriciler için karmaşıklık getirebilir ancak gerekli ifadeyi sunar. Gelişmiş açık artırma mantığı için Özel Korumalı Alan özelliklerinin optimum şekilde kullanılmasını sağlamak amacıyla, yardımcı işlevler veya yönergeler aracılığıyla bu süreçleri kolaylaştırmanın yollarını keşfetmeye kararlıyız. Bu sorunu burada ele alıyoruz ve ek geri bildirimlerinizi bekliyoruz. |
| reportEvent() | Reklam öğesi içeren bir çerçeve başlatıldıktan sonra tarayıcı tarafından tetiklenen yeni bir ayrılmış etkinlik (otomatik işaretçi olabilir) ekleyin. | Bu isteği burada tartışıyoruz. Ek geri bildirimlerinizi bekliyoruz. |
| adCost | adCost değerinin dökümüne izin verme. | Her maliyet değeri, açık artırmadan sınırlı miktarda bilgi gönderme fırsatıdır. Bu maliyetlerin N tanesinin tam listesine izin vermek, siteler arası izlemeyi etkinleştirecek tam bir kullanıcı tanımlayıcısı göndermek için yeterli olur. Bu konuyu burada ele alıyoruz ve ek geri bildirimlerinizi bekliyoruz. |
| resolveToConfig | resolveToConfig üst düzeyden devralınmalı ve browserSignals'da gösterilmeli mi? | Bu isteği burada tartışıyoruz. Ek geri bildirimlerinizi bekliyoruz. |
| Daha İyi Araçlar | PA API için chrome://topics-internals'a benzer bir şey var mı? | Hiçbir şey tam olarak aynı değildir. Ancak PA API için geniş kapsamlı geliştirici araçları mevcuttur. |
| Etiketler | Chrome, %20'lik k-anon nüfusunu tanımlamak için etiketleri kullanabilir mi? | Bu isteği değerlendiriyoruz ve ekosistemden ek geri bildirimler almak istiyoruz. |
| Belgeler | Özel Korumalı Alan açık artırma iş parçacıkları standart iş parçası türleri haline gelecek mi? | Benzersiz gizlilik ve güvenlik koşulları nedeniyle bu iş parçacıkları, standart tarayıcı iş parçacığı türlerinden önemli ölçüde farklıdır. Bu nedenle, yakında HTML spesifikasyonunda standart iş parçacığı türleri haline geleceklerini beklemiyoruz. Geliştirici kaynaklarımızı, açık artırma iş parçacıklarının uygulama ve yürütme ortamı hakkında net açıklamalar ekleyerek geliştirmeye ve bu bilgileri Gizlilik Korumalı Alan katılımcıları için daha erişilebilir hale getirmeye kararlıyız. Bu konuyu daha ayrıntılı olarak burada ele aldık. |
| Kendi Sunucunuzu Getirin (BYOS) Anahtar/Değer (KV) sunucusu | Taraflar, BYOS KV Hizmeti kurulumunda KV hizmetleri sorguları aracılığıyla bir kullanıcının katıldığı birden fazla IG'yi (aynı sahipten) öğrenebilir. | KV sunucuları TEE'lerde çalıştırıldığında ve yayınlanan güven modeline uyabileceklerinden emin olabildiğimizde bu artık mümkün olmayacaktır. |
| userBiddingSignals | "userBiddingSignals"in bir kısmını güncellerken diğerini koruyabilirsiniz. | Bu, API'de herhangi bir değişiklik yapmadan zaten mümkündür. |
| API Kullanımı | KV sunucusunu veya değiştirilmiş "prevWinsMs" verilerini kullanarak Özel Korumalı Alan'daki birden fazla IG'de sıklık sınırı uygulayın. | Özel Korumalı Alan'da gelişmiş sıklık sınırlama özelliklerine olan ihtiyacın farkındayız. IG'ler arasında veri paylaşımıyla ilgili mevcut kısıtlamaların bu stratejilerin uygulanmasında zorluklar oluşturabileceğinin farkındayız. KV sunucusu, uygun gizlilik önlemlerine sahip potansiyel bir mekanizma sağlar. Ancak geliştiricilerin tek bir IG modelinde çözümleri keşfetmelerini öneririz. Bu sorunu burada ele alıyoruz ve ek geri bildirimlerinizi bekliyoruz. |
| API Kullanımı | Bileşen satıcıları (Gizlilik Korumalı Alan'daki iç içe yerleştirilmiş açık artırmalara katılanlar), kendi yapılandırmalarını optimize etmek ve gereksiz gecikmeleri önlemek için üst düzey açık artırma zaman aşımlarını görebilmelidir. | Özel Korumalı Alan'daki üst düzey satıcılar ile bileşen satıcıları arasında daha iyi zaman aşımı koordinasyonu yapılması gerektiğinin farkındayız. Tüm açık artırma için olası bir zaman aşımı da dahil olmak üzere yeni zaman aşımı mekanizmalarının eklenmesini aktif olarak araştırıyor ve bileşen açık artırmalarına üst düzey zaman aşımları uygulamanın yollarını araştırıyoruz. Hedefimiz, Özel Korumalı Alan açık artırma sürecine katılan tüm tarafların verimliliğini ve öngörülebilirliğini artırmaktır. Bu sorunu burada ele alıyoruz ve ek geri bildirimlerinizi bekliyoruz. |
Protected Audience Hizmetleri
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Güvenilir Yürütme Ortamları (TEE'ler) | TEE'leri şirket içi reklam teknolojisi veri merkezleri yerine herkese açık bulutlarda çalıştırmak daha mı pahalı? | Yanıtımız önceki çeyreklerdekine benzer: Mevcut TEE güvenlik modelimiz, herkese açık bulut uygulamalarının uygulamalarından yararlanır. Özellikle mevcut donanım tabanlı TEE'ler tüm fiziksel saldırılara karşı koruma sağlamaz. Desteklenen mevcut herkese açık bulut sağlayıcılarımız AWS ve Google Cloud, çalışanlar da dahil olmak üzere fiziksel erişim riskleri için azaltıcı önlemler tasarlayıp uyguladı. Şirket içi destek hakkında aşağıdaki ayrıntılara bakın. Reklam teknolojisi uzmanları, bulut hizmetlerini çalıştırmanın şirket içi reklam teknolojisi veri merkezlerinden daha pahalı olduğunu belirtti. Bu ifadeleri değerlendirme yetkimiz olmasa da maliyetlerle ilgili ek geri bildirimler bekliyoruz ve TEE desteğimizi genişletme seçeneklerini değerlendirmeye devam ediyoruz. |
| TEEs | Herkese açık olmayan bulut ortamlarında TEE'ler için destek | Yanıtımız önceki çeyreklerle benzer: Herkese açık bulut tabanlı çözümlerin ötesindeki seçenekler için destek sunmaya devam ederken, şu anda şirket içi TEE'leri destekleme planımız bulunmuyor. Bu aşamada, Özel Korumalı Alan güvenlik şartları ve şirket içi dağıtımların sunduğu önemli zorluklar göz önüne alındığında, bulut tabanlı dağıtımları genişletmeye ve iyileştirmeye (ör. AWS'ye ek olarak Google Cloud'u desteklemeye) devam etmenin ekosistem için en yararlı seçenek olduğuna inanıyoruz. Ancak gizlilik ve güvenlik kısıtlamaları göz önüne alındığında bu tür bir şartın neden gerekli ve uygulanabilir olduğu konusunda ek geri bildirimler bekliyoruz. |
| Diğer Bulut Sağlayıcılar | Diğer bulut sağlayıcılar için destek | Diğer bulut sağlayıcılarla ilgili önerilere her zaman açığız ancak 3PCD zorunlu hale getirildiğinde en azından Google Cloud ve AWS'yi desteklemeyi planlıyoruz. Daha fazla bilgi için bu açıklamayı inceleyin. |
| B&A Services API | Google'ın B&A Services API ile ilgili politikası nedir? Cihaz açık artırmalarında Chrome Tarayıcı Protected Audience'ın üstünde mi yoksa altında mı öncelikli olacak? | Yanıtımız önceki çeyreklerle benzer: Mevcut Protected Audience cihaz üzerinde teklif verme tasarımına bağlıyız. B&A hizmetleri, cihazın bilgi işlem gücünün veya ağ hızının sınırlı olabileceği kullanım alanlarının bir alt kümesini desteklemek için olası çözümleri keşfetmek amacıyla önerilmiştir. |
| Standartlaştırma | B&A hizmetleri standartlaştırma sürecinden geçmemiştir. | B&A Hizmetleri önerisi, standartlaştırma sürecinin bir aşamasının ortasındadır ve bu hedefi desteklemek için ek etkileşime açığız. Öneri (önceki önerilere dayalı) ile başladı ve W3C'de kapsamlı bir açık tartışmayla herkese açık olarak geliştiriliyor. İlgili geliştiriciler, bu öneriyi denemeye ve geri bildirim vermeye başlayabilir. Bu, web özelliği geliştirmede genellikle izlenen yoldur. Örneğin, buradaki blog yayınımızda bu konu açıklanmaktadır. |
| KV sunucusu | İçerik / bağlam / site hedefleme için tam URL'yi alıcının KV sunucusuna gösterin. | Bu isteği burada ele alıyoruz ve ekosistemden ek geri bildirimler almaktan memnuniyet duyarız. |
| Belgeler | GitHub'daki "Güvenilir/Zorunlu bileşenler ve isteğe bağlı bileşenler" dokümanları, kendi dağıtım resimleri ve altyapıları olan bazı reklam teknolojisi uzmanları arasında kafa karışıklığına neden oluyor. | "Güvenilir/Zorunlu bileşenler ve isteğe bağlı bileşenler" konulu dokümanları iyileştirmek istiyoruz. Bu tür çalışmalara öncelik verilmesinin gerekip gerekmediğini ekosistemden öğrenmek isteriz. |
| API İyileştirmesi | KV sunucu çağrısının HTTP durum kodu, scoreAd() işlevi tarafından parametre olarak da kullanılabilir. | Bu isteği değerlendiriyoruz ve ekosistemden ek geri bildirimler bekliyoruz. |
| Belgeler | JS ve WASM iş yüklerinin UDF yürütmeyle tam olarak nasıl ele alınacağı hakkında daha fazla bilgi verin. | Bu bilgileri sunmak için çalışmalarımızı sürdürüyoruz. Burada ek geri bildirimlerinizi paylaşabilirsiniz. |
| Belgeler | Depo adının güncellenmesi için istekte bulunma. | Depoyu "protected-auction-key-value-service" olarak yeniden adlandırdık. Bu, ait olduğu hizmet koleksiyonunun terimiyle uyumludur. Bu koleksiyonda Protected Audience Services tartışması ve Protected Auction Services dokümanları gibi başka depolar da bulunur. |
| Belgeler | bidding_auction_services_gcp_guide.md dosyasında Cloud hata ayıklayıcı API'sine yapılan referansı kaldırın. | Dokümanları güncelledik ve referansı kaldırdık. |
| API Kullanımı | KV araması nedeniyle oluşan gecikme 50 ms'den uzun sürüyor. Bu işlem yaklaşık 100 ms sürüyor. Diğer satıcılar için işe yarayan yöntemler hakkında öneriniz var mı? Zaman aşımları ve zamanlamayı nasıl ölçeceğiniz konusunda öneriniz var mı? |
KV sunucusu çağrısı, komut dosyası çalıştırıcıları bağlamında (yani Chrome tarayıcısının içindeki özel korumalı ortamda) gerçekleşir. Bu komut dosyası çalıştırıcılarındaki bilgilerin API dışı erişime karşı korunması amaçlanmıştır. Ayrıntılı açıklamayı burada bulabilirsiniz. |
| API Kullanımı | KV sunucusunun belirli bir sürede yanıt vermesi için zaman aşımı var mı? | Satıcılar, açık artırma yapılandırmasında "perBuyerCumulativeTimeouts" alanını belirtebilir. Bu zaman aşımı, güvenilir teklif sinyallerini getirmenin gerektirdiği süreyi içerir. |
| Gecikme | Özel Korumalı Alan ekibi, gecikmeyi gidermek için nasıl çalışıyor? | Gecikmeyi kabul edilebilir sınırlar içinde tutmak için araştırdığımız stratejiler için bu makaleyi inceleyin. |
Dijital reklamları ölçme
İlişkilendirme raporları (ve diğer API'ler)
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Manuel Kampanya Optimizasyonu | ARA, manuel kampanya optimizasyonunu desteklemez. | Bu senaryoyu reklam teknolojisiyle görüştük ve manuel kampanya optimizasyonunu desteklemek için ARA'nın nasıl kullanılabileceğini gösterdik. ARA, çeşitli reklam teknolojisi kullanım alanlarını çözmek için reklam teknolojisi özelleştirmesine ve esnekliğe olanak tanıyacak şekilde tasarlanmıştır. Sunulan birkaç öneri arasında, farklı esnek etkinlik düzeyinde yapılandırmalar kullanma ve gürültünün etkisini azaltmak ve manuel ve otomatik optimizasyon ihtiyaçlarını karşılamak için etkinlik düzeyindeki raporları özet raporlarla kullanma yer alıyordu. ARA yapılandırmalarının özelleştirilebilirliği ve esnekliğiyle ilgili ek ekosistem geri bildirimlerini memnuniyetle karşılarız. |
| Dönüşüm türü | Google yalnızca sekiz dönüşüm türüne izin veriyor. Bu da sınırlayıcı bir durum. | Esnek etkinlik düzeyinde raporlamanın büyük bir kısmını kullanıma sunduk. Bu özellik, reklam teknolojisi uzmanlarına raporlama aralıkları, ilişkilendirme raporları ve kullanabilecekleri tetikleyici veri parçaları sayısı açısından ek esneklik sağlar. Reklam teknolojisi uzmanları, 32'ye kadar farklı dönüşüm türünü ölçmeye olanak tanıyan bir yapılandırma seçebilir. |
| Toplanabilir Rapor Etkinliği Sınırı | Birleştirilebilir rapor başına minimum 20 dönüşüm etkinliği, sınırlı bütçeye sahip küçük reklamverenler için uygun değildir. | Birleştirilebilir rapor başına minimum dönüşüm etkinliği sayısı yoktur. Ayrıca, daha küçük reklamverenler için birleştirilebilir raporları optimize etmek amacıyla, izlenen anahtar yapıyı / boyutları değiştirme, farklı epsilon seviyelerini test etme, daha uzun toplu işlem sıklıkları test etme ve ölçüm hedefleri arasında farklı katkı bütçesi tahsislerini test etme gibi çeşitli tasarım kararları alınabilir. Daha küçük reklam teknolojileri şirketleri, gürültünün etkisini azaltmak için etkinlik düzeyindeki raporları ve özet raporları birleştirmeyi de deneyebilir. |
| Gerçek Zamanlı Veriler | DSP'lerin teklif stratejilerini uyarlamak ve daha iyi kampanya etkinliği elde etmek için kullandıkları gerçek zamanlı verilerden (ör. tıklamalar, oturumlar ve dönüşümler) mahrum bırakmak, mevcut işlevleri sürdürme taahhüdüne aykırıdır. | ARA ile bile tıklamalar ve oturumlar gerçek zamanlı olarak kalır ve dönüşümler, 3PC'ler kullanılsa bile her zaman sonradan raporlanır. |
| Eksik Alanlar | Tam esnek etkinlik kullanıma sunma sürecinde eksik koşullar: i) Para birimi alanı ve ii) orderID / TransactionID alanı. | Mevcut etkinlik düzeyinde raporlamayla bunu yapmanın yolları zaten olduğundan, tam esnek etkinlik düzeyinin bir parçası olarak şu anda para birimi alanını veya sipariş kimliği / işlem kimliği alanını desteklemeyi planlamıyoruz. Bu alanlarla ilgili ek geri bildirimlere açığız ve bunları gerektiren başka kullanım alanları olup olmadığını yeniden değerlendireceğiz. ARA'nın mevcut tasarımını para birimi ve sipariş kimliği türü bilgilerini ölçmek için kullanmanın yolları: 1. Geri bildirime göre para birimi, kullanıcının coğrafi konumuna göre belirlenir. Bu konum, hangi para biriminin kullanıldığını belirlemek için source_event_id kapsamında eklenebilir. 2. Geri bildirime göre, dönüşümlerin ve değerlerin yanlışlıkla iki kez sayılmamasını sağlamak için sipariş kimliği alanının kullanılması gerekir. Bu işlem, tekilleştirme anahtarları kullanılarak yapılabilir. |
| Gizli Erişim Limiti | ARA Gizlilik Bütçesi, birden fazla boyutta ölçüm yapma olanağını sınırlar | ARA, reklam teknolojilerinin çeşitli ilişkilendirme senaryolarını kapsayacak şekilde kendi ARA yapılandırmalarını özelleştirmelerine olanak tanıyacak şekilde tasarlanmıştır. Mevcut ARA tasarımında reklam teknolojilerinin, ölçmeleri için en önemli olan boyutlar ile verilerindeki gürültünün etkisi arasındaki dengeyi düşünmesi gerekir. Ölçülen boyutların ayrıntı düzeyine bağlı olarak verilere gürültü eklemek gizlilik açısından çok önemlidir. Farklı boyutlarda ölçüm yapma özelliğiyle ilgili ek ekosistem geri bildirimlerine açığız ancak bunun gerektirdiği belirli kullanım alanlarını anlamamız gerekir. |
| Spesifikasyonu güncelleme | Google, sabit etkinlik raporlama aralıklarını esnek aralıklarla değiştirdiğini belirtmiş olsa da bu durum Google'ın Teknik Özellikleri'ne yansıtılmadı. Teknik Özellikler'de hâlâ minimum bir saatlik aralık geçerli. | Esnek etkinlik düzeyinde raporlama, reklam teknolojilerinin şu anda kaynak etkinlik başına ilişkilendirme raporlarının sayısını, tetikleyici verilerin bitlerini ve raporlama aralıklarını değiştirmesine olanak tanır. ARA'da etkinlik düzeyindeki raporlar için hâlâ 1 saatlik minimum bir raporlama aralığı vardır. Bu, gizliliği korumak ve belirli türde geçmiş yeniden oluşturma saldırılarını azaltmak için gereklidir. Özet raporlar toplu olarak bilgi sağladığından, reklam teknolojileri, kullanım alanları için gerekirse toplu raporları gecikmeden hemen almayı etkinleştirebilir. |
| API Tasarımı | Dönüşüm raporlarındaki bilgilerin azaltılması ve raporlara gereksiz bilgi eklenmesi, ekosistemi Google'dan daha fazla etkileyebilir. | Google, CMA'ya Özel Korumalı Alan tekliflerini Google'ın kendi işletmesini tercih ederek rekabeti bozmayacak şekilde tasarlayıp uygulamayı ve dijital reklamcılıktaki rekabeti, tüm ölçeklerdeki yayıncıları ve reklamverenleri üzerindeki etkiyi dikkate almayı taahhüt etmiştir. |
| İlişkilendirme Düzeltmesi | ARA, teknoloji sağlayıcının doğru ilişkilendirmeyi kontrol etmesine ve doğrulamasına izin vermez. | ARA'da doğrulama özellikleri sunan birçok çözüm mevcuttur: 1. Reklam teknolojisi uzmanları, ARA davranışının beklentileriyle eşleştiğini doğrulayabilir: – ARA istemci tarafı kodu açık kaynaktır. – ARA sunucu tarafı kodu da açık kaynaktır ve koordinatörler, yalnızca izin verilen toplama hizmeti sürümlerinin toplanabilir raporların şifresini çözebildiğinden ve işleyebildiğinden emin olur. 2. Chrome, reklam teknolojilerinin ilişkilendirme davranışını doğrulamak için reklam teknolojilerinin ARA'nın ilişkilendirmeyi bir simülasyon ortamında nasıl gerçekleştirdiğini test edebileceği bir Simülasyon Kitaplığı sağlamıştır. 3. ARA, beklenen işlemenin gerçekleşip gerçekleşmediğini ve neden gerçekleşmediğini doğrulamaya yardımcı olan çeşitli hata ayıklama sinyallerini destekler. |
| (Önceki çeyreklerde de bildirilmiştir) Gürültü |
Gürültü seviyesinin çok yüksek olduğu ve raporlamanın faydasını etkilediğine dair geri bildirim. | Aynı geri bildirimi veren reklam teknolojisi uzmanlarıyla görüştük ve ARA'nın gürültü olsa bile kullanım alanlarına daha iyi uyacak şekilde özelleştirilebileceği yolları belirledik. Reklam teknolojileriyle görüştüğümüz tasarım kararlarının ve özelleştirmelerin çoğunu içeren bir geliştirici dokümanımız var. ARA, reklam teknolojilerinin çeşitli ilişkilendirme senaryolarını kapsayacak şekilde kendi ARA yapılandırmalarını özelleştirmelerine olanak tanıyacak şekilde tasarlanmıştır. Ancak reklam teknolojisi uzmanlarının, ölçmeleri için en önemli boyutlar ile gürültünün verileri üzerindeki etkisi arasındaki dengeyi düşünmesi gerekir. Gürültünün etkisiyle ilgili ek ekosistem geri bildirimlerine açığız ve gürültünün etkisini değiştirmek için kullanılabilecek ARA kolları hakkında ek rehberlik sağlayabiliriz. |
| Web alanları arası ilişkilendirme | Web alanları arası ilişkilendirmeler nasıl izlenir? | Reklam teknolojileri, bu kullanım alanını çözmek için farklı raporlama URL'lerine yönlendirebilir. ARA'nın bu tasarım özelliğiyle ilgili ek ekosistem geri bildirimlerini memnuniyetle karşılarız. |
| API İyileştirmesi | ARA Özet Raporları için ilişkilendirme kaydederken kullanılan ölçeklendirme faktörünü düzenli olarak değiştirin. | GitHub'daki tartışmaya göre, toplama hizmetinde birden fazla ölçeklendirme faktörü kullanılmasının, büyük olasılıkla mevcut işleve kıyasla özet raporlara daha fazla gürültü eklenmesine neden olacağı anlaşılıyor. Toplanabilir raporların bir parçası olarak ölçeklendirme faktörlerine duyulan ihtiyaçla ilgili ek geri bildirimlere açığız ancak artan gürültü ile olası değiş tokuşları belirtmek istiyoruz. Gelecekte kullanıma sunulacak diğer ARA özelliklerinin de bu kullanım alanını çözmeye yardımcı olup olmayacağını değerlendiriyoruz. |
| API Kullanımı | İlişkilendirme etkinliklerinin tüm katılımcılarla nasıl paylaşılacağı konusunda tek bir yöntem belirleme fırsatı (SSP, DSP vb. için faydalıdır). | Geri bildirimlerini ve karşılaştıkları sınırlamaları daha iyi anlamak için reklam teknolojisiyle senkronize olmayı planlıyoruz. |
| Test Trafik Hacmi | B modu için test trafiği tüm Chrome'larda kararlı mı? | Bir deneme grubuna dahil edilme, Chrome ayarlarından etkilenmez (Chrome ayarlarından bağımsızdır). |
| Belgeler | Pixel'ler için ARA desteği. | Bu kullanım alanının nasıl destekleneceği hakkında bilgi yayınladık ve ekosistemden ek geri bildirimler almaktan memnuniyet duyarız. |
| API Kullanımı | Dönüşüm son temasla yapılmazsa ARA, e-ticaret platformlarındaki üçüncü taraf satıcılar için doğru kaynakla ilişkilendirilmeyebilir. | Şirketler, hatalı ilişkilendirmenin oluşmasını önlemek için filtreler kullanabilir (dönüşüm raporu oluşturulmaz). Ayrıca bu kullanım alanına yardımcı olmak için ilişkilendirme öncesi filtreleme önerisi üzerinde çalışıyoruz. |
| Tarayıcı desteği | ARA farklı tarayıcılarda desteklenecek mi? | Diğer tarayıcıların Özel Korumalı Alan API'lerini benimsemesini memnuniyetle karşılıyoruz ve W3C'de yaklaşımımızı açık bir şekilde tartışmaya devam ediyoruz. ARA'yı kullanıma sunma hedefimiz olarak birlikte çalışabilirliği açıkça belirttik. ARA'nın tasarımı, farklı gizlilik tutumlarına sahip tedarikçiler için tedarikçi tarafından belirtilen esnek değerlerle tarayıcıdan bağımsız olacak şekilde tasarlanmıştır. Diğer tarayıcılar, siteler arası tanımlayıcılara içerik ve hizmetlerin dijital ekosistemini destekleyebilecek uygun alternatifler sunup sunmama konusunda kendi seçimlerini yapıyor. Microsoft Edge'in ARA'yı destekleyeceğini belirtmesi bizi memnun etti. |
| API Kullanımı | registerAdBeacon/reportEvent (ve navigation_start/commit otomatik işaretçiler) için ARA kaynak kayıtlarında beklenen kaynak türü nedir? | Bu, işaretçilerin otomatik mi yoksa manuel mi olduğuna bağlıdır:
- ayrılmış.* (yani otomatik) etkinliklerin gezinme kaynağı türüne sahip olması gerekir. - Manuel olarak tetiklenen etkinlikler etkinlik kaynağı türü olmalıdır. |
| API Kullanımı | Kaynak başına 20 toplu rapor maksimum sınırı, her kaynak etkinliği için mi geçerlidir? Sınır dünya genelinde mi yoksa günlük mü? Sınırın artırılması planlanıyor mu? | Kaynak başına 20 birleştirilebilir rapor sınırı, her kaynak için 20 birleştirilebilir rapor oluşturulabileceği genel bir sınırdır. Sınır tarayıcı tarafından belirlenir ve yapılandırılabilir değildir. Bu sınırın amacı, gerçek ilişkilendirme raporlarının korumasının, boş raporlarla kötüye kullanılmasını önlemektir. Bu konuyu daha ayrıntılı olarak burada ele aldık. |
| API Kullanımı | ARA'yı kullanan e-posta pazarlama için destek. | Şu anda ARA'da bu kullanım alanı için doğrudan destek yoktur (e-posta barındırma sitesini kontrol etmiyorsanız). Bu konuyu burada ele alıyoruz ve ek geri bildirimlerinizi bekliyoruz. |
| Epsilon | Toplu API için epsilon değeri ne zaman belirlenir? | Mevcut epsilon değeri, reklam teknolojileri tarafından Özel Korumalı Alan tarafından tanımlanan önceden belirlenmiş bir eşiğe (şu anda 64) kadar yapılandırılabilir. Farklı epsilon değerlerini test etmenizi, kendi kullanım alanlarınız için dönüm noktalarını belirlemenizi ve geri bildirimde bulunmanızı öneririz. Epsilon değerlerinin aralığında yapılacak değişikliklerden önce reklam teknolojileriyle iletişime geçeceğiz. |
| API İyileştirmesi | Reklamverenlerin dönüşümlerin kalitesini doğrulamalarına olanak tanımak için harici CRM verileriyle eşleştirmek üzere trigger_data alanına bir tanımlayıcı ekleyebildiği bir kullanım alanını destekleyin. | İsteği görüşüyoruz. Burada ek geri bildirimlerinizi bekliyoruz. |
| API Kullanımı | Yönlendirme URL'lerinin hedef URL olarak ele alınması. | Reklam teknolojisi uzmanları aşağıdakilerden birini yapabilir: 1. Nihai hedef URL'yi hedef alanına girin; 2. Hedef alanına en fazla 3 URL girebilirsiniz. Bu sayede alana birden fazla URL ekleyebilirsiniz. Her iki seçenekte de nihai hedef URL'yi bilmeniz gerekir. Bu konuyu buradan daha ayrıntılı olarak inceleyebilirsiniz. |
Aggregation Service
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Anahtar Keşif Mekanizması | Anahtar bulma mekanizması isteği | Anahtar keşfi için bir önerimiz var ve ekosistemden bu öneriyle ilgili geri bildirim almayı bekliyoruz. |
| API Kullanımı | Aggregation Service'te gözlemlenebilirlik için yol haritası | Daha fazla gözlemlenebilirliği desteklemek için seçenekleri inceliyoruz ve ekosistemden buradan geri bildirim almayı bekliyoruz. |
| API İyileştirmesi | Raporları yeniden sorgulamak için izin isteğinde bulunma | Toplama Hizmeti, reklam teknolojilerinin her rapor için epsilon'larını bölebileceği bir istek önerisi üzerinde çalışıyor. Bu, sorgu başına daha fazla gürültü getirebilir ancak reklam teknolojilerinin yeniden sorgu yapmasına ve gizliliği korumasına olanak tanır. |
| API İyileştirmesi | Birden fazla kaynağı aynı AWS kimliğiyle ilişkilendirebilmek istiyorum. | Toplama Hizmeti artık aynı bulut hesabına (Google Cloud veya AWS) birden fazla sitenin eklenmesine izin verecek. Bu sayede reklam teknolojisi uzmanları, birden fazla siteden ve aynı sitelerdeki birden fazla kaynaktan gelen raporları işlemek için aynı toplama hizmeti ağı korumalı alanını kullanabilir. |
| API Kullanımı | Toplanabilir gruplar başarısız olduğunda bütçenin tüketilip tüketilmediğinden ve gruplarını yeniden işleyip işleyemeyeceklerinden emin değiller. Bir toplama hizmeti, yinelenen raporlar için bütçe hatasıyla karşılaştığında kalan raporların geri kalanı kaybolur. Bu kaybı en aza indirmek için ne yapmalıyım? | Tipik bir senaryoda, işin tamamı başarısız olursa bütçe tüketilmez. Bütçenin tüketildiği nadir durumlarda reklam teknolojileri bütçenin geri alınmasını isteyebilir. Reklam teknolojisi, bütçe tükendi hatasıyla sık sık iş hatasıyla karşılaşırsa gruplandırma stratejisini doğrulamalıdır. Doğru şekilde gruplandırma ve yinelenen raporlar ile hatalardan kaçınma talimatlarını burada bulabilirsiniz. Bütçe kurtarma hakkındaki geri bildirimlerinizi buradan bekliyoruz. |
| API Kullanımı | Burada açıklanan tetikleyiciyle Private Aggregation API'yi kullanmak, her açık artırma için birleştirilebilir bir rapor oluşturur. Toplama Hizmeti'nin ölçeklendirme özellikleri nelerdir? | Toplama Hizmeti, bir gruptaki anahtar veya rapor sayısı için üst sınır belirlemez ancak şu anda gerekli olan bellek nedeniyle 10^14 rapor ve 10^12 anahtar ölçeği desteklenmez. Boyutlandırma rehberimizde, beklenen yük ve desteklenen bulut sanal makinesi örnek türleri göz önüne alındığında optimum performans için test ettiğimiz ve önerdiğimiz aralıklar belirtilmiştir. |
| Veri İşleme | Şifrelenmiş verilerde kişisel bilgiler varsa şifrelenmiş verilerin Toplama Hizmeti'ne sağlanması için yasal düzenleme nedir? Koordinatörün şifrelenmiş verilere erişmeyeceğinin garanti edilip edilmediğini öğrenebilir miyim? |
Toplama hizmeti, şifrelenmiş / kullanıcı verilerini Koordinatör ile paylaşmaz. Toplama hizmeti, anahtar yönetimi ve muhasebe için koordinatörü kullanır. Koordinatör hakkında bazı ayrıntıları burada bulabilirsiniz. Toplama hizmeti, muhasebe için yalnızca paylaşılan kimliği ve raporlama kaynağını bütçe tüketimi amacıyla PBS ile paylaşır. Çok siteli bir sürüm kullanıma sunulduğunda origin parametresini site ile değiştireceğiz. Toplama hizmetinin, istemcilerden gelen raporların şifresinin tek başına çözülebildiği TEE'de çalıştığını unutmayın. TEE'de çalışan kod açık kaynaklıdır ve burada belirtildiği gibi harici taraflarca denetlenir. |
Private Aggregation API
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| API Kullanımı | Bileşen satıcılarının, bir TEE'de birden fazla toplama sunucusuna rapor gönderebilmesi. | Geçerli Private Aggregation API durumu bu özelliği desteklemiyor. Bu konuyu burada daha ayrıntılı olarak ele aldık. |
| Belgeler | Google'ın denemelerinde kullanılan epsilon değeri nedir? | Özel Toplama API'sinde, bir toplama hizmeti sorgusunda belirtilen ε değeri, 10 dakikalık bir süre boyunca uygulanan 2^16'lık L1 katkı bütçesine karşılık gelir. Ayrıca, 24 saatlik bir döngüde uygulanan 2^20 değerinde bir "yedek" L1 katkı bütçesi de vardır. Dolayısıyla, gizlilik parametresi 10 dakikalık bir süre boyunca ε, 24 saatlik bir süre boyunca ise 16ε'dir (144ε yerine). Toplama hizmeti, farklı toplama stratejileriyle deneme yapmanıza ve Özel Toplama ile diğer API'ler için farklı gizlilik parametreleriyle sistemin yararı hakkında geri bildirim sağlamanıza olanak tanımak amacıyla şu anda test için ε aralığını (64'e kadar) desteklemektedir. Test kullanıcılarından geri bildirim alırken ve gizlilik bütçesinin daha verimli kullanılmasına olanak tanıyan özellikler eklerken zaman içinde izin verilen maksimum epsilon değerini tekrar gözden geçirmeyi planlıyoruz. |
Gizli İzlemeyi Sınırlama
Kullanıcı Aracısı Azaltma/Kullanıcı Aracısı İstemci İpuçları
Bu çeyrekte geri bildirim alınmadı.
IP Protection (eski adıyla Gnatcatcher)
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Çözüm kimliği | Özel Korumalı Alan'ın, genellikle IP'ye dayalı olarak oluşturulan çözünürlük kimliklerinin reklamverenler için sürdürülebilir olmadığını daha fazla vurgulaması gerekiyor. | Özel Korumalı Alan, siteler arası izlemeyi azaltmayı hedeflediğimizi açıkça belirtmiştir. Çerezlerin ötesine geçen herkese açık girişimlerimiz hem privacysandbox.com hem de GitHub'da duyurulur. IP adreslerine dayalı olanlar da dahil olmak üzere siteler arası izlemeyi azaltmak için çalışıyoruz. Ancak siteler arası izlemenin proaktif olarak etkinleştirilip etkinleştirilmeyeceğine karar vermek web sitelerine bağlıdır. Yasal uygunlukla ilgili incelemelerin arttığı bir dönemde, şirketlerin hizmet sağlayıcılarının uyguladığı uygulamaları anlaması akıllıca bir harekettir. |
| Chromecast | IP Koruması, Chromecast'i veya diğer Chrome cihazları etkileyecek mi? | IP Koruma'nın Chromecast cihazlara uygulanmasıyla ilgili şu anda herhangi bir plan bulunmamaktadır. |
| IP Koruma Listesi | Web genelinde siteler arası izleme için IP adreslerini kullanabileceği tespit edilen üçüncü tarafların listesi yayınlanacak mı? | Liste, burada açıklandığı gibi tamamlandıktan sonra yayınlanacaktır. |
Hemen Çıkma Durumunu İzleme Çözümü
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Tek Oturum Açma (TOA) Muafiyeti | Hesap İptali İzleme Azaltma (BTM), TOA kullanım alanlarını muafiyet için nasıl doğrular? | BTM, Chrome sezgisel kuralları tarafından devre dışı bırakılır. Ayrıntılar için açıklamayı inceleyin. |
| Kullanımdan Kaldırma Deneme Sürümü | BTM, 3. taraf çerez desteğinin sonlandırılmasına yönelik deneme sürümündeki siteler için etkin mi? | Hayır, BTM, burada açıklandığı gibi desteğin sonlandırılması denemesi tarafından oluşturulan çerez istisnalarını dikkate alır. |
Gizli Erişim Limiti
GitHub'daki açıklama ve geliştirici sitesinde belirtildiği gibi,gizlilik bütçesi artık Özel Korumalı Alan önerileri kapsamında aktif olarak değerlendirilmiyor.
Siteler arası gizlilik sınırlarını güçlendirme
İlişkili Web Sitesi Grupları (eski adıyla Birinci Taraf Gruplar)
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Özellik İsteği | CHIP'lere ve / veya depolama alanı bölümlendirmeye, Storage Access API'ye veya kullanıcı etkileşimine gerek kalmadan RWS üzerinden otomatik olarak erişilmesine izin verilir. | Bu işlevi gerçekleştirebilecek bir özelliğin avantajlarını ve uygulanabilirliğini değerlendiriyoruz. Tarayıcılar arası birlikte çalışabilirlikteki olası bir boşluk, RWS'nin Storage Access API'den yararlanarak ele aldığı bir konudur. Diğer tarayıcılarda desteklenen, istenen bu işlevin eşdeğeri şu anda mevcut değildir. Geliştiricilerin, bu konuyla ilgili kullanım alanlarını buradan göndererek tartışmayı kolaylaştırmalarını öneririz. |
| Uyumlu Olmayan Setlerin Kaldırılması | Uyumlu olmayan setleri depodan kaldırma süreci nasıldır? | Bu konuda bir süreç belirlemek için çalışıyoruz. Güncellemeleri, kullanıma sunulduğunda paylaşacağız. |
| Yaptırım Süreci | Google'ın RWS yaptırım sürecindeki öznel rolü net değildir. | RWS devam eden bir proje olduğundan ve yeni gönderimler almaya devam ettiğimizden, sürecin bazı yönleri ve ölçütlerimiz henüz kesinleşmedi. Gönderim yönergelerimizin, gönderim koşullarımızı eksiksiz bir şekilde belirtmesinin önemli olduğunu kabul ediyoruz. Daha fazla belirsizlik ve karışıklık yaşanmaması için gönderim yönergelerimize daha fazla ayrıntı ekleyeceğiz. İnsan müdahalesini aşamalı olarak sonlandırıp tamamen otomatik kontrollere güvenebilmemiz için gönderim sürecinin mümkün olduğunca teknik olmasını amaçlıyoruz. Bu tür PR'ler, beklemediğimiz davranışlar içerdiğinden daha fazla insan etkileşimi gerektirir ancak otomasyon için daha fazla alan ve gelecekte bu tür sorunları önlemek amacıyla yönergelerimizi düzeltebileceğimiz yöntemler belirlememize olanak tanır. |
| Veri Paylaşımı | Alan sahiplerinin, kullanıcı izniyle bir üçüncü tarafın da RWS verilerini paylaşmasını istediklerini belirtmelerine olanak tanıyan bir özellik isteği. | İstenen işlev, kullanıcı bir izin istemini kabul ettikten sonra kimliği doğrulanmış kimliğe erişimi sağlayan FedCM ve Depolama Erişimi API'leri gibi API'ler aracılığıyla zaten kullanılabilir. Ekosistemden, mümkün olmadığını düşündükleri belirli kullanım alanları hakkında geri bildirim almaktan memnuniyet duyarız. |
| Diğer Depolama Yöntemleri | Yerel depolama veya oturum depolama alanına kaydedilen bilgiler de 3. taraf çerez olarak yorumlanacak mı? | Yerel depolama, oturum depolama ve üçüncü taraf bağlamlarında kullanıldığında çerez olmayan diğer depolama alanı biçimleri, Chrome'un 115 sürümünden beri bölümlere ayrılmıştır. Daha fazla bilgi için bu blog yayınını inceleyin. |
| İlişkilendirilmiş Grup Sınırı | "5 ilişkili siteyle sınırlıdır" olmasına rağmen 5'ten fazla alan gönderen kuruluşlara ne olur? | Bu kümeler GitHub süreci aracılığıyla kabul edilir ancak tarayıcı (Chrome), Storage Access API otomatik izin verme kurallarımızı yalnızca ilk 5 alana uygular ve burada açıklandığı gibi kalan alanları yoksayar. |
| find_robots_txt | find_robots_txt kontrolü, yönlendirmelerle çalışmaz. | Bu sorunu çözmek için buradaki düzeltme gönderildi. |
| Kullanıcı Hareketi | accessStorage() için kullanıcı hareketi şartını kaldırın. | Bu şart, requestStorageAccess API için tüm büyük tarayıcılarda bulunan benzer bir tasarıma göre belirlenmiştir. Bu isteğe öncelik vermemize ve tarayıcılar arası tartışmaları etkinleştirmemize yardımcı olmak için bu GitHub sorununda ek geri bildirim ve kullanım alanları paylaşmanızı rica ediyoruz. |
| Kullanıcı Hareketi | Chrome veya işletim sistemi yeniden başlatıldıktan sonra üçüncü taraf depolama alanı erişimi için izin vermek üzere kullanıcı hareketi gerekir mi? | Evet, ancak bu davranışın değiştirilip değiştirilmeyeceği konusunda ekosistemden buradan ek geri bildirim almayı bekliyoruz. |
Fenced Frames API
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| adComponent | Çitli çerçevelerle AdComponents'i kullanmayla ilgili dokümanlar ve esneklik eksikliği. | Bu kullanım alanıyla ilgili daha fazla doküman paylaşmayı planlıyoruz. Ayrıca, reklam bileşenleri, burada belirtilen spesifikasyonda açıklanan getNestedConfigs() kullanılarak çitle çevrili çerçevelerde desteklenir. |
| (Önceki çeyreklerde de raporlanmıştır) Reklam bileşenini oluşturma |
"Çitli çerçeve"de adComponents öğelerinin nasıl oluşturulacağıyla ilgili örnek kodlar isteyin. | Burada bazı örnek kodları paylaşmak için çalışmalarımızı sürdürüyoruz. |
| Üçüncü Taraf Reklam Doğrulaması | Üçüncü taraf reklam doğrulamasının, çitli çerçeveler bağlamında özellikle içerik/marka güvenliğiyle ilgili olarak daha ayrıntılı açıklanması gerekiyor. | Günümüzde, Çitli Çerçeve Reklam Raporlaması, DSP'lerin oluşturma sonrası marka güvenliği kontrolleri ve faturalandırma için gösterim ve açık artırma etkinlik düzeyindeki verileri üçüncü taraf reklam doğrulayıcılara göndermesine olanak tanır. |
| Genişletilebilir Reklamlar | Genişletilebilir reklamları destekleme isteği. | Reklamın aynı en boy oranına sahip iki boyut arasında geçiş yapması gerekiyorsa ve bu iki boyut arasında işlevsel bir fark yoksa (yalnızca boyut farklıysa) yerleştirici, korumalı çerçeveyi ikinci reklam boyutuyla yeniden boyutlandırabilir ve tarayıcı, korumalı çerçeve öğesini buna göre ölçeklendirir. |
| (Önceki çeyreklerde de raporlanmıştır) Video ve Yerel Envanter Desteği |
Çitli çerçeveler video ve yerel envanteri destekler mi? | Yanıtımız önceki çeyreklerdekine benzer: PA API, iframe'lere dayalı bir mekanizma kullanarak video oluşturmayı destekler. Ancak video ve doğal reklam oluşturma için henüz Çitli Çerçeveler ile uyumlu bir çözüm tasarlamadık. Çitli Çerçeveler yaptırımını 2026'ya erteleme kararımızın nedenlerinden biri de budur. Yani bir iş ortağı şu anda korumalı çerçeveleri uygulamaya karar verirse video ve doğal reklamlar için destek alamaz. |
| Danışma Kurulu | Çitli çerçeve uygulamalarının endüstri standartlarına uymasını sağlamak için doğal reklam tedarikçilerinden oluşan bir danışma kurulu oluşturulmasını ister. | Çitli çerçeveler, 2026'dan önce PA API'de kullanılmak için gerekli değildir. Ek süre, daha geniş bir kritik kullanım alanı yelpazesi için destek tasarlayıp uygulamak üzere sektörle çalışmaya devam etmemizi sağlıyor. PA API ile video ve doğal reklamları destekleme şartı gelmeden önce, korumalı çerçeveleri geliştireceğimizi daha önce belirtmiştik. Taahhütlerimiz uyarınca, bu tür değişiklikleri CMA ile paylaşıp CMA'yı bilgilendireceğiz ve Çitli Çerçeveler'i zorunlu kılmadan önce ekosistemden gelen geri bildirimleri almaya devam edeceğiz. W3C ve IAB Tech Lab gibi reklam standartları kuruluşlarındaki ekosistem etkileşim modelimiz, her türden sektör uzmanının tasarımlara ihtiyaç duyulmadan önce rehberlik etmesine olanak tanır. |
| (Önceki çeyreklerde de raporlanmıştır) Platformlar Arasında Boyut Farklılığı |
Çitli çerçevede gösterilen içeriğin boyutunun masaüstü ve akıllı telefonlarda farklı göründüğünü bildirir. | Bu, araştırmakta olduğumuz bilinen bir Chromium sorunu. Buradan ek geri bildirim gönderebilirsiniz. |
| API İyileştirmesi | Doğal reklamların artık Özel Korumalı Alan'da desteklenmesi için çitli çerçeve şartı 2025'e ertelendi mi? | 2026'dan önce uygulanacak olan Çitli Çerçeveler yaptırımıyla ilgili kamuya açık duyurumuzda belirttiğimiz gibi, Çitli Çerçeveler'i "uyumlu hale getirmek için önemli bir çaba" gösterildiğini öğrendik. Elbette, bunlardan biri doğal reklamlardı ancak tek faktör bu değildi. Amaç, ekosistemin yerel reklamlar da dahil ancak bunlarla sınırlı olmamak üzere temel kullanım alanlarını desteklemeye hazır olmasını sağlamak için daha fazla zaman tanımaktı. |
Shared Storage API
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Performans | Ortak Depolama'nın iş akışı dışındaki geri gönderme süreleri, iş akışında yapılan etkinliğe bağlıdır. | Bu test sonucunu burada ele alıyoruz. |
| Daha geniş kullanım | Paylaşılan depolama alanı, tarayıcılarda kullanılabilen sektör genelinde bir standart olmalıdır. | Bu geri bildirimi memnuniyetle karşılıyor ve dikkate alıyoruz. Chrome, öneriyi desteklemek, geri bildirim almak ve benimsenmesini sağlamak için WICG dahil olmak üzere W3C forumlarına aktif olarak katılmaya devam ediyor. |
| Teklifli Sistem İş Akışı | Siteler arası bilgilere dayalı reklam kararı / iş mantığı (ör. sıklık sınırı) uygulamak ve reklamların bir alt kümesini seçmek için generateBid (bir iş parçasında zaten çalışıyor) içinden Paylaşılan Depolama Alanı'ndan okumak mümkün mü? | Hayır, teklif verme iş parçacıkları içinde paylaşılan depolama alanından veri okumak mümkün değildir. |
CHIPS
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Bölüm Kapasitesi | Bölme kapasitesinin aşıldığı durumlarda davranışı netleştirme. | Kapasiteye ulaşıldığında, en eski çerezler en son erişilen çerezlerden çıkarılır ve sınır aşılana kadar bellek boşaltılır. Geliştiriciler sonraki isteklerde güncellenmiş çerez üst bilgisini görür. |
| Üçüncü taraf iFrame erişimi | Aynı üçüncü taraf sitesine yeni bir sekme/pencere açan yerleşik üçüncü taraf iFrame içeriği, açanla aynı bölümlenmiş çerezlere erişebilmelidir. | Bu kullanım alanını tartışıyoruz ve ekosistemden buradan ek geri bildirim almaktan memnuniyet duyarız. |
| Yinelenen Çerezler | Aynı ada sahip bir bölümlenmiş çerez ve bölümlenmemiş çerez varsa tarayıcı hangi anahtar değerini göndermeye karar verir? | Aynı ada sahip iki çerez (biri bölümlenmiş, diğeri bölümlenmemiş) olduğunda her iki çerezi de alırsınız. Maalesef hangisinin hangisi olduğunu ayırt etmenin bir yolu yoktur. Bu konudaki RFC spesifikasyonu burada bulunabilir. Bu spesifikasyonda, çerezlerin gönderilme sırasına güvenilmemesi gerektiği açıklanmaktadır. |
| Özellik İsteği | Kaynak bölümüne ayrılmış çerezleri etkinleştirin. | Bu isteği değerlendiriyoruz ve ekosistemden buradan ek geri bildirimler bekliyoruz. |
FedCM
Bu çeyrekte geri bildirim alınmadı.
Spam ve sahtekarlıkla mücadele etme
Private State Token API (ve diğer API'ler)
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Web görünümü | Gizlilik durumu jetonları (PST'ler) aynı mobil cihazdaki (profil) birden fazla Web Görünümü'nde devam ediyor mu? | Web Görünümü kullanan her uygulamanın farklı bir yerel depolama alanı vardır. Bu nedenle, PST sağlayıcıları bir uygulamanın Web Görünümü'nde jeton yayınlayamaz ve daha sonra ayrı bir uygulamada jeton kullanımına izin veremez. Bu durum, web görünümlerinde yerel olarak depolanan diğer veri türleri (ör. çerezler) için de geçerlidir. PST'ler henüz WebView'de tam olarak kullanılamıyor. Bu konuyla ilgili güncel bilgileri 2. çeyreğin sonuna kadar paylaşmayı planlıyoruz. |
| Yeni Jeton Türü | Yeni bir jeton türü önerisi. | Bu öneri ve PST'lerin uygulamaları ve uyarlamaları hakkındaki keşifleriniz için teşekkür ederiz. 2024'ün 2. çeyreğinde yapılacak Sahtekarlık Önleme Topluluğu toplantılarında bu öneri hakkında daha fazla bilgi edinmeyi sabırsızlıkla bekliyoruz. |
| Kullanıcı Kimliği | Kullanıcıların sahip olduğu belirli PST'lere göre tanımlanmasını nasıl önleyebilirim? | Bu durum şu anda, bir sitedeki ödeme kullanma girişimleri, ilgili sağlayıcıdan jeton olup olmadığına bakılmaksızın iki sağlayıcıyla sınırlandırılarak azaltılmaktadır. Aksi takdirde site, pozitif bir eşleşme bulana kadar tüm sağlayıcıları yineleyebileceğinden, jeton mevcut olmasa bile sağlayıcıyı sınıra göre saymanız gerekir. |
| Kayıt | PST'ler için kayıt ne kadar süreyle gerekli olacak? | Kayıt, burada daha ayrıntılı olarak açıklandığı gibi, yakın gelecekte zorunlu olmaya devam edecektir. |
| Diğer Chromium Tarayıcılar için destek | Diğer Chromium tabanlı tarayıcılar için PST veren kurum kaydı, Chrome Issuer Registration deposu üzerinden desteklenecek mi? | Chrome, temel taahhütleri getirir ve Bileşen Güncelleyici adlı bir mekanizma aracılığıyla Chrome istemcilerine dağıtır. Diğer tarayıcılar API için daha kapsamlı destek ekledikçe, bileşen güncelleyici tarzı bir yöntem veya başka bir yöntem aracılığıyla istemciye temel taahhütleri almak için bir süreç oluşturmaları gerekecektir. Bu konuyla ilgili daha ayrıntılı bilgiyi burada bulabilirsiniz. |