Bu sayfa, Cloud Translation API ile çevrilmiştir.

Geri Bildirim Raporu - 2024 4. Çeyrek

Privacy Sandbox teklifleri ve Chrome'un yanıtı hakkında alınan ekosistem geri bildirimlerini özetleyen 2024 4. çeyrek için üç aylık rapor.

Google, CMA'ya verdiği taahhütler kapsamında, Özel Korumalı Alan teklifleriyle ilgili paydaş etkileşim süreci hakkında üç ayda bir herkese açık raporlar sunmayı kabul etmiştir (Taahhütler'in 12. ve 17(c)(ii) paragraflarına bakın). Bu Privacy Sandbox geri bildirim özet raporları, Chrome'un geri bildirime genel bakış bölümünde listelenen çeşitli kaynaklardan aldığı geri bildirimler (GitHub sorunları, privacysandbox.com adresinde sunulan geri bildirim formu, sektör paydaşlarıyla yapılan toplantılar ve web standartları forumları dahil ancak bunlarla sınırlı olmamak üzere) toplanarak oluşturulur. Chrome, ekosistemden aldığı geri bildirimleri memnuniyetle karşılar ve edindiği bilgileri tasarım kararlarına entegre etmenin yollarını etkin bir şekilde araştırır.

Geri bildirim temaları, API başına yaygınlığa göre sıralanır. Bu işlem, Chrome ekibinin belirli bir temayla ilgili aldığı geri bildirim miktarının toplanması ve miktara göre azalan düzende düzenlenmesiyle yapılır. Ortak geri bildirim temaları, herkese açık toplantılardaki (W3C, PatCG, IETF) tartışma konuları, doğrudan geri bildirimler, GitHub ve Google'ın şirket içi ekipleri ile herkese açık formlar üzerinden ortaya çıkan sık sorulan sorular incelenerek belirlendi.

Daha ayrıntılı olarak belirtmek gerekirse, web standartları kuruluşları toplantılarının tutanakları incelendi ve doğrudan geri bildirim için Google'ın paydaşlarla bire bir toplantılarının kayıtları, mühendislerin aldığı e-postalar, API posta listesi ve herkese açık geri bildirim formu dikkate alındı. Ardından Google, her API ile ilgili olarak ortaya çıkan temaların göreceli yaygınlığını belirlemek için bu çeşitli tanıtım etkinliklerinde yer alan ekipler arasında koordinasyon sağladı.

Chrome'un geri bildirimlere verdiği yanıtlarla ilgili açıklamalar, yayınlanan SSS'lerden, paydaşların gündeme getirdiği sorunlara verilen gerçek yanıtlardan ve bu herkese açık raporlama çalışması için özel olarak belirlenen bir konumdan geliştirilmiştir. Geliştirme ve testin mevcut odağını yansıtan sorular ve geri bildirimler, özellikle Topics, PA API ve Attribution Reporting API'leri ve teknolojileri hakkında alındı.

Yakın zamanda alınan geri bildirimler henüz Chrome tarafından değerlendirilmemiş olabilir.

Kısaltmalar sözlüğü

ARA: Attribution Reporting API
CHIPS: Bağımsız Bölümlendirme Durumuna Sahip Çerezler
DSP: Talep Tarafı Platformu
FedCM: Federated Credential Management
IAB: Interactive Advertising Bureau
IDP: Kimlik Sağlayıcı
IETF: Internet Mühendisliği Görev Gücü
IP: İnternet Protokolü adresi
openRTB: Gerçek zamanlı teklif verme
uzatma: Origin Deneme Sürümü
PA API: Protected Audience API (eski adıyla FLEDGE)
PatCG: Private Advertising Technology Community Group
RP: Bağlı Taraf
RWS: İlgili Web Sitesi Grupları (eski adıyla Birinci Taraf Gruplar)
SSP: Arz tarafı platformu
UA: Kullanıcı aracısı dizesi
UA-CH: Kullanıcı Aracısı İstemci İpuçları
W3C: World Wide Web Consortium
WIPB: İstençli IP Körlüğü

Belirli bir API/Teknoloji ile ilgili olmayan genel geri bildirimler

Geri Bildirim Teması	Özet	Chrome Yanıtı
Taahhütler	Taahhütler'in G Bölümü, Özel Korumalı Alan'ın uygulanabilirliği için zorunludur. Google'ın kendi reklamcılık işinin yalnızca korumalı alan teknolojileriyle çalışacağı garanti edilmediğinden, Google'ın teknolojiyi satma olasılığı gibi faydanın giderek azalma riski de artar. Bu tür bir elden çıkarma veya yardımcı programda yapılan bir azaltma, açık web'de gizlilik odaklı adreslenebilirlik için varoluşsal bir tehdit olacaktır.	Taahhütler, Google'ın kendi reklamcılık işinin yalnızca Özel Korumalı Alan teknolojileri üzerinde çalışacağını garanti etmez. Google, üçüncü tarafların kullanabildiği ve kullandığı şekilde, adreslenebilirlik için Özel Korumalı Alan teknolojilerini de kapsayan bir portföy yaklaşımı kullanmayı amaçlamaktadır. Portföy yaklaşımının reklam ekosisteminde yaygın olduğunu biliyoruz. Geliştiricilerin gizliliği korumaya yönelik araçlara ve teknolojilere sahip olmasının önemli olmaya devam ettiğine inanıyoruz. Gizliliği ve işlevselliği daha da iyileştirmek için Özel Korumalı Alan API'lerini kullanıma sunmaya ve bu API'lere yatırım yapmaya devam edeceğiz.
Yönetim	Önerilen yönetim modeli, resmi danışma veya itiraz süreçlerinde hesap verebilirlik için belirli mekanizmalar içermiyor.	Bu doğru değil. Hem (i) karar verme sistemi ve ilişkili yayınlar hem de (ii) itiraz süreci, hesap verebilirlik için belirli mekanizmalar sağlar. Ayrıca, İzleme Mütevelli Heyeti, bu kuruluşların işleyişini ayrıntılı olarak denetler.
Yönetim	Modelin, platformlar arası bir standardın oluşturulması ve sürdürülmesiyle ilgili hükümler içermediğine dair geri bildirim.	Hiçbir yönetim modeli, diğer aktörleri (bu durumda tarayıcıları) bir standardı benimsemeye zorlayamaz. Bu nedenle, standartların platformlar arası olarak benimsenmesini gerektiren bir model önermedik. Google, standartlar forumlarına katılmaya devam edecek. Bu forumlarda, önerilerde bulunma ve önerileri uygulama deneyimini paylaşma süreci yaygın bir etkinliktir.
Yönetim	Danışma süresinin en az 2 ay uzatılması önerilir. Önerilen yönetişim modeli, ekosisteme önerilen değişikliklerin etkilerini analiz etmek için yeterli zaman tanımamaktadır.	Mevcut geri bildirim döngüleri (çok daha uzun) devam edeceğinden, üç haftalık süre belirli bir değişikliğin geri bildirim süresinin tamamı değildir. Danışma süreci, stratejik kararlar için mevcut süreç içinde yeni ve resmi bir geri bildirim penceresi sunar. Bu nedenle, üçüncü taraflar özellik geliştirme sürecinde çeşitli forumlar (GitHub, W3C ve IAB Tech Lab gibi reklam standartları kuruluşları dahil) aracılığıyla geri bildirim vermeye devam edebilecek. Geri bildirim döngülerini bu şekilde yapılandırmak, ekosisteme önerilen bir değişiklikle ilgili görüşlerini analiz etme ve geliştirme sürecinde önemli bir gecikme olmadan paylaşma fırsatı verir.
Yönetim	Gelecekteki yönetim planlarıyla ilgili ayrıntıları isteyin.	Önerilen yönetim modelinin özeti, CMA'nın 2024'ün 2./3. çeyrek raporunda (burada 3-5. sayfalar) yer almaktadır.
İstisna İsteği	İzin veren kullanıcıları için üçüncü taraf çerezlerine (3PC'ler) erişmek üzere istisna isteğinde bulunun.	Belirli veri işleme amaçları için cihaz erişimine ve depolamaya izin vermek, kullanıcının Chrome'daki 3. Taraf Çerezleri ayarını geçersiz kılmak istediğini göstermez. Kullanıcının 3PC ayarlarının site düzeyinde geçersiz kılınmasına izin verilmesi, kötüye kullanım olasılığını önemli ölçüde artıracaktır. Ayrıca Chrome'un, istisna isteğine yol açabilecek tüm sitelerin davranışını denetlemesi mümkün değildir.
Özel Korumalı Alan	Özel Korumalı Alan API'si etkinleştirme oranları için istek.	Bu bilgileri ekosistemle paylaşma planımız yok. Geliştiriciler, Privacy Sandbox API'lerinin kullanılabilirliğini tahmin etmek için kodlarının dağıtıldığı API'leri çağırabilir.
Kaynak denemesi	Kaynak deneme süresini uzatma planı var mı?	Kaynak denemesi 14 Nisan 2025'e kadar uzatıldı.
Özel Korumalı Alan	Özel Korumalı Alan'ın işletmeniz için değerini vurgulayan ve üst düzey yöneticilerin desteğini almanızı sağlayacak kısa ve teknik olmayan bir açıklama isteyin.	Kısa süre önce privacysandbox.com'a buradaki İşletme Kaynakları bölümünü ekleyerek bu bilgileri sağladık.
B modu	Bir tarayıcı "B Modu"ndayken mevcut çerez kabı (1 PC, 3 PC, yerel depolama) kalır mı yoksa silinir mi?	Mevcut çerez kabı silinmez. 3PC'lere birinci taraf bağlamlarında erişmeye devam edebilirsiniz.
Chrome'da 3 PC'ye yönelik güncellenmiş yaklaşım	3PC'ler gelecekte Chrome'dan tamamen kaldırılacak mı?	Kullanıcı tercihine öncelik veren güncellenmiş bir yaklaşım öneriyoruz. Burada belirtildiği gibi, 3. taraf çerezleri desteğini sonlandırmak yerine Chrome'da kullanıcıların web'de gezinme deneyimleri için bilinçli bir seçim yapmalarına olanak tanıyan yeni bir deneyim sunacağız. Kullanıcılar bu seçimi istedikleri zaman değiştirebilir. Bu yeni yolu düzenleyicilerle görüşüyoruz ve kullanıma sunmadan önce sektörle iletişime geçeceğiz.
Chrome Testi	Chrome tarafından desteklenen test etiketlerinin kullanıma devam etmesini talep edin.	Özel Korumalı Alan ekibi, şirketlerin çerez desteğinin sonlandırılmasına ilişkin etiketleri kullanmaya devam etmek istediğinin farkındadır. Etiketlerin kullanılabilirliğini uzatma süreci, kaynak deneme süresini uzatma sürecine benzer. Bu süreç kapsamında, deneme tek seferde yalnızca üç Chrome aşaması için uzatılabilir. Örneğin, Chrome'un çerez desteğinin sonlandırılmasıyla ilgili etiketler için en son Intent to Extend Experiment (I2EE) denemesi, Chrome M130-M132 dahil olmak üzere uzatıldı. Bu sayede, Şubat ayının başlarında yayınlanacak M133 kararlı sürümüne kadar etiketler için destek sağlanır. Diğer uzantılar da aynı süreçten geçeceğinden, güncellemeler için blink-dev e-posta grubunu takip etmenizi öneririz.

Kayıt ve Onay

Bu çeyrekte geri bildirim alınmadı.

Alakalı İçerik ve Reklamlar Gösterme

Konular

Geri Bildirim Teması	Özet	Chrome Yanıtı
Özellikler	Sınıflandırıcı modeli Android (uygulama adına göre) ile Chrome (ana makine adına göre) arasında paylaşılıyor mu?	Hayır, farklı sınıflandırmaları olduğundan ayrı modellerdir.
Topics sınıflandırmasının ayrıntı düzeyi	Konuların, birinci taraf bilgileriyle birlikte kullanılması yararlı olmayacak kadar genel olması.	Topics sınıflandırması, kullanışlılık ile gizlilik arasında denge kurmayı amaçlar. Konuları daha spesifik hale getirecek olası mekanizmaları değerlendirdik ancak güvenlik ve gizlilik gibi endişeler nedeniyle bu mekanizmaları kullanmamaya karar verdik. Reklam teknolojileri, bağlamsal veriler, reklam öğesi verileri ve birinci taraf verileri ile birlikte makine öğrenimi ve gizliliği korumaya yönelik API'lerden alınan gizlilik açısından güvenli sinyaller gibi mevcut tüm araçları birleştirerek en iyi sonuçları elde edebilir. Bu konuda daha fazla bilgiyi burada bulabilirsiniz.
API Kullanımı	Topics API'nin kapsamı düşüktür.	Kapsamın düşük olmasının yaygın nedenleri şunlardır: - Kullanıcı kontrolleri/kapsam dışında kalma - Yayıncı kontrolleri/kapsam dışında kalma - Site uygunluğu (Aşağıdaki sitelerin Topics ile eşleşmesi onaylanmamıştır: güvenli olmayan siteler; WebView; iOS'teki Chrome ve Gizli mod) - Kullanıcı sınırlamaları (18 yaşından küçük veya Gizli modu kullanan Chrome kullanıcıları gözlemlenemez ve Topics atanamaz) - Satıcı gözlemi şartı (arayanın gözleminin ölçeklendirilmesi için yaklaşık 4 haftalık bir süreye izin verilir) - Uygulamanın yakın zamanda yapılması (arayanın gözleminin ölçeklendirilmesi için yaklaşık 4 haftalık bir süreye izin verilir)
API Kullanımı	Ağ sekmesi, gönderilen ve yakalanan bir çağrı olduğunu gösteriyor ancak chrome://topics-internals/, gözlemcinin kaydedildiğini göstermiyor. Bu nedenle Topics API'nin kullanımıyla ilgili bilgi isteğinde bulunuyoruz.	Topics API ile etkileşime geçmek için HTTP üstbilgisi mekanizması kullanıldığında konular Sec-Browsing-Topics istek üstbilgisinde gönderilir ancak yalnızca sunucu Observe-Browsing-Topics: ?1 yanıt üstbilgisini gönderirse gözlemlenir. Bu konu hakkında daha fazla bilgiyi burada bulabilirsiniz.
Chromium'a Katkı	Chrome, masaüstünde Chromium tabanlı diğer tarayıcılarla aynı gözlem ve sıralama bağlamını paylaşır mı? Mobil cihazlarda Android Chrome, Chromium / Uygulama İçi Chromium tabanlı diğer Android tarayıcılarla aynı gözlem ve sıralama bağlamını paylaşır mı?	Chrome, Topics verilerini cihazdaki diğer tarayıcılarla paylaşmaz.
Özellikler	Topics API, bir kullanıcının sayfa görüntülemesinin "konu geçmişi girişi" olarak kabul edilip edilmeyeceğine nasıl karar verir?	Haftalık konular hesaplaması için uygun olmak üzere bir sayfa ziyaretinde "gözlemle" çağrısı (herhangi bir arayandan gelebilir) bulunmalıdır. "Observe" çağrısı olmadan ziyaret, konu geçmişi için dikkate alınmaz.
Güvenlik	Topics API, bir araya gelen kullanıcıların diğer kullanıcıların gözlemlediği konuları görmesini nasıl engeller?	Konuyla ilgili açıklamayı burada bulabilirsiniz.
Sınıflandırma	Topics API'deki ağaç yapısı sınıflandırması her dönemdeki gözlemde nasıl kullanılır?	İlk 5 konu hesaplanırken yalnızca sınıflandırıcı tarafından sağlanan orijinal konular dikkate alınır ve sıralama (i) sayfa ziyaretlerinin sıklığı ve (ii) önceliklendirme puanı (özelliğe bakın) ile belirlenir. En popüler 5 konunun her birinin arayanlar tarafından görüntülenme sayısı hesaplanırken, ana konuyu veya alt konularından herhangi birini görüntüleyen arayanlar dahil edilir.
Özellikler	Yanıtta bulunan% 5 rastgele gürültü ile ilgili ek bilgi isteğinde bulunma	Her dönem için her zaman en çok ilgi gösterilen 5 konu vardır. Tarama geçmişinde 5 konu yoksa 5 konu seçilene kadar konular rastgele seçilir. Bu tür konulara doldurulmuş konular diyoruz. Son birkaç hafta içinde kullanıcıyı ilgili konuyu içeren bir sitede gözlemlemedikçe (API'yi kullanıcı için çağırmadıysa) arayanlara bu rastgele doldurulmuş konulardan biri gösterilmez. API çağrıldığında kullanıcı başına, site başına ve dönem başına bir karma oluşturma işlemi hesaplanır. Bu karma, alakasız veri eklenmiş bir konunun döndürülme olasılığından azsa döndürülecek kullanıcı, site ve dönem başına rastgele konu seçilir. Ancak gürültü eklenmiş konu yalnızca arayan, söz konusu kullanıcı/site/dönem için gürültü eklenmemiş konuyu gözlemlediyse döndürülür (ör. filtrelenmez) (açıklamaya bakın). Bu filtreleme, gözlem kapasitesinden bağımsız olarak, belirli bir arayanın% 5'inde gürültülü konuların döndürülmesini sağlar.
Özellikler	Haftalar arası yinelenen konular nasıl çalışır? API, haftalar arasında bağımsız olarak seçim yapıp mı birleştiriyor?	Her haftanın (dönemin) konuları bağımsız olarak hesaplanır. Her bir dönemde döndürülecek konu, arayan kullanıcının bulunduğu siteye bağlıdır. Belirli bir arayanın farklı dönemlerde aynı konuyu tekrarlayabileceğini dikkate almayız (bu nedenle farklı bir konu seçmeyi düşünmelidir). Ancak bu sorunla ilgili buradan ek geri bildirimlerinizi bekliyoruz.

Protected Audience API

Geri Bildirim Teması	Özet	Chrome Yanıtı
A/B Testi	Burada açıklanan Paylaşılan Depolama çözümü, gecikmeye neden olur ve yüksek bir hata oranına sahiptir (yani trafiğin önemli bir kısmı popülasyon kimliği olmadan sonlandırılır). Düşük entropi kimliği (ör. 3 bit) önemli bir gizlilik etkisi olmadan etkili A/B testi için yeterli olabilir.	Paylaşılan depolama alanı çözümünün geçerli bir yaklaşım olmaya devam ettiğine inanıyoruz. Ancak bu isteği değerlendiriyoruz ve bu özellik sizin için öncelikliyse ek geri bildirimler bekliyoruz.
Raporlama	Özellikle PA API'deki yeni tıklama ve görüntülü reklam raporlamasının 6-8 bit kullanacağı ve diğer PA API raporlamaları için kullanılabilecek kalan bitleri etkili bir şekilde azaltacağı anlaşıldığı için `reportWin()` için ek bit isteğinde bulunun.	Gizlilik endişeleri nedeniyle artık modelingSignals bitlerini mevcut 12 bitin üzerine çıkarmayı düşünmüyoruz. Ekosistemi, Özel Korumalı Alan tarafından bitler üzerinde uygulanan bir sınırlama olmadan güvenli bir ortamda makine öğrenimi eğitim ihtiyaçlarını desteklemeyi amaçlayan Gizli Model Eğitimi önerimiz hakkında geri bildirim vermeye davet ediyoruz.
İlgi Alanı Grupları	İlgi alanı grupları (IG'ler) için 90 günlük yaşam döngüsü isteğinde bulunun. 30 gün yeterli değildir.	Blog yayınımızda da belirttiğimiz gibi, Instagram'daki hikayelerin süresini 90 güne çıkarmayı planlıyoruz. Bu konuyla ilgili açıklamaları burada bulabilirsiniz. Şu anda uygulama üzerinde çalışıyoruz. Özellik kullanıma sunulduğunda lansman zaman çizelgesini paylaşacağız.
İlgi Alanı Grupları	IG yetkilendirmesi için dinamik güncelleme isteğinde bulunma.	Çeşitli paydaşlardan gelen bu talebin farkındayız ve bir çözüm üzerinde çalışıyoruz. Gelişmeler yaşandıkça GitHub'da güncellemeler paylaşacağız ve ekosistemden ek geri bildirimler almaktan memnuniyet duyarız.
Cihaz üzerinde	Cihaz üzerinde PA API çözümlerine yatırım yapmaya devam etmek için ekosisteme daha fazla değer sunun.	Özel Korumalı Alan ekibi, geliştiricilere tarayıcıda daha fazla gizliliği korumaya yönelik seçenek sunmak için PA API dahil olmak üzere Gizliliği Geliştiren Teknoloji (PET) tabanlı API'ler geliştirmeye devam ediyor. Bu teknolojiler artık genel olarak Chrome tarayıcılarında büyük ölçekte kullanılabilir (bazı geliştiricilerin yanlış anladığı gibi yalnızca% 1'inde değil). Kullanıcılar 3. taraf çerezleri etkinleştirsin veya etmesin, geliştiriciler, tıpkı birçok şirketin tarayıcı dışındaki diğer PET tabanlı çözümleri kullanmayı tercih ettiği gibi, PET tabanlı çözümleri ürünlerine dahil etmeyi seçebilir. Birçok geliştirici, siteler genelinde daha iyi erişim için belirli birinci taraf kitle sinyallerini genişleterek cihaz üzerinde PA API çözümlerine yatırım yapmaktan zaten yararlanıyor. Bazı geliştiricilerin, daha fazla üçüncü taraf çerezi devre dışı bırakılırsa Özel Korumalı Alan API'lerini veya diğer PET tabanlı çözümleri kullanmayı tercih edeceğini ve bu geliştiricilerin, kaç tarayıcının üçüncü taraf çerezlerini kullanmaya devam edeceğini tahmin etmelerini sağlayacak bilgiler beklediğini biliyoruz. Bu geliştiricilerin, ürün kararları almak için aradıkları bilgileri bulana kadar bekleyeceğinin farkındayız.
İlgi Alanı Grupları	SSP'lerin IG oluşturma sürecinde ve bunlarla ilişkili rollerde yer almasına izin verin. STP'ler, bu özelliği katma değerlerinin önemli bir parçası olarak görür ve yayıncıların STP'leri aracılığıyla IG satmalarına yardımcı olmak ister.	Birden fazla paydaştan daha gelişmiş IG yetkilendirmelerini destekleme isteği aldık ve SSP'lerin bu sürece katkıda bulunan katma değerini görüyoruz. Farklı tarafların kitle genişletme sürecine katılmasına olanak tanıyan en iyi çözümü bulmak için araştırma yapıyoruz. Gelişmeler yaşandıkça GitHub'da güncellemeler paylaşacağız ve ekosistemden ek geri bildirimler almaktan memnuniyet duyarız.
Raporlama	forDebuggingOnly ile Private Aggregation API arasında "sıfır olmayan teklifler" raporlarının sayısında tutarsızlıklar.	İki nedenden dolayı tutarsızlık olmasını bekleriz: İlk olarak, Private Aggregation API hata ayıklama modu yalnızca cihazda 3PC'ye izin verildiğinde kullanılabilirken forDebuggingOnly API her zaman örneklenmemiş olarak kullanılabilir (bu son davranış, burada açıklandığı şekilde zaman içinde değişecektir). İkinci olarak, Özel Toplama API'sinde katkı sınırları vardır ancak forDebuggingOnly'da yoktur. Ancak bu geri bildirim, beklenmedik bir tutarsızlığa başka bir şeyin neden olabileceğini gösteriyor. Bu sorunu çözmek için üçüncü taraf bir paydaşla birlikte çalışıyoruz.
Tıklama oranı	Tıklama sinyali için güncellenmiş öneride belirtildiği gibi, "attributionsrc" özelliği tarafından başlatılan ve uygun olan isteklere yeni bir HTTP yanıt başlığı döndürülerek görüntülemeler ve tıklamalar kaydedilir. Bu yanıt başlığı, diğer hangi tarafların bu görüntülemeleri ve tıklamaları toplu sayılarına dahil edebileceğini belirtmek için kullanılabilecek kaynak listesini içerir. Bu, reklam teknolojisinin kökleri keyfi olarak belirleyebileceği anlamına mı geliyor?	Tıklama oranıyla ilgili açıklama bölümünde, birleştirilmiş görüntüleme ve tıklama sayılarına bir görüntüleme veya tıklama etkinliği katkıda bulunan bir reklam teknolojisinin ("kaynak sağlayan") yanıt başlığında isteğe bağlı bir parametre içerebileceği belirtilmektedir. Bu parametre, "bu etkinliğin, Protected Audience açık artırmalarında `generateBid()` çağrılarına sağlanacak hesaplanmış görüntüleme ve tıklama sayılarına dahil edilebileceği bir veya daha fazla IG sahibi kaynağı" ("uygun kaynaklar") belirtmelerine olanak tanır. Bununla birlikte, bu görüntülemeler ve tıklamalar görüntüleme ve tıklama sayılarına otomatik olarak dahil edilmez. Bunun yerine, her reklam teknolojisi, IG'lerinde görünüm ve tıklama etkinliklerinin dahil edilmesi gereken"kaynak sağlayan" grubunu belirtmelidir. Yalnızca bu kaynak sağlayanlardan gelen veriler, ilgili reklam teknolojisinin `generateBid()` çağrılarına sunulan görüntüleme ve tıklama sayılarına katkıda bulunur. Bu mekanizma için her iki tarafın da anlaşma yapması gerekir ve kötü amaçlı oyuncuların diğer reklam teknolojilerinin görüntüleme ve tıklama sayılarını etkilemesini önler. Bu aynı zamanda, "uygun kaynakları" keyfi olarak ayarlayan bir "sağlayıcı" reklam teknolojisinin, bu uygun kaynaklar IG'lerine bu sağlayıcı kaynağını açıkça ve kasıtlı olarak dahil etmediği sürece bu uygun kaynakların görüntüleme ve tıklama sayılarını etkilemeyeceği anlamına gelir.
Özel Model Eğitimi	DP-SGD (Diferansiyel Gizlilik - Stokastik Gradyan İnişi), geri yayılım sırasında hesaplanan gradanların seyrekliğini yok ettiği için eğitim sürecini önemli ölçüde yavaşlatabilir. Bu sorunu çözmek için düşünülen teknikler veya bu endişeyle ilgili düşünceler var mı?	DP-SGD'de seyrekliği korumak için bazı tekniklerin (ör. bu) farkındayız ve gizli model eğitim altyapısında bu tür teknikleri destekleme konusunda araştırma yapıyoruz. Gelişmeler olduğunda güncellemeler paylaşacağız. Burada ek geri bildirimlerinizi bekliyoruz.
Negatif hedefleme	Burada açıklanan IG negatif filtreleme işlevinin kullanıma sunulması hakkında güncelleme isteğinde bulunun.	Buradaki yanıtımızda da belirttiğimiz gibi, PA API tekliflerinde negatif IG'leri desteklemeyi planlıyoruz. Kullanıma sunma zaman çizelgesini uygun olduğunda paylaşacağız. Burada ek geri bildirimlerinizi bekliyoruz.
Teklif verme	Teklif verirken birden fazla IG'yi birleştirebilir miyim?	Bu işlem şu anda PA API ile mümkün değildir. PA API, IG'nin tek bir sitenin kullanıcı hakkında bildiği bilgilerle ilgili olduğu tasarımını temel alır. Bu tasarım, ekosistem genelindeki tartışmaların merkezinde yer almıştır. Bu yaklaşım, reklam teknolojilerinin reklamverenlerin birinci taraf kitlelerini web'de genişletmesine yardımcı olacak çeşitli çözümler geliştirmesine olanak tanır. Microsoft'ın Ads Selection API teklifinde, kitlelerin sitelerdeki bilgilere dayandığı farklı bir tasarımın önerildiğinin farkındayız. Bu yaklaşımı izlemeye devam edeceğiz. Ancak Chrome'da benzer değişiklikler yapmayı düşünmeden önce gizlilik topluluğu da dahil olmak üzere ekosistemde daha fazla tartışma görmek isteriz.
Doğal reklamlar	PA API'nin doğal reklamların çeşitli biçimlerini ve oluşturma koşullarını yeterli düzeyde destekleyip destekleyemeyeceği ve PA API'nin etkili doğal reklamcılık için gereken reklam öğesi esnekliğine ve optimizasyona izin verip vermediğiyle ilgili endişeler.	Doğal reklamlar için daha fazla destek sunmak üzere aktif olarak araştırma yapıyoruz ve ekosistemden daha fazla geri bildirim almayı bekliyoruz.
Raporlama	Teklif verme komut dosyalarıyla kaynak için rekabet eden ve çalışan açık artırma çerçevesi başka bir sayfaya yönlendirildiğinde kaybolabilecek raporlama komut dosyalarının sağlamlığını iyileştirme isteği.	Yakında GitHub'da bir yanıt yayınlamayı umuyoruz ancak bu endişelerin geçerli raporlamayı önemli ölçüde etkilediğini düşünmüyoruz.
Makro Değişimi	Açık artırma yapılandırması tarafından iletilen makro değiştirmeleri bazı üçüncü taraf yapılandırmalarıyla çalışmıyor.	Temel neden, A/B modu etiketli trafiğin tamamında bu özelliğin etkin olmamasıydı. Kısa süre önce bu özelliği (ve aynı durumdaki diğer özellikleri) tüm A/B modu etiketli trafikte etkinleştirmeye karar verdik. Bu değişikliği 2025'in 1. çeyreğinde yapmayı planlıyoruz. Burada ek geri bildirimlerinizi paylaşabilirsiniz.
Belgeler	`generateBid()` içindeki browserSignals nesnesinde yenilik değeri için ölçü birimi ile ilgili belgelerde tutarsızlık olduğu anlaşıldığı için açıklama talep ediyoruz.	Bu konuyla ilgili daha ayrıntılı yanıtı burada bulabilir ve dokümanlarımızı buna göre güncelleyebilirsiniz. Doğru yanıt, ölçü biriminin milisaniye olmasıdır.
Raporlama	Üçüncü taraf raporlama isteği; DSP'ler ve SSP'ler Chrome'dan gösterim bildirimleri alırken orta katman teknik sağlayıcılar varsayılan olarak almaz.	Şu anda bu özellik isteğini burada tartışıyoruz ve ek geri bildirimler bekliyoruz.
İlgi Alanı Grupları	Paralel IG açık artırma iş akışları kullanılırken interestGroupBuyers öğelerinin dinamik olarak nasıl hariç tutulacağıyla ilgili yardım isteme.	Bu konudaki kılavuzu burada bulabilirsiniz.
Doğal reklamlar	Belirli bir sayfa yüklemesi için bağımsız PA API açık artırmaları, aynı sayfadaki reklamların filtrelenmesini önler.	"Doğal" olarak bilinen ve tek bir birimde birden fazla reklam bulunan öneri widget'ları da dahil olmak üzere daha fazla doğal reklam desteği, aktif bir araştırma alanıdır. Mevcut tasarımın aynı sayfadaki reklam filtrelemeyi destekleyemeyeceğini ve Çitli Çerçeveler gibi diğer korumaların da bunu daha da engelleyebileceğini kabul ediyoruz.
Doğal reklamlar	URL tabanlı sinyallere dayanan reklam öğesi taraması, raporlama gibi mevcut PA API özelliklerinin, doğal reklam öğelerinde kullanılan JSON nesnelerini işlemek için uyarlanması gerekebilir.	Doğal reklamlar için daha fazla destek, aktif bir araştırma alanıdır. PA API'yi doğal reklam oluşturmaya yardımcı olacak şekilde uyarlamanın fizibilitesini değerlendiriyoruz.
Reklam Doğrulaması	PA API'deki üçüncü taraf marka güvenliği, perBuyerSignals'in gecikmesi ve önbelleğe alma sınırlamaları nedeniyle etkilenir. Bu durum dinamik içerik için sorun teşkil eder.	SSP'lerin ve DSP'lerin, önbelleğe alınan verilerin marka güvenliği açısından alakalı kalmasını sağlamak için trafik şekillendirme hedefleri ile marka güvenliği maksimum TTL'lerini dengeleyen, önbelleğe alma için optimum bir TTL belirlemesi gerektiğini biliyoruz. Bu sorunu araştırıyoruz ve gelişmeleri paylaşacağız.
Reklam Doğrulaması	Teklif sonrası marka güvenliği ölçümü yapmak için SSP'ler tarafından FullpageURL makrosu değiştirme işleminin yapılması gerekir.	deprecatedReplaceInURN, SSP'lerin bu sinyali sağlaması için önerilen mevcut yöntemdir.
Reklam Doğrulaması	SSP'lerin teklif sonrası doğrulama için kullandığı makro biçimlerinde standartlaşma eksikliği, veri işleme ve analizde tutarsızlıklara ve hatalara neden olabilir.	STP'ler ve reklam doğrulayıcılar, tutarlılık sağlamak ve veri işleme ve analizde hataları önlemek için STP'ler arasında makro biçimlerinin standartlaştırılmasını sağlamak amacıyla makro kullanımıyla ilgili net yönergeler ve spesifikasyonlar tanımlamak üzere doğrudan işbirliği yapmalıdır. Bu, IAB Tech Lab gibi reklam standartları kuruluşlarının çok uygun olduğu bir etkinliktir.
Reklam Doğrulaması	Reklamverenler ve reklam doğrulayıcılar, hata ayıklama ve sorun giderme için aynı yayıncı bağlamında teklif öncesi ve teklif sonrası kontrolleri bağlayan bir mekanizmaya ihtiyaç duyar.	Teklif sonrası doğrulama için bir seçenek, etkinlik düzeyinde raporlamaya dahil edilen açık artırma ve kampanyaya dayalı sinyallerdir. Bu, teklif öncesi karar günlükleriyle birleştirme yapmanıza olanak tanıyabilir. Bu hedefe ulaşmak için olası kalıpları araştırıyoruz ve gelişmeleri paylaşacağız.
Reklam Doğrulaması	Teklif vermeden önce Güvenilir Anahtar/Değer (TKV) sunucu çözümlerini (DSP'ye ait ve Reklam Doğrulayıcı'ya ait) keşfetme ve teklif vermeden sonra çitle çevrili çerçeve sınırlamalarını ele alma isteği.	Bu talebi değerlendiriyoruz ve teklif öncesi marka güvenliğini destekleyebilecek ve taraflar arasındaki koordinasyon şartlarını kolaylaştırabilecek bir çözüm bulmak için ekosistemden buradan ek geri bildirim almayı bekliyoruz.
Doğal reklamlar	Yerel reklamlar için satıcı tarafı teklif sonrası oluşturma denetimi isteği.	Yerel reklamlar için daha fazla destek sunmak, aktif bir araştırma alanıdır. Bu gibi mevcut özellikleri, yerel reklam oluşturmaya yardımcı olacak şekilde uyarlamayı düşünüyoruz.

Protected Auction (B&A Hizmetleri)

Geri Bildirim Teması	Özet	Chrome Yanıtı
Gecikme	Gecikmeyle ilgili yeterli azaltma yapılmamıştır. B&A Hizmetleri uzun vadede bu sorunu azaltsa da Google, Chrome'daki 3PC'lerde yapılan değişikliklerden önce bu hizmetin yaygın olarak kullanılacağını taahhüt etmemiştir.	Geçtiğimiz birkaç çeyrekte cihaz üzerindeki gecikmede çeşitli iyileştirmeler yaptık. Ayrıca, gerektiğinde B&A hizmetlerini oluşturup ölçeklendiriyoruz. Bu özelliklerden nasıl yararlanacağınız hakkında daha fazla bilgi içeren gecikmeyle ilgili en iyi uygulamalar kılavuzumuzu kısa süre önce güncelledik. Ayrıca, gecikmeyle ilgili yeni iyileştirmeler geliştirmeye devam ediyoruz. Bunlardan bazılarını burada görebilirsiniz.
(Önceki çeyreklerde de raporlanmıştır) Açık Artırma Güvenliği	Cihaz üzerinde açık artırmayla oynama girişimlerini önleme/azaltma yaklaşımları hakkında daha fazla açıklama isteğinde bulunma (ör. Google'ın bunu önemli bir risk olarak görüp görmediği dahil).	Yanıtımız önceki çeyreklerden farklı değil: "PA API reklamlarının raporlama mekanizmaları, kullanıcıları bot trafiğinden ayırt etmek için kullanılan bilgileri korur. Ayrıca, alanları dahil etme veya hariç tutmayla ilgili mevcut alan tabanlı teknikler PA API'de kullanılabilir. Bu konu, IAB Tech Lab'in Özel Korumalı Alan raporuna verdiğimiz yanıtta daha ayrıntılı olarak açıklanmıştır."
Şirket İçi Çözümler	Özel bulut desteğinin olmaması ve bu desteği sağlamaya yönelik uzun ve şeffaf olmayan yol haritası nedeniyle en büyük tedarikçilerin Özel Korumalı Alan'ı veya B&A'yı benimsememesiyle ilgili endişeler.	Özel Korumalı Alan hizmetlerinin çalıştığı altyapıları genişletmeye kararlıyız. Kısa süre önce Azure bulutu için destek sunduğumuzu duyurduk ve özel bulutlar için benzer gizlilik ve güvenlik önlemleri sunmaya yönelik olası çözümleri araştırmaya devam ediyoruz. Ekim ayındaki iletişimimizden bu yana, Chrome kullanıcılarının gizliliğini Yerleşik Güvenli Yürütme Ortamı'nda (TEE) korumaya yönelik olası yaklaşımları araştırmaya devam ederek ilerleme kaydettik. Araştırmamızda şu anda ekosistem paydaşlarıyla farklı yaklaşımları doğrulamak istiyoruz. 1. çeyrekte de geri bildirim almaya başlamayı planlıyoruz. Ekosistem geri bildirimleri ve ortak çalışmalar, olası çözümleri hassaslaştırmaya yardımcı olur.
Test	PA API raporlama çözümlerini (gerçek zamanlı raporlama ve özel toplama) test etmek için TEE oluşturmak mümkün mü?	Reklam teknolojileri, toplama hizmeti testinde işlevsel test için özet raporlar oluşturmak amacıyla test verilerini ve yerel test araçlarını kullanabilir. Lütfen buradaki Yerel Test Codelab'ine bakın. TEE'de toplamayı test etmek için reklam teknolojilerinin, yukarıdaki Codelab ön koşullarında belirtildiği gibi kayıt sürecini tamamlaması gerekir. Bu istekle ilgili ek geri bildirimlerinizi buradan bizimle paylaşabilirsiniz.
Fırsat K/V Entegrasyonu	İşletme kullanım alanları için KV'den anlaşmaya dayalı bilgi alma özelliğini talep edin.	Bu özellik isteğini değerlendiriyoruz ve GitHub'da güncelleme yapacağız.
Kazançsız Anlaşma Ölçümü	Bir SSP'nin ne zaman kazanmadığını ve neden kazanmadığını anlamak için sinyal isteme veya bu yeteneği kullanma.	Bu isteği değerlendiriyoruz ve GitHub'da güncel bilgileri paylaşacağız.
Özellik İsteği	Özel Korumalı Alan'dan, bir reklam grubunu ilgili anlaşma kimliği grubuyla eşleştirmeye yardımcı olacak bir sözlük yapısı sağlaması istenir.	Anlaşma kimliklerini depolamayla ilgili olarak IG boyutunu küçültmenin diğer yollarıyla birlikte bu isteği değerlendiriyoruz. GitHub'da güncelleme yapacağız.
Performans	Muhtemelen teklif verme komut dosyası boyutu nedeniyle kaçırılan olası reklam açık artırması fırsatlarını ölçmek için çözümler.	Bu isteği değerlendiriyoruz. Burada ek geri bildirimlerinizi bekliyoruz.
Özellikler	Şu anda B&A, özellikte prevWins'in yerini alan en son alan olan prevWinMs yerine yalnızca prevWins alanını okur.	B&A'nın, önceki kazançlardaki milisaniye cinsinden süreyi `generatebid()`'e iletmemesi doğrudur. Chrome, yükte daha az yükü sağlamak için süreyi saniye cinsinden gönderir. Buradaki çözüm, B&A'nın saniyeleri milisaniyeye dönüştürmesidir. B&A, bunu cihaz üzerinde açık artırmalarla uyumlu hale getirmek için browserSignals'de hem prevWins hem de prevWinsMs sağlar. Web'deki cihaz üzerinde açık artırmalar için bile prevWins ve prevWinsMs'nin aynı değere karşılık geldiğini ve prevWinsMs = prevWins * 1000 olduğunu unutmayın. Sorunu düzeltmeye öncelik veriyoruz.
Belgeler	Satıcı Ön Uç'unun (SFE) nasıl test edileceği dokümanda net bir şekilde belirtilmiyor. Dağıtım tamamlandıktan hemen sonra ek test kılavuzu ve derlemeler için Bazel'in nasıl kullanılacağı hakkında bilgi verilmesi yararlı olur.	Bu codelab, daha geniş ekosistemin SFE'lerini test etmesini kolaylaştırmak için bir kılavuz olarak yayınlanmıştır.
Dağıtım	B&A için önceden derlenmiş ikili dosyalar sunma planı var mı?	B&A için önceden derlenmiş ikili programlar sunmayı düşünüyoruz ancak bununla ilgili kesin bir zaman çizelgemiz yok. O zamana kadar reklam teknolojileri, ikili dosyaları kendileri oluşturabilir ve sağlanan karma oluşturma işlemlerini kullanarak doğrulayabilir.
Dağıtım	Tüm orkestrasyon türleri (sunucu, istemci, karma) desteklenmeli mi yoksa diğerlerinden öncelikli olması gereken bir tür mü var?	Reklam teknolojisinin hangi modları uyguladığıyla ilgili özel bir önerimiz yok. Bu seçim çeşitli faktörlere bağlıdır ancak nihayetinde müşterilerinizin yararına olan seçeneği belirlemeniz gerekir.
Test	B&A derlemesi sırasında başarısız testlerle ilgili açıklama istiyoruz.	Bu durum, testin tutarlı olmamasının bir sonucu olabilir. Reklam teknolojisine, testleri atlamak için tüm `build_and_test_all_in_docker` derleme komutlarında `--no-tests` işaretini kullanmasını önerdik.
Günlükler	GCP'deki günlük gezgininde günlüklerin, test modundayken SFE'yi çalıştıran sanal makine örneğine, üretim modundayken ise sanal makine örneğine neden etiketlenmediği konusunda açıklama istiyoruz.	Tam olarak ne görüldüğüne bağlı olduğundan genelleştirmek zordur ancak genel olarak: - non_prod kaynaklı günlükler muhtemelen bulut sağlayıcı (bu durumda GCP) tarafından yönlendirilen stderr günlükleridir ve GCP etiketi eklemiştir. - Sanal makine tarafından oluşturulan günlükler genellikle sanal makine örneğiyle etiketlenir. İkili kod tarafından oluşturulan günlükler ise GCP tarafından etiketlenmez. - Üretimdeki günlükler, TEE'de Open Telemetry tarafından dışa aktarılır ve farklı etiketlere sahiptir. non_prod ve prod'de kullanılabilen özelliklerle ilgili bazı ayrıntıları burada bulabilirsiniz.
B&A	OTEL günlük kaydı devre dışıyken gizli anahtarlar eksik olduğunda 403 hatası.	Bu sorun, 4.1 sürümü itibarıyla düzeltildi ve dokümanlar buna göre düzenlendi.
B&A	GCP terraform yapılandırması için outputs.tf dosyası eksik olduğunda hata oluşur.	Bu sorun artık düzeltildi.
Test	Test modunda özel anahtar getirilirken hata oluştu.	Bu gibi durumlarda, sunucuların TEST_MODE=true ile çalıştığından emin olun. Ayrıntılı açıklamayı burada bulabilirsiniz.
Yol Haritası	getInterestGroupAdAuctionData'nın birden fazla satıcı kaynağını kabul etmesi ve B&A yükü şifre metnine satıcı kaynağının bir haritasını döndürmesi planlanıyor mu?	Evet, navigator.getInterestGroupAdAuctionData() işlevinin birden fazla satıcıyı kabul etmesine izin verme desteğinin eklenmesi planlanmaktadır.
KV Özellikleri	KV URL'si (trustedScoringSignalsURL) bir promise olarak gönderilebilir mi?	Buradaki açıklamaya bakın.
B&A	Özel açık artırmanın gerçekleşmesi için istemcinin (tarayıcının) hangi özelliklere ihtiyacı olduğunu B&A satıcı tarafına belirtmek üzere yeni bir platform üstbilgisinin oluşturulmasını isteme.	Şu anda bu özellik isteğini burada tartışıyoruz ve ek geri bildirimler bekliyoruz.
Trafik Şekillendirme	Özellikle DSP'ler için B&A sunucularını barındırmanın ek maliyetlerini düşürmeye yönelik öneri.	Şu anda bu teklifi burada tartışıyoruz ve ek geri bildirimlerinizi bekliyoruz.
Bring-Your- Own-Binary	Açıklayıcı metni, tüm ikili dosyaların desteklendiğine dair açık bir ifadeyle güncelleyebilirsiniz.	Bu politika güncellendi. Ayrıntılı bilgi için lütfen bu makaleyi inceleyin.
KV Aramaları	`generateBid()`, tüm Anahtar/Değer (KV) mağaza çağrılarının tamamlanmasını mı yoksa bağımsız olarak mı bekler? KV gruplandırması zamanlamasını nasıl etkiler?	Buradaki açıklamaya bakın.
Performans	Teklif verme komut dosyalarını yeniden kullanma ve komut dosyalarında önbelleğe alma denetimi başlıkları ayarlama hakkında ek doküman isteğinde bulunun.	Dokümanlar buraya eklendi.
Performans	Cihaz üzerindeki açık artırma gecikmesini azaltmak için kaynakları (ör. teklif verme komut dosyaları) eşzamansız olarak yükleme özelliğini değerlendirme ve keşfetme isteğinde bulunun.	Şu anda bu özellik isteğini burada tartışıyoruz ve ek geri bildirimler bekliyoruz.
İzin Günlüğe Kaydetme	CONSENTED_DEBUG_TOKEN ayarlanarak izin günlüğü kullanmaya çalışırken görülen hata için açıklama gerekli.	Bu durumlarda, gizli yöneticide CONSENTED_DEBUG_TOKEN'ın bulunduğundan, ENABLE_OTEL_BASED_LOGGING'in true olarak ayarlandığından ve TELEMETRY_CONFIG'in mode: PROD olarak ayarlandığından emin olun. Buradaki kaynağa atıfta bulunan buradaki açıklamayı inceleyin.
Günlükler	forDebuggingOnly etkinlikleri B&A üzerinden kullanılabilir mi?	B&A için forDebuggingOnly, Nisan 2024'ten beri tek satıcılı açık artırmalarda kullanılabilmektedir. Bu özelliği çok yakında çok satıcılı açık artırmalar için etkinleştirmeyi planlıyoruz.
Worklet Günlükleri	Worklet günlük kaydını ChromeDriver ile uyumlu hale getirme isteği.	Bu isteği değerlendiriyoruz. Burada ek geri bildirimlerinizi bekliyoruz.

Dijital reklamları ölçme

İlişkilendirme raporları (ve diğer API'ler)

Geri Bildirim Teması	Özet	Chrome Yanıtı
Hata Ayıklama Raporları	Chrome'daki 3. taraf çerezlerle ilgili güncellenmiş yaklaşımın ardından ARA hata ayıklama raporları reklam teknolojisi uzmanları tarafından nasıl kullanılabilecek? Reklam teknolojilerinin, 3. taraf çerezleri kullanmaya devam eden ve Özel Korumalı Alan API'lerinin etkin olduğu kullanıcılar için ARA hata ayıklama raporlarına erişmeye devam etmesi gerekir mi?	Reklam teknolojileri, hem 3PC'leri hem de ARA'yı etkinleştirmiş kullanıcılar için çerez tabanlı ve çerezsiz hata ayıklama çözümlerine erişebilir. Çerezler devre dışıyken yalnızca toplu hata ayıklama çözümüne erişebilirler. Hata ayıklama çözümleriyle ilgili daha fazla bilgiyi burada ve burada bulabilirsiniz.
Özellik Algılama	Sunucu tarafında ARA için özellik algılamanın nasıl yapılacağıyla ilgili yardım isteme.	Şu anda ARA özellik desteği, kullanıcı aracısı dizesinde görülen Chrome sürümüne göre belirlenebilir. Bu konuyla ilgili ek ekosistem geri bildirimlerinizi bekliyoruz.
Özellik İsteği	ARA Toplu shared_info özelliğinde kullanılan source_registration_time özelliğinin daha ayrıntılı (ör. bir güne kıyasla bir saat veya bir dakikaya yuvarlanmış) olması ve saat dilimini dikkate alacak şekilde yapılandırılabilir olması (şu anda yalnızca UTC) için istek.	source_registration_time alanının en yakın güne yuvarlanması, reklam teknolojisinin belirli bir kullanıcıyı belirli bir kaynak kaydıyla ilişkilendirmesini azaltmak için kullanılan bir gizlilik mekanizmasıdır. Şu anda source_registration_time, UTC'yi temel alır ve reklam teknolojisi şirketleri, reklam raporlarını bunu hesaba katacak şekilde ayarlayabilir. Bu istekle ilgili ek ekosistem geri bildirimlerinizi buradan bizimle paylaşabilirsiniz.
Özellikler	Özellikle dizi değeriyle birlikte kullanıldığında "trigger_data" ve "priority" özelliklerinin netleştirilmesini talep edin.	Bu alanlar dizi değerlerini kabul etmez. Açıklama bölümündeki köşeli parantezler bir diziyi değil, metnin örnek bir değer değil, açıklama içeren bir yer tutucu olduğunu gösterir. Kare parantez içindeki metinde belirtildiği gibi: - trigger_data bir int-64'tür - priority, imzalı bir int-64'tür Bu alanların hiçbiri dizi değerlerini kabul etmez. Belgeler kafanızı karıştırıyorsa farklı değerler denemek ve hatalarla karşılaşmamak için ARA'da başlık doğrulayıcı aracını da kullanabilirsiniz.
Accelerated Mobile Pages (AMP) Reklam Desteği	ARA, AMP reklamları destekliyor mu?	AMP'yi nasıl destekleyebileceğimizle ilgili önerimizi burada bulabilirsiniz. Ek geri bildirimlerinizi bekliyoruz.
Özellikler	ARA için çok katmanlı yerleşik reklamlarda hangi URL "source-site" olarak kabul edilir?	Üst düzey sitenin URL'si.
(Önceki çeyreklerde de raporlanmıştır) Özellik İsteği	event_report_window minimum değerinin 3.600 saniyeden (1 saat) 1.800 saniyeye (30 dakika) düşürülmesi için istek.	Minimum raporlama aralığını belirlemek için fayda ve gizlilik hususları arasında denge kurulmalıdır. Etkinlik düzeyindeki raporlar için 1 saatlik minimum raporlama aralığı, gizliliği korumak ve belirli türde geçmiş yeniden oluşturma saldırılarını azaltmak için gereklidir. Bu istekle ilgili ek geri bildirimlerinizi buradan bizimle paylaşabilirsiniz.
Gürültü	Verilerin doğru şekilde yorumlanması ve kullanılması için ARA etkinlik düzeyindeki raporlarda gürültünün nasıl uygulandığı hakkında daha derin bir anlayış edinmek.	Daha fazla bilgiyi burada ve burada bulabilirsiniz.
Raporlama	Toplu raporlardaki shared_info artık varsayılan olarak source_registration_time değerini içermez.	Bu durum, API değişikliklerinden kaynaklanmaktadır ve burada daha ayrıntılı olarak açıklanmıştır.
Raporlama	`filtering_id`, chrome://attribution-internals/ kullanıcı arayüzünün "Toplanabilir Raporlar" sekmesinde yer almıyor.	`filtering_id` simgesi, bir satırı tıkladığınızda "Tetikleyici Kayıtları" sekmesi ayrıntılarında görünür ve satırın geçerliliğini onaylamanızı sağlar. Bu metriğin "Toplanabilir Raporlar" sekmesinde gösterilmesinin yararlı olduğunun farkındayız ve bu konuyu burada ele aldık.
İlişkilendirme Kaynağı	İlişkilendirme kaynağının işleyiş şekliyle ilgili açıklama isteğinde bulunun.	Konuyla ilgili açıklamayı burada bulabilirsiniz.
Uygulamadan web'e ilişkilendirme	Kaynakların işletim sistemi mi yoksa web mi olacağından emin olunamayan uygulamalar için rehberlik isteğinde bulunma.	Buradaki bilgilerden yararlanabilirsiniz.

Aggregation Service

Geri Bildirim Teması	Özet	Chrome Yanıtı
Özellik İsteği	AgS için yapılandırılabilir bir zaman aşımı ve/veya uzun süreli çalıştırmalar için iş durumuna dair daha fazla görünürlük isteği.	Uzun süren işlerin izlenmesini destekleyen özellikler üzerinde çalışıyoruz. Bu konuyla ilgili ek ekosistem geri bildirimlerinizi bekliyoruz.
Terraform	Terraform, service_account_token_creator_list ayarlanmamış olsa bile hesap IAM politikasını değiştirmeye çalışıyor.	Geliştiriciler, ekledikleri izinleri yerel modules/adtech_setup/main.tf dosyalarına ekleyebilir.
Doküman İsteği	Toplama hizmetinin durumunun nasıl izleneceğini açıklayan dokümanlar veya bir codelab isteme.	Hizmeti ve iş durumunu izlemek için kullanılabilecek mevcut alarmların açıklaması, coordinator-services-and-shared-libraries deposundaki ilgili operatör terraform dosyalarında (alarms.tf ve monitoring.tf) bulunabilir. Toplama hizmeti işlerini izlemeyle ilgili ek dokümanlar ve rehberlik bilgileri yayınlayacağız.
Ölçeklendirme	Ölçeklendirme sorunlarını nasıl izleyebilirim?	Bu rehberliğin, toplama hizmetinin daha yüksek ölçeğini belgeleyen güncellenmiş bir sürümünü yayınladık. Makine, işin ölçeğini destekleyemediği için şu anda bir hatanın oluştuğunu gösteren doğrudan bir sinyal yok. Dolaylı sinyaller arasında şunlar yer alır: Hata öncesi% 90 bellek tüketimi, sürekli olarak başarısız olan bir iş. Bu tür bir sinyale duyulan ihtiyaçla ilgili ek ekosistem geri bildirimlerini memnuniyetle karşılarız.
Özellikler	AgS rapor gruplarının tipik çalışma süresi nedir?	Lütfen buradaki yönergeleri inceleyin.

Private Aggregation API

Geri Bildirim Teması	Özet	Chrome Yanıtı
Özellik İsteği	2^16 hassasiyetiyle contributeToHistogramOnEvent işlevine kayan değerlerin (negatif olanlar dahil) katkılarına izin verme isteği	Şu anda bu teklifi burada tartışıyoruz ve ek geri bildirimlerinizi bekliyoruz.

Gizli İzlemeyi Sınırlama

Kullanıcı Aracısı Azaltma/Kullanıcı Aracısı İstemci İpuçları

Bu çeyrekte geri bildirim alınmadı.

IP Protection (eski adıyla Gnatcatcher)

Geri Bildirim Teması	Özet	Chrome Yanıtı
Coğrafi konum	IP Koruması coğrafi konum dosyası isteği.	IP'leri IP koruması için yaklaşık konumlarla eşleyen dosyayı buradan indirebilirsiniz. Bu dosyanın düzenli olarak güncellendiğini lütfen unutmayın.

Hemen Çıkma Durumunu İzleme Çözümü

Geri Bildirim Teması	Özet	Chrome Yanıtı
İzin verilenler listesi	Güncellenen konumda artık izin verilenler listesi veya Google'ın karar verme sürecinden bağımsız olacak benzer mekanizmalar ele alınmamaktadır.	Google, hemen çıkma izleme azaltmalarıyla (BTM) ilişkili izin listeleri oluşturmayı planlamamaktadır. Korumalar tüm alanlara eşit şekilde uygulanır.
Uygunluk	ICO'nun gizlilikle ilgili uygunluk konusunda yetkisi olmalıdır.	Uygunluk durumu, BTM'nin uygulanmasıyla ilgili değildir ve Google, BTM'nin uygulanmasında uygunlukla ilgili herhangi bir karar vermez.
Rekabet	Google'ın BTM'yi (veya başka önlemleri) kullanarak PET rakiplerinin işini sonlandırmasına ve ardından bu rakiplerin pazara geri dönüp dönmeyeceğine karar vermesine izin verilebilir. Mevcut itiraz süreci, PET rakiplerinin BTM'yi veya benzer önlemleri geçici olarak kullanmasını engelleyebilir.	Mevcut BTM teklifi, teknik olarak hemen çıkma izlemeyi hedefliyor. Google, benzer teknikler içerebilecek belirli kullanım alanlarını ihlal etmekten kaçınmayı amaçlasa da BTM'den ayrı muafiyet sağlama planı yoktur. Bu nedenle, Google'ın rakiplerin varlığı konusunda takdir yetkisini kullanması sorunu ortaya çıkmaz.

Siteler arası gizlilik sınırlarını güçlendirme

İlişkili Web Sitesi Grupları (eski adıyla Birinci Taraf Gruplar)

Geri Bildirim Teması	Özet	Chrome Yanıtı
(Önceki çeyreklerde de raporlanmıştır) İlgili Web Sitesi Grupları (RWS) Alan Sınırı	Beş ilişkili alanla ilgili mevcut sınır, siteler arası ölçüm kullanım alanlarını karşılayacak kadar yüksek değildir.	Yanıtımız önceki çeyreklerdekine benzer: Şu anda sayısal sınırı artırmayı düşünmüyoruz. Sınır, kullanıcı gizliliğiyle ilgili hususlar, W3C'deki ekosistem paydaşlarından gelen geri bildirimler ve diğer tarayıcılardaki benzer uygulamalar dikkate alınarak belirlenmiştir. Daha fazla bilgi için lütfen blog yayınlarımızı (1, 2) inceleyin. Siteler arası çerez erişimi için sayısal sınırın ötesinde erişim gerektiren kullanım alanlarını incelemenizi ve kimlik kullanım alanları, kimliği doğrulanmış yerleşimler ve reklamcılık kullanım alanları ile ilgili yönergelerimizden yararlanmanızı öneririz. Bu sorunla ilgili buradan ek geri bildirim gönderebilirsiniz.

Fenced Frames API

Geri Bildirim Teması	Özet	Chrome Yanıtı
Doğal reklamlar	Iframe ile yayıncının sayfası arasındaki iletişimdeki sınırlamalar nedeniyle yayıncının stilini devralma sınırlı olduğundan, çitle çevrili çerçevelerde doğal reklam oluşturma zorluklar oluşturur.	Çitli çerçevelerin zorunlu kılınmasının ardından sağlanan destek de dahil olmak üzere yerel reklamlar için daha fazla destek, aktif bir araştırma alanıdır. Bu sorunla ilgili buradan ek geri bildirim gönderebilirsiniz.

Shared Storage API

Geri Bildirim Teması	Özet	Chrome Yanıtı
API Kullanımı	Diğer Privacy Sandbox API'leri çalışırken Shared Storage API bazı cihazlarda kullanılamaz.	Bu davranış, ortak depolama alanı ayırma denemesine katılan kullanıcıların küçük bir alt kümesinde (yaklaşık %1) beklenir. Bu deneysel kurulum, API'lerin farklı senaryolardaki performansını ve benimsenmesini değerlendirmek için kullanılır.
API Kullanımı	Paylaşılan depolama birimine yapılan yazma işlemleri yayıncı kaynağında mı yoksa teklifli sistem komut dosyası kaynağında mı gerçekleşiyor? İlk test, yayıncı kaynağı komut dosyası kaynağından farklı olduğunda yazma işlemi olmadığını gösterdi.	Bu sorun çözüldü ve yalnızca olası bir devtools hatası olması durumunda açık kalacak. Daha fazla ayrıntıyı burada bulabilirsiniz. Paylaşılan Depolama Alanı, `generateBid` çağrısının teklif verme bağlamında alıcı kaynağına yazar. Yayıncı sayfası farklı bir alanda olsa bile yazma işlemi yayıncı kaynağına bağlı değildir.
API Kullanımı	Kötü niyetli kişilerin Paylaşılan Depolama Alanı raporlarını okuyabilmesini önlemek için ne gibi önlemler alınmıştır?	Kötü niyetli bir kullanıcı veya reklam teknolojisi, başka bir reklam teknolojisindeki ortak depolama alanı verilerini okuyamaması için ortak depolama alanı, origin çağrısı yapılarak bölümlenir. Özel toplama raporları, TLS üzerinden doğrudan aynı kaynağa gönderilir. Bu sayede, raporların akışı kesilebilir.

CHIPS

Geri Bildirim Teması	Özet	Chrome Yanıtı
Bölünmüş Çerezler	Özellikle Bölümlendirilmiş özelliği kullanıldığında, Chrome ve Firefox'ta farklı yerel ana makine bağlantı noktalarında çerezler tutarsız bir şekilde ele alınıyor.	Firefox, farklı bağlantı noktalarına sahip localhost'i farklı bölüm anahtarları olarak değerlendirir. Bu davranış güvenlik ilkeleriyle uyumlu olsa da spesifikasyondan ve Chrome'un yaklaşımından farklıdır. Bu konuyu HTML spesifikasyonu tartışmasında diğer tarayıcılarla görüşmeyi planlıyoruz. CHIPS bölüm anahtarında bir değişiklik olursa ekosistemi bilgilendireceğiz. Bu sorunla ilgili ek geri bildirimlerinizi buradan bizimle paylaşabilirsiniz.
Bölünmüş Çerezler	Site Verilerini Silme taslağı, burada atıfta bulunulan önceki tartışmalara aykırı olarak, yayın yapan sitenin bölümünün ötesinde temizlemeye yanlışlıkla izin veriyor.	Bu, standartlar spesifikasyonu belgesindeki bir hatadır ve yakında düzeltmeyi planlıyoruz. Doğru davranış, açıklamanın bu bölümünde belirtilmiştir ve depolama alanı bölümlendirmesi açıklama deposundaki diğer tarayıcılarla uyumlu bir davranıştır. Chrome'un uygulaması zaten doğru şekilde çalışıyor.