Özel Korumalı Alan teklifleri ve Chrome'un yanıtı hakkında alınan ekosistem geri bildirimlerini özetleyen 2023'ün 2. çeyreğine ait üç 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üğü
- 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ü
- PatCG
- Private Advertising Technology Community Group
- RP
- Bağlı Taraf
- 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/teknolojiyle ilgili olmayan genel geri bildirimler
| Geri bildirim teması | Özet | Chrome Yanıtı |
|---|---|---|
| Veri Yönetimi ve Yasal Uygunluk | Özel Korumalı Alan'ı yasal şartlara uygun şekilde kullanmayla ilgili ekosistem kılavuzu. | 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. Bununla birlikte, bu konunun ekosistem için önemli bir konu olduğunun farkındayız. Her API için gerekli yasal değerlendirmeleri yapmanın temelini oluşturması gereken kapsamlı teknik dokümanlar yayınladık ve şirketlerin yasal şartlara uyma çabalarını desteklemek için ek materyaller sunmak üzere çalışıyoruz. |
| CMA Sayısal Test teklifi | CMA nicel test önerisi hakkında daha fazla bilgi | Üçüncü taraf çerez desteğinin sonlandırılmasının ve Özel Korumalı Alan tekliflerinin kullanıma sunulmasının ekosistem üzerindeki etkisini gösteren deneyler tasarlamak için CMA ile birlikte çalışıyoruz. CMA, Nisan ayında Test ve Deneme dönemi boyunca nelerle karşılaşacağınızla ilgili genel düzeyde bir kılavuz yayınladı. Ardından Haziran ayında ayrıntılı bir kılavuz yayınladı. CMA'nın Kantitatif Test önerisiyle ilgili sorularınızı veya geri bildirimlerinizi doğrudan CMA ile paylaşmanızı öneririz. |
| Chrome tarafından desteklenen test modları | Test programları hakkında daha fazla bilgi ve açıklama | 18 Mayıs'ta, Chrome tarafından desteklenen testin iki modu hakkında daha fazla bilgi paylaştığımız bir blog yayını yayınladık. Bu bilgiler nihai değildir. 2023'ün 3. çeyreğinde ilerledikçe daha fazla uygulama kılavuzu yayınlayacağız. |
| Bölünmüş Depolama | Chrome tarafından desteklenen test sırasında bölümlenmiş depolama alanı kullanılır mı? | Depolama alanı bölme özelliği, üçüncü taraf çerez desteğinin sonlandırılması denemesinden önce tüm kullanıcılara sunulacaktır. Bu nedenle, denemenin tüm kolları için etkinleştirilir. Bu süre zarfında siteler, bölümlenmemiş depolama alanını geri almak için desteğin sonlandırılmasına yönelik bir deneme etkinleştirme seçeneğine sahip olacaktır. |
| Prodüksiyon desteği | Chrome'un, ekosistemi etkileyen Özel Korumalı Alan teknik sorunlarını ve üst birime iletme işlemlerini desteklemek için uyguladığı süreç nedir? | Google, reklam teknolojisi uzmanlarının sorunları bildirmesine ve gerekli üst birime iletmelerine olanak tanıyan çeşitli kanallar sunar. Geri bildirim ve üst birime iletme için herkese açık ve özel forumlar hakkında daha fazla bilgi için lütfen geri bildirime genel bakış makalemizi inceleyin. |
| Kayıt Zaman Çizelgesi | Kayıt için geçerli zaman aralığı çok kısa | Yaptırım için son tarihi hâlâ değerlendiriyoruz ve ekosistemin hangi zaman çizelgesinin daha uygun olduğunu öğrenmek istiyoruz. |
| D-U-N-S Numarası | Kayıt ve Onay için D-U-N-S numarası şartı hakkında daha fazla bilgi | Katılımcılar, D-U-N-S numarası alma şartlarını Dun and Bradstreet web sitesinde bulabilir. Şartlar pazara göre değişir. Bu nedenle katılımcılar, ilgilendikleri pazarın web sitesini kontrol etmelidir. Ancak genel olarak katılımcıların işletmeleriyle ilgili temel bilgileri (ör. işletmenin adı, adresi ve işletme sahibinin veya yöneticisinin iletişim bilgileri) sağlaması gerekir. Katılımcılardan işletmenin yıllık geliri gibi finansal bilgiler de istenebilir. Başvuru tamamlandıktan sonra D&B tarafından incelenir ve onaylanması durumunda D-U-N-S numarası verilir. |
| Kaynak denemesinden genel kullanıma geçiş | Kaynak denemesinden genel kullanıma geçiş, mevcut kaynak denemesi test kullanıcılarını etkiler mi? | Temmuz ayından itibaren test kullanıcıları, genel kullanıma sunulan alaka düzeyi ve ölçüm API'lerine erişebilecek. Bu sayede, kaynak deneme sürümünün kullanıma sunulması ile genel kullanıma sunulması arasında çakışma yaşanmaz. |
| AdExchanger Çalışması | Anket metodolojisi hakkında daha fazla bilgi | Ankete katılanlardan, işletmeleri için senkronizasyon oranlarını ve geliri tahmin etmeleri istendi. Katılımcıların, soruları yanıtlama metodolojisi kendilerine bırakıldı. |
| Parametre değerleri | Gürültü seviyesi, anonimlik eşikleri ve gizlilik bütçesi gibi parametre değerleri nasıl belirlenir? | Bu GitHub makalesinde, Privacy Sandbox API'lerinin temelindeki daha genel ilkeler açıklanmaktadır. Birçok değer henüz kesinleşmedi. Bu konudaki geri bildirimlerinizi bekliyoruz. |
Alakalı İçerik ve Reklamlar Gösterme
Konular
| Geri bildirim teması | Özet | Chrome Yanıtı |
|---|---|---|
| Gizliliği koruma | Gizliliği koruma konusunda Topics API'yi değerlendiren araştırma | Araştırma topluluğuyla aktif olarak ilgileniyor, Topics API'nin gizlilik özellikleriyle ilgili araştırmalarımızı makalelerde, raporlarda ve atölye sunumlarında sunuyoruz. Araştırma topluluğunun daha fazla üyesinin bu alanda aktif olarak yer almasından memnuniyet duyuyoruz. Topics API, kullanıcıları geniş ölçekte izlemeyi çok zorlaştırarak web'de genel izlemeye karşı korur. Bu makaleler, Topics API ile bunu başarıyla yaptığımızı gösteriyor. Üçüncü taraf çerezlerinden daha gizlidir ve ziyaret etmekten keyif aldıkları siteleri desteklerken kullanıcıları korur. |
| Konu sınıflandırması yeterince ayrıntılı değil | Geniş konular sınıflandırması, bölgeye özgü konular da dahil olmak üzere daha ayrıntılı konuları içermez. | Ekosistemden aldığımız geri bildirimler doğrultusunda, 15 Haziran'da ekosistemden aldığımız geri bildirimler doğrultusunda çok sayıda iyileştirme içeren yeni ve güncellenmiş bir sınıflandırmanın ayrıntılarını paylaştığımız bir blog yayını yayınladık. Düzeltilmiş sınıflandırmayla ilgili çalışmalarımız kapsamında, Raptive (eski adıyla CafeMedia) ve Criteo gibi ekosistemdeki çeşitli şirketlerle birlikte çalıştık. Güncellenen sınıflandırmada, daha az yararlı olduğu bildirilen kategoriler kaldırılarak reklamveren çıkarlarıyla daha iyi eşleşen kategoriler eklendi. Bu sayede, hassas olabilecek konuları hariç tutma taahhüdümüz de korundu. Ekosistemin en son sınıflandırmayı incelemesini ve değişikliklerle ilgili geri bildirim vermesini öneririz. |
| Sınıflandırma ve sınıflandırıcı güncelleme süreci | Topics sınıflandırması ve sınıflandırıcı sürüm yayınlama sıklığı ile şirketlerin bu tür güncellemelere nasıl hazırlanabileceği hakkında daha fazla bilgi. | Yakın zamanda paylaşılan blog yayınında da belirtildiği gibi, sınıflandırmanın zaman içinde gelişeceğini ve sınıflandırmanın yönetiminin nihayetinde sektördeki paydaşları temsil eden harici bir tarafa devredileceğini umuyoruz. Ayrıca, topics-announce grubunda kullanıma sunma planını da paylaştık. |
| Birinci taraf sinyalleri üzerindeki etkisi | Son sınıflandırma güncellemesinde konu sayısının artması son derece değerli olabilir ve bunun sonucunda ilgi alanına dayalı diğer birinci taraf sinyallerin değeri düşer. | CMA, 2023'ün 1. çeyreğine ait raporunda "Google'ın, önerdiği yeni sınıflandırmayı reklam teknolojisi tedarik zincirindeki çeşitli pazar katılımcılarıyla görüştüğünü anlıyoruz. Birkaç büyük yayıncı, konuların daha fazla yararlı olmasının birinci taraf veri tabanlı çözümleri üzerindeki rekabet baskısını artıracağını belirtmiş olsa da ön görüşümüz, daha fazla yararlılığın genel olarak rekabet için daha iyi olduğudur. Özellikle de küçük yayıncıların, üçüncü taraf çerezlerinin desteğinin sonlandırılmasından sonra envanterlerinden para kazanmaya devam etme kabiliyeti için daha iyidir." Görüşümüz, CMA tarafından yapılan bu yorumla aynı doğrultudadır. |
| Farklı paydaş türleri için yararlı olması | SSP ve DSP olarak işlev gören reklam teknolojilerinin diğer ekosistem oyuncularına göre önemli avantajları olabilir. | Yanıtımız önceki çeyreklerden farklı değil: "Google, Özel Korumalı Alan tekliflerini Google'ın kendi işletmesini tercih ederek rekabeti bozmayacak şekilde tasarlayıp uygulamayı ve dijital reklamcılıktaki rekabeti, boyutları ne olursa olsun yayıncılar ve reklamverenler üzerindeki etkisini dikkate almayı CMA'ya taahhüt etmiştir. Çalışmalarımızın bu taahhütlere uymasını sağlamak için CMA ile yakın bir şekilde çalışmaya devam ediyoruz. Özel Korumalı Alan'ın testleri ilerledikçe, yeni teknolojilerin farklı paydaş türleri için nasıl performans gösterdiğini değerlendireceğimiz önemli sorulardan biri olacaktır. Bu bağlamda geri bildirim çok önemlidir. Özellikle teknik tasarımları daha da iyileştirmemize yardımcı olabilecek spesifik ve uygulanabilir geri bildirimler çok önemlidir. Nicel teste yaklaşımımızı geliştirmek için CMA ile birlikte çalıştık ve CMA'nın pazar katılımcılarına daha fazla bilgi sağlamak ve önerilen yaklaşımlar hakkında yorum yapma fırsatı sunmak için deneme tasarımıyla ilgili bir not yayınlamasını destekliyoruz." |
| Alt Konuları | Konu seçim ölçütleri tarayıcı ziyaretlerinin sıklığı olduğunda, segment parçalanması alt konuların hiçbir zaman üst sıralara çıkamamasına neden olur mu? | Chrome şu anda diğer sıralama metodolojilerini değerlendiriyor ve sıralamayı iyileştirebilecek diğer sinyalleri araştırıyor. Düzeltilen planlarımızı ekosistemle uygun zamanda paylaşacağız. |
| Hassasiyet | Topics API'nin amacı, Topics API'den elde edilen veya türetilen kullanıcı bilgilerinin, günümüzün izleme yöntemleri kullanılarak elde edilebilecek bilgilerden daha az kişisel hassasiyete sahip olmasını sağlamak olmalıdır. | Topics API'nin mevcut teknolojilerden çok daha gizli olduğuna, kullanıcıların yeniden tanımlanmasını önemli ölçüde sınırlandırdığına ve hassas konuları hariç tutacak şekilde tasarlandığına inanıyoruz. Konuların, hassas kategoriler oluşturmak için birinci taraf verileriyle ilişkilendirilebileceğini veya birleştirilebileceğini kabul ediyoruz ancak Topics API'nin kullanıcı gizliliği açısından ileriye doğru bir adım olduğuna inanıyoruz ve API'yi geliştirmeye devam etmeye kararlıyız. |
| Sınıflandırma Yapısı | Konu Taksonomisi'ne kimlik, sürüm ve diğer meta veri yapılarını ekleme | Şu anda API yanıtına sınıflandırma kimliğini ekliyoruz. Uzun vadeli yönetime doğru ilerlerken Topics nesnesini incelemek ve gerekirse sürüm oluşturma hakkında ek meta veriler eklemek mantıklı olacaktır. |
| Yayıncı denetimi | Yayıncıların, sitelerinin hangi konular altında sınıflandırılacağı konusunda söz sahibi olması gerekir. | 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. Yayıncıların sınıflandırmalarını kontrol etmelerine izin vermek risklidir. Siteler, sitelerini kasıtlı olarak yanlış sınıflandırarak herkes için faydayı azaltabilir veya hassas anlamları daha az yaygın konularda kodlayarak kullanıcı gizliliğine zarar verebilir. |
| Chrome uzantıları | Mevcut çerez yönetimi uzantılarına benzer şekilde, Chrome uzantılarının konuları yönetmesine ve filtrelemesine izin verme | GitHub'da da belirtildiği gibi bu işlem zaten mümkün olsa da ekosistemden daha fazla geri bildirim almaktan memnuniyet duyarız. |
| Genel kullanıma geçiş | Kaynak denemesinden genel kullanıma geçiş, Topics API'yi etkiler mi? | Origin deneme sürümünden genel kullanıma geçen kullanıcıların verileri kaybolmaz. |
| Gizlilik | Ana makine adları, Topics API tarafından açıklanabilecek gizli bilgiler içerebilir | Gizliliği sağlamak için burada açıklanan çeşitli önlemlerimiz vardır. |
| Sahtekarlık ve Kötüye Kullanım | Sahte ziyaretler nedeniyle Konuların tahrif edilmesini önleme | Azaltma önlemleri burada açıklanmıştır. |
| Konu sınıflandırıcı | Web siteleri, Konu sınıflandırmalarını değiştirme isteğinde bulunabilir mi? | Bu konuda ekosistemden geri bildirim almak istiyoruz. Geri bildirimlerinizi buradan gönderebilirsiniz. |
| Topics sağlayıcı siteleri | Birçok konu için içerik barındıran belirli web sitelerini "Özel Konu Sağlayıcı Siteleri" olarak tanımlayın ve sınıflandırıcıları web sayfalarında sağlanan etiketlere göre eğitin. | Öneriyi burada tartışıyoruz ve ek geri bildirimlerinizi bekliyoruz. |
Protected Audience API (eski adıyla FLEDGE)
| Geri bildirim teması | Özet | Chrome Yanıtı |
|---|---|---|
| Trafik Şekillendirme | Saniyedeki sorgu sayısı (QPS) yükünü optimize etmek için SSP destekli filtrelemenin performans üzerindeki etkisi | Trafik şekillendirme konusunda oldukça fazla zaman harcadık ve SSP'lerin önbelleğe alma özelliğinden yararlanmasını öneriyoruz. |
| Hacim testleri | STP'ler ve DSP'ler büyük trafik hacimleri elde etmekte zorlandığından Protected Audience'i test etmek zordur. | Protected Audiences'i benimsemek ve test etmek için SSP ve DSP iş ortaklarıyla sürekli olarak iletişim kuruyoruz. Genel kullanıma sunma süreci başladı. PA'nın etkin olduğu trafik yüzdesinin, iş ortaklarının test etmesini daha cazip hale getireceğinden eminiz. |
| Karmaşıklık | Protected Audience çözümlerini uygulamak önemli miktarda çaba ve maliyet gerektirir. | Özel Korumalı Alan da dahil olmak üzere yeni teknolojilerin benimsenmesinin zor olduğunun farkındayız. Özel Korumalı Alan ekibi, çabalarını eğitmek ve desteklemek için çok çeşitli paydaşlarla yakın bir şekilde çalışıyor ve ekosistemin benimsenmesini desteklemek için diğer hızlandırıcıları sürekli olarak değerlendiriyor. |
| Güvenilir Yürütme Ortamları | Herkese açık olmayan bulut ortamlarında Güvenilir Yürütme Ortamları (TEE) desteği | Bulut tabanlı çözümlerin ötesinde olası destek seçeneklerini araştırıyoruz ancak Özel Korumalı Alan için zaman alıcı bir değerlendirme gerektiren şirket içi güvenlik sınırlamaları nedeniyle şirket içi TEE'leri şu anda desteklememiz mümkün değildir. Ö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 GCP'yi desteklemeye) devam etmenin ekosistem için en yararlı seçenek olduğuna inanıyoruz. Ancak bu tür bir şartın neden gerekli olduğu konusunda ek geri bildirimlerinizi bekliyoruz. |
| Maliyet Yapısı | Teklifli sistem ve açık artırma hizmetleri teklifi, reklam teknolojilerinin maliyetini ve karmaşıklığını istemci tarafı modellere kıyasla artıracaktır. | Şu anda Teklif Verme ve Açık Artırma sunucusunda teklif verme ve açık artırma iş akışlarını destekleme maliyetlerini tahmin etmek için bir kılavuz geliştiriyoruz. Bu kılavuz, tasarımlarımızın hedeflerinden birini gerçekleştirerek reklam teknolojisi kullanımıyla ilişkilendirilecek. |
| K-Anon Zaman Çizelgeleri | Planlanan k-anonimlik kısıtlamaları "renderUrl" üzerinde ne zaman uygulanacak? | Yaptırım zaman çizelgesi hakkında kısa süre içinde yayınlayacağımız bir açıklama üzerinde çalışıyoruz. |
| runAdAuction kısıtlamaları | Chrome, runAdAuction'ü yalnızca üst sayfadan çağrılabilir şekilde kısıtlayabilir mi? |
Tasarımımız, runAdAuction'ün üst sayfadan çağrılmasını tam olarak desteklese de yayıncıların bu özelliği yalnızca üst alan adından çağrılacak şekilde kısıtlamasının daha zararlı olacağına inanıyoruz.Özellikle ekosistemden, Özel Korumalı Alan'ın yayıncılar ve reklamverenler üzerindeki yükü en aza indirmesi gerektiğini duyuyoruz. Bu geri bildirim, site sahiplerinin sitelerini yönetmek için üçüncü taraf araçlarını kullanabileceği web geliştirmeyle ilgili genel ilkeyle uyumludur. Özel Korumalı Alan'ın amacı, yayıncıların ve reklam teknolojilerinin nasıl çalıştığını belirtmek zorunda kalmadan sağlıklı bir ekosistemi teşvik etmektir. Yayıncının, sitesinde runAdAuction çağrısını nasıl ve kim tarafından yapılacağını seçmesine izin vererek yayıncılara, ihtiyaçlarına en uygun yolu bulmaları için esneklik sunduğumuzu düşünüyoruz. |
| Uygulama desteği | Chrome, çok satıcılı açık artırmanın açık kaynak uygulamasını oluşturabilir veya bu uygulamaya katkıda bulunabilir mi? | Özel Korumalı Alan, üçüncü taraf çerezlerine veya diğer siteler arası tanımlayıcılara ihtiyaç duymayan, gizliliği korumaya yönelik teknolojiler geliştirmeyi amaçlar. Reklam teknolojilerinin nasıl çalışması gerektiğini belirtmek zorunda kalmadan sağlıklı bir ekosistemi teşvik etmek istiyoruz. API'lerin işleyiş şekliyle ilgili kılavuzu GitHub depomuzda yayınladık ve sektörle birlikte çözümler keşfetmeye açığız. Temel görevimiz platform teknolojileri oluşturmak olduğundan, bu teknolojilerin kullanımıyla ilgili stratejileri dikte etmek yerine belirli bir uygulama oluşturmayı planlamıyoruz. Teknolojilerimiz, reklam teknolojisi şirketlerinin tüketiciler için doğru gizlilik korumalarıyla müşterilerine en iyi şekilde hizmet vermesine yardımcı olacak. |
| Çok satıcılı açık artırmalar | Chrome, "bağlamsal" bir kazananı bileşen açık artırmalarıyla paylaşmaya zorlar mı? | Protected Audience API, çok satıcılı açık artırmayı başlatan tarafların bileşen açık artırmasına bilgi iletme olanağı sunmak için tasarlanmıştır (not: yalnızca açık artırmayı başlatmadan önce). Bununla birlikte, tarayıcının bir bilginin bağlamsal kazanan olup olmadığını ayırt etmesinin mümkün olmadığını düşünüyoruz. Bu nedenle, belirli bilgilerin engellenmesini veya zorunlu tutulmasını zorunlu kılamıyoruz. |
| İzinle izleme için kullanıcı tercihi | Adtech, PA'dan kullanıcı rızası izlemenin doğru şekilde nasıl uygulanacağını soruyor | Yanıtımız 1. Bölümde söylediklerimizi içerir: "Belirli reklamlar için ilgili reklam teknolojisi, hangi reklam öğelerinin gösterileceği veya nasıl seçileceği konusunda kontrol sunmak için en iyi konumda olan taraftır." Mayıs ayındaki WICG Protected Audience Meeting sırasında bu konuyla ilgili çeşitli senaryolar üzerinde konuştuk. Bu konuyla ilgili daha fazla geri bildirim ve tartışma paylaşabilirsiniz. |
| Özel Kitleler | Özel kitle oluşturmayla ilgili STP kullanım alanları Protected Audience API tarafından desteklenecek mi? | Protected Audience API, STP'lerin ve diğer reklam teknolojisi sağlayıcıların özel kitlelere sahip olmasına ve bunları yönetmesine olanak tanır. STP'lerin PA API ile nasıl entegre olabileceğiyle ilgili daha fazla bilgi geliştirilmekte olup STP'lerin ve diğer reklam teknolojisi sağlayıcıların entegrasyon çalışmalarını desteklemek için kullanıma sunulacaktır. |
| Formatlar | Video, Protected Audience API tarafından desteklenir mi? | Video reklamlar iki şekilde yayınlanır: VAST XML veya HTML (nihayetinde VAST XML'i bir video oynatıcıya da yükleyebilecek yayın dışı reklam). Alıcılar, renderURL aracılığıyla her iki biçimi de döndürebilir. VAST spesifikasyonu, Attribution Reporting API'yi desteklemek için yakın zamanda güncellendi. Video reklam yayınlayan sitelerin, reklamların Protected Audience API aracılığıyla yayınlanma şekline hazırlanması gerekir. Bu, yerleşim etiketlerinin URL'yi Protected Audience iFrame'sinden bir video oynatıcıya iletebildiğinden emin olmak anlamına gelir. Çitli çerçeveler için, 2026'dan önce zorunlu kılınacak olan Çitli Çerçeveler kullanma şartından önce video ihtiyaçlarını karşılamak için çalışacağız. |
| İlerleme hızı | Pacing kullanım alanı, Protected Audience API ile nasıl çalışır? | Geri bildiriminiz için teşekkür ederiz. Bu talep, bugüne kadar çoğunlukla DSP ile ilgili bir sorun olduğu için daha fazla SSP iş ortağının daha fazla ayrıntı içeren bu isteği daha fazla kez göndermesini isteriz. |
| Güncelleme sıklığı | dailyUpdate'ten gelen aramaların sıklığı (ilgi alanı grubu başına günde en fazla 1) ürün bilgilerini güncelleme gibi belirli kullanım alanları için yeterli olmayabilir. |
Geri bildiriminiz için teşekkür ederiz. Reklam teknolojilerinin farklı ritimlerde yenilenen sinyalleri kullanmasına izin veren başka çözümler de vardır (ör. K/V aramaları). |
| Reklam Kalitesi Kontrolü | Yayıncılar reklam kalitesi denetimini nasıl uygular? | Protected Audience API şu anda yayıncıların, açık artırma yapılandırması ve teklif vermeden önce (ör. reklamlarla ilişkili etiketlere dayalı engellenenler listeleri) oluşturabilecekleri belirli denetimler hakkında STP'lerini bilgilendirmelerine olanak tanıyan işlevler sunar. Ekosistemin ihtiyaç duyabileceği ek işlevler hakkındaki geri bildirimlerinizi bekliyoruz. |
| Hata ayıklama | forDebuggingOnly işlevi ne zaman kaldırılacak? |
Üçüncü taraf çerez desteğinin sonlandırılması nedeniyle kayıp etkinlikleri için forDebuggingOnly'ü kullanımdan kaldırmayı planlıyoruz. Kazanma etkinlikleri için forDebuggingOnly'ü en erken 2026'da kullanımdan kaldırmayı planlıyoruz. |
| Cihazlar Arası İlgi Alanı Grupları | Kimliği doğrulanmış kullanıcı aracıları için cihazlar arası ilgi alanı gruplarını etkinleştirme önerisi | Bu öneriyi değerlendiriyoruz ancak cihazlar arası hedeflemenin yüksek özgünlüğü, bu GitHub sorununda da belirtildiği gibi önemli gizlilik endişeleri oluşturuyor. |
| (1. çeyrekte de raporlanır) Dinamik Yeniden Pazarlama | Üçüncü taraf çerezleri için destek sonlandırıldıktan sonra Protected Audience API ile dinamik yeniden pazarlama mümkün olacak mı? | Bu kullanım alanının, burada açıklandığı gibi Protected Audience kullanılarak mümkün olduğuna inanıyoruz. |
| İlgili verileri tıklayın | browserSignals.'e tıklamayla ilgili veriler ekleme |
Önerilen konumu belirlemek için tıklamanın ne zaman gerçekleştiği konusunda açıklama istiyoruz. |
| (2022'nin 4. çeyreğinde de bildirilmiştir) Protected Audience'ta kullanıcı tanımlı işlevler | Protected Audience API'de kullanıcı tanımlı işlevler (UDF) nasıl desteklenecek? Bunlar, API'nin işlevini genişletmek için son kullanıcılar tarafından programlanabilen işlevlerdir. | Bu sorunu gündeme getiren reklam teknolojisi şirketi, UDF ile neler yapabileceklerini hâlâ değerlendirdiklerini belirtti. Bu nedenle, en azından genel kullanıma sunuluncaya kadar bu konuda henüz uygulanabilir bir geri bildirim bulunmuyor. |
| Para Birimi | Para birimi tutarları kayan nokta kullanılarak gösterilmemelidir. | Bu konuyu buradan ayrıntılı bir şekilde ele aldık. |
| DSP dışı reklam seçim özellikleri | Reklam sunucuları, Protected Audience API açık artırmalarında ne gibi bir rol oynar? | Reklam sunucularının teklif sonrası reklam seçimi / dinamik reklam öğesi optimizasyonu hizmetleri sunmaya devam etmesiyle ilgili taleplerin farkındayız. Şu anda mevcut Protected Audience API ile bu istekler arasındaki ayrıntılı boşluk analizini değerlendiriyoruz. |
| GenerateBid | Google Ads'in generateBid'ten reklam ilgi alanı grubu başına birden fazla aday reklam döndürme ve bu adayların "scoreAd"da puanlanması önerisi için destek. |
Bu konu şu anda değerlendiriliyor. Buradaki ek geri bildirimlerinizi bekliyoruz. |
| Açık Artırma Siparişi | Protected Audience API açık artırmalarının, diğer tüm açık artırmaların sonuçlarından bilgi alabilmesi için en son çalıştırılan açık artırma olması gerekir mi? | Protected Audience API'nin en son çalıştırılması için teknik bir şart yoktur. |
| Kullanıcı tarafından başlatılmayan navigasyon | Kullanıcı tarafından başlatılmayan navigasyonu gösterme | Bu isteği inceliyoruz ve buradan tartışıyoruz . Ek geri bildirimler bekliyoruz. |
| Önbelleğe alma | SSP, kullanıcı durumu değişirse belirli bir DSP'nin perBuyerSignals öğesini önbellekten oluşturmamalıdır. | Önbelleğe alma işleminin, alıcı başına sinyallerin her kullanım alanında işe yaramadığının farkındayız ve diğer seçenekleri değerlendiriyoruz. Ekosistemden, kullanım alanları için önbelleğe alma özelliğinin işe yarayıp yaramayacağıyla ilgili ek geri bildirimler almaktan memnuniyet duyarız. |
| İlişkilendirme Raporları ve Korunan Kitle | Attribution Reporting API ve Protected Audience API birlikte nasıl çalışabilir? | Entegrasyonlar şu anda hem Attribution Reporting API modlarında (etkinlik düzeyinde ve özet raporlar) hem de Protected Audience API için kullanılabilir. 1 Haziran'da, iyileştirilmiş Protected Audience API ve Attribution Reporting entegrasyonu hakkında daha fazla bilgi paylaştık. Bu konu hakkında daha fazla bilgiyi buradan edinebilirsiniz. |
| Sunucu Uç Noktası | Sunucu uç noktası, nihai tasarımda Güvenilir Toplama Sunucusu olacak mı? | Sunucu uç noktası, toplanan ve dönüştürülen raporları işlemek için kullanılan Güvenilir Toplama Sunucularından bağımsız olan, reklam teknolojisi tarafından yönetilen bir uç noktadır. Şu anda raporlama uç noktası için planlanmış herhangi bir değişiklik yoktur. Mevcut tasarım, birleştirilebilir raporların (şifrelenmiş yüklerle) siteler arası veri sızıntısı oluşturmamasını sağlamayı amaçlar. Bu nedenle, güvenilir bir uç nokta gerekli değildir. Farklı reklam teknolojilerinin farklı gruplandırma stratejileri olması da ek bir karmaşıklıktır. Buradaki ek geri bildirimlerinizi bekliyoruz. |
| WebIDL | Mevcut Protected Audience API spesifikasyonu, WebIDL spesifikasyonuyla uyumlu değildir. | Bu geri bildirimi değerlendiriyor ve sorunu burada tartışıyoruz. |
| İzin Yönetimi | Kullanıcı rızası sinyali iletimi Protected Audience API'de nasıl ele alınır? | Bağlamsal bilgiler Protected Audience API kapsamında değildir. Bu konuyu görüşüyoruz ve ek geri bildirimlerinizi bekliyoruz. |
| Hesaba Dayalı Pazarlama | Hesaba dayalı pazarlama kullanım alanları mümkün mü? | Protected Audience API, kitle tabanlı çeşitli pazarlama kullanım alanlarını destekler. Protected Audience API'nin bu kullanım alanını en iyi şekilde nasıl destekleyebileceğini anlamaya devam ediyoruz. Bu konuda ekosistemden ek geri bildirim almaktan memnuniyet duyarız. |
| Bileşen açık artırması | Bileşen açık artırması katılımcıları neyi puanlar? | Bileşen açık artırmaları, ilgi alanı gruplarını doğrudan puanlamaz. Bunun yerine, bir TTP'nin generateBid işlevinden gönderdiği reklamları ve teklifleri puanlar. generateBid() işlevi, ilgi alanı grubu başına çalışır ve TTP, generateBid'i yürüttüğünde aşağıdakileri döndürür: return {
'ad': adObject,
'adCost': optionalAdCost,
'bid': bidValue,
'render': renderUrl,
'adComponents':
[adComponent1, adComponent2, ...],
'allowComponentAuction': false,
'modelingSignals': 123};
}
|
| Harici Katkılar | Anahtar/Değer Sunucusu GitHub kod tabanında harici katkıları destekleme isteği. | GitHub koduna harici katkıları desteklemek için ilgili süreçlerimizi güncellemeye çalışıyoruz. |
| İlgi Alanı Grubu Boyutu | IG'nin destekleyebileceği maksimum anahtar sayısı nedir? | Şu anki sınır, bir IG boyutu için 50 KB'tır ve anahtarlar bu sınıra dahildir. Boyut sınırı hakkında daha fazla tartışma için bizimle iletişime geçebilirsiniz. |
| Toplu işleme | K/V sunucusu çağrılarının sayısı nasıl azaltılabilir? | K/V çağrılarının sayısını azaltmak için HTTP Önbellek Kontrolü Üst Bilgilerini kullanabilirsiniz. Örneğin, bileşen açık artırmaları ve tek bir sayfadaki reklam alanları arasında önbelleğe alınabilir. |
| Sürüm denetimi | Reklam teknolojisi kodunun birden fazla sürümü için destek | Teklif ve açık artırma hizmetleri, reklam teknolojisi kodunun birden fazla sürümünü destekleyecektir. Teklif ve Açık Artırma API'sinde SelectAd isteği, açık artırma isteği için kullanılan kodun sürümünü (ör. teklif verme / açık artırma ve raporlama için) belirtebilir. |
| Paylaşılan Depolama | Teklif ve Açık Artırma Hizmeti'nde Paylaşılan Depolama Alanı'na yazma desteği. | Teklif Verme ve Açık Artırma Hizmetleri şu anda Paylaşılan Depolama Alanını desteklemiyor ancak bu tür kullanım alanlarının ekosistem için neden önemli olduğuyla ilgili ek geri bildirimler bekliyoruz. |
| Web'den uygulamaya | İlgi alanı gruplarının web'den uygulamaya paylaşımını destekleyin. | Web'den uygulamaya veri aktarımı, şu anda Chrome ve Android'de Protected Audience API dağıtımında kapsamlı değildir ancak ekosistemin bu kullanım alanının önemi hakkındaki görüşlerini öğrenmek isteriz. |
| K-Anonymity | K-anonimlik yedekleri nasıl ele alınır? | Sorunu görüşüyoruz ve ek geri bildirimlerinizi bekliyoruz. |
Dijital reklamları ölçme
İlişkilendirme raporları (ve diğer API'ler)
| Geri bildirim teması | Özet | Chrome Yanıtı |
|---|---|---|
| Alternatif VTC Etkinlik Düzeyi Rapor Yapılandırmaları | Alternatif VTC etkinlik düzeyindeki rapor yapılandırmaları hakkında geri bildirim | Mevcut etkinlik düzeyindeki yapılandırmaların optimal olmadığına dair bazı geri bildirimler aldık ve optimal genel yapılandırmalar hakkında geri bildirim istiyoruz. Bu konuyla ilgili ek geri bildirim almaya açığız. Esnek etkinlik düzeyinde açıklamamızı da bu konuda yardımcı olacağını düşünüyoruz. |
| Esnek etkinlik düzeyinde yapılandırmalar | Esnek etkinlik düzeyinde yapılandırma özelliğinin durumu nedir? | Esnek etkinlik düzeyinde yapılandırma ile ilgili dokümanları paylaştık. Bu özellik henüz teklif aşamasındadır ve ekosistem için değerli olup olmayacağı konusunda daha fazla geri bildirim almak istiyoruz. |
| Esnek etkinlik düzeyinde yapılandırmalar | Farklı taraflardan gelen çelişen raporlar nasıl uyumlu hale getirilebilir? | Çoğu raporlama senaryosu toplu raporlar kullanılarak ele alınırken esnek etkinlik düzeyinde yapılandırma önerisi, özellikle en sık optimizasyon kullanım alanları için kullanılan etkinlik düzeyindeki raporlarda ek esneklik sağlamak içindir. Bu senaryayla ilgili ek ekosistem yorumları/geri bildirimleri için bizimle iletişime geçebilirsiniz. |
| Kaynak kaydı | Kaynak kaydı tetikleyici kaydından sonra gerçekleşirse ne olur? | Şu anda, tetikleyici kaydı yapıldıktan sonra bir kaynak kaydı yapılırsa kaynak ve tetikleyici birbirine ilişkilendirilemez. Bu, sıra dışı bir durum senaryosu gibi görünüyor. Bu sorunla ilgili ek geri bildirimler bekliyoruz. Birçok reklam teknolojisinin karşılaştığı bir senaryoysa sorunu gidermeye çalışacağız. |
| Birden fazla reklam ajansıyla çalışma | Bir reklamveren birden fazla reklam ajansıyla çalışıyorsa TTP'ler Attribution Reporting API'yi nasıl kullanabilir? | API, yönlendirmeleri destekler ve bu nedenle bir reklamveren birden fazla reklam ajansıyla çalışıyor olsa bile kullanılabilir. Ayrıca, API'nin gizliliği iyileştirdiğinden emin olmak için yönlendirmelerle ilgili bazı sınırlamalar vardır. Ayrıca, reklam teknolojisinin ortaya çıkardığı belirli senaryo için Shared Storage API'yi kullanan olası bir geçici çözüm de belirledik. Bu senaryoyla ilgili ek geri bildirimler bekliyoruz ve bu geri bildirimler doğrultusunda geliştirme yapmaya devam edeceğiz. |
| Hedef Sınırları | Otomatik olarak yenilenen reklamlar kullanım alanı, hedef sınırlarından etkilenebilir. | Bu konuyu 1 Mayıs tarihli WICG toplantısında ele aldık ve makul bir sınırın ne olabileceği konusunda geri bildirim almak istiyoruz. Etkinlik düzeyinde raporlarla ilişkilendirme raporlaması açıklamamıza, tarayıcının kaynak siteler tarafından temsil edilen "hedef" eTLD+1 sayısını sınırlandırabileceğini belirten bir açıklama ekledik. (Alma isteği konusuna bakın.) |
| İlişkilendirme Raporları ve Korunan Kitle | Attribution Reporting API ve Protected Audience API birlikte nasıl çalışabilir? | Entegrasyonlar şu anda hem Attribution Reporting API modlarında (etkinlik düzeyinde ve özet raporlar) hem de Protected Audience API için kullanılabilir. 1 Haziran'da, iyileştirilmiş Protected Audience API ve Attribution Reporting entegrasyonu hakkında daha fazla bilgi paylaştık. Bu konu hakkında daha fazla bilgiyi buradan edinebilirsiniz. |
| Esnek etkinlik düzeyinde yapılandırmalar | Parametreler yapılandırılabilir hale geldiğinden artık gürültü simülasyonuyla ilgili en iyi uygulamaları paylaşın. | Test etmek istedikleri esnek etkinlik düzeyindeki yapılandırmalar için bilgi kazancı ve gürültü etkisini değerlendirmek üzere herkesin kullanabileceği GitHub'da kod paylaştık. Kodu test etmeyi seçen ve geri bildirim paylaşmak isteyen herkesten haber almak isteriz. |
| Uygulamalar ve web arasında ilişkilendirme ölçümü | Uygulamalar arası ve web ilişkilendirme ölçümü ne zaman kullanıma sunulacak? | 9 Mayıs'ta Attribution Reporting API aracılığıyla uygulama ve web genelinde ilişkilendirme ölçümü için bir deneme duyurmuştuk. Chrome 115'te alaka düzeyi ve ölçüm API'leri için genel kullanıma sunma planı olsa da uygulama ve web ilişkilendirme ölçümünün şu anda Chrome 115 ile genel kullanıma sunulması planlanmıyor. |
| Dönüşümleri tekilleştirme | Bağımsız ölçüm çözümleri, ARA ile nasıl uyumlu hale getirilebilir? | Mevcut standart uygulamada olduğu gibi, reklamverenler dönüşüm raporlamasını tekilleştirmek için üçüncü taraf bağımsız bir ölçüm sağlayıcıyla çalışır. Etkinlik düzeyinde raporlama için dönüşümleri tekilleştirme hakkında kaynaklar sunduk. |
| İlişkilendirme raporlama veritabanı güncellemeleri sırasında veri kaybı | Chrome, İlişkilendirme Raporlama Veritabanı'nı açıklandığı şekilde güncellediğinde veri kaybı yaşanır mı? | Chrome 115 kararlı sürümünden itibaren, Chrome kullanıcılarının bir kısmı için Relevance ve Measurement API'lerini varsayılan olarak etkinleştirmeye başlayacağız. Olası sorunları izlerken bu genel kullanılabilirlik artacaktır. Hedefimiz, 2023'ün 3. çeyreğine kadar birkaç hafta içinde% 100 kullanılabilirlik elde etmektir. Bu, Alaka düzeyi ve Ölçüm kaynağı denemesinin sona ermesiyle aynı zamana denk gelecektir. Temmuz ayından itibaren test kullanıcıları, genel kullanıma sunulan bu API'lere erişmek için kaydolabilecektir. Bu sayede, orijinal deneme sürümünün kullanılabilirliği ile kayıt yoluyla genel kullanılabilirlik arasında çakışma yaşanmaz. Kaynak deneme jetonunuz 19 Eylül'e kadar geçerli olacak ancak devam eden testleri kesintiye uğratmadan kaynak denemeden sorunsuz bir şekilde geçiş yapmak için API'lere süre dolmadan önce kaydolmanızı öneririz. Bu duyuruda belirtildiği gibi, eski sürümlerden (M113 ve önceki sürümler) kaydedilen veriler güncelleme sonrasında taşınmayacağından veri kaybı yaşanabilir. Bu veri kaybı, hata ayıklama raporlarında gösterilmez ve 114 ile 115 arasında veri kaybı yaşanmasını önlemeye çalışırız. |
| Faturalandırma | Dönüşüm başına maliyet faturalandırması için ilişkilendirme raporlarını kullanma | Bu makalede belirtildiği gibi, Attribution Reporting API, etkinlik düzeyindeki ve özet raporlara eklenen gürültü nedeniyle dönüşüm başına maliyet faturalandırma ihtiyaçlarına uygun olmayabilir. Ekosistemdeki oyuncuların, Attribution Reporting API'nin çeşitli faturalandırma modelleri üzerindeki etkisiyle ilgili geri bildirimlerini GitHub'da paylaşmalarını öneririz. |
Aggregation Service
| Geri bildirim teması | Özet | Chrome Yanıtı |
|---|---|---|
| Toplanabilir rapor gecikmesi değişikliği | Ekosistemden gelen geri bildirimler doğrultusunda, birleştirilebilir rapor gecikmesinin [10-60 dakika] yerine [0-10 dakika] olarak değiştirilmesi önerisine olumlu tepkiler | Önerilen değişiklikle ilgili olumlu tepkiler görmekten memnuniyet duyuyoruz ve ekosistemi, önerilerimizle ilgili geri bildirim vermeye devam etmeye teşvik ediyoruz. |
| Şirket içi çözüm | Toplama Hizmeti şirket içi veri merkezlerinde dağıtılabilir mi? | Bulut tabanlı çözümlerin ötesinde olası destek seçeneklerini araştırıyoruz ancak Özel Korumalı Alan için zaman alıcı bir değerlendirme gerektiren şirket içi güvenlik sınırlamaları nedeniyle şirket içi TEE'leri şu anda desteklememiz mümkün değildir. Ö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 GCP'yi desteklemeye) devam etmenin ekosistem için en yararlı seçenek olduğuna inanıyoruz. Ancak bu tür bir şartın neden gerekli olduğu konusunda ek geri bildirimlerinizi bekliyoruz. |
| Raporları farklı dönemler için yeniden işleme | Raporları farklı dönemler için yeniden işleyebilme | Farklı tarih aralıkları için grupları bölebilmek üzere benzer talepler aldık. Bir öneri, raporların farklı gruplara bölünebilmesi için paylaşılan kimliğin reklam teknolojisi tarafından tanımlanan bir etiketle genişletilmesine izin vermektir. Bu süreci değerlendirme sürecinin ilk aşamalarındayız ve bu teklif geliştikçe ekosistemi bilgilendirmeye devam edeceğiz. |
| Güvenilir Yürütme Ortamının Gizlilik Açısından Yansımaları | Güvenilir Yürütme Ortamlarının gizlilik üzerindeki etkilerine yönelik olumlu görüşler | Önerilerimizle ilgili olarak ekosistemden olumlu tepkiler almaktan memnuniyet duyuyoruz. Geliştirme ve iterasyon süreçlerine devam ederken ek geri bildirimler almak için sabırsızlanıyoruz. |
| Hizmet Şartları | Toplama Hizmeti Hizmet Şartları'nı kabul etme son tarihi nedir? | Hükümler ve koşulları kabul etmek için henüz son tarih belirtmemiş olsak da ekosistem şirketlerinin, kayıtta gecikme yaşanmaması için hükümler ve koşulları en kısa sürede kabul etmesini öneririz. Şirketlerin soruları varsa bizimle iletişime geçmelerini öneririz. |
| Anahtar Keşfi | Anahtar bulma özelliği, test kullanıcılarının daha iyi performans ve doğruluk için ağlar arası ilişkilendirmeyle ilgili özet raporları işlemek üzere olası anahtar kombinasyonlarının açık listesine ihtiyaç duymadan toplu raporları sorgulamasına olanak tanır. | Şu anda olası çözümleri ve geçici çözümleri araştırıyoruz. Ekosistemden daha fazla geri bildirim almaktan memnuniyet duyarız. |
Private Aggregation API
| Geri bildirim teması | Özet | Chrome Yanıtı |
|---|---|---|
| Bildirim kaynağı | Raporlama kaynağı nasıl tanımlanır? | Raporlama kaynağı, her zaman Gizli Toplama çağıranın komut dosyası kaynağıdır. |
| 128 bit anahtar alanı | 128 bit anahtar alanı sınırlaması hakkında netlik | Bu anahtar alanı sınırlamasını daha net hale getirecek ve sayfalar arasındaki tutarsızlıkları gidereceğiz. Bu anahtar alanında kalmak için karma oluşturma stratejileri kullanmanızı öneririz. |
| Rapor başına maksimum katkı | Rapor başına 20 katkıyla belirlenen mevcut sınır çok düşük. | Maksimum katkı sayısını artırmak yerine, sınıra ulaşıldığında raporları kesmek yerine bölmeyi değerlendirmeye açığız. Bu teklif geliştikçe ekosistemle etkileşime geçeceğiz. |
| Erişim raporları | Platformlar arası/cihazlar arası erişim raporlaması isteği. Erişim, marka reklamcılığının temel metriklerinden biridir. Reklamverenler, kampanyalarını analiz etmek ve harcama tahsis etmek için erişim ve sıklık raporlaması için platformlar arası/cihazlar arası yaklaşık değerlere güvenir. Erişim modelleri, üçüncü taraf ortamlarda gösterilen reklamları ölçmek için üçüncü taraf çerezlerini sinyal olarak kullanır. Bu nedenle, üçüncü taraf çerezlerinin desteği sonlandırıldıktan sonra reklam teknolojileri alternatif bir çözüm talep etti. |
Özel Korumalı Alan ekibi, üçüncü taraf çerez desteğinin sonlandırılmasından sonra alan adları arası erişim metodolojilerini destekleyen özellikleri araştırıyor. Ekosistemden ek geri bildirimler bekliyoruz. |
Gizli İzlemeyi Sınırlama
Kullanıcı Aracısı Azaltma/Kullanıcı Aracısı İstemci İpuçları
| Geri bildirim teması | Özet | Chrome Yanıtı |
|---|---|---|
| (2023'ün 1. çeyreğinde de bildirilecek) Ek form faktörleriyle ilgili ipuçları | TV, VR gibi ek form faktörleri sağlamak için kullanıcı aracısı istemci ipuçları (UA-CH) isteğinde bulunma | Bazı önemli tasarım kararları (ör. "TV" gibi tek bir değer mi yoksa form faktörü özelliklerinin listesi mi sağlanacağı) üzerinde çalışmaya devam ediyoruz ancak bu fikrin prototipini oluşturmaya ilgi duyuyoruz. |
| Gizli Erişim Limiti | Gizlilik bütçesi kısıtlamaları, çok fazla istek gönderildiğinde UA-CH isteklerinin kesin olmayan hale gelmesine neden olabilir. | Gizlilik Bütçesi önerisiyle ilgili şu anda yeni bir güncellememiz yok ancak üçüncü taraf çerezleri desteği sonlandırılmadan önce UA istemci ipuçları isteklerini kısıtlamayacağımızı taahhüt ettik. |
| Site Uyumluluğu | Web siteleri, belirli tarayıcıların sitelere erişmesini kısıtlamak için UA-CH markasını kullanıyor. | Marka listesi oluşturmanın geçerli kullanım alanları vardır. Bunlardan biri de uyumluluktur. UA'ların bu sorunları gidermek için birden fazla markaya sahip olması serbesttir. |
IP Protection (eski adıyla Gnatcatcher)
| Geri bildirim teması | Özet | Chrome Yanıtı |
|---|---|---|
| Sahtekarlık ve Kötüye Kullanım | Şirketler, IP koruması ile sahtekarlık önleme önlemlerini nasıl ayarlayabilir? | Sahtekarlık önleme kullanım alanlarının önemini ve bu kullanım alanlarındaki olası etkiyi anlıyoruz. Sahtekarlık önleme desteğiyle ilgili daha fazla bilgiyi bu yaz paylaşmayı planlıyoruz. Sahtekarlık önleme kullanım alanlarını nasıl daha iyi destekleyebileceğimiz konusunda ekosistemden geri bildirim almak istiyoruz. |
| GeoIP | Coğrafi IP için test ve dağıtım zaman çizelgesi hakkında daha fazla bilgi | Chrome kısa süre önce Coğrafi IP planlarımızı ayrıntılı olarak açıklayan yeni bilgiler yayınladı. 3. çeyrekte dağıtım zaman çizelgeleri hakkında daha fazla bilgi yayınlamayı planlıyoruz. IP Koruması'nı ilk olarak trafiğin küçük bir yüzdesinde kullanıcının etkinleştirmesi gereken bir özellik olarak kullanıma sunmayı planlıyoruz. Bunun nedeni, bu teklifin şirketler için bazı önemli değişiklikler içerebileceğinin farkında olmamız ve özelliğin daha geniş bir kapsamda kullanıma sunulmadan önce ekosisteme uyum sağlama ve geri bildirim verme zamanı tanımak istememizdir. |
| Hesap kimlik doğrulaması | Proxy sunucusu ile hesap kimlik doğrulaması tam olarak nasıl çalışır? | Hesap kimlik doğrulaması hakkında daha fazla bilgiyi bu yaz paylaşmayı planlıyoruz. Bununla birlikte, ilk değerlendirmelerimizi daha önce paylaşmıştık. |
Hemen Çıkma Durumunu İzleme Çözümü
| Geri bildirim teması | Özet | Chrome Yanıtı |
|---|---|---|
| Test Yönergeleri | Hemen çıkma durumunu izleme çözümünü test etme hakkında bilgi | Hemen çıkma izleme azaltma özelliğinin nasıl test edileceği hakkında daha fazla bilgi içeren bir blog yayını Mayıs ayında yayınlandı. |
| Belgeler | Sıçramalı İzleme Önerisinde Netlik | Mevcut teklif üzerinde yoğun bir şekilde çalışılıyor. Chrome, ekosisteme netlik ve bilgi sağlamak için teklifi güncellemeye devam ediyor. Daha fazla ayrıntı sağlamak için çalışmalarımızı sürdürüyoruz. Ek geri bildirimlerinizi bekliyoruz. |
| Çerez silme | Hemen çıkma izleme azaltma özelliği, bir alandaki tüm çerezleri siler mi? | Hemen çıkma izleme azaltma (BTM), burada açıklandığı gibi tüm depolama alanını ve tüm önbelleği temizler. |
| Hemen Çıkma Durumunu İzleme Çözümünü Atlama | Hemen çıkma izleyici sınıflandırması, pop-up'lar veya yeni sekmelerle yönlendirme yapılarak atlanabilir. | Hemen çıkma durumunu izleme çözümü spesifikasyonu hâlâ geliştirme aşamasındadır. Şimdiye kadar çoğunlukla aynı sekmedeki yönlendirmelere odaklandık ancak gelecekte pop-up akışları üzerinde çalışmayı planlıyoruz. Buradaki ek geri bildirimlerinizi bekliyoruz. |
Gizli Erişim Limiti
| Geri bildirim teması | Özet | Chrome Yanıtı |
|---|---|---|
| Yakınlık Hedefleme | Gizlilik bütçesi, yakınlık hedefleme kullanım alanlarını etkileyebilir. | Bu konuyla ilgili geri bildirimler aldık ve ekosistemin olası etkileri hakkında daha fazla bilgi edinmek istiyoruz. |
Siteler arası gizlilik sınırlarını güçlendirme
Birinci Taraf Gruplar
| Geri bildirim teması | Özet | Chrome Yanıtı |
|---|---|---|
| (Önceki çeyreklerde de raporlanmıştır) Alan Sınırı | İlişkilendirilen alan adlarının sayısını artırma isteği | Chrome, tanımlanan kullanım alanları için gizlilik ve yararlılığı dengeleyecek, İlişkili alt küme için uygun sayısal sınırı değerlendiriyor. Chrome, başlangıçtan itibaren, ilişkili alt kümenin tam sayısının henüz kesinleşmediğini paylaşmıştı. |
| Yerleştirilmiş Kullanım Alanı | Birinci Taraf Gruplar, CHIP'ler ve paylaşılan depolama alanı gerektiren yerleşik kullanım alanları için destek | Chrome, bu kullanım alanıyla ilgili geri bildirimi aldı. Ekip konuyu araştırıyor ve ek geri bildirimleri bekliyor. |
| Depo Yönetimi | Tutarsızlık veya ihmal varsa First-Party Sets'in GitHub deposundan kaldırılmasına ilişkin politikalar hakkında bilgi | Chrome, bu kullanım alanıyla ilgili geri bildirimi aldı. Ekip konuyu inceliyor ve ek geri bildirimler bekliyor. |
| Kullanıcı Eğitimi | Chrome, kullanım oranını artırmak için kullanıcıların birinci taraf kümelerle ilgili farkındalığını ve bilgisini artırmalıdır. | Chrome, kullanıcıları Birinci Taraf Gruplar hakkında bilgilendirmeye kararlıdır ve bu konuda bir Yardım Merkezi makalesi (Chrome kullanıcı arayüzünden bağlantısı verilmiştir) yayınlamıştır. Chrome, kullanıcıları uygun bağlamlarda en iyi şekilde nasıl eğitebileceğini öğrenmeye de devam etmektedir. |
| 3PCD yayını | Üçüncü taraf çerezlerine yönelik desteğin sonlandırılmasından sonra üçüncü taraf çerezleri, birinci taraf grubunda var olmaya devam edecektir. | requestStorageAccess ve requestStorageAccessFor, üçüncü taraf çerezlerini belirli ve net bir şekilde tanımlanmış kullanım alanları için yeniden kullanılabilir hale getirse de artık üçüncü taraf çerezlerinin mevcut durumu (Chrome'da) gibi varsayılan olarak kullanılabilir olmak yerine site tarafından etkin olarak çağrılmasını gerektiriyor.Tek bir grup içinde yapılan bu çağrı için kullanıcı onayı gerekmez ancak kullanıcılar, Ayarlar'da bu davranışı devre dışı bırakarak bunu önleyebilir. Kullanıcılar, Yardım Merkezi makalesinde (Chrome kullanıcı arayüzünden bağlantısı verilmiştir) daha fazla bilgi edinebilir. FPS %100'e yükseldikçe mevcut geliştirici kılavuzunu genişletmeyi planlıyoruz. |
| First-Party Sets gönderimi | Gerekli .well-known/first-party-set dosyasını .json uzantısı içerecek şekilde yeniden adlandırın. |
Belirli web barındırma planlarının desteklenmesini sağlamak için bu değişikliği yaptık. |
| IANA Kaydı | first_party_sets.JSON, IANA'ya kayıtlı olmalıdır. |
Teklifi değerlendiriyoruz ve buradan ek geri bildirimlerinizi bekliyoruz. |
Fenced Frames API
| Geri bildirim teması | Özet | Chrome Yanıtı |
|---|---|---|
| Reklam Engelleme | Çitli çerçeveler, reklam engelleyicilerin reklamları engellemesini kolaylaştırabilir. | Uzantılar, çevrili çerçevelerle iframe'lerle etkileşime geçecekleri şekilde etkileşim kurabilir. Çitli çerçevenin yönlendirileceği gerçek URL de uzantılara görünür. Bu nedenle, uzantılar, iframe'lerde olduğu gibi engelleme için herhangi bir URL eşleştirme kuralı uygulayabilir. Tüm çitli çerçeveleri koşulsuz olarak engellemek, çitli çerçevelerin reklam dışı kullanım alanlarını bozabilir. |
Shared Storage API
| Geri bildirim teması | Özet | Chrome Yanıtı |
|---|---|---|
| Daha geniş kapsamlı benimsenme | 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 W3C forumlarına aktif olarak katılmaya devam ediyor. |
| Çıkış Kapıları | Paylaşılan depolama alanı çıkış kapıları çok sınırlı. | Bu geri bildirimi dikkate alıyoruz ve çıkış kapılarının neden çok sınırlı olduğuyla ilgili ek ekosistem geri bildirimlerini memnuniyetle karşılıyoruz. |
| Yasal Düzenlemelere Uygunluk | Paylaşılan depolama alanı, veri saklama politikaları gibi yasal uygunluk konularını nasıl ele alacak? | Paylaşılan Depolama, depolanan verilerin kullanım süresini ve geçerlilik bitiş tarihini kontrol etmek için mantık uygulama ve özelleştirme esnekliği sunar. Reklam teknolojileri, yazma zaman damgalarını temel alarak Ortak Depolama Alanı verilerini güncelleyebilir veya temizleyebilir. |
| A/B Testi | Paylaşılan Depolama ve Protected Audience API için A/B testi nasıl yapılabilir? | Bu konuda ek rehberlik yayınlamak için çalışıyoruz ve gelecekte daha fazla ayrıntı paylaşmayı umuyoruz. |
| Paylaşılan Depolama Alanı Sınırı | Ortak depolama alanı sınırına ulaşıldığında ne olur? | Sınıra ulaşılırsa başka giriş saklanmaz. |
| Aynı sayfa yüklemesinde birden fazla erişim | Aynı sayfa yüklenirken Ortak Depolama alanına birden fazla kez erişildiğinde ne olur? | Bunu yapmanın en iyi yolu window.sharedStorage.append(key, value) işlevini kullanmaktır. Birden fazla reklam varsa çakışmalara neden olabilecek her reklamın değerini güncellemek yerine. Sonuna ekleme işlevi, yeni değeri mevcut değerin sonuna ekler. |
| iFrame İşlevi | Üçüncü taraf çerezlerine yönelik desteğin sonlandırılmasının ardından artık çalışmayan belirli iframe işlevleri, Ortak Depolama'da desteklenecek mi? | Üçüncü taraf çerezlerine yönelik desteğin sonlandırılmasından sonra, iFrame'lerdeki yerel depolama alanı üst düzey site tarafından bölümlenir ancak iFrame'lerin kendisi engellenmez. Bir iframe'ın yerel depolama alanındaki veriler birden fazla üst düzey sitede çoğaltılamaz ancak yerel depolama alanı iframe içinde kullanılabilir. |
CHIPs
| Geri bildirim teması | Özet | Chrome Yanıtı |
|---|---|---|
| Bölüm sınırı | Bölünmüş site başına 10 KiB hâlâ önemli bir değer. Bu değeri düşürülmesini istiyoruz. | Firefox, CHIPS'de pozitif bir konum sergiledi. Webkit desteği için geliştiricilerin, bölümlenmiş depolama yerine bölümlenmiş çerezlerin tercih edildiği kullanım alanlarıyla ilgili olarak doğrudan Apple'a bu GitHub sorunu hakkında geri bildirimde bulunmalarını öneririz. |
| Kimlik doğrulaması yapılmış yerleşimler | CHIP'ler, kimliği doğrulanmış yerleşik öğeleri etkileyen farklı bölümlendirme nedeniyle mevcut TOA oturum açma akışını etkileyebilir. | Kimlik doğrulanmış yerleşik içerik kullanım alanını desteklemek için Storage Access API'den (kullanıcı istemleriyle) yararlanmayı planlıyoruz ve kısa süre önce bir prototip oluşturma isteği gönderdik. |
| Ömür Boyu Politikaları | Potansiyel ömür boyu politikalar birinci taraf çerezleri için geçerli olacak mı? | Şu anda birinci taraf çerezleri için ömür boyu sınırlar uygulamayı planlamıyoruz. |
FedCM
| Geri bildirim teması | Özet | Chrome Yanıtı |
|---|---|---|
| OAuth Yetkilendirme Desteği | Profil dışı Oauth kapsamlarının yetkilendirilmesi konusunda uzlaşmaya varma | Üçüncü taraf çerezleri için desteğin sonlandırılmasının ardından temel kimlik doğrulamanın ötesinde yetkilendirmeyi desteklemenin en iyi yolları hakkında W3C FedID CG aracılığıyla Web Kimliği topluluğundan aktif olarak görüş alıyoruz. |
| SAML desteği | SAML desteğiyle ilgili şartlara uyma | Ekip, üçüncü taraf çerezlerinin desteğinin sonlandırılmasının ardından SAML destek ihtiyaçları (OpenID Connect desteğinin yanı sıra) hakkında araştırma ve eğitim topluluklarından aktif olarak görüş istemektedir. |
Spam ve sahtekarlıkla mücadele etme
Private State Token API (ve diğer API'ler)
| Geri bildirim teması | Özet | Chrome Yanıtı |
|---|---|---|
| Yeni sinyalleri keşfetme | Birkaç iş ortağı, tarayıcı tarafından kolaylaştırılan cihaz bütünlüğü veya kullanıcı güveni sinyallerini keşfetme konusunda olumlu bir tutum sergiledi. Genellikle, özel olarak tasarlanmış yeni sinyallerin mevcut sahtekarlık tespiti seviyelerini korumaya yetip yetmeyeceği konusunda da dikkatli davranırlar. | Dolandırıcılık ve web güvenliği topluluğuyla birlikte yeni teklifleri keşfetmekten ve endişelerini kabul edip paylaşmaktan heyecan duyuyoruz. "Spam ve dolandırıcılıkla mücadele"nin Özel Korumalı Alan'ın temel çalışma akışlarından biri olmasının ve kullanıcı gizliliğini iyileştirirken web güvenliğini korumaya yönelik yatırımlara öncelik vermeye devam etmemizin nedeni de budur. |
| PST ile ilgili olumlu geri bildirim | Çeşitli iş ortakları, çeşitli sahtekarlık önleme veya web güvenliği kullanım alanları için PST'leri test etmek ya da kullanmak istediklerini belirtti. | PST'leri kullanan yeni çözümleri daha ayrıntılı bir şekilde keşfetme konusundaki desteğinizi ve ilginizi görmekten memnuniyet duyuyoruz. Chrome geliştirici sitesinde kaynaklarımıza ve örnek kodlarımıza ulaşabilirsiniz. Daha fazla geri bildirim gönderebilirsiniz. |
| Sahtekarlık ve Kötüye Kullanım | Üçüncü taraf çerezlerine yönelik desteğin sonlandırılmasının ardından tanımlayıcılar artık kullanılamadığında ölçümde reklam sahtekarlığını önleme / algılamayla ilgili yol gösterici bilgiler. | Sahtekarlık önleme amacıyla üçüncü taraf çerezleri tarafından kaybedilen sinyallerin bir kısmını yeni gizlilik denetimleriyle birlikte kurtarmaya yardımcı olan gizli durum jetonları gibi araçlar kullanıma sunduk. Diğer Özel Korumalı Alan değişiklikleriyle birlikte özellikleri korumak için sahtekarlık ve kötüye kullanım karşıtı yeni tekliflere aktif olarak yatırım yapıyoruz. |
| Kart veren kuruluştan kaynak kuruluşa bilgi oranı | Yayıncıdan kaynağa bilgi oranı, benzersiz kullanıcıları tanımlayacak kadar yüksek olmalıdır. | Özel durum jetonları kullanılarak hangi kullanıcı verilerinin iletilebileceği konusunda daha net olması için spesifikasyonu güncelledik. Tasarım gereği, aynı anda en fazla altı ortak anahtar kullanılabilir. Bu anahtarlar, belirli bir kullanıcının "durumu"nu temsil edebilir. Bu anahtar kümeleri yalnızca 60 günde bir güncellenebilir (acil durum anahtar rotasyonunun gerekli olduğu nadir durumlar hariç). Bu da zaman içinde ek kullanıcı verilerini birleştirme potansiyelini yavaşlatır. Her yeni web API'sinde, sağlanan fayda ve sağladığı net yeni kullanıcı bilgileri arasında bir denge vardır. PST'lerin, üçüncü taraf çerez desteğinin sonlandırılmasından etkilenen önemli sahtekarlık önleme kullanım alanlarını etkinleştirirken kullanıcı gizliliğini koruma konusunda uygun dengeyi sağladığını tahmin ediyoruz. |
| Entegrasyonu Getirme | fetch entegrasyonu karmaşık ve gereksiz. |
fetch'ün kullanılmasının avantajları ve dezavantajları vardır. Web ekosisteminde daha fazla standartlaşmayı benimsemek isteriz ancak standardın nasıl olacağına dair daha net bir fikir edinene kadar bu değişikliği yapmanın çok erken olacağını düşünüyoruz. Bir standart ortaya çıkarsa ve ortaya çıktığında web geliştiricilerini bu standarda sorumlu bir şekilde geçirmeyi de taahhüt ediyoruz. |
| Depolama Konumu | Gizlilik Jetonu anahtar yapılandırmaları, PrivacyPass Protokolü ile aynı konumda saklanmalıdır. | Geliştiriciler, Kaynak Deneme Sürümü sırasında yaptıkları testlerde, anahtarlarını .well-known dizininde saklamak yerine genel URL'lerde saklama esnekliğini tercih ettiklerini belirtti. PrivacyPass'teki anahtar taahhüt biçimi, anahtar kümelerinin gizli bir "herkese açık meta veri" değerine izin vermesi amaçlanan bir sürüm için özellikle uygun değildir. PrivacyPass'in bir varyantı herkese açık meta verileriyle standartlaştırılırsa (POPRF, kısmi RSA karartma veya anahtar kümeleri olarak) bunu desteklemek için PST'nin gelecekteki bir sürümüne geçebiliriz. |
| API'nin başlık uygulaması | API'nin başlık uygulamasıyla ilgili sorular | API standartlaştıkça ve bu API'nin ekosistem kullanımı olgunlaştıkça, bu API'nin hem standart başlıksız sürümünü destekleyebiliriz hem de kullanım yeterince düşükse veya kullanım/kupon kullanma isteklerini diğer verilerle ilişkilendirmenin standart yolları için yeterli geliştirici aracı/destek varsa başlık sürümünün desteğini sonlandırabiliriz. Sorunu burada tartışıyoruz. |
| Kayıt | Yayıncıların tarayıcı tedarikçi firmalarına kaydolmasını zorunlu kılmak pratik mi? | Spesifikasyonu, gizlilik jetonları için sağlayıcı kaydı sürecini açıklayacak şekilde güncelledik. Kendi süreci olsa da Privacy Sandbox çalışmalarının geri kalanı için kullanılan kayıt planlarına benzer. Bu planlarda, sağlayıcılardan PST'leri nasıl kullanmayı planladıklarına dair herkese açık bir beyan vermelerini ve kullanıcı gizliliğini koruyan teknik kısıtlamaları kabul etmelerini isteriz. |