Özel Korumalı Alan teklifleri ve Chrome'un yanıtları hakkında alınan ekosistem geri bildirimlerini özetleyen, 2023'ün 2. çeyreğine yönelik üç aylık rapor.
Google, CMA'ya olan taahhütlerinin bir parçası olarak, Özel Korumalı Alan teklifleri için paydaş etkileşim süreci hakkında üç aylık raporları kamuya açık bir şekilde sunmayı kabul etmiştir (Taahhütler'ün 12 ve 17(c)(ii) paragraflarına bakın). Bu Özel Korumalı Alan geri bildirim özet raporları, geri bildirim genel bakışı bölümünde listelenen ve bunlarla sınırlı olmamak üzere Chrome'un çeşitli kaynaklardan aldığı geri bildirimler toplanarak oluşturulur: GitHub Sorunları, privacysandbox.com adresinde kullanıma sunulan geri bildirim formu, sektörden paydaşlarla toplantılar ve web standartları forumları. Chrome, ekosistemden alınan geri bildirimleri memnuniyetle karşılar ve öğrendiklerini tasarım kararlarına entegre etmenin yollarını aktif olarak araştırır.
Geri bildirim temaları, API başına yaygınlığa göre sıralanır. Bu, Chrome ekibinin belirli bir temayla ilgili aldığı geri bildirim miktarının toplanmasıyla ve azalan düzende düzenleyerek yapılır. Yaygın geri bildirim temaları; herkese açık toplantılarda ele alınan tartışma konuları (W3C, PatCG, IETF), doğrudan geri bildirimler, GitHub ve Google'ın şirket içi ekipleri ile herkese açık formlar üzerinden sıklıkla sorulan sorular incelenerek belirlenmiştir.
Daha net açıklamak gerekirse web standardı kuruluş toplantıları için toplantı notları incelendi ve doğrudan geri bildirim sağlamak amacıyla Google'ın bire bir paydaş toplantılarıyla ilgili kayıtları, tek tek mühendisler tarafından alınan e-postalar, API posta listesi ve genel geri bildirim formu dikkate alındı. Daha sonra Google, her bir API ile ilişkili olarak ortaya çıkan temaların göreceli yaygınlığını belirlemek için bu çeşitli destek faaliyetlerinde yer alan ekipler arasında koordinasyon sağladı.
Chrome'un geri bildirimlere verdiği yanıtların açıklamaları; yayınlanan SSS'lerden, paydaşlar tarafından dile getirilen sorunlara verilen gerçek yanıtlardan ve bu herkese açık raporlama alıştırmasının amaçları doğrultusunda, özel olarak bir pozisyonun belirlenmesinden alınmıştır. Geliştirme ve test çalışmalarının şu andaki odaklandığı konuları ele aldık. Özellikle Topics, Protected Audience ve Attribution Reporting API'lerle ilgili sorular ve geri bildirimler alındı.
Geçerli raporlama döneminin bitiminden sonra alınan geri bildirimde henüz Chrome yanıtı dikkate alınmamış olabilir.
Kısaltmalar sözlüğü
- ÇİPLER
- Bağımsız Bölümlendirilmiş Çerezler
- DSP
- Talep Tarafı Platformu
- FedCM
- Birleştirilmiş 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ü
- YA
- İnternet Protokolü adresi
- openRTB
- Gerçek zamanlı teklif verme
- UZ
- Kaynak Denemesi
- PatCG
- Özel Reklamcılık Teknolojisi Topluluğu Grubu
- RP
- Bağlı Taraf
- STP
- Arz Tarafı Platformu
- TEE
- Güvenilir Yürütme Ortamı
- UA
- User Agent dizesi
- UA-CH
- Kullanıcı Aracısı İstemci İpuçları
- W3C
- World Wide Web Konsorsiyumu
- WIPB
- Hasta IP Körlüğü
Genel geri bildirim, belirli bir API/Teknoloji yok
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Veri Yönetimi ve Mevzuata 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. Ancak bunun ekosistem açısından önemli bir ilgi alanı olduğunun farkındayız. Her API için, gerekli yasal değerlendirmelerin yapılması için gerekli temeli sağlayacak kapsamlı teknik dokümanlar yayınladık. Ayrıca, şirketlerin düzenleyici gereksinimlerine uyma çabalarını desteklemek için ek materyaller kullanıma sunmaya çalışıyoruz. |
| CMA Nicel Test teklifi | CMA nicel test teklifi hakkında daha fazla bilgi | Üçüncü taraf çerezlerinin kullanımdan kaldırılmasının ve ekosistem üzerinde Özel Korumalı Alan tekliflerinin kullanıma sunulmasının etkisini gösteren denemeler tasarlamak için CMA ile birlikte çalışıyoruz. Nisan ayında CMA, test ve deneme sürecinde neler olacağına dair üst düzey kılavuz, ardından Haziran ayında ayrıntılı rehberlik yayınladı. CMA'nın Nicel Test teklifiyle ilgili soruların veya geri bildirimlerin doğrudan CMA ile paylaşılmasını öneririz. |
| Chrome destekli test modları | Test zaman çizelgeleri hakkında daha fazla bilgi ve açıklama | 18 Mayıs'ta, Chrome destekli testin iki modu hakkında daha fazla bilgi paylaştığımız bir blog yayını yayınladık. Buradaki ayrıntılar nihai değildir. 2023'ün 3. çeyreğinde ilerleme kaydettikçe uygulama yönergeleriyle ilgili daha fazla bilgi yayınlayacağı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ümlendirmeleri, üçüncü taraf çerezlerini kullanımdan kaldırma denemesinden önce tüm kullanıcılara gönderilecektir. Bu nedenle, bu özellik 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ştirebilir. |
| Prodüksiyon desteği | Chrome'un, Özel Korumalı Alan ile ilgili teknik sorunları ve ekosistemi etkileyen üst birime iletme süreçlerini desteklemesi için süreç nasıldır? | Google, reklam teknisyenlerinin sorunları bildirmeleri ve gerekli üst birime iletmeleri için çeşitli kanallar sağlar. Geri bildirim ve sorun iletme için herkese açık ve gizli forumlar hakkında daha fazla bilgi edinmek için lütfen geliştirici yayınımıza göz atın. |
| Kayıt Zaman Çizelgesi | Kayıt için mevcut zaman aralığı çok kısa | Yaptırımla ilgili son tarihi değerlendirmeyi sürdürüyoruz. En uygun tarihin hangisi olduğu konusunda ekosistemden bilgi almak istiyoruz. |
| DUNS Numarası | Kayıt ve Onay için D-U-N-S numarası şartı hakkında daha fazla bilgi | Katılımcılar, DUNS numarası almayla ilgili koşulları Dun and Bradstreet web sitesinde bulabilir. Gereksinimler pazara göre değişiklik gösterdiğinden, katılımcılar ilgilendikleri pazarla ilgili web sitesini mutlaka kontrol etmelidir. Bununla birlikte, genellikle katılımcıların işletme hakkında işletme adı, adres ve işletme sahibi veya yöneticisinin iletişim bilgileri gibi temel bilgileri sağlaması gerekir. Katılımcılardan, işletmenin yıllık geliri gibi finansal bilgiler sağlamaları da istenebilir. Başvuru tamamlandığında D&B başvuruyu inceler ve başvuru onaylanırsa bir D-U-N-S numarası verir. |
| Kaynak Denemesinden Genel Kullanıma Geçiş | Kaynak Denemesi'nden Genel Kullanıma Geçiş, mevcut Kaynak Denemesi test kullanıcılarını etkiler mi? | Test kullanıcıları, Temmuz ayından itibaren alaka düzeyi ve ölçüm API'lerine genel kullanıma erişebilecekler. Bu durum, kaynak denemesinin kullanılabilirliği ile genel kullanılabilirlik arasında çakışma oluşturur. |
| AdExchanger Çalışması | Anket metodolojisi hakkında daha fazla bilgi | Ankette, katılımcılardan işletmelerinin senkronizasyon oranlarını ve gelirlerini tahmin etmeleri istendi. Katılımcıların sorularını yanıtlamak için kullandıkları yöntem kendilerine kalmıştır. |
| 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 temelindeki genel ilkeler açıklanmaktadır. Birçok değer henüz kesinleşme aşamasındadır. Bu konuyla ilgili geri bildirimlerinizi almaktan memnuniyet duyarız. |
Alakalı İçerik ve Reklamlar Gösterin
Konular
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Gizliliği Koruma | Gizliliği koruma konusunda Topics API'yi değerlendiren araştırma | Makalelerde, raporlarda ve atölye sunumlarında Topics API'nin gizlilik özelliklerine yönelik araştırmalarımızı sunarak araştırma topluluğunda aktif bir rol oynuyoruz. Araştırma topluluğunda bu alanla etkileşim kuran kuruluş dışı üye sayısının artmasından mutluluk duyuyoruz. Topics API, kullanıcıların geniş ölçekte izlenmesini çok zorlaştırarak kullanıcıları web'de genel izlemeye karşı korur. Bu belgelerde, bunu Topics API ile başarıyla gerçekleştirdiğimiz görülüyor. Üçüncü taraf çerezlerinden daha gizlidir ve kullanıcıları ziyaret etmekten keyif aldıkları siteleri desteklerken korur. |
| Konular sınıflandırması yeterince ayrıntılı değil | Geniş konular sınıflandırması, bölgeye özel de dahil olmak üzere daha ayrıntılı konuları içermez. | Ekosistemden aldığımız önceki geri bildirimlere yanıt olarak 15 Haziran'da, ekosistemden alınan geri bildirimlere göre sayısız iyileştirme içeren yeni ve güncellenmiş sınıflandırmanın ayrıntılarını içeren bir blog yayını yayınladık. Gözden geçirilmiş sınıflandırma çalışmalarımızın bir parçası olarak, ekosistemdeki Raptive (eski adıyla CafeMedia) ve Criteo gibi birçok şirketle iletişime geçtik. Güncellenen sınıflandırma, daha az yararlı olduğunu duyduğumuz kategorileri kaldırarak reklamverenlerin ilgi alanlarıyla daha iyi eşleşen kategorileri öne çıkarırken, hassas olabilecek konuları hariç tutma taahhüdümüzü de sürdürüyor. Ekosistemi en son sınıflandırmayı incelemeye ve değişiklikler hakkında geri bildirim sağlamaya teşvik ediyoruz. |
| 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ı yayın 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 değişmesini ve sınıflandırma yönetiminin sonunda sektörden paydaşları temsil eden harici bir tarafa geçiş yapmasını bekliyoruz. Ayrıca, artış planını topics-duunce grubunda da paylaştık. |
| Birinci taraf sinyalleri üzerindeki etkisi | Son Sınıflandırma güncellemesinde Konu sayısındaki artış, son derece değerli olabilir ve bunun sonucunda diğer birinci taraf ilgi alanına dayalı sinyallerin değerini azaltabilir. | 2023'ün 1. çeyreğine ait raporda CMA şu yorumda bulundu: "Google'ın, teklif ettiği yeni sınıflandırmayı reklam teknolojisi tedarik zincirindeki çeşitli pazar katılımcılarıyla tartışmakta olduğunu biliyoruz. Birkaç büyük yayıncı, konuların daha fazla kullanılması birinci taraf veriye dayalı çözümleri üzerindeki rekabet baskısını artıracağını belirtmiş olsa da ilk görüşümüz, genel olarak rekabet açısından daha fazla faydanın daha iyi olduğu, özellikle de küçük yayıncıların üçüncü taraf çerezlerinin kullanımdan kaldırılmasının ardından envanterlerinden para kazanmaya devam edebilmeleri için". Bakışımız, CMA'nın bu yorumuyla tutarlıdır. |
| Farklı paydaşlar için yararlılık | STP ve TTP görevi gören reklam teknolojileri, diğer ekosistem oyuncularına göre önemli avantajlara sahip olabilir. | Önceki çeyreklere yönelik tutumumuz değişmedi: "Google, Özel Korumalı Alan tekliflerini, kendi işletmesine öncelik vererek rekabeti bozmayacak şekilde tasarlamayı ve uygulamayı ve boyutları ne olursa olsun dijital reklamcılık ile yayıncılar ve reklamverenler üzerindeki rekabeti dikkate alma konusunda CMA'ya taahhüt verdi. Çalışmalarımı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 testleri devam ederken değerlendireceğimiz temel sorulardan biri, yeni teknolojilerin farklı paydaş türleri için nasıl performans gösterdiğidir. Geri bildirimler bu açıdan büyük önem taşıyor. Özellikle de teknik tasarımları daha da geliştirmemize yardımcı olabilecek spesifik ve harekete geçirici geri bildirimler almak istiyoruz. Nicel testlere yaklaşımımızı geliştirmek için CMA ile çalıştık ve pazar katılımcılarına daha fazla bilgi ve önerilen yaklaşımlar hakkında yorum yapma fırsatı sağlamak için CMA'nın deneme tasarımıyla ilgili bir not yayınlamasını destekliyoruz." |
| Alt Konular | Konu seçim ölçütleri tarayıcı ziyaretlerinin sıklığıdır. Segment ayrımı, alt konuların hiçbir zaman en üste çıkmasına neden olur mu? | Chrome şu anda diğer sıralama yöntemlerini değerlendirmekte ve sıralamayı iyileştirebilecek diğer sinyalleri keşfedmektedir. Gözden geçirilmiş planlarımızı zaman içinde ekosisteme ileteceğiz. |
| Hassasiyet | Topics API'nin hedefi, Topics API'den elde edilen veya türetilen kullanıcı bilgilerinin, günümüzün izleme yöntemleri kullanılarak elde edilenden daha az kişisel hassasiyet göstermesi olmalıdır. | Topics API'nin mevcut teknolojilerden önemli ölçüde daha gizli olduğuna, kullanıcıların yeniden tanımlanmasını önemli ölçüde kısıtladığı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 onaylıyoruz. Ancak Topics API'nin kullanıcı gizliliği için 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ı | Konu 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 ekliyoruz. Uzun vadeli yönetime doğru ilerlerken Konular nesnesini incelemek ve gerekirse sürüm oluşturma sırasında ek meta veriler eklemek mantıklı olacaktır. |
| Yayıncı denetimi | Yayıncılar, sitelerinin hangi Konular olarak sınıflandırılması gerektiği konusunda söz sahibi olmalıdır. | Sitelerin yanlış sınıflandırılması, Konular sinyalinin genel bir sinyal olarak pek az yararlı olmasına neden olabilir. Ancak, yanlış sınıflandırılan belirli siteler bu durumdan diğer sitelerden daha fazla veya daha az zarar görmeyecektir. Bunun nedeni, bir sitenin bağlamsal bilgilerinin, sitedeki açık artırmalarda her zaman kullanılabilir olmasıdır. Bu bilgiler, yanlış sınıflandırma durumunda bile doğru konuyla benzer bilgiler sağlar. 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 kasıtlı olarak yanlış bir şekilde sınıflandırarak herkesin yararlanabileceği faydayı azaltabilir veya pek yaygın olmayan konularda hassas anlamları 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 ver | GitHub'da da konuştuğumuz gibi bunun şimdiden mümkün olması gerekiyor ancak ekosistemden ek geri bildirimler almaktan memnuniyet duyarız. |
| Genel kullanıma geçiş | Kaynak Denemesinden Genel Kullanıma Geçişe geçiş Topics API üzerinde herhangi bir etki yaratır mı? | Kaynak Deneme'den Genel Kullanıma Geçiş yapan kullanıcılar için veri kaybı yaşanmaz. |
| Gizlilik | Ana Makine Adları, Topics API tarafından ortaya çıkabilecek özel bilgiler içerebilir | Gizliliği sağlamak için burada açıklandığı gibi çeşitli hafifletme yöntemlerimiz bulunmaktadır. |
| Sahtekarlık ve Kötüye Kullanım | Topics'in sahtekarlık amaçlı 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ştirmek isteyebilir mi? | Ekosistemden bu konuyla ilgili bilgi almak isteriz. Buradan geri bildirimlerinizi bizimle paylaşabilirsiniz. |
| 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 atayın ve web sayfalarında sağlanan etiketlere dayalı olarak sınıflandırıcıları eğitin. | Teklifi burada ele alıyoruz. Ek geri bildirimleri almaktan 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 STP odaklı filtrelemenin performansa etkisi | Trafik şekillendirme üzerinde 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ığı için korunan kitleyi test etmek zordur. | Korunan Kitleleri kullanmaya başlamak ve test etmek için STP ve TTP iş ortaklarıyla sürekli olarak etkileşim kuruyoruz. Genel Kullanım başladı. PA'nın etkinleştirildiği trafik yüzdesinin, testin iş ortakları tarafından daha da tercih edilebilir olmasını sağlayacağından eminiz. |
| Karmaşıklık | Korunan Kitle çözümlerini uygulamak, yüksek düzeyde çaba ve maliyet gerektirir. | Özel Korumalı Alan gibi yeni teknolojilerin benimsenmesinin zor olduğunun farkındayız. Özel Korumalı Alan ekibi, çok çeşitli paydaşları eğitmek ve desteklemek için onlarla yakın bir şekilde çalışıyor. Ekosistemin benimsenmesini desteklemek için hızlandırıcı diğer unsurları 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 potansiyel olarak destekleyici seçenekleri araştırıyoruz ancak şu anda Özel Korumalı Alan için çok zaman alan bir değerlendirme gerektiren şirket içi güvenlik sınırlamaları göz önüne alındığında şirket içi TEE'leri desteklemek uygun değil. Özel Korumalı Alan güvenlik gereksinimleri ve şirket içi dağıtımların getirdiği önemli zorluklar göz önünde bulundurulduğunda, bulut tabanlı dağıtımları genişletmeye ve iyileştirmeye (ör. AWS'nin yanı sıra GCP'yi destekleme) devam etmenin ekosistem için en faydalı yol olduğuna inanıyoruz. Ancak bu şartın neden gerekli olduğuna dair ek geri bildirimler almaktan memnuniyet duyarız. |
| Maliyet Yapısı | Teklif Verme ve Açık Artırma Hizmetleri teklifi, müşteri tarafı modellere kıyasla Reklam Teknolojileri için maliyeti ve karmaşıklığı artıracaktır. | Şu anda Teklif ve Açık Artırma sunucusunda teklif verme ve açık artırma iş akışlarını desteklemenin maliyetlerini tahmin etmeyle ilgili bir kılavuz hazırlıyoruz. Bu kılavuz, tasarımlarımızın hedeflerinden birini yerine getirerek reklam teknolojisi kullanımıyla ilişkilendirilecektir. |
| K-Anon Zaman Çizgileri | Planlanan k-anonimlik kısıtlamaları "renderUrl" öğesinde ne zaman uygulanır? | Yakında yayınlayacağımız yaptırım zaman çizelgesi için bir açıklama üzerinde çalışıyoruz. |
| reklam açık artırma kısıtlamaları | Chrome, runAdAuction öğesini yalnızca üst sayfadan çağrılabilecek şekilde kısıtlayabilir mi? |
Tasarımımız runAdAuction öğesinin en üst sayfadan çağrılmasını tam olarak desteklese de, yayıncıların bunu yalnızca üst alan adından çağrılabilir şekilde sınırlandırmanın daha zararlı olacağına inanıyoruz.Ekosistemden özel Korumalı Alan'ın yayıncılar ve reklamverenlerin üzerindeki yükü en aza indirmesi gerektiğini öğrendik. Bu geri bildirim, site sahiplerinin sitelerini çalıştırırken üçüncü taraf araçlar kullanabileceği genel web geliştirme ilkesiyle uyumludur. Özel Korumalı Alan hedefi, yayıncıların ve reklam teknolojilerinin çalışma şeklinin belirlenmesine gerek kalmadan sağlıklı bir ekosistemi teşvik etmekti. Yayıncıların, sitelerinde runAdAuction uygulamasını nasıl ve kimin çağıracağını seçmesine olanak tanıyarak yayıncılara, gereksinimleri için en iyi yolu bulmaları konusunda esneklik sağladığımızı düşünüyoruz. |
| Uygulama desteği | Chrome, çok satıcılı açık artırmaların açık kaynaklı bir uygulamasını oluşturabilir veya uygulamaya 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 hedefler. Reklam teknolojilerin nasıl çalışması gerektiğine dair bir talimat vermeye gerek kalmadan sağlıklı bir ekosistemi teşvik etmek istiyoruz. GitHub depomuzdaki API'lerin işleyiş şekliyle ilgili kılavuzlar yayınladık. Sektördeki çözümleri keşfetmeye açığız. Temel görevimiz bu teknolojilerin kullanımına yönelik stratejiler belirlemek değil, platform teknolojileri geliştirmek olduğundan özel bir uygulama oluşturmayı düşünmüyoruz. Teknolojilerimiz, reklam teknolojisi şirketlerinin tüketicilere doğru gizlilik korumalarıyla müşterilere en iyi şekilde hizmet vermelerine yardımcı olacak. |
| Çok satıcılı açık artırmalar | Chrome, bileşen açık artırmalarıyla "bağlamsal" kazanan paylaşmayı zorunlu kılar mı? | Protected Audience API, çok satıcılı açık artırmayı başlatan tarafların bileşen açık artırmasına bilgi aktarmasını sağlamak üzere tasarlanmıştır (not: yalnızca açık artırmayı başlatmadan önce). Bununla birlikte, tarayıcının bağlamsal olarak başarılı olup olmadığını ayırt etmesi mümkün değildir. Bu nedenle, engellemeyi veya belirli bilgileri zorunlu kılmayı zorunlu tutamadık. |
| İzin izleme için kullanıcı tercihi | Adtech, PA'ya kullanıcı rızası izlemenin nasıl doğru şekilde uygulanacağını soruyor | Yanıtımız 1. çeyrekte şunları söyledi: "Belirli reklamlar için, ilgili reklam teknolojisi hangi reklam öğelerinin gösterileceği veya nasıl seçileceği konusunda kontrol olanağı sunabilecek en iyi konumdaki taraftır." Mayıs WICG Korunan Kitle Toplantısı'nda bu sorunla ilgili çeşitli senaryolardan bahsettik. Bu konuyla ilgili ek geri bildirim ve tartışmalar almaktan memnuniyet duyarız. |
| Özel Kitleler | STP, özel kitle oluşturmayla ilgili 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. Bir STP'nin PA API ile nasıl entegre olabileceği konusunda daha fazla rehberlik geliştirilmekte ve entegrasyon çalışmalarını desteklemek için STP'ler ve 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 (nihayetinde bir video oynatıcıya VAST XML yükleyebilen bir yayın dışı reklam). Alıcılar, her iki biçimi de birrenderURL aracılığıyla döndürebilir. VAST spesifikasyonu, Attribution Reporting API'yi destekleyecek şekilde kısa süre önce güncellenmiştir. Video reklam yayınlayan siteler, reklamların Protected Audience API aracılığıyla yayınlanma biçimine hazırlanmalıdır. Yani yerleşim etiketlerinin, Korunan Kitle iframe'inden bir video oynatıcıya URL'yi iletebildiğinden emin olun. 2026'dan önce sınırlı olmamakla birlikte, Çitli Çerçeveler için video gereksinimlerinden önce ilgilenmeye çalışacağı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. Bu talep bugüne kadar çoğunlukla DSP ile ilgili bir sorun olduğu için daha fazla STP iş ortağından daha fazla ayrıntı gelmesini sağlayarak bu talebin daha fazla örneğini görmek isteriz. |
| Güncelleme sıklığı | dailyUpdate tarafından yapılan telefon aramalarının sıklığı (ilgi alanı grubu başına günde en fazla 1 adet), ürün bilgilerini güncelleme 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 açık artırma yapılandırmasının bir parçası olarak teklif öncesi (ör. reklamlarla ilişkili etiketlere dayalı ret listeleri) oluşturabilecekleri belirli denetimler konusunda STP'lerine bilgi vermelerini sağlayan işlevler sunuyor. Ekosistem için gerekli olabilecek ek işlevlerle ilgili geri bildirimlerinizi almaktan memnuniyet duyarız. |
| Hata ayıklama | forDebuggingOnly işlevi ne zaman kaldırılacak? |
Üçüncü taraf çerezlerinin kullanımdan kaldırılmasından kaynaklanan kayıp etkinlikleri nedeniyle forDebuggingOnly özelliğini kullanımdan kaldırmayı planlıyoruz. forDebuggingOnly, ödül kazanma etkinlikleri için en kısa zamanda 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 Sorununda da açıklandığı üzere cihazlar arası hedeflemenin yüksek derecede spesifik olması gizlilikle ilgili önemli endişeler doğurmaktadır. |
| (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 kullanılmaya devam edecek mi? | Bu kullanım alanının, burada açıklandığı gibi Korunan Kitle özelliği kullanıldığında mümkün olduğunu düşünüyoruz. |
| Tıklamayla ilgili veriler | Tıklamayla ilgili verileri browserSignals. kampanyasına ekleyin |
Şu anda, ön pozisyon vermek için tıklamanın ne zaman gerçekleştiğine dair bir açıklamaya ihtiyacımız var. |
| (2022'nin 4. çeyreğinde de bildirilmiştir) Korunan kitledeki 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şlevselliğini genişletmek için programlanabilen işlevlerdir. | Bu sorunu dile getiren reklam teknolojisi, hâlâ UDF ile neler yapabileceklerini değerlendirmeye devam ettiklerini de belirtti. Bu nedenle, en azından genel kullanıma sunulmadan önce yanıt verebileceğimiz uygulanabilir bir geri bildirim bulunmuyor. |
| Currency | Para birimi tutarları, kayan noktalar kullanılarak temsil edilmemelidir. | Bu sorunu burada ayrıntılı bir şekilde ele aldık. |
| TTP olmayan 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'in generateBid kampanyasından reklam ilgi alanı grubu başına birden fazla aday reklam döndürme ve bu adayların "scoreAd" olarak puanlanmasını sağlama teklifi için destek. |
Bu bilgi şu anda değerlendiriliyor. Buradan daha fazla geri bildirim almaktan memnuniyet duyarız. |
| 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 girdi alabilmesi için, yürütülen son açık artırma olması gerekir mi? | Protected Audience API'nin son çalışması için teknik bir şart yoktur. |
| Kullanıcı tarafından başlatılmayan gezinme | Kullanıcı tarafından başlatılmayan gezinmeyi göster | Bu isteği inceliyor, burada tartışıyoruz ve ek geri bildirim almaktan memnuniyet duyarız. |
| Önbelleğe alma | Kullanıcı durumu değişirse STP, belirli bir TTP'nin perBuyerSignals değerini bir önbellekten derlememelidir. | Önbelleğe almanın, her Alıcı sinyallerine yönelik her kullanım alanında çalışmayacağını biliyoruz ve ek seçenekleri değerlendiriyoruz. Önbelleğe almanın kullanım alanları için işe yarayıp yaramayacağı konusunda ekosistemden gelecek ek geri bildirimleri memnuniyetle karşılıyoruz. |
| İlişkilendirme Raporlama 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 da (etkinlik düzeyi ve özet raporlar) kullanılabilir. 1 Haziran'da, Protected Audience API ve Attribution Reporting entegrasyonu iyileştirildi. Daha fazla bilgi paylaşmıştık. Bunlar hakkında bilgi edinebilirsiniz. |
| Sunucu Uç Noktası | Sunucu uç noktası son tasarımda Güvenilir Toplama Sunucusu mu olacak? | 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 ve reklam teknolojisi tarafından sürdürülen bir uç noktadır. Raporlama uç noktası için şu anda planlanmış herhangi bir değişiklik yok. Mevcut tasarım, birleştirilebilir verilerin (şifrelenmiş yüklerle birlikte) siteler arası verileri sızdırmamasını sağlamayı amaçlamaktadır. Bu nedenle, güvenilir bir uç nokta gerekli olmamalıdır. Diğer bir komplikasyon da farklı reklam teknisyenlerinin istenen farklı gruplama stratejilerine sahip olma olasılığıdır. Buradan daha fazla geri bildirim almaktan memnuniyet duyarız. |
| WebIDL | Geçerli Protected Audience API spesifikasyonu, WebIDL spesifikasyonuyla uyumlu değil. | Bu geri bildirimi değerlendirip sorunu ele alıyoruz. |
| Kullanıcı Rızası Yönetimi | Protected Audience API'de izin sinyali iletimi nasıl işlenir? | Bağlamsal bilgiler, Protected Audience API kapsamında değildir. Bu sorunu ele alıyoruz ve daha fazla geri bildirim almaktan memnuniyet duyarız. |
| Hesaba Dayalı Pazarlama | Hesaba dayalı pazarlama kullanım alanları mümkün olur mu? | 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 nasıl destekleyebileceğini anlamaya devam ediyoruz. Ekosistemin bu konuyla ilgili ek geri bildirimlerini almaktan memnuniyet duyarız. |
| Bileşen açık artırması | Bileşen açık artırma katılımcılarının puanı nedir? | Bileşen açık artırmaları, doğrudan İlgi Alanı Gruplarını 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ıştırılır ve TTP, generateBid yürütülürken 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. | Google'dan GitHub koduna yapılan katkıları desteklemek için ilgili süreçlerimizi güncellemeyi planlıyoruz. |
| İlgi Grubu Boyutu | IG'nin destekleyebileceği maksimum anahtar sayısı nedir? | Mevcut sınır, bir IG'nin boyutu için 50 kb'tır ve anahtarlar bunun bir parçası olarak sayılır. Boyut sınırıyla ilgili daha ayrıntılı görüşmekten memnuniyet duyarız. |
| Gruplama | 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ü Başlıkları kullanabilirsiniz. Örneğin, bileşen açık artırmalarında ve tek bir sayfadaki reklam alanlarında önbelleğe alınabilir. |
| Sürüm denetimi | Birden fazla reklam teknolojisi kodu sürümü desteği | Teklifli Sistem ve Açık Artırma hizmetleri, reklam teknolojisi kodunun birden çok sürümünü destekleyecek. Teklif Verme 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 ayrıca raporlama için) belirtebilir. |
| Paylaşılan 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ğu konusunda daha fazla geri bildirim almak isteriz. |
| Web'den uygulamaya | İlgi alanı gruplarının web'den uygulamaya paylaşımını destekleme. | Web'den uygulamaya geçiş şu an için Chrome ve Android genelindeki Protected Audience API dağıtımının kapsamında değildir. Ancak bu kullanım alanının önemi hakkında ekosistemden bilgi almak isteriz. |
| K-Anonimlik | K-Anonimlik yedeklerini işleme | Bu sorunu ele alıyor ve sizden daha fazla geri bildirim almaktan memnuniyet duyuyoruz. |
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ı hakkında geri bildirim | Etkinlik düzeyindeki mevcut yapılandırmaların uygun olmadığına dair bazı geri bildirimler aldık ve en uygun genel yapılandırmalarla ilgili geri bildiriminizi istiyoruz. Bu konuyla ilgili ek geri bildirimlere açığız. Etkinlik düzeyindeki esnek açıklayıcımızın da bu sorunu çözmeye yardımcı olacağını düşünüyoruz. |
| Etkinlik düzeyinde esnek yapılandırmalar | Etkinlik düzeyinde esnek yapılandırma özelliğinin durumu nedir? | Etkinlik düzeyinde esnek yapılandırma ile ilgili dokümanlar paylaştık. Bu özellik hâlâ teklif aşamasındadır ve özelliğin ekosistem açısından değerli olup olmayacağı konusunda daha fazla geri bildirim almak istiyoruz. |
| Etkinlik düzeyinde esnek yapılandırmalar | Farklı taraflardan gelen, çelişen raporlar nasıl uzlaştırılabilir? | Raporlama senaryolarının çoğu, toplu raporlar kullanılarak ele alınır. Etkinlik düzeyinde esnek yapılandırma teklifi ise özellikle optimizasyon kullanım alanlarında kullanılan etkinlik düzeyindeki raporlarda daha fazla esneklik sağlamak için tasarlanmıştır. Bu senaryoyla ilgili olarak ekosistem ile ilgili diğer yorumları/geri bildirimleri almaktan memnuniyet duyarız. |
| Kaynak kaydı | Kaynak kaydı tetikleyici kaydından sonra gerçekleşirse ne olur? | Şu anda, tetikleyici kaydından sonra kaynak kaydı gerçekleşirse kaynak ve tetikleyici birbiriyle ilişkilendirilemez. Bu sıra dışı bir durum gibi görünüyor. Bu sorunla ilgili başka geri bildirimleriniz varsa lütfen almak isteriz. Birçok reklam teknisyeninin karşılaştığı bir senaryo söz konusuysa sorunu çözmeye çalışacağız. |
| Birden fazla 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 destekler ve bu nedenle, bir reklamveren birden fazla reklam ajansıyla çalıştığında bile kullanılabilir. Ayrıca, API'nin gizliliği iyileştirmesini sağlamak için yönlendirmelerle ilgili bazı sınırlamalar da vardır. Reklam teknolojisinin ortaya çıkardığı spesifik senaryo için de Shared Storage API'den yararlanmak üzere olası bir çözüm belirledik. Bu senaryoyla ilgili başka geri bildirimleriniz varsa lütfen bizim için çok değerlidir. Bu geri bildirimler doğrultusunda önerilerimizi geliştirmeye devam edeceğiz. |
| Hedef Sınırları | Otomatik olarak yenilenen reklamların kullanım alanı, hedef sınırlarının eklenmesinden etkilenebilir. | Bu sorunu 1 Mayıs WICG toplantısında ele aldık ve makul bir sınırın ne olacağı konusunda geri bildirimde bulunmanızı rica ediyoruz. Tarayıcının, kaynak siteler tarafından temsil edilen "hedef" eTLD+1 sayısını sınırlayabileceğini belirten Etkinlik düzeyindeki raporlarla ilişkilendirme raporu açıklayıcısına ekleme yaptık. (Çekme isteği bölümünü inceleyin). |
| İlişkilendirme Raporlama 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 da (etkinlik düzeyi ve özet raporlar) kullanılabilir. 1 Haziran'da, Protected Audience API ve Attribution Reporting entegrasyonu iyileştirildi. Daha fazla bilgi paylaşmıştık. Bunlar hakkında bilgi edinebilirsiniz. |
| Etkinlik düzeyinde esnek yapılandırmalar | Parametreler yapılandırılabilir hale geldiğinden gürültü simülasyonu için en iyi uygulamaları paylaşın. | GitHub'da paylaşılan kodu paylaştık. İsteyen herkes, test etmek istediği etkinlik düzeyindeki esnek yapılandırmalar için bilgi kazancını ve gürültü etkisini değerlendirebilir. Kodla test yapmayı seçen ve geri bildirimde bulunmak isteyen herkesin görüşlerini öğrenmek isteriz. |
| Uygulamalar Arası ve Web İlişkilendirmesi Ö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 Uygulamalar Arası ve Web İlişkilendirme Ölçümü için bir deneme duyurmuştuk. Chrome 115'teki alaka düzeyi ve ölçüm API'leri için Genel Kullanıma sunulması planlanmakla birlikte, Uygulamalar Arası ve Web İlişkilendirme Ölçümü şu anda Chrome 115 ile birlikte genel kullanıma sunulması planlanmamaktadır. |
| Dönüşümleri tekilleştir | Bağımsız ölçüm çözümleri ARA ile nasıl uzlaştırılabilir? | Mevcut standart uygulamada olduğu gibi, reklamverenler dönüşüm raporlamasında yinelemeleri kaldırmak için üçüncü taraf bağımsız bir ölçüm sağlayıcısıyla birlikte çalışır. Etkinlik düzeyinde raporlama için dönüşümlerin nasıl tekilleştirileceği konusunda kaynaklar sunduk. |
| İlişkilendirme Raporları veritabanı güncellemeleri sırasında veri kaybı | Chrome, duyurulduğu şekilde İlişkilendirme Raporlama Veritabanı'nı güncellediğinde veri kaybı olur mu? | Chrome'un kararlı 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 izlenirken bu genel kullanıma sunum işlevi daha da artacaktır. Hedef, 2023'ün 3. çeyreğine kadar haftalık bir süreçte% 100 kullanılabilirliğe ulaşmak olacak. Bu, Alaka Düzeyi ve Ölçüm kaynak denemesinin sonu ile aynı zamana denk gelecek. Temmuz ayından itibaren test kullanıcıları, genel kullanıma sunulduğunda bu API'lere erişim için kaydolabilecekler. Bu durum, kaynak denemesinin kullanılabilirliği ile kayıt üzerinden kullanılan genel kullanılabilirlik arasında çakışma oluşturur. 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 geçerlilik bitiş tarihinden önce API'lere kaydolmanızı öneririz. Bu duyuruda belirtildiği gibi, eski sürümlerden (M113 ve öncesi) kaydedilen veriler güncellemeden sonra taşınmayacak. Bu nedenle veri kaybı yaşanabilir. Bu veri kaybı, hata ayıklama raporlarında görünmez ve 114 ile 115 arasındaki veri kaybını önlemeye çalışırız. |
| Faturalandırma | Dönüşüm başına maliyet faturalandırması için İlişkilendirme Raporlamasını Kullanma | Bu makalede belirtildiği gibi, Attribution Reporting API, etkinlik düzeyindeki ve özet raporlara eklenen sapma nedeniyle 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. |
Toplama Hizmeti
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Toplanabilir rapor gecikme değişikliği | Birleştirilebilir rapor gecikmesinin ekosistemden gelen geri bildirimden sonra [10-60 dakika] ila [0-10 dakika] olacak şekilde değiştirilmesi teklifine verilen olumlu tepkiler | Önerilen değişikliğe olumlu tepki verilmesinden memnuniyet duyuyor ve ekosistemimizi tekliflerimizle ilgili geri bildirim sağlamaya 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 potansiyel olarak destekleyici seçenekleri araştırıyoruz ancak şu anda Özel Korumalı Alan için çok zaman alan bir değerlendirme gerektiren şirket içi güvenlik sınırlamaları göz önüne alındığında şirket içi TEE'leri desteklemek uygun değil. Özel Korumalı Alan güvenlik gereksinimleri ve şirket içi dağıtımların getirdiği önemli zorluklar göz önünde bulundurulduğunda, bulut tabanlı dağıtımları genişletmeye ve iyileştirmeye (ör. AWS'nin yanı sıra GCP'yi destekleme) devam etmenin ekosistem için en faydalı yol olduğuna inanıyoruz. Ancak bu şartın neden gerekli olduğuna dair ek geri bildirimler almaktan memnuniyet duyarız. |
| Raporları farklı dönemler için yeniden işleme | Raporları farklı dönemler için yeniden işleyebilme | Grupları farklı tarih aralıklarına göre bölebilmek için bazı benzer istekler de 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 değerlendirmenin ilk aşamasındayız ve teklif geliştikçe ekosistemi güncel tutacağız. |
| Güvenilir Yürütme Ortamının Gizlilik Sonuçları | Güvenilir Yürütme Ortamlarının gizlilik açısından etkilerine olumlu yaklaşım | Ekosistemin tekliflerimizle ilgili olumlu tepkilerini öğrenmekten memnuniyet duyuyoruz. Aynı zamanda, kendimizi geliştirmeye ve geliştirmeye devam ederken geri bildirimlerinizi de almaktan memnuniyet duyuyoruz. |
| Hizmet Şartları | Toplama Hizmeti Hizmet Şartları'nı kabul etmek için gereken son tarih nedir? | Hükümler ve koşulların kabul edilmesi için henüz bir son tarih belirlememiş olsak da kayıtta gecikme yaşanmaması için ekosistem şirketlerinin şartlar ve koşulları en kısa sürede kabul etmelerini öneririz. Şirketlerin, soruları olduğunda iletişime geçmelerini öneririz. |
| Anahtar Keşif | Önemli keşif özelliği, test kullanıcılarının ağlar arası ilişkilendirmeye yönelik özet raporlarını daha iyi performans ve doğruluk sağlayacak şekilde işlemek için olası anahtar kombinasyonlarının açık bir listesine ihtiyaç duymadan toplu raporları sorgulamalarını sağlar. | Şu anda olası çözümleri ve geçici çözümleri araştırıyoruz ve ekosistemden ek geri bildirimler almaktan memnuniyet duyuyoruz. |
Private Aggregation API'si
| 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 tuş alanı sınırlamasını daha net hale getirip sayfalar arasındaki tutarsızlıkları gidereceğiz. Bu anahtar alanının dışına çıkmamak için karma oluşturma stratejileri kullanmanızı öneririz. |
| Rapor başına maksimum katkı | Şu anda rapor başına 20 katkı sınırı çok düşük. | Maksimum katkı sayısını artırmak yerine, sınırda kesinti yapmak yerine raporları bölmeyi değerlendirebiliriz. Bu teklif değiştikçe ekosistemi dahil edeceğiz. |
| Erişim raporları | Platformlar arası/cihazlar arası erişim raporlaması isteği. Erişim, marka reklamcılığının temel bir metriğidir. Reklamverenler, kampanyalarını analiz etmek ve harcamayı paylaştırmak için Erişim ve Sıklık raporları için platformlar arası/cihazlar arası yaklaşımlardan yararlanır. Erişim modelleri, üçüncü taraf ortamlarda gösterilen reklamları ölçmek için bir sinyal olarak üçüncü taraf çerezlerini kullanır. Bu nedenle reklam teknolojileri, üçüncü taraf çerezleri kullanımdan kaldırıldığında alternatif bir çözüm talep etmiştir. |
Özel Korumalı Alan ekibi, üçüncü taraf çerezleri için destek sonlandırıldıktan sonra web alanları arası erişim yöntemlerini destekleyecek özellikleri araştırıyor. Ekosistemden geri bildirim almaktan 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) Diğer form faktörleri için ipuçları | TV ve VR gibi ek form faktörleri sağlamak için Kullanıcı Aracısı İstemci İpuçları (UA-CH) isteği | Bazı temel tasarım kararları üzerinde çalışmaya devam ediyoruz ("TV" gibi tek bir değer veya form faktörü özelliklerinin bir listesi olabilir) ancak bu fikrin prototipini oluşturmakla ilgilenmeye devam edeceğiz. |
| Gizlilik Bütçesi | Gizlilik Bütçesi kısıtlamaları, çok fazla istek gönderildiğinde UA-CH isteklerinin belirleyici olmamasına neden olabilir. | Şu anda Gizlilik Bütçesi teklifiyle ilgili yeni bir güncellememiz yok. Ancak üçüncü taraf çerezleri kullanımdan kaldırılmadan önce UA istemci ipuçlarıyla ilgili istekleri kısıtlamamayı taahhüt ediyoruz. |
| 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 olmanın geçerli kullanım alanları vardır ve bunlardan biri tam uyumluluktır. Bir UA, bu sorunlara çözüm bulmak için birden fazla markaya sahip olabilir. |
IP Koruması (eski adıyla Gnatcatcher)
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Sahtekarlık ve Kötüye Kullanım | Şirketler, IP Koruması ile sahtekarlıkla mücadele önlemlerini nasıl alabilir? | Sahtekarlıkla mücadele kullanım alanlarının önemini ve bunun bu kullanım alanları üzerindeki olası etkisini biliyoruz. Sahtekarlıkla mücadeleyi destekleme hakkında 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 ekosistemle ilgili geri bildirimler almak 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ın ayrıntılarını içeren 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ı tercihi özelliği 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 özellik daha geniş bir kitlenin kullanımına sunulmadan önce ekosisteme gerekli düzenlemeleri yapması ve geri bildirim sağlaması için zaman tanımamızdır. |
| Hesap kimlik doğrulaması | Proxy sunucusuyla hesap kimlik doğrulaması tam olarak nasıl çalışacak? | Bu yazın ilerleyen günlerinde hesap kimlik doğrulama hakkında daha fazla ayrıntı yayınlamayı planlıyoruz, ancak daha önce de dikkate almanız gereken bazı ilk hususları paylaştık. |
Hemen Çıkma Durumunu İzleme Çözümleri
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Test Kılavuzu | Hemen çıkma durumunu izleme etkisinin nasıl test edileceğiyle ilgili bilgiler | Mayıs ayında, Hemen Çıkma Durumunu İzleme Çözümleri'nin nasıl test edileceğiyle ilgili daha fazla bilgi içeren bir blog yayını yayınlamıştık. |
| Belgeler | Hemen Çıkma İzleme Teklifinin Netliği | Mevcut teklif ile ilgili çalışmalar devam etmektedir ve Chrome, ekosisteme netlik ve bilgi sağlamak amacıyla teklifi güncellemeye devam etmektedir. Daha ayrıntılı bilgi vermek için çalışıyoruz. Başka geri bildirimleriniz varsa lütfen almaktan memnuniyet duyarız. |
| Çerez silme | Hemen Çıkma Durumunu İzleme Çözümleri bir alandaki tüm çerezleri siler mi? | Hemen çıkma durumunu izleme çözümü (BTM), burada açıklandığı gibi tüm depolama alanını ve tüm önbelleği temizler. |
| Hemen Çıkma Durumunu İzleme Çözümlerini Atlatma | Hemen çıkma izleyici sınıflandırması, pop-up'lar veya yeni sekmelerle yönlendirmeler yapılarak atlanabilir. | Hemen Çıkma Durumunu İzleme Çözümleriyle ilgili çalışmalar halen devam etmektedir. Şu ana kadar çoğunlukla aynı sekme yönlendirmelerine odaklandık, ancak ileride pop-up akışları üzerinde çalışmayı planlıyoruz. Buradan daha fazla geri bildirim almaktan memnuniyet duyarız. |
Gizlilik Bütçesi
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Yakınlık Hedefleme | Gizlilik Bütçesi, yakın çevredeki hedefleme kullanım alanlarını etkileyebilir. | Bu sorunla ilgili geri bildirimler aldık ve ekosistemde yaşanabilecek potansiyel etkiler hakkında 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 bildirilmiştir) Alan Sınırı | İlişkilendirilmiş alan adlarının sayısını artırma isteği | Chrome, tanımlanan kullanım alanlarında gizlilik ve faydayı dengeleyecek İlişkilendirilmiş alt küme için uygun sayısal sınırı değerlendiriyor. Chrome, en başından itibaren İlişkili alt küme için kesin sayının kesinleşmediğini paylaştı. |
| Yerleştirilmiş Kullanım Örneği | 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 bildirimi aldı. Ekibimiz konuyu araştırıyor ve ek geri bildirimleri memnuniyetle kabul ediyor. |
| Depo Yönetimi | Tutarsızlıklar veya ihmaller varsa GitHub deposundan Birinci Taraf Gruplar'ı kaldırmaya yönelik politikalar hakkında bilgi | Chrome bu kullanım alanıyla ilgili geri bildirimi aldı. Ekibimiz bu durumu araştırıyor ve ek geri bildirimler almaktan memnuniyet duyuyor. |
| Kullanıcı Eğitimi | Chrome, Birinci Taraf Grup kullanımının artması için kullanıcı bilinirliğini ve anlayışını artırmalıdır. | Chrome, kullanıcıları Birinci Taraf Gruplar hakkında eğitmeyi ilke edinmiştir ve bu konuyla ilgili olarak 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 devam etmek için de çalışmaktadır. |
| 3PCD Yayın | Üçüncü taraf çerezleri, üçüncü taraf çerezleri için destek sonlandırıldıktan sonra Birinci Taraf Gruplar arasında kalmaya devam edecek. | requestStorageAccess ve requestStorageAccessFor, üçüncü taraf çerezlerini gerçekten belirli ve açıkça tanımlanmış kullanım alanları için tekrar kullanılabilir hale getirse de üçüncü taraf çerezlerinin mevcut durumunda (Chrome'da) olduğu gibi varsayılan olarak kullanılabilir olmak yerine artık site tarafından etkin bir çağrı yapılmasını gerektiriyor.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 önleyebilir. Kullanıcılara, Chrome kullanıcı arayüzünden bağlantı verilen Yardım Merkezi makalesinden daha fazla bilgi edinebilirsiniz. FPS %100'e kadar yükseldikçe mevcut geliştirici kılavuzunu genişletmeyi planlıyoruz. |
| Birinci Taraf Grup 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 desteklendiğinden emin olmak 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 almaktan memnuniyet duyarız. |
Çitli Çerçeveler API'sı
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Reklam Engelleme | Kısıtlanmış Çerçeveler, reklam engelleyicilerin reklamları engellemesini kolaylaştırabilir. | Uzantılar, iframe'lerle olan etkileşimine benzer şekilde sınırlanmış çerçevelerle etkileşim kurabilir. Sınırlarla çevrili çerçevenin gidilmek üzere olduğu gerçek URL, uzantılar tarafından da görülebilir. Dolayısıyla uzantılar, engelleme için iframe'lerde olduğu gibi URL eşleştirme kurallarını uygulayabilir. Kısıtlanmış tüm çerçeveleri koşulsuz olarak engellemek, sınırlı çerçevelerin reklam dışı kullanım alanlarını bozabilir. |
Shared Storage API'si
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Daha yaygın kullanım | Paylaşılan Depolama, tüm tarayıcılarda kullanılabilecek, sektör genelinde geçerli bir standart olmalıdır. | Bu geri bildirimi memnuniyetle karşılıyoruz ve kabul ediyoruz. Chrome, teklifi desteklemek, geri bildirim almak ve benimsenme oranını artırmak için W3C fora'ya aktif olarak katılmaya devam etmektedir. |
| Çıkış Kapıları | Paylaşılan 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ğu konusunda ekosisteme ilişkin ek geri bildirimleri değerlendiriyoruz. |
| Yasal Düzenlemelere Uygunluk | Paylaşılan Depolama, veri saklama politikaları gibi yönetmeliklere uygunluğu nasıl ele alır? | Paylaşımlı Depolama, depolanan verilerin kullanım ömrünü ve geçerlilik süresini kontrol etmek için mantığı uygulama ve özelleştirme esnekliği sağlar. Reklam teknisyenleri, yazma zaman damgalarına göre Paylaşılan Depolama Alanı verilerini güncelleyebilir veya silebilir. |
| A/B Testi | Shared Storage ve Protected Audience API için A/B testi nasıl yapılabilir? | Bu konuda daha fazla açıklama yayınlamak için çalışıyoruz. Gelecekte daha fazla ayrıntı paylaşmayı umuyoruz. |
| Paylaşılan Depolama Alanı Sınırı | Paylaşılan Depolama Alanı sınırına ulaşıldığında ne olur? | Sınıra ulaşılırsa başka giriş depolanmaz. |
| Aynı sayfa yüklemesinde çoklu 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. Her reklamın değerini güncellemek yerine, birden fazla reklam olduğunda çakışmalara neden olabilir. Ekleme işlevi, yeni değeri mevcut değerin sonuna ekler. |
| iframe İşlevi | Paylaşılan Depolama, üçüncü taraf çerezleri için destek sonlandırıldıktan sonra artık çalışmayan belirli iframe işlevlerini destekleyecek mi? | Üçüncü taraf çerezlerinin kullanımdan kaldırılmasından sonra, iframe'lerde yerel depolama alanı üst düzey site tarafından bölümlendirilmiş olacak ancak iframe'lerin kendisi engellenmeyecektir. Bir iframe'in yerel depolama alanındaki veriler birden fazla üst düzey sitede çoğaltılamaz, ancak yerel depolama alanı iframe içinde kullanılabilir. |
ÇİPLER
| 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 mesele ve bunun düşürülmesini istiyor. | Firefox, CHIPS üzerinde zaten olumlu bir konum belirtmiştir. Webkit desteği için geliştiricilerin, bölümlendirilmiş depolama alanı yerine bölümlendirilmiş çerezlerin tercih edildiği kullanım alanları hakkında bu GitHub sorunu hakkında doğrudan Apple'a geri bildirim sağlamalarını öneririz. |
| Kimliği doğrulanmış yerleştirmeler | 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ştirme kullanım alanını desteklemek için Storage Access API'den (kullanıcı istemleriyle) yararlanmayı planlıyoruz. Kısa süre önce bir intent-prototip kodu gönderdik. |
| Ömür Boyu Politikalar | Potansiyel kullanım ömrü politikaları birinci taraf çerezler için geçerli olacak mı? | Şu anda birinci taraf çerezlerine ömür boyu sınırlar getirme gibi bir planımız yoktur. |
FedCM
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| OAuth Yetkilendirme Desteği | Profil dışı OAuth kapsamlarının yetkilendirilmesine uyum sağla | Üçüncü taraf çerezlerinin kullanımdan kaldırılmasının ardından, temel kimlik doğrulamanın ötesinde yetkilendirmeyi desteklemenin en iyi yollarıyla ilgili olarak W3C FedID CG aracılığıyla Web Identity topluluğundan görüş alabilirsiniz. |
| SAML desteği | SAML desteği gereksinimleri üzerinde uzlaşma | Ekip, üçüncü taraf çerezlerinin kullanımdan kaldırılmasının ardından OpenID-connect desteğine ek olarak SAML'ye yönelik destek ihtiyaçları hakkında araştırma ve eğitim topluluklarından etkin bir şekilde görüş almak istiyor. |
Spam ve sahtekarlıkla mücadele edin
Private State Token API (ve diğer API'ler)
| Geri Bildirim Teması | Özet | Chrome Yanıtı |
|---|---|---|
| Yeni sinyalleri keşfetme | Birçok iş ortağı, cihaz bütünlüğü veya kullanıcı güveni konusunda tarayıcının sağladığı sinyalleri araştırmaya karşı olumlu bir yaklaşım benimsemiştir. Genel olarak, amaca yönelik yeni sinyallerin mevcut sahtekarlık algılama düzeylerini korumak için yeterli olmasına da dikkat ederler. | Sahtekarlıkla mücadele ve web güvenliği topluluğunda yeni teklifleri keşfetmenin yanı sıra onların endişelerini de onaylayıp paylaşmaktan heyecan duyuyoruz. "Spam ve sahtekarlıkla mücadele", Özel Korumalı Alan'ın temel çalışma süreçlerinden biri oldu. Kullanıcı gizliliğini geliştirirken web güvenliğini koruma yatırımlarına öncelik vermeye devam etmemizin nedeni de tam olarak budur. |
| PST hakkında olumlu geri bildirim | Birçok iş ortağı, sahtekarlıkla mücadele veya web güvenliğiyle ilgili çeşitli kullanım alanlarında PST'leri test etmek veya kullanmak istediğini ifade etmiştir. | Destek aldığımızı ve PST'lerin kullanıldığı yeni çözümleri daha da keşfetmeyi talep ettiğini duymak bizi heyecanlandırıyor. Chrome geliştirici sitesinde kaynaklarımız ve örnek kodlarımız mevcuttur. Geri bildirimlerinizi almaktan memnuniyet duyarız. |
| Sahtekarlık ve Kötüye Kullanım | Tanımlayıcıların artık kullanılamadığı durumlarda, üçüncü taraf çerezleri için destek sonlandırıldıktan sonra ölçümde Reklam Sahtekarlığını Önleme / Algılama ile ilgili rehberlik. | Sahtekarlıkla mücadele amacıyla üçüncü taraf çerezleri tarafından kaybedilen sinyallerin bir kısmının kurtarılmasına yardımcı olan gizlilik jetonları gibi araçları kullanıma sunduk. Bu araçlar, yeni gizlilik denetimleri sunmaktadır. Özel Korumalı Alan'da yapılan diğer değişikliklerin özelliklerini korumak için sahtekarlıkla ve kötüye kullanımla mücadele ile ilgili yeni tekliflere aktif olarak yatırım yapıyoruz. |
| Sertifikayı veren kuruluş-kaynak bilgilerinin oranı | Kartı veren kuruluştan kaynağa bilgi oranı, benzersiz kullanıcıların belirlenmesine yetecek kadar yüksek. | Bu özelliği, Gizlilik Jetonları kullanılarak hangi kullanıcı verilerinin iletilebileceği konusunda daha net olacak şekilde güncelledik. Tasarım gereği, aynı anda en fazla altı ortak anahtar kullanılabilir. Bu anahtar, belirli bir kullanıcı için bir "durum"u 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 durum, zaman içinde başka kullanıcı verilerini birleştirme olasılığını yavaşlatır. Her yeni web API'sinde, sağlanan fayda ile sağladığı net yeni kullanıcı bilgileri arasında bir denge vardır. PST'lerin, üçüncü taraf çerezlerinin kullanımdan kaldırılmasından etkilenen ve sahtekarlıkla mücadele için önemli kullanım alanlarını etkinleştirirken kullanıcı gizliliğinin korunması açısından doğru dengeyi sağladığını tahmin ediyoruz. |
| Getirme Entegrasyonu | fetch entegrasyonu karmaşık ve gereksizdir. |
fetch kullanmanın avantajları ve dezavantajları vardır ve web ekosisteminde daha fazla standartlaştırma gerçekleştirmek istiyoruz. 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. Bir standart ortaya çıktığında, web geliştiricilerini sorumlu bir şekilde bu standarda geçirmeyi de taahhüt ederiz. |
| Depolama Konumu | Gizlilik Jetonları anahtar yapılandırmaları, PrivacyPass Protokolü ile aynı konumda depolanmalıdır. | Kaynak Denemesi sırasında test yapan geliştiriciler, anahtarlarını .well known dizininde değil genel URL'lerde saklama esnekliğini tercih ettiklerini belirttiler. PrivacyPass'teki anahtar taahhüdü biçimi, anahtar setlerinin dolaylı bir "herkese açık meta veri" değerine izin vermesi amaçlanan sürümler için özellikle uygun değildir. Bir PrivacyPass varyantı herkese açık meta verilerle (POPRF, kısmi RSA gizleme 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 standart hâle geldikçe ve bu API'nin ekosistem kullanımı olgunlaştıkça, bu API'nin hem standart başlık olmayan sürümünü destekleyebiliriz hem de kullanım yeterince düşükse veya sertifika verme/kullanma isteklerini diğer verilerle ilişkilendirmek için yeterli geliştirici araçları/desteği varsa en sonunda başlık sürümünü kullanımdan kaldırabiliriz. Sorunu burada ele alıyoruz. |
| Kayıt | Kartı veren kuruluşların tarayıcı sağlayıcılarına kaydolması pratik mi? | Gizlilik Jetonları için kartı veren kuruluşun kayıt sürecini açıklayacak şekilde spesifikasyonları güncelledik. Kendi sürecini kullansa da Özel Korumalı Alan'ın diğer çalışmaları için kayıt planlarına benzerdir. Bu çalışmalarda, yayıncılardan PST'leri ne şekilde kullanma niyetlerini kamuya açık bir şekilde açıklamalarını ve kullanıcı gizliliğini koruyan teknik kısıtlamaları kabul etmelerini isteriz. |