Özel Korumalı Alan teklifleri ve Chrome'un yanıtları hakkında alınan ekosistem geri bildirimlerini özetleyen, 2023'ün 2. çeyreğine ait üç aylık rapor.
CMA'ya olan taahhütlerinin bir parçası olarak Google, Özel Korumalı Alan için paydaş etkileşim süreci hakkında üç aylık raporlar (bkz. Taahhütler). Bu Özel Korumalı Alan geri bildirim özeti raporları, geri bildirimde belirtildiği şekliyle çeşitli kaynaklardan Chrome'un aldığı geri bildirim Genel bakış, şunları içerir ancak bunlarla sınırlı değildir: GitHub kullanıma sunulan geri bildirim formunu privacysandbox.com, sektörle toplantılar ve web standartları forumlarını kullanabilirsiniz. Chrome alınan geri bildirimi memnuniyetle karşıladı Google'ın öğrenme sürecini, ekosisteme entegre etme ve tasarım kararları verebilirsiniz.
Geri bildirim temaları, API'lerin yaygınlık düzeyine göre sıralanır. Bunu yapmak için haftalık, aylık, üç aylık azalan düzende düzenleniyor. Ortak geri bildirim herkese açık toplantılarda konuşulan konular incelenerek temalar belirlendi. (W3C, PatCG, IETF), doğrudan geri bildirim, GitHub ve sık sorulan sorular Google'ın dahili ekipleri ve herkese açık formları aracılığıyla görüntülenebilir.
Daha net ifade etmek gerekirse, web standart kuruluş toplantılarının toplantı dakikaları ve doğrudan geri bildirim için Google'ın bire bir paydaş toplantılarının kayıtlarını, mühendisler tarafından alınan e-postalar, API posta listesi ve kamu değerlendirildi. Bunun üzerine Google, bu muhtelif sosyal yardım aktivitelerine katılıp her API ile ilişkili olarak ortaya çıkan temaların yaygınlığı
Chrome'un geri bildirimlere verdiği yanıtların açıklamaları, SSS'ler, paydaşlar tarafından dile getirilen sorunlara verilen gerçek yanıtlar ve nasıl bu genel veri bildirme uygulamasının amaçları doğrultusunda belirlenen yeni pozisyonları kabul eder. Şu anki geliştirme ve test odağı, sorular ve geri bildirimler Topics, Protected Audience ve İlişkilendirme gibi Raporlama API'leri.
Mevcut raporlama döneminin bitiminden sonra alınan geri bildirimler henüz dikkate alınmış bir Chrome yanıtı olabilir.
Kısaltmalar sözlüğü
- CHIPS
- Bağımsız Bölümlendirilmiş Duruma Sahip Çerezler
- DSP
- Talep Tarafı Platformu
- FedCM
- Birleşik Kimlik Bilgisi Yönetimi
- FPS
- Birinci Taraf Gruplar
- IAB
- İnteraktif Reklamcılık Bürosu
- IDP
- Kimlik Sağlayıcı
- IETF
- İnternet Mühendisliği Görev Gücü
- IP
- İnternet Protokolü adresi
- openRTB
- Gerçek zamanlı teklif verme
- uzatma
- Kaynak Denemesi
- PatCG
- Özel Reklamcılık Teknolojisi Topluluğu Grubu
- KY
- 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
- Kasıtlı IP Körlüğü
Genel geri bildirim, spesifik bir API/Teknoloji yok
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Veri Yönetimi ve Yasal Düzenlemelere Uygunluk | Özel Korumalı Alan'ın yasal şartlara uygun şekilde kullanılmasıyla ilgili ekosistem rehberliği. | Her yeni teknolojide olduğu gibi, her şirket Özel Korumalı Alan kullanımının yasalara uygun olmasını sağlamaktan sorumludur; Google, başkalarına yasal tavsiyede bulunamaz. Bununla birlikte, bunun ekosistem için önemli bir ilgi alanı olduğunun da farkındayız. Her API için, gerekli yasal değerlendirmelerin yapılması için dayanmasını sağlayacak kapsamlı teknik dokümanlar yayınladık ve şirketlerin desteklenmesi için ek materyaller sunmak üzere çalışıyoruz. ve yönetmelik şartlarına uymaya ilişkin çaba tahminidir. |
| CMA Nicel Test teklifi | CMA nicel test teklifi hakkında daha fazla bilgi | Üçüncü taraf çerezlerine yönelik desteğin sonlandırılmasının etkileri ve Özel Korumalı Alan tekliflerinin ekosistemde kullanıma sunulmasıyla ilgili bilgiler sağlayacak denemeler tasarlamak için CMA ile birlikte çalışıyoruz. CMA, Nisan ayında Test ve Deneme döneminde neler bekleyebileceğinizle ilgili üst düzey rehberlik ve ardından Haziran ayında ayrıntılı rehberlik yayınladı. CMA'nın Nicel Test teklifine ilişkin soruların veya geri bildirimlerin doğrudan CMA ile paylaşılmasını öneririz. |
| Chrome destekli test modları | Test programları hakkında daha fazla bilgi ve açıklama | 18 Mayıs'ta, Chrome'un desteklediği iki test modu hakkında daha fazla bilginin yer aldığı bir blog yayını yayınladık. Bu ayrıntılar nihai değildir. 2023'ün 3. çeyreğinde ilerledikçe uygulamayla ilgili daha fazla bilgi paylaşacağız. |
| Bölümlendirilmiş Depolama | Chrome'un desteklediği testler sırasında bölümlendirilmiş depolama alanı kullanılacak mı? | Depolama alanı bölümlendirme, üçüncü taraf çerezlerine yönelik desteğin sonlandırılması denemesinden önce tüm kullanıcılara gönderilecektir. Bu nedenle, denemenin tüm kolları için etkinleştirilir. Siteler, bu süre zarfında bölümlendirilmemiş depolama alanını geri almak için desteği sonlandırma denemesini etkinleştirme seçeneğine sahiptir. |
| Prodüksiyon desteği | Chrome'un, Özel Korumalı Alan'da ekosistemi etkileyen teknik sorunları ve üst birime iletme işlemlerini desteklemek için uyguladığı süreç nedir? | Google, reklam teknisyenlerinin sorunları bildirmesine ve gerekli üst birime iletilebilmesi için çeşitli kanallar sağlar. . Geri bildirim ve sorun iletmek için herkese açık ve gizli forumlarda daha fazla bilgi edinmek üzere geliştirici yayınımızı inceleyebilirsiniz. |
| Kayıt Zaman Çizelgesi | Mevcut kayıt zaman aralığı çok kısa | Yaptırım için son tarihi değerlendirmeyi sürdürüyoruz. Bu nedenle, hangi zaman çizelgesinin daha uygun olduğu konusunda ekosistemden bilgi almak isteriz. |
| DUNS Numarası | Kayıt ve onay için D-U-N-S numarası gereksinimi hakkında daha fazla bilgi | Katılımcılar, DUNS numarası alma şartlarını Dun and Bradstreet web sitesinde bulabilir. Koşullar pazara göre değiştiğinden, katılımcılar ilgilendikleri pazarla ilgili web sitesini mutlaka kontrol etmelidir. Bununla birlikte, genel olarak katılımcıların, işletme adı, adresi ve işletme sahibi veya yöneticisinin iletişim bilgileri gibi işletmeleri hakkında temel bilgileri sağlaması gerekir. Katılımcılardan işletmenin yıllık geliri gibi finansal bilgileri de vermeleri istenebilir. Başvuru tamamlandıktan sonra D&B, başvurunuzu inceler ve başvuru onaylanırsa bir D-U-N-S Numarası verir. |
| Kaynak Deneme'den Genel Kullanıma Geçiş | Kaynak Deneme'den Genel Kullanım'a geçiş, mevcut Kaynak Denemesi test kullanıcılarını etkileyecek mi? | Temmuz ayından itibaren, test kullanıcıları alaka düzeyi ve ölçüm API'lerine genel kullanıma sunulduğunda erişebilecek. Bu durumda kaynak deneme sürümü kullanılabilirliği ile genel kullanıma sunulma durumu çakışır. |
| AdExchanger Çalışması | Anket metodolojisi hakkında daha fazla bilgi | Ankette katılımcılardan işletmeleri için senkronizasyon oranlarını ve geliri tahmin etmeleri istendi. Katılımcıların nasıl bir yöntem izlemesi gerektiğini öğrenmişti. |
| Parametre değerleri | Gürültü düzeyi, anonimlik eşikleri ve gizlilik bütçesi gibi parametre değerleri nasıl belirlenir? | Bu GitHub açıklayıcısında, Özel Korumalı Alan API'lerinin temelinde yatan daha genel ilkeler açıklanmaktadır. Birçok değer ile ilgili süreç hâlâ devam ediyor ve bu konuda geri bildirimler almaktan memnuniyet duyarız. |
Alakalı İçerikler Gösterin ve Reklamlar
Konular
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Gizliliği Koruma | Gizliliği koruma ile ilgili Topics API değerlendirme araştırması | Topics API'nin gizlilik özellikleri hakkındaki araştırmamızı makalelerde, raporlarda ve atölye sunumlarında sunarak araştırma topluluğuyla aktif olarak çalışıyoruz. Araştırma topluluğundaki daha fazla harici üyenin bu alanda etkileşimde bulunduğunu görmekten mutluluk duyuyoruz. . . Topics API, kullanıcıları geniş ölçekte izlemeyi çok zor hale getirerek web'de genel izlemeye karşı kullanıcıları korur. Bu makaleler, Topics API ile bu konuda başarılı olduğumuzu gösteriyor. Üçüncü taraf çerezlerinden daha gizlidir ve kullanıcıları korurken ziyaret etmek istedikleri siteleri destekler. |
| Konular sınıflandırması yeterince ayrıntılı değil | Genel konular sınıflandırması, bölgeye özgü olanlar da dahil olmak üzere daha ayrıntılı konular içermez. | Ekosistemden aldığımız geri bildirimlere yanıt olarak, 15 Haziran'da bir blog yayınında, ekosistemden aldığımız geri bildirimler ışığında çok sayıda iyileştirmeyi içeren güncellenmiş yeni sınıflandırmanın ayrıntılarını açıkladık. Revize edilmiş sınıflandırmayla ilgili çalışmalarımız kapsamında, ekosistem genelinde Raptive (eski adıyla CafeMedia) ve Criteo gibi çeşitli şirketlerle etkileşim kurduk. Güncellenen sınıflandırma, daha az faydalı olduğunu düşündüğümüz kategorileri kaldırıp reklamverenlerin ilgi alanlarıyla daha iyi eşleşen kategorilerin tercih edilmesini sağlarken, hassas olabilecek konuları hariç tutma taahhüdümüzü de sürdürüyor. . . Ekosistemin en son sınıflandırmayı gözden geçirmesini ve değişikliklerle ilgili geri bildirim vermesini öneririz. |
| Sınıflandırma ve sınıflandırıcı güncelleme işlemi | Topics sınıflandırması ve sınıflandırıcı sürüm sıklığı ile şirketlerin bu tür güncellemelere nasıl hazırlanabileceği hakkında daha fazla bilgi edinin. | Kısa süre önce yayınlanan blog yayınında belirtildiği gibi, sınıflandırmanın zaman içinde gelişmesini ve sınıflandırma yönetiminin, sektördeki paydaşları temsil eden harici bir tarafa geçiş yapmasını bekliyoruz. Artış planını topics-anunce grubunda da paylaşmıştık. |
| Birinci taraf sinyaller üzerindeki etkisi | Son sınıflandırma güncellemesinde Topics'in sayısındaki artış son derece değerli olabilir ve sonuç olarak diğer birinci taraf ilgi alanına dayalı sinyallerin değerini düşürür. | CMA, 2023'ün 1. çeyreğindeki raporda "Google'ın, önerilen yeni sınıflandırmayı reklam teknolojisi tedarik zincirindeki çeşitli pazar katılımcılarıyla tartıştığını anlıyoruz. Birkaç büyük yayıncı, konulardan daha fazla yararlanmanın birinci taraf verilerine dayalı çözümleri üzerindeki rekabet baskısını artıracağını söylese de ön görüşümüze göre genel olarak rekabet açısından daha fazla fayda, özellikle de küçük yayıncıların üçüncü taraf çerezleri kullanımdan kaldırıldıktan sonra envanterlerinden para kazanmaya devam edebilmesi açısından daha iyidir." Görüşümüz, CMA'nın yaptığı bu yorumla uyumludur. |
| Farklı paydaşlar için kullanışlılık | STP ve TTP işlevi gören reklam teknolojileri, diğer ekosistem oyuncularına göre önemli avantajlara sahip olabilir. | Yanıtımız, önceki çeyreklerle aynı değil: . "Google, CMA'nın Özel Korumalı Alan tekliflerini, kendi işini Google'ın kendi işini tercih ederek rekabeti bozmayacak şekilde tasarlaması ve uygulaması ve boyutları ne olursa olsun dijital reklamcılıkta, yayıncılar ile reklamverenler üzerindeki rekabeti göz önünde bulundurmayı taahhüt eder. Çalışmamızın bu taahhütlere uygun olmasını sağlamak için CMA ile yakın bir şekilde çalışmaya devam ediyoruz. Özel Korumalı Alan testi ilerledikçe değerlendireceğimiz temel sorulardan biri, yeni teknolojilerin farklı paydaş türleri için nasıl performans gösterdiğidir. Geri bildirimleriniz, özellikle teknik tasarımları daha da geliştirmemize yardımcı olabilecek belirli ve eyleme dökülebilir geri bildirimler açısından bu açıdan büyük önem taşıyor. Nicel testlere 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 teklif edilen yaklaşımlar hakkında yorum yapma fırsatı sağlamak için deneme tasarımıyla ilgili bir not yayınlamasını destekliyoruz." |
| Alt Konular | Konu seçme ölçütü tarayıcı ziyaretlerinin sıklığıdır. Bu durumda segment parçalanması, alt konuların hiçbir zaman en üste çıkmamasını sağlayacak mı? | Chrome şu anda diğer sıralama yöntemlerini değerlendirmekte ve sıralamayı iyileştirebilecek diğer sinyalleri araştırmaktadır. Gözden geçirilmiş planlarımızı zamanla ekosisteme ileteceğiz. |
| Hassasiyet | Topics API'nin amacı, Topics API'den edinilen veya türetilen kullanıcı bilgilerinin kişisel olarak bugünün izleme yöntemleriyle elde edilebilecek bilgilerden daha az hassas olmasını sağlamaktır. | Topics API'nin mevcut teknolojilerden önemli ölçüde daha gizli olduğunu, kullanıcıların yeniden tanımlanmasını önemli ölçüde sınırladığını ve hassas konuları hariç tutacak şekilde tasarlandığını düşünüyoruz. Hassas kategoriler oluşturmak için konuların ilişkilendirilebileceğini veya birinci taraf verileriyle birleştirilebileceğini kabul ediyoruz. Bununla birlikte, Topics API'nin kullanıcı gizliliği konusunda atılmış bir adım olduğuna inanıyoruz ve API'yi iyileştirmeye devam etme konusunda kararlıyız. |
| Sınıflandırma Yapısı | Konular Sınıflandırmasına Kimlik, Sürüm Oluşturma ve diğer meta veri yapılarını ekleme | Şu anda API yanıtına sınıflandırma kimliğini dahil ediyoruz. Uzun vadeli yönetime doğru ilerlerken Topics nesnesini gözden geçirmek ve gerekirse sürüm oluşturma ile ilgili daha fazla meta veri eklemek mantıklı olacaktır. |
| Yayıncı kontrolü | Yayıncılar, sitelerinin hangi Konular olarak sınıflandırılacağı konusunda söz sahibi olmalıdır. | Sitelerin yanlış sınıflandırılması, Konular sinyalini genel bir sinyal olarak biraz daha az yararlı hale getirebilir, ancak yanlış sınıflandırılmış belirli siteler bu sinyalden diğer sitelerden daha fazla veya daha az zarar almaz. Bunun nedeni, yanlış sınıflandırma durumlarında bile doğru konuyla karşılaştırılabilir bilgiler sağlayabilecek olan açık artırmalarda sitenin bağlamsal bilgilerinin her zaman mevcut olmasıdır. Bu konuyla ilgili geri bildirimlerinizi buradan paylaşabilirsiniz. . . Yayıncıların sınıflandırmalarını kontrol etmesine izin vermenin riskleri vardır. Siteler, sitelerini bilinçli bir şekilde yanlış sınıflandırarak herkes için yararlılığı azaltabilir veya daha seyrek görülen konularda hassas anlamları kodlayarak kullanıcı gizliliğine zarar verebilir. |
| Chrome uzantıları | Chrome Uzantılarının, mevcut Çerez Yönetimi uzantılarına benzer şekilde Topics'i yönetmesine ve filtrelemesine izin ver | GitHub'da da konuştuğumuz gibi bu mümkün olsa da ekosistemden ek geri bildirimler almaktan memnuniyet duyarız. |
| Genel Kullanıma Geçiş | Kaynak Deneme'den Genel Kullanıma geçişin Topics API üzerinde bir etkisi olacak mı? | Kaynak Deneme'den Genel Kullanıma geçiş yapan kullanıcılar için veri kaybı yaşanmayacaktır. |
| Gizlilik | Ana makine adları, Topics API'nin ortaya çıkarabileceği gizli bilgiler içerebilir | Gizliliği sağlamak için burada açıklandığı gibi bir dizi çözümümüz vardır. |
| Sahtekarlık ve Kötüye Kullanım | Topics'in sahte ziyaretlerle değiştirilmesini önleme | Çözümler burada açıklanmaktadır. |
| Konu sınıflandırıcı | Web siteleri Topics sınıflandırmalarını değiştirmeyi talep edebilir mi? | Ekosistemin bu konuyla ilgili görüşlerini öğrenmek ve geri bildirimlerinizi buradan paylaşmak isteriz. |
| Konu sağlayıcı siteleri | Birçok Konu için içerik barındıran belirli web sitelerini "Özel Konu Sağlayıcı Siteleri" olarak belirtme ve sınıflandırıcıları, web sayfalarında sağlanan etiketlere göre eğitir. | Teklif hakkında buradan görüşebiliriz. Geri bildirimlerinizi öğrenmekten memnuniyet duyarız. |
Protected Audience API (eski adıyla FLEDGE)
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Trafik Şekillendirme | Saniye başına sorgu (QPS) yükünü optimize etmek için SSP'ye dayalı filtrelemenin performans üzerindeki etkisi | Trafik şekillendirme üzerine epey zaman harcadık. STP'lerin önbelleğe alma özelliğinden yararlanmasını öneriyoruz. |
| Test hacmi | STP'ler ve TTP'ler yüksek trafik hacimleri elde etmekte zorlandığından Protected Audience'ın test edilmesi zordur. | Korunan Kitleler'i kullanmaya başlamak ve bunları test etmek için STP ve TTP iş ortaklarıyla sürekli olarak etkileşim kuruyoruz. Genel kullanıma sunulmaya başladı. PA'nın etkinleştirildiği trafik yüzdesinin, iş ortaklarımızın test deneyimini daha cazip hale getireceğinden eminiz. |
| Karmaşıklık | Protected Audience çözümlerini uygulamak, yüksek çaba ve maliyet gerektirir. | Özel Korumalı Alan da dahil olmak üzere yeni teknolojilerin kullanımının zor olduğunun farkındayız. Özel Korumalı Alan ekibi, çalışmaları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 destekleyici olabilecek seçenekleri araştırıyoruz. Ancak şu anda, Özel Korumalı Alan için zaman alıcı bir değerlendirme gerektirecek şirket içi güvenlik sınırlamaları nedeniyle şirket içi TEE'leri desteklemek mümkün değildir. Özel Korumalı Alan güvenlik koşulları ve şirket içi dağıtımların sunduğu önemli zorluklar göz önünde bulundurulduğunda, bulut tabanlı dağıtımları genişletmeye ve iyileştirmeye devam etmenin (ör. AWS'nin yanı sıra GCP'yi de destekleme) ekosistem için en faydalı yöntem olduğuna inanıyoruz. Ancak, bu tür bir şartın neden gerekli olduğuyla ilgili ek geri bildirim almaktan memnuniyet duyarız. |
| Maliyet Yapısı | Teklif verme ve Açık Artırma Hizmetleri teklifi, istemci tarafı modellere kıyasla Reklam Teknolojilerinin maliyetini ve karmaşıklığını artıracaktır. | Şu anda Teklif Verme ve Açık Artırma'da teklifli sistem ve açık artırma iş akışlarını desteklemenin maliyetlerini tahmin etmek amacıyla Reklam teknolojisi kullanımıyla ilişkili açık artırma sunucusu ve tasarımlarımızın hedeflerinden birini yerine getirir. |
| K-Anon Zaman Çizelgeleri | Planlanan k-anonimlik kısıtlamaları "renderUrl"de ne zaman uygulanacak? | Yaptırım süreci hakkında yakında bir açıklama paylaşacağız. |
| runAdAuction kısıtlamaları | Chrome, runAdAuction sitesini yalnızca üst sayfadan çağrılabilecek şekilde kısıtlayabilir mi? |
Tasarımımız runAdAuction öğesinin üst sayfadan çağrılabilmesini tam olarak desteklese de, bu özelliğin yayıncılar açısından yalnızca üst alan adından çağrılabilir şekilde kısıtlanmasının daha zararlı olacağına inanıyoruz.. . Ekosistemden, Özel Korumalı Alan'ın yayıncıların ve reklamverenlerin üzerindeki yükü en aza indirmek için ihtiyaç duyduğunu özellikle duyduk. Bu geri bildirim, site sahiplerinin sitelerini çalıştırmak için üçüncü taraf araçları kullanabileceği şeklindeki web geliştirme genel ilkesiyle uyumludur. Özel Korumalı Alan hedefi, yayıncıların ve reklam teknolojilerinin nasıl çalıştığını açıklamaya gerek kalmadan sağlıklı bir ekosistemi teşvik etmektir. . . Yayıncının, sitesinde runAdAuction numaralı telefonu nasıl ve kim arayacağını seçmesine olanak tanıyarak yayıncılara, gereksinimlerine en uygun yolu bulma konusunda esneklik sunduğumuzu düşünüyoruz. |
| Uygulama desteği | Chrome, çok satıcılı bir açık artırmanın açık kaynak uygulamasını oluşturabilir veya buna katkıda bulunabilir mi? | Özel Korumalı Alan, üçüncü taraf çerezlerine veya diğer siteler arası tanımlayıcılara dayalı olmayan, gizliliği korumaya yönelik teknolojiler geliştirmeyi amaçlar. Reklam teknolojilerinin nasıl çalışmaları gerektiğini açıklamaya gerek kalmadan sağlıklı bir ekosistemi teşvik etmek istiyoruz. . . GitHub depomuzda API'lerin nasıl çalıştığı hakkında bir kılavuz yayınladık ve sektörle ilgili çözümler bulmaya hazırız. . . Temel görevimiz platform teknolojileri oluşturmak olduğundan, bu teknolojilerin kullanımına yönelik stratejiler belirlemek için özel bir uygulama geliştirmeyi 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 paylaşımı zorunlu kılar mı? nasıl elde edilir? | Protected Audience API, çok satıcılı açık artırmayı başlatan tarafların, bileşen açık artırmasına bilgi iletebilmesine imkan sunmak amacıyla tasarlanmıştır (not: yalnızca açık artırmayı başlatmadan önce). . . Bununla birlikte, tarayıcının bir bilgi parçasının bağlama dayalı daha iyi olup olmadığını ayırt etmesi için bir yol olmadığından, engellemeyi veya belirli bilgileri istemeyi zorunlu kılamazız. |
| İzin izleme için kullanıcı tercihi | Adtech, PA'ya kullanıcı izni izlemenin doğru şekilde nasıl uygulanacağını soruyor | Yanıtımız şu şekildedir: 1. çeyrekte şu söylediklerimiz: "Belirli reklamlarda, hangi reklam öğelerinin gösterileceği veya bunların nasıl seçileceği üzerinde kontrol sağlayabilecek en iyi konum, ilgili reklam teknolojisidir." . . Mayıs WICG Mayıs Korunan Kitle Toplantısı'nda bu sorunla ilgili çeşitli senaryoları ele aldık ve bu konuyla ilgili ek geri bildirimler ve tartışmalar almaktan memnuniyet duyarız. |
| Özel Kitleler | Özel Kitleler 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 Kitleler'e sahip olmasına ve bunları yönetmesine olanak tanır. Bir STP'nin PA API'si ile nasıl entegre olabileceği konusunda daha fazla rehberlik geliştirilmekte olup entegrasyon çalışmalarını desteklemek üzere STP'ler ile diğer reklam teknolojisi sağlayıcıların kullanımına sunulacaktır. |
| Formatlar | Video, Protected Audience API tarafından destekleniyor mu? | Video reklamlar, şu iki yöntemden biriyle yayınlanır: VAST XML veya HTML olarak (sonuçta video oynatıcıya da VAST XML yükleyebilecek bir yayın dışı reklam). Alıcılar, her iki biçimi de bir oluşturma URL'si aracılığıyla döndürebilir. VAST spesifikasyonu, Attribution Reporting API'yi destekleyecek şekilde yakın zamanda güncellenmiştir. Video reklam yayınlayan siteler, reklamların Protected Audience API üzerinden yayınlanma şekline hazırlanmalıdır. Bu, yerleşim etiketlerinin URL'yi Protected Audience iframe'inden video oynatıcıya iletebildiğinden emin olmak anlamına gelir. 2026'dan sonra Çitli Çerçeveler'i kullanma şartından önce video ihtiyaçlarını karşılamak için çalışmaya başlayacağız. |
| İlerleme hızı | İlerleme hızı kullanım alanı Protected Audience API ile nasıl çalışır? | Geri bildiriminiz için teşekkür ederiz. Söz konusu talebin daha fazla örneğini görmeyi ve daha fazla STP iş ortağından daha fazla ayrıntı almayı bekleriz. Çünkü bu konu bugüne kadar çoğunlukla bir TTP sorunu olmuştur. |
| Güncelleme sıklığı | dailyUpdate kaynağından gelen aramaların sıklığı (ilgi alanı grubu başına günde en fazla 1), ürün bilgilerinin güncellenmesi gibi belirli kullanım alanları için yeterli olmayabilir. |
Geri bildiriminiz için teşekkür ederiz. Reklam teknisyenlerinin K/V aramaları gibi farklı sıklıklarda yenilenen sinyalleri kullanmasına olanak tanıyan başka çözümler de vardır. |
| Reklam Kalitesi Kontrolü | Yayıncılar reklam kalitesi kontrolünü nasıl uygular? | Günümüzde Protected Audience API, yayıncıların teklif öncesi açık artırma yapılandırmasının bir parçası olarak belirleyebilecekleri belirli kontroller (ör. reklamlarla ilişkili etiketlere dayalı ret listeleri) hakkında STP'lerini bilgilendirmelerini sağlayan işlevler sunar. Ekosistemin ihtiyaç duyabileceği her türlü ek işlevle ilgili geri bildirimlerinizi almaktan memnuniyet duyarız. |
| Hata ayıklama | forDebuggingOnly işlevi ne zaman kaldırılacak? |
Üçüncü taraf çerezlerine verilen desteğin sonlandırılmasıyla, kayıp etkinlikleri için forDebuggingOnly ürününü kullanımdan kaldırmayı planlıyoruz. Kazanma etkinlikleri için forDebuggingOnly uygulamasını 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 teklifi | Bu teklifi değerlendiriyoruz, ancak bu GitHub Sorunu'nda da belirtildiği gibi, cihazlar arası hedeflemenin yüksek hassasiyeti gizlilikle ilgili önemli endişeler barındırmaktadır. |
| (1. çeyrekte de bildirilmiştir) Dinamik Yeniden Pazarlama | Dinamik yeniden pazarlama, üçüncü taraf çerezleri desteğinin sonlandırılmasının ardından Protected Audience API ile yine de kullanılabilecek mi? | Bu kullanım alanının, burada açıklandığı gibi Protected Audience kullanılarak mümkün olduğunu düşünüyoruz. |
| İlgili verileri tıklayın | browserSignals. kampanyasına tıklamayla ilgili verileri ekleyin |
Şu anda ön görüş vermek amacıyla tıklamanın ne zaman gerçekleştiğine dair açıklama talep ediyoruz. |
| (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, son kullanıcılar tarafından API'nin işlevlerini artıracak şekilde programlanabilen işlevlerdir. | Bu sorunu gündeme getiren reklam teknolojisi, UDF ile neler yapabileceklerini değerlendirmeye devam ettiğini belirtti. Bu nedenle de, en azından genel kullanıma sunulana kadar, şu an için harekete geçirici bir geri bildirim bulunmuyor. |
| Para Birimi | Para birimi tutarları, kayan noktalar kullanılarak temsil edilmemelidir. | Bu sorunu burada ayrıntılı olarak ele aldık. |
| TTP harici reklam seçimi özellikleri | Reklam sunucuları, Protect Audience API açık artırmalarında nasıl bir rol oynar? | Reklam sunucularının teklif sonrası reklam seçimi / dinamik reklam optimizasyon hizmetleri sunmaya devam etmesi için yapılan isteklerin 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 desteği teklifinin (generateBid reklam ilgi alanı grubu başına birden fazla aday reklam döndürmesini ve bu adayların "scoreAd") puanlanmasını sağlayın. |
Bu öğe şu anda değerlendiriliyor. Buradan daha fazla geri bildirimde bulunmaktan memnuniyet duyarız. |
| Açık Artırma Siparişi | Diğer tüm açık artırmaların sonucundan girdi alabilmesi için Protected Audience API Açık Artırmalarının en son çalıştırılması gerekir mi? | Protected Audience API'nin uzun süre çalışması için teknik bir gereklilik yoktur. |
| Kullanıcı tarafından başlatılmayan gezinme | Kullanıcı tarafından başlatılmayan gezinmeyi göster | Bu isteği inceleyip burada tartışıyoruz . Başka geri bildirimler almaktan da memnuniyet duyarız. |
| Önbelleğe alma | Kullanıcı durumu değişirse SSP, belirli bir TTP'nin perBuyerSignals öğesini önbellekten oluşturmamalıdır. | Önbelleğe almanın perBuyer sinyallerinin her kullanım alanı için çalışmadığını biliyor ve diğer seçenekleri değerlendiriyoruz. Ekosistemden önbelleğe almanın kendi kullanım alanları için uygun olup olmadığına dair 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 Protected Audience API'de her iki Attribution Reporting API modunda (etkinlik düzeyinde ve özet raporlar) kullanılabilir. 1 Haziran'da, iyileştirilmiş Protected Audience API ve Attribution Reporting entegrasyonu hakkında daha fazla bilgi paylaştık. Bunlarla ilgili bilgileri 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, reklam teknolojisi tarafından yönetilen bir uç noktadır. Şu anda raporlama uç noktası için planlanmış bir değişikliğimiz yok. Mevcut tasarım, toplanabilir raporların kendilerinin (şifrelenmiş yüklerle) siteler arası verileri sızdırmamasını sağlamayı amaçlamaktadır. Bu nedenle, güvenilir bir uç nokta gerekli değildir. Diğer bir sorun da farklı reklam teknolojilerinin, istenen farklı toplu işleme stratejilerine sahip olabilmesidir. Buradan daha fazla geri bildirimde bulunmaktan memnuniyet duyarız. |
| WebIDL | Mevcut Protected Audience API spesifikasyonu, WebIDL spesifikasyonuyla uyumlu değil. | Bu geri bildirimi değerlendiriyoruz ve sorunu burada tartışıyoruz. |
| İzin Yönetimi | Protected Audience API'de izin sinyali iletimi nasıl işlenecek? | Bağlamsal bilgiler, Protected Audience API'nin kapsamında değildir. Bu sorunu inceliyoruz. Yeni geri bildirimler almaktan memnuniyet duyarız. |
| Hesaba Dayalı Pazarlama | Hesap tabanlı pazarlama kullanım alanları mümkün mü? | Protected Audience API, kitleye dayalı çeşitli pazarlama kullanım alanlarını destekler. Protected Audience API'nin bu özel kullanım alanını en iyi şekilde nasıl destekleyebileceğini anlamaya devam ediyoruz ve bu konuyla ilgili olarak ekosistemden ek geri bildirimler bekliyoruz. |
| Bileşen açık artırması | Bileşen açık artırma katılımcıları ne puan verir? | Bileşen açık artırmaları, İlgi Alanı Gruplarını doğrudan puanlamaz. Bunun yerine, bir TTP'nin generateBid işlevinden gönderdiği reklamlar ve teklifler puanlanır. generateBid() işlevi, ilgi alanı grubu başına çalışır ve TTP, generateBid çalıştırılırken şunu döndürür:
return {
'ad': adObject,
'adCost': optionalAdCost,
'bid': bidValue,
'render': renderUrl,
'adComponents':
[adComponent1, adComponent2, ...],
'allowComponentAuction': false,
'modelingSignals': 123};
}
|
| Harici Katkılar | Key/Value Server GitHub kod tabanında harici katkıları destekleme isteği. | GitHub koduna dışarıdan yapılan katkıları desteklemek için ilgili süreçlerimizi güncellemeye çalışıyoruz. |
| İlgi Alanı Grubu Boyutu | IG'nin destekleyebileceği desteklenen maksimum anahtar sayısı nedir? | Geçerli sınır, bir IG'nin boyutu için 50 KB'tır ve anahtarlar bu kapsamda sayılır. Boyut sınırıyla ilgili daha ayrıntılı tartışmaları memnuniyetle karşılarız. |
| Toplu işleme | K/V sunucu ç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ü Başlıkları'nı kullanabilirsiniz. Örneğin, bileşen açık artırmalarında ve ayrıca tek bir sayfadaki reklam alanlarında önbelleğe alınabilir. |
| Sürüm denetimi | Reklam teknolojisi kodunun birden fazla sürümü için destek | Teklifli sistem ve açık artırma hizmetleri, reklam teknolojisi kodunun birden fazla sürümünü destekleyecek. Teklif Verme ve Açık Artırma API'sinde SelectAd isteği, açık artırma isteği (ör. teklif verme / açık artırma ve aynı zamanda raporlama için) için kullanılan kodun sürümünü belirtebilir. |
| Ortak Depolama | Teklif Verme ve Açık Artırma Hizmeti'nde, paylaşılan depolama alanına yazma desteği. | Teklifli Sistem ve Açık Artırma Hizmetleri şu anda paylaşılan depolama alanını desteklememektedir. Ancak bu tür kullanım alanlarının ekosistem için neden önemli olduğuyla ilgili ek geri bildirimler almaktan memnuniyet duyarız. |
| Web'den uygulamaya geçiş | İlgi alanı gruplarının web'den uygulamaya paylaşımını destekleme. | Web-to-app özelliği şu anda Chrome ve Android'deki Protected Audience API dağıtımının kapsamında değildir. Ancak bu kullanım alanının önemi konusunda ekosistemden fikir alışverişinde bulunmak istiyoruz. |
| K-Anonimliği | K-Anonimlik yedeklerinin işlenmesi | Bu sorunu inceliyoruz ve ek geri bildirimler almaktan memnuniyet duyarız. |
Dijital Reklamları Ölçme
Attribution Reporting (ve diğer API'ler)
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Alternatif GD Etkinlik Düzeyi Rapor Yapılandırmaları | Alternatif GD etkinlik düzeyindeki rapor yapılandırmalarıyla ilgili geri bildirim | Etkinlik düzeyindeki mevcut yapılandırmaların optimum durumda olmadığına dair bazı geri bildirimler aldık ve optimum genel yapılandırmalar hakkında geri bildirimde bulunmanızı istiyoruz. Bu konuyla ilgili ek geri bildirimlere açığız. Etkinlik düzeyinde esnek açıklayıcı açıklamamızın bu sorunu da çözmeye yardımcı olacağını düşünüyoruz. |
| Etkinlik düzeyinde esnek yapılandırmalar | Etkinlik düzeyinde esnek yapılandırmalar özelliğinin durumu nedir? | Etkinlik düzeyinde esnek yapılandırma ile ilgili ortak dokümanlar paylaştık. Bu özellik hâlâ teklif aşamasında ve özelliğin ekosistem açısından değerli olup olmayacağıyla ilgili daha fazla geri bildirim bekliyoruz. |
| Etkinlik düzeyinde esnek yapılandırmalar | Farklı taraflardan gelen çakışan raporlar nasıl uzlaştırılabilir? | Çoğu raporlama senaryosu toplu raporlar kullanılarak ele alınır. Öte yandan, etkinlik düzeyinde esnek yapılandırma teklifi, özellikle optimizasyon kullanım alanları için en sık kullanılan etkinlik düzeyindeki raporlara daha fazla esneklik kazandırmak amacıyla tasarlanmıştır. Bu senaryoyla ilgili ek ekosistem yorumlarını/geri bildirimlerini almaktan memnuniyet duyarız. |
| Kaynak kaydı | Kaynak kaydı, tetikleyici kaydından sonra gerçekleşirse ne olur? | Şu anda, bir kaynak kaydı tetikleyici kaydından sonra gerçekleşirse kaynak ve tetikleyici birbiriyle ilişkilendirilemez. Bu, uç bir senaryo gibi görünüyor. Bu sorunla ilgili yeni geri bildirimler almaktan memnuniyet duyarız. Birçok reklam teknisyeninin karşılaştığı bir senaryo olduğu düşünüldüğünde bu sorunu gidermeye çalışacağız. |
| Birden çok Reklam Ajansıyla çalışma | Bir reklamveren birden fazla reklam ajansıyla çalışırken TTP'ler Attribution Reporting API'yi nasıl kullanabilir? | API, yönlendirmeleri desteklediğinden bir reklamveren birden çok reklam ajansıyla çalışırken bile kullanılabilir. Ayrıca, API'nin gizliliği artırdığından emin olmak için yönlendirmelerle ilgili bazı sınırlamalar uygulanır. Ayrıca, reklam teknolojisinin ortaya koyduğu belirli senaryo için Shared Storage API'yi kullanan olası bir geçici çözüm de belirledik. Bu senaryoyla ilgili yeni geri bildirimler almaktan memnuniyet duyarız. Aldığımız geri bildirimler doğrultusunda çalışmalarımızı sürdüreceğiz. |
| Hedef Sınırları | Otomatik yenilenen reklamların kullanım alanı, hedef sınırlarından etkilenebilir. | Bu sorunu 1 Mayıs WICG toplantısında tartıştık ve makul bir sınırın ne olabileceği hakkında geri bildirim bekliyoruz. Etkinlik düzeyindeki raporlar içeren İlişkilendirme Raporları açıklayıcısı bölümüne, tarayıcının kaynak sitelerin temsil ettiği "hedef" eTLD+1'lerin sayısını sınırlandırabileceğini belirten bir bölümü ekledik. (Çekme isteği bölümüne bakın). |
| İlişkilendirme Raporları ve Korunan Kitle | Attribution Reporting API ve Protected Audience API birlikte nasıl çalışabilir? | Entegrasyonlar, şu anda Protected Audience API'de her iki Attribution Reporting API modunda (etkinlik düzeyinde ve özet raporlar) kullanılabilir. 1 Haziran'da, iyileştirilmiş Protected Audience API ve Attribution Reporting entegrasyonu hakkında daha fazla bilgi paylaştık. Bunlarla ilgili bilgileri buradan edinebilirsiniz. |
| Etkinlik düzeyinde esnek yapılandırmalar | Parametreler yapılandırılabilir olduğundan gürültü simülasyonuyla ilgili en iyi uygulamaları paylaşın. | GitHub'da paylaştığımız bir kod, herkesin test etmek istediği etkinlik düzeyindeki esnek yapılandırmalar için bilgi kazancını ve gürültü etkisini değerlendirmek amacıyla kullanabileceği bir koddur. Kodu kullanarak test yapmayı seçen ve görüşlerini paylaşmak isteyen herkesin görüşlerini öğrenmek isteriz. |
| Uygulamalar ve Web Siteleri Arası İliş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 Arası ve Web İlişkilendirme Ölçümü için bir deneme yaptığımızı duyurmuştuk. Chrome 115'te alaka düzeyi ve ölçüm API'leri için genel kullanıma sunulması planlanıyor olsa da, Uygulamalar Arası ve Web İlişkilendirmesi Ölçümü şu anda Chrome 115 ile genel kullanıma sunulması planlanmamaktadır. |
| Dönüşümleri tekilleştirin | Bağımsız ölçüm çözümleri ARA ile nasıl mutabık kılınabilir? | Mevcut standart uygulamada olduğu gibi, reklamverenler dönüşüm raporlamasının tekilleştirilmesi için üçüncü taraf bir bağımsız ölçüm sağlayıcısıyla birlikte çalışacaktır. Etkinlik düzeyinde raporlama için dönüşümlerin tekilleştirilmesiyle ilgili kaynaklar sunduk. |
| İlişkilendirme Raporu veritabanı güncellemeleri sırasındaki veri kaybı | Chrome, duyurulduğu gibi İlişkilendirme Raporlama Veritabanı'nı güncellediğinde veri kaybı yaşar mıyım? | Chrome Mevcut Ürün sürümü 115'ten itibaren, Chrome kullanıcılarının bir kısmı için Alaka Düzeyi ve Ölçüm API'lerini varsayılan olarak etkinleştirmeye başlayacağız. Olası sorunları izlediğimiz süre boyunca bu özelliğin genel kullanıma sunulma durumu artacaktır. Hedef, 2023'ün 3. çeyreğine kadar haftalar boyunca% 100 kullanılabilirliğe ulaşmak olacak. Bu süreç, Alaka Düzeyi ve Ölçüm kaynak denemesinin sonuna denk gelecektir. Temmuz ayından itibaren, test kullanıcıları bu API'lere genel kullanıma sunulmak üzere kaydolabilecek. Bu durumda kaynak deneme sürümü kullanılabilirliği ile kayıt boyunca genel kullanılabilirlik çakışır. Kaynak deneme jetonunuz 19 Eylül'e kadar geçerli olacaktır. Ancak devam eden testleri kesintiye uğratmadan kaynak denemesinden sorunsuz bir şekilde geçiş yapmak için API'lere son tarihten önce kaydolmanızı öneririz. . . Bu duyuruda belirtildiği gibi, eski sürümlerden (M113 ve önceki sürümler) kaydedilen veriler güncellemeden sonra taşınmayacağı için veri kaybı yaşanabilir. Bu veri kaybı, hata ayıklama raporlarında görünmez. 114 ile 115 arasındaki veri kaybından kaçınmaya çalışırız. |
| Faturalandırma | Dönüşüm başına maliyet faturalandırması için İlişkilendirme Raporları'nı kullanma | Bu makalede belirtildiği gibi, etkinlik düzeyindeki ve özet raporlara eklenen gürültü nedeniyle Attribution Reporting API, dönüşüm başına maliyet faturalandırma ihtiyaçları için uygun olmayabilir. Ekosistem oyuncularının, GitHub'da Attribution Reporting API'nin çeşitli faturalandırma modelleri üzerindeki etkisi hakkında geri bildirim paylaşmalarını öneriyoruz. |
Aggregation Service
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Toplanabilir raporlarda gecikme değişikliği | Ekosistemden gelen geri bildirim doğrultusunda, Toplanabilir rapor gecikmesinin [10-60 dakika] yerine [0-10 dakika] olarak değiştirilmesi teklifine verilen olumlu tepkiler | Teklif edilen değişikliğe olumlu tepkiler görmekten mutluluk duyuyoruz ve ekosistemi tekliflerimizle 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 destekleyici olabilecek seçenekleri araştırıyoruz. Ancak şu anda Özel Korumalı Alan için zaman alıcı bir değerlendirme gerektirecek şirket içi güvenlik sınırlamaları nedeniyle şirket içi TEE'leri desteklemek mümkün değildir. Özel Korumalı Alan güvenlik koşulları ve şirket içi dağıtımların sunduğu önemli zorluklar göz önünde bulundurulduğunda, bulut tabanlı dağıtımları genişletmeye ve iyileştirmeye devam etmenin (ör. AWS'nin yanı sıra GCP'yi de destekleme) ekosistem için en faydalı yöntem olduğuna inanıyoruz. Ancak, bu tür bir şartın neden gerekli olduğuyla ilgili ek geri bildirim almaktan memnuniyet duyarız. |
| Raporları farklı dönemler için yeniden işleme | Farklı zaman aralıklarına ait raporları yeniden işleyebilme | Grupları farklı tarih aralıklarına bölebilmek için benzer talepler aldık. Tekliflerden biri, raporların farklı gruplara bölünebilmesi için, paylaşılan kimliğin reklam teknolojisi tanımlı bir etiketle genişletilmesine olanak tanımaktır. Bu süreci henüz değerlendirme aşamasındayız ve teklif geliştikçe ekosistemi güncel tutacağız. |
| Güvenilir Yürütme Ortamının Gizlilikle İlgili Etkileri | Güvenilir yürütme ortamlarının gizlilik üzerindeki etkileri konusunda olumlu düşünce | Ekosistemin tekliflerimizle ilgili olumlu tepkilerini öğrenmekten mutluluk duyuyoruz. İlerledikçe ve geliştirmeye devam ederken ek geri bildirimler almaktan memnuniyet duyarız. |
| Hizmet Şartları | Toplama Hizmeti Hizmet Şartları'nı kabul etmek için son tarih nedir? | Hükümler ve koşulları kabul etmek için henüz bir son tarih belirlememiş olsak da ekosistem şirketlerinin, kayıtta gecikmeleri önlemek için şartlar ve koşulları en kısa sürede kabul etmelerini öneririz. Şirketlerin herhangi bir sorusu olması durumunda iletişime geçmelerini öneririz. |
| Anahtar Bulma | Temel keşif özelliği, test kullanıcılarının daha iyi performans ve doğruluk için ağlar arası ilişkilendirmeye yönelik ö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 çözümleri araştırıyoruz ve ekosistemden ek geri bildirimler almaya çalışıyoruz. |
Private Aggregation API
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Raporlama Kaynağı | Raporlama kaynağı nasıl tanımlanır? | Raporlama kaynağı her zaman Özel Toplama çağrısının komut dosyası kaynağıdır. |
| 128 bit anahtar alanı | 128 bit anahtar alanı sınırlamasıyla ilgili netlik | Bu anahtar alanı sınırlamasını daha açık 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 şu an için 20 katkı yapma sınırı çok düşük. | Maksimum katkı sayısını artırmak yerine, sınırlı sayıda raporu kısaltmak yerine raporları bölmeyi tercih ediyoruz. Teklif gelişmeye devam ettikçe ekosistemden de yararlanacağız. |
| Erişim raporlama | Platformlar ve cihazlar arası raporlama için erişim isteği. Erişim, marka reklamcılığının temel metriğidir. Reklamverenler, kampanyalarını analiz etmek ve harcamaları paylaştırmak amacıyla Erişim ve Sıklık raporlarında platformlar arası/cihazlar arası yaklaşımlardan yararlanır. Erişim modelleri, üçüncü taraf ortamlarda gösterilen reklamları ölçmek için üçüncü taraf çerezlerini kullanır. Bu nedenle, üçüncü taraf çerezleri kullanımdan kaldırıldıktan sonra reklam teknolojileri alternatif bir çözüm talep ederler. |
Özel Korumalı Alan Ekibi, üçüncü taraf çerezleri için desteğin sonlandırılmasının ardından web alanları arası erişim yöntemlerini destekleyecek özellikleri araştırıyor. . Ekosistemden gelen ek geri bildirimlerden de memnuniyet duyarız. |
Gizli Takibi Sınırla
Kullanıcı Aracısı Kısaltma/Kullanıcı Aracısı İstemci İpuçları
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| (2023'ün 1. çeyreğinde de bildirilmiştir) Ek form faktörleri hakkında ipuçları | TV ve sanal gerçeklik gibi ek form faktörleri sağlamaları için kullanıcı aracısı istemci ipuçları (UA-CH) isteği | Bazı temel tasarım kararları ("TV" gibi tek bir değer veya form faktörü özellikleri listesi sağlama) üzerinde çalışmaya devam ediyoruz. Ancak bu fikrin prototipini oluşturma konusunda ilgimizi sürdürüyoruz. |
| Gizli Erişim Bütçesi | Gizlilik Bütçesi kısıtlamaları, çok fazla istek gönderildiğinde UA-CH isteklerinin belirsiz hale gelmesine neden olabilir. | Şu anda Gizlilik Bütçesi teklifiyle ilgili yeni bir güncellememiz yok. Ancak üçüncü taraf çerezleri için destek sonlandırılmadan önce UA istemci ipucu isteklerini kısıtlamamaya karar verdik. |
| Site Uyumluluğu | Web siteleri, belirli tarayıcıların sitelere erişimini kısıtlamak için UA-CH markasını kullanıyor. | Marka listesine sahip olmak için geçerli kullanım alanları vardır ve bu örneklerden biri tam olarak uyumluluktır. UA'da bu sorunlarla ilgilenen birden fazla marka bulunabilir. |
IP Koruması (eski adıyla Gnatcatcher)
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Sahtekarlık ve Kötüye kullanım | Şirketler, IP korumasıyla sahtekarlıkla mücadele önlemlerini nasıl oluşturabilir? | Sahtekarlıkla mücadele kullanım alanlarının önemini ve bu kullanım alanları üzerindeki olası etkilerinin farkındayız. Sahtekarlıkla mücadeleyi desteklemekle ilgili daha fazla bilgiyi bu yazın ilerleyen günlerinde yayınlamayı planlıyoruz. Sahtekarlıkla mücadele kullanım alanlarını nasıl daha iyi destekleyebileceğimiz konusunda ekosistemden geri bildirim istiyoruz. |
| GeoIP | GeoIP için test ve dağıtım zaman çizelgesi hakkında daha fazla bilgi | Chrome kısa süre önce GeoIP planlarımızı ayrıntılı şekilde açıklayan yeni bilgiler yayınladı. Dağıtım zaman çizelgeleri hakkında daha fazla bilgiyi 3. çeyrekte yayınlamayı planlıyoruz. IP Koruması'nı, başlangıçta trafiğin küçük bir yüzdesinde kullanıcılar için isteğe bağlı bir özellik olarak kullanıma sunmayı planlıyoruz. Bunun nedeni, bu teklifin şirketler açısından bazı önemli değişiklikler içerebileceğinin farkındayız ve özellik daha geniş bir kitlenin kullanımına sunulmadan önce gerekli düzenlemeleri yapması ve geri bildirimde bulunması için ekosisteme zaman vermek istiyoruz. |
| Hesap kimlik doğrulaması | Proxy sunucuyla hesap kimlik doğrulaması tam olarak nasıl çalışır? | Hesap kimlik doğrulaması hakkında daha fazla bilgiyi bu yazın ilerleyen günlerinde yayınlamayı planlıyoruz. Bununla birlikte, ilk olarak göz önünde bulundurduğumuz bazı noktaları daha önce paylaşmış bulunuyoruz. |
Hemen Çıkma Durumunu İzleme Çözümleri
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Test Kılavuzu | Hemen Çıkma Durumunu İzleme çözümünün nasıl test edileceğiyle ilgili bilgiler | Mayıs ayında, Hemen Çıkma Durumunu İzleme Çözümlerinin nasıl test edileceğiyle ilgili daha fazla bilgi içeren bir blog yayını yayınladık. |
| Belgeler | Hemen Çıkma Durumunu İzleme Teklifinde Anlaşılırlık | Mevcut teklif büyük ölçüde devam eden bir çalışmadır ve Chrome, ekosisteme netlik ve bilgi sağlamak amacıyla teklifi güncellemeye devam etmektedir. Daha ayrıntılı bilgi vermek üzere çalışmalarımızı sürdürüyoruz. Yeni geri bildirimlerinizi bekliyoruz. |
| Çerez silme | Hemen Çıkma Durumunu İzleme Çözümü, bir alandaki tüm çerezleri siler mi? | Hemen çıkma durumunu izleme çözümü (BTM), burada açıklandığı gibi tüm depolama alanını ve önbelleğin tamamını temizler. |
| Hemen Çıkma Durumunu İzleme Çözümlerini Atlatma | Hemen çıkma izleyici sınıflandırması, pop-up'lar veya yeni sekmelerle yönlendirmeler uygulanarak atlanabilir. | Hemen Çıkma Durumunu İzleme Çözümleri spesifikasyonuyla ilgili çalışmalar devam etmektedir. Şu ana kadar çoğunlukla aynı sekmedeki yönlendirmelere odaklandık ancak gelecekte pop-up akışları üzerinde çalışmayı planlıyoruz. Buradan daha fazla geri bildirimde bulunmaktan memnuniyet duyarız. |
Gizli Erişim Bütçesi
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Yakınlık Hedefleme | Gizlilik Bütçesi, yakın çevreyi hedefleme kullanım alanlarını etkileyebilir. | Bu konuyla ilgili geri bildirim aldık. Ekosistemin olası etkileri konusunda daha fazla bilgi edinmek isteriz. |
Siteler arası gizlilik sınırlarını güçlendirin
Birinci Taraf Gruplar
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| (Önceki çeyreklerde de bildirildi) Alan Adı Sınırı | İlişkilendirilmiş alan sayısını artırma isteği | Chrome, ilişkili alt küme için uygun sayısal sınırı değerlendiriyor. Bu sınır, tanımlanan kullanım alanları için gizlilik ve fayda arasında denge kuracak. Chrome, en başından itibaren, İlişkili alt grubun tam sayısının henüz kesinleşmediğini paylaştı. |
| Yerleştirilmiş Kullanım Alanı | Birinci taraf gruplar, CHIP'ler ve paylaşılan depolama alanı gerektiren yerleştirilmiş kullanım alanları için destek | Chrome bu kullanım alanıyla ilgili geri bildirim aldı ve ekip konuyu araştırıyor ve ek geri bildirimden memnuniyet duyacaktır. |
| Depo Yönetimi | Tutarsızlıklar veya ihmaller olması durumunda Birinci Taraf Gruplar'ın GitHub deposundan kaldırılmasıyla ilgili politikalar hakkında bilgiler | Chrome, bu kullanım alanıyla ilgili geri bildirim aldı. Ekibimiz konuyu araştırıyor ve ek geri bildirimlerden memnuniyet duyacaktır. |
| Kullanıcı Eğitimi | Chrome'un benimsenmesini artırmak için kullanıcı farkındalığını ve Birinci Taraf Gruplar'ı anlamasını sağlamalısınız. | Chrome, kullanıcıları Birinci Taraf Gruplar hakkında eğitmeyi ilke edinmiş ve bu konuda bir Yardım Merkezi makalesi (Chrome kullanıcı arayüzünden bağlantı) yayınlamıştır. Chrome, kullanıcıları uygun bağlamlarda en iyi şekilde nasıl eğiteceğini öğrenmeye de devam etmek için çalışmaktadır. |
| 3. PCD'den sonra | Üçüncü taraf çerezleri, üçüncü taraf çerezlerine yönelik destek sonlandırıldıktan sonra Birinci Taraf Grup'ta var olmaya devam edecek. | requestStorageAccess ve requestStorageAccessFor üçüncü taraf çerezlerini belirli, açıkça tanımlanmış kullanım alanları için tekrar kullanılabilir hale getiriyor olsa da, artık üçüncü taraf çerezlerinin mevcut durumunda (Chrome'da) olduğu gibi varsayılan olarak kullanılabilir değil, site tarafından aktif çağrılmaları gerekiyor.. . Tek bir gruptaki bu çağrı için kullanıcının onayı gerekmese de kullanıcılar, Ayarlar'da bu davranışı devre dışı bırakarak bunu engelleyebilir. . . Kullanıcılar için daha fazla bilgi edinmek üzere Chrome kullanıcı arayüzünden bağlantı verilen Yardım Merkezi makalesini inceleyebilirsiniz. FPS oranı %100'e ulaştığında mevcut geliştirici kılavuzunu daha ayrıntılı olarak kullanıma sunmayı 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. Buradan daha fazla geri bildirim alabilirsiniz. |
Çitli Çerçeveler API'sı
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Reklam Engelleme | Çitli Çerçeveler, reklam engelleyicilerin reklamları engellemesini kolaylaştırabilir. | Uzantılar, iframe'lerle etkileşimde bulundukları gibi, sınırlanmış çerçevelerle etkileşimde bulunabilir. Sınırla çevrili çerçevenin gidileceği gerçek URL de uzantılar tarafından görülebilir. Bu nedenle, uzantılar engelleme için tüm URL eşleştirme kurallarını iframe'lerde olduğu gibi uygulayabilirler. Çitli tüm çerçevelerin koşulsuz olarak engellenmesi, çitli çerçevelerin reklam harici kullanım alanlarını bozabilir. |
Shared Storage API
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Daha geniş kullanım | Paylaşılan Depolama Alanı, tüm tarayıcılarda kullanılabilen, sektör genelinde geçerli bir standart olmalıdır. | Bu geri bildirimi almaktan memnuniyet duyuyor ve kabul ediyoruz. Chrome, teklifin savunulması, geri bildirim alınması ve benimsenmesinin sağlanması amacıyla W3C fora'ya aktif bir şekilde katılmaya devam etmektedir. |
| Çıkış Kapıları | Ortak Depolama çıkış kapıları çok sınırlı. | Bu geri bildirimi değerlendiriyor ve çıkış kapılarının neden çok sınırlı olduğuna dair ek ekosistem geri bildirimlerini bekliyoruz. |
| Yasal Düzenlemelere Uygunluk | Paylaşılan depolama alanı, veri saklama politikaları gibi düzenlemelere uygunluğu nasıl ele alacak? | Paylaşılan depolama, depolanan verilerin kullanım ömrünü ve geçerlilik süresini kontrol etmek için mantığı uygulama ve özelleştirme esnekliği sunar. Reklam teknolojileri, paylaşılan depolama alanı verilerini yazma zaman damgalarına göre güncelleyebilir veya temizleyebilir. |
| A/B Testi | Paylaşılan Depolama Alanı ve Protected Audience API için A/B testi nasıl yürütülebilir? | Bu konuda daha fazla rehberlik yayınlamaya çalışıyoruz ve gelecekte daha ayrıntılı bilgi paylaşmayı umuyoruz. |
| Ortak Depolama Alanı Sınırı | Paylaşılan depolama alanı sınırına ulaşıldığında ne olur? | Bu sınıra ulaşılırsa başka giriş saklanmaz. |
| Aynı sayfa yüklemede birden fazla erişim | Paylaşılan depolama alanına aynı sayfa yüklemesinde birden çok kez erişildiğinde ne olur? | Bunu yapmanın en iyi yolu window.sharedStorage.append(key, value) işlevini kullanmaktır. Bunun yerine, her bir reklamın değerini güncellemek yerine, birden fazla reklam varsa çakışmalara neden olabilir. Ekleme işlevi, yeni değeri mevcut değerin sonuna ekler. |
| iframe İşlevselliği | Paylaşılan Depolama Alanı, üçüncü taraf çerezlerine verilen desteğin sonlandırılmasından sonra artık çalışmayacak olan belirli iframe işlevlerini destekleyecek mi? | Üçüncü taraf çerezleri için desteğin sonlandırılmasının ardından, iframe'lerdeki yerel depolama alanı üst düzey site tarafından bölümlendirilecek ancak iframe'ler engellenmeyecektir. Bir iframe'in yerel depolama alanındaki veriler birden fazla üst düzey sitede çoğaltılamaz, ancak yerel depolama yine iframe içinde kullanılabilir. |
ÇIP'ler
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Bölüm sınırı | Bölümlendirilmiş site başına 10 KiB hâlâ önemli bir sınır ve bunun düşürülmesini istiyor. | Firefox zaten CHIPS konusunda olumlu bir konumda bulundu. Webkit desteği için geliştiricilerin, bölümlendirilmiş depolama alanı yerine bölümlendirilmiş çerezlerin tercih edildiği kullanım alanlarıyla ilgili olarak bu GitHub sorunu hakkında doğrudan Apple'a geri bildirim sağlamalarını öneririz. |
| Kimliği doğrulanmış yerleştirilmiş yerleştirilmiş öğeler | CHIP'ler, kimliği doğrulanmış yerleştirmeleri etkileyen farklı bölümlendirmeler nedeniyle mevcut TOA oturum açma akışını etkileyebilir. | Kimliği doğrulanmış yerleşik yerleştirmelerin kullanım alanını desteklemek için Storage Access API'den (kullanıcı istemleriyle) yararlanmayı amaçlıyoruz. Kısa süre önce bir intent prototipi gönderdik. |
| Ömür Boyu Politikalar | Olası kullanım ömrü politikaları birinci taraf çerezleri için geçerli midir? | Şu anda birinci taraf çerezlerine ömür boyu sınır koyma gibi bir planımız bulunmuyor. |
FedCM
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| OAuth Yetkilendirme Desteği | Profil dışı Oauth kapsamlarının yetkilendirilmesinde uzlaşma | Üçü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ı için Web Identity topluluğundan W3C FedID CG aracılığıyla aktif geri bildirim almaya çalışıyoruz. |
| SAML desteği | SAML desteği için gereksinimleri uyumlu hale getirme | Ekip, üçüncü taraf çerezlerine verilen desteğin sonlandırılmasının ardından, SAML desteği ihtiyaçları konusunda araştırma ve eğitim topluluklarından (auth-connect desteğinin yanı sıra) aktif bir şekilde görüş almak ister. |
Spam ve sahtekarlıkla mücadele
Private State Token API (ve diğer API'ler)
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Yeni sinyalleri keşfetme | Bazı iş ortakları, cihaz bütünlüğüne veya kullanıcı güvenine dair tarayıcı tarafından sağlanan sinyalleri keşfetme konusunda olumlu düşünceleri olduğunu ifade etti. Genel olarak, sahtekarlık tespitinin mevcut düzeylerini korumak için yeterli olan, amaca yönelik yeni sinyaller konusunda da temkinliler. | Sahtekarlıkla mücadele ve web güvenliği topluluğunda yeni teklifleri birlikte keşfetmekten ve ayrıca endişelerini kabul edip paylaşmaktan heyecan duyuyoruz. "Spam ve sahtekarlıkla mücadele" tam da bu yüzden , Özel Korumalı Alan'ın temel iş akışlarından biri oldu. Kullanıcı gizliliğini geliştirirken web güvenliğini korumaya yönelik yatırımlara neden devam ediyoruz? |
| PST ile ilgili olumlu geri bildirim | Birçok iş ortağı, sahtekarlıkla mücadele veya web güvenliği ile ilgili çeşitli kullanım alanlarında PST'leri test etmek veya kullanmakla ilgilendiğini ifade etmiştir. | PST'lerin kullanıldığı yeni çözümleri keşfetmek için aldığımız destek ve ilgi bizi heyecanlandırıyor. Chrome geliştirici sitesinde kaynaklarımız ve örnek kod mevcuttur. Geri bildirimlerinizi bekliyoruz. |
| Sahtekarlık ve Kötüye Kullanım | Üçüncü taraf çerezleri için desteğin sonlandırılmasının ardından tanımlayıcılar artık kullanılamadığında ölçümde reklam sahtekarlığını önleme ve ölçümlerde tespit etme rehberi | Sahtekarlığı önleme amacıyla üçüncü taraf çerezleri tarafından kaybedilen sinyallerin bir kısmını kurtarmaya yardımcı olan gizlilik jetonları gibi araçlar kullanıma sunduk ancak yeni gizlilik denetimleri ekledik. Diğer Özel Korumalı Alan değişiklikleriyle özellikleri korumak amacıyla, sahtekarlıkla ve kötüye kullanımla mücadele ile ilgili yeni tekliflere etkin bir şekilde yatırım yapıyoruz. |
| Sertifikayı veren kuruluşun kaynak bilgisine oranı | Sertifikayı veren kuruluş-kaynak arası bilgi oranı, tekil kullanıcıların belirlenmesine yetecek kadar yüksek. | Spesifikasyonları, Gizlilik Jetonları kullanılarak hangi kullanıcı verilerinin aktarılabileceği konusunda daha net olacak şekilde güncelledik. Tasarım gereği, aynı anda en fazla altı ortak anahtar kullanılabilir ve bu anahtarlar bir "eyaleti" temsil edebilir. düzenlemenizi sağlar. Bu anahtar grupları yalnızca 60 günde bir güncellenebilir (acil durum anahtarı rotasyonunun gerekli olduğu nadir durumlar hariç). Bu durum, zaman içinde ek kullanıcı verilerinin birleşme olasılığını azaltır. Her yeni web API'de bir fayda dengesi vardır. Ayrıca, sağlanan net yeni kullanıcı bilgileri dengelenir. PST'lerin, bir yandan üçüncü taraf çerezlerine verilen desteğin sonlandırılmasından etkilenen önemli sahtekarlıkla mücadele kullanım alanlarını mümkün kılarken diğer yandan kullanıcı gizliliğini koruma konusunda uygun dengeyi sağladığını tahmin ediyoruz. |
| Getirme Entegrasyonu | fetch entegrasyonu karmaşık ve gereksizdir. |
fetch kullanmanın avantajları ve dezavantajları vardır. Web ekosisteminde daha fazla standartlaştırma çalışması yapmak isteriz. Ancak, standardın nasıl olacağına dair daha net bir fikir edinene kadar bu değişikliği yapmak için çok erken olacağını düşünüyoruz. Yeni bir standart ortaya çıktığında da web geliştiricilerini bu standarda sorumluluk bilinciyle geçirmeyi taahhüt ediyoruz. |
| Depolama Konumu | Gizlilik Jetonları anahtar yapılandırmaları, PrivacyPass Protocol ile aynı konumda depolanmalıdır. | Kaynak Denemesi sırasında test yaparken geliştiriciler, anahtarlarını .well-known dizini yerine genel URL'lerde depolama esnekliğini tercih ettiklerini belirttiler. PrivacyPass'teki anahtar taahhüt biçimi, anahtar setlerinin örtülü "herkese açık meta verilere" izin vermesinin amaçlandığı bir sürüm için pek uygun değil. değer. PrivacyPass'in bir varyantı, herkese açık meta verilerle (POPRF, kısmi RSA gizlemesi veya anahtar setleri olarak) standart hale getirilirse 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, ya bu API'nin standart başlık olmayan sürümünü destekleyebiliriz ve kullanım yeterince düşükse ya da yayınlama/tekliften yararlanma isteklerini diğer verilerle ilişkilendirmeye yönelik standart yollar için yeterli geliştirici araçları/destekleri varsa, başlık sürümünü kullanımdan kaldırabiliriz. Sorunu burada tartışıyoruz. |
| Kayıt | Sertifika verenlerin tarayıcı tedarikçi firmalarına kaydolmasını sağlamak pratik mi? | Spesifikasyonu, Gizlilik Jetonları için kartı veren kuruluş kayıt sürecini açıklayacak şekilde güncelledik. Kendi sürecini kullansa da Özel Korumalı Alan çalışmasının geri kalanı için kayıt planlarına benzer. Bu aşamada, yayıncılardan PST'leri nasıl kullanmak istediklerine dair kamuya bir açıklama sunmalarını ve kullanıcı gizliliğini koruyan teknik kısıtlamaları kabul etmelerini isteriz. |