Report di feedback - T1 2024

Report trimestrale per il primo trimestre del 2024 che riassume il feedback dell'ecosistema ricevuto sulle proposte di Privacy Sandbox e sulla risposta di Chrome.

Nell'ambito dei suoi impegni nei confronti della CMA, Google ha accettato di fornire pubblicamente report trimestrali sul processo di coinvolgimento degli stakeholder per le sue proposte Privacy Sandbox (fai riferimento ai paragrafi 12 e 17(c)(ii) degli impegni). Questi report di riepilogo dei feedback di Privacy Sandbox vengono generati aggregando i feedback ricevuti da Chrome dalle varie fonti elencate nella panoramica dei feedback, inclusi, a titolo esemplificativo: problemi di GitHub, modulo di feedback reso disponibile su privacysandbox.com, riunioni con gli stakeholder del settore e forum sugli standard web. Chrome apprezza il feedback ricevuto dall'ecosistema e sta attivamente esplorando modi per integrare le nozioni apprese nelle decisioni di progettazione.

I temi di feedback sono classificati in base alla prevalenza per API. Per farlo, puoi aggregare la quantità di feedback ricevuti dal team di Chrome in merito a un determinato tema e organizzarli in ordine decrescente di quantità. I temi di feedback comuni sono stati identificati esaminando gli argomenti di discussione di riunioni pubbliche (W3C, PatCG, IETF), il feedback diretto, GitHub e le domande frequenti che sono state presentate tramite i team interni e i moduli pubblici di Google.

In particolare, sono stati esaminati i verbali delle riunioni degli enti standard web e, per il feedback diretto, sono stati presi in considerazione i record di Google delle riunioni 1:1 con gli stakeholder, le email ricevute dai singoli ingegneri, la mailing list dell'API e il modulo pubblico di feedback. Google ha poi coordinato i team coinvolti in queste varie attività di contatto per determinare la prevalenza relativa dei temi emergenti in relazione a ciascuna API.

Le spiegazioni delle risposte di Chrome ai feedback sono state sviluppate sulla base di domande frequenti pubblicate, risposte effettive a problemi sollevati dagli stakeholder e determinazione di una posizione specifica per le finalità di questa esercitazione di segnalazione pubblica. Per riflettere l'attuale obiettivo di sviluppo e test, sono state ricevute domande e feedback, in particolare in merito alle API Topics, Protected Audience e Attribution Reporting.

I feedback ricevuti dopo la fine del periodo del report corrente potrebbero non avere ancora una risposta di Chrome considerata.

Glossario degli acronimi

ARA

API Attribution Reporting

CHIPS

Cookie con stato partizionato indipendente

DSP

Demand-Side Platform

FedCM

Gestione delle credenziali federate

f/s

Insiemi proprietari

IAB

Ufficio pubblicitario interattivo

IdP

Provider di identità

IETF

Internet Engineering Task Force

interno

Indirizzo Internet Protocol

openRTB

Offerte in tempo reale

TS

Prova dell'origine

API PAT

API Protected Audience (in precedenza FLEDGE)

PatCG

Gruppo della community di tecnologia pubblicitaria privata

RP

Parte coinvolta

RWS

Insiemi di siti web correlati (in precedenza Insiemi proprietari)

SSP

Supply-Side Platform

TEE

Ambiente di esecuzione affidabile

UA

Stringa user agent

UA-CH

Client hint user agent

W3C

World Wide Web Consortium

In fase di elaborazione

Invisibilità involontaria degli IP

Feedback generale, nessuna API o tecnologia specifica

Tema feedback	Riepilogo	Risposta di Chrome
Governance	Interesse a un periodo di commento pubblico per eventuali aggiornamenti sulla governance di Privacy Sandbox.	Siamo aperti a un ragionevole feedback degli stakeholder su eventuali sviluppi significativi relativi a Privacy Sandbox, inclusa la futura governance di Privacy Sandbox.
Test	Fasi di test aggiuntive per 3PCD oltre all'attuale test facilitato da Chrome all'1%.	Non intendiamo offrire test agevolati da Chrome oltre l'attuale 1% del traffico di Chrome attivato dall'inizio di gennaio.
Da web ad app	La verifica 3PCD sui dispositivi mobili non deve avvenire prima di ottenere la completa interoperabilità tra web e app.	Crediamo che sia opportuno supportare l'interoperabilità tra app e web e abbiamo lanciato la misurazione dell'attribuzione web e tra app e stiamo esplorando soluzioni di targeting da web ad app. Tuttavia, non prevediamo di ritardare 3PCD sul web mobile. Non abbiamo un obiettivo di copertura del 100% alla fine della campagna 3PCD. Piuttosto, prevediamo che la compatibilità su Android per la misurazione cross-app e web sia ragionevolmente elevata per 3PCD e aumenterà nel tempo man mano che gli utenti aggiornano i loro smartphone.
Ruolo del browser	Sembra che Chrome stia assumendo il ruolo di ad server o SSP.	Chrome non assume il ruolo di ad server o SSP. Con l'API PA, Chrome fornisce un contenitore per ad server, SSP, DSP e altre tecnologie pubblicitarie per applicare la propria logica di offerta e punteggio.
Indicazioni per i casi d'uso	Indicazioni più chiare su quali casi d'uso saranno supportati dalle API Privacy Sandbox.	All'inizio del progetto Privacy Sandbox, la documentazione per gli sviluppatori era incentrata principalmente sul coinvolgimento degli sviluppatori nei processi di discussione e feedback per tutte le proposte. Questo significava che i contenuti erano generalmente strutturati per comprendere le motivazioni e i concetti alla base del progetto, seguiti da dettagli dei dettagli dei primi test di sviluppo e test di ogni proposta. Si è trattato di un processo efficace per creare una vera collaborazione con l'ecosistema nello sviluppo delle proposte, ma con l'avanzare della disponibilità generale delle API, c'è un nuovo pubblico di sviluppatori che si dedicano principalmente alle API anziché contribuire al loro sviluppo sottostante. Di recente abbiamo aggiornato la navigazione del report Developer.google.com/privacy-sandbox Sandbox su Privacy Sandbox per lo sviluppo simile da parte di IAB Questo approccio alla documentazione basato sui casi d'uso è qualcosa che continueremo in futuro.
Ambiente di sviluppo locale	Come continuiamo a sviluppare e testare il nostro frontend in locale su http://localhost quando il cookie è SameSite=Secure e il backend ha come frontend una CDN?	Stiamo discutendo di questo problema qui e ci piacerebbe ricevere ulteriori feedback dall'ecosistema.
Mitigazione 3PCD	Esiste un modo programmatico per sapere che i 3PC sono bloccati o quando sono attive le euristiche?	In Chrome, sia il rilevamento delle funzionalità che document.hasStorageAccess richiamati in un iframe consentono a uno sviluppatore di sapere se l'origine dell'iframe ha accesso a tre PC.
Test video	Al momento non è possibile testare gli annunci video in Privacy Sandbox.	Chrome ha pubblicato oggi una discussione e una dimostrazione dei diversi modi possibili per realizzare il video con l'API PA (vedi 242 e 254 nel nostro repository delle demo su GitHub). Tieni presente che questi non sono intesi come codice campione che le tecnologie pubblicitarie adotteranno all'ingrosso, ma piuttosto come proof of concept e dimostrazione delle tecniche che potrebbero supportare il rendering video VAST con l'API PA. Nel corso di questa discussione, è stato anche chiaro che sebbene il rendering video sia già possibile oggi, ci sono modifiche che Chrome potrebbe apportare che semplificherebbero l'implementazione con l'API PA. Ad esempio, gli aggiornamenti alla sostituzione delle macro (spiegati qui), che avevamo già intenzione di affrontare in base al feedback sui casi d'uso della sicurezza del brand degli strumenti di verifica degli annunci di terze parti, verrebbero presi in considerazione anche nel caso d'uso dei video, in cui l'acquirente sta cercando le macro del venditore da utilizzare per il rendering. Finora la maggior parte delle discussioni si è concentrata in particolare sul rendering degli annunci video VAST. Il rendering degli annunci nativi potrebbe utilizzare gli stessi approcci ed è sotto molti aspetti più semplice. Il formato nativo sembra attualmente ricevere meno attenzione rispetto ai video, ma questa è solo una questione di priorità del settore dell'ad tech, senza alcuna barriera tecnica all'implementazione.
Misurazione degli annunci non pubblicitari	3PCD può influire sulle soluzioni di misurazione del pubblico non correlate agli annunci.	Le API di misurazione non richiedono che il caso d'uso sia relativo agli annunci. Mentre l' ARA è più specifica per un percorso pubblicitario tipico,l' aggregazione privata è per uso generico. Questi due componenti di base possono essere utilizzati per gestire un'ampia gamma di attività di misurazione.
Creatori di contenuti	Privacy Sandbox è strutturata per incoraggiare i creatori di contenuti a realizzare più contenuti per YouTube e meno sui propri siti.	L'iniziativa Privacy Sandbox è mirata a mantenere privata l'attività delle persone su una rete internet aperta e senza costi. Sappiamo che i publisher fanno affidamento sugli annunci per produrre contenuti e renderli disponibili su larga scala. Gli inserzionisti aiutano gli utenti a scoprire nuovi prodotti o offerte di loro interesse. Le funzionalità di Privacy Sandbox consentono ai siti web di tutti i tipi, inclusi quelli che collaborano con i creator di contenuti, di mostrare agli utenti annunci utili in base alla loro attività con diverse parti, senza rivelare l'identità dell'utente a queste parti.
Spostamenti più chiari	Pianificazioni delle release più chiare e dettagliate per le tecnologie di Privacy Sandbox.	La documentazione dell'API Privacy Sandbox include le pagine relative allo stato e alla disponibilità dell'API. In queste pagine sono elencate le funzionalità future e le relative tempistiche (ad es. API PA o ARA). Un quadro centrale di questi stati è disponibile qui.
Machine learning	I tecnici pubblicitari non sono in grado di addestrare correttamente i modelli di machine learning finché la metrica 3PCD non supera l'1%.	L'espansione del 3PCD a più browser per i test non garantirebbe un maggiore utilizzo delle API, presumibilmente ciò che i tecnici pubblicitari cercano per addestrare ulteriormente i modelli di machine learning. Se l'utilizzo dell'ecosistema in generale non è ciò che le tecnologie pubblicitarie cercano per addestrare ulteriormente i modelli di machine learning, non c'è motivo di espandere il 3PCD, dal momento che una tecnologia pubblicitaria che vuole addestrare modelli per ottenere più traffico può farlo oggi senza aumentare la 3PCD. Questa operazione può essere eseguita senza che Chrome sembri che passi a 3PCD prima della fine dello stato di arresto.
Caso d'uso non supportato	I casi d'uso di DSP self-service non sono attualmente presi in considerazione.	Esistono diverse DSP self-service che forniscono regolarmente feedback pubblici sulle API. Anche diverse DSP che forniscono un regolare feedback pubblico si sono indicate come tester. Inoltre, Chrome sta interagendo attivamente su argomenti tipici delle DSP self-service come video e ad server di terze parti. Di recente, le chiamate settimanali all'API PA hanno trattato questi argomenti.
Prova dell'origine	Richiesta di OT per i siti che desiderano un periodo di adattamento più aggressivo e una copertura di test per 3PCD.	Chrome sta attualmente sviluppando una OT proprietaria, che consentirà alle origini di attivare il comportamento di eliminazione graduale di 3PC. Nelle origini di primo livello che si registrano a questa prova e implementano token verranno bloccati 3 PC come se sul dispositivo dell'utente fosse attivata la protezione dal tracciamento. Questa OT costituirà una preziosa opportunità per i siti di eseguire test più ampi sulle alternative a lungo termine ai 3 PC, prima dell'eventuale eliminazione graduale dei 3 PC prevista dopo la consultazione con la CMA. Stiamo ancora lavorando per finalizzare le tempistiche per il lancio dell'OT.
Report IAB Tech Lab	Feedback su Privacy Sandbox ricevuto dal report di IAB Tech Lab.	Abbiamo risposto in dettaglio al report di IAB Tech Lab qui. Abbiamo inoltre riconosciuto che "il report solleva questioni relative a documentazione frammentata, requisiti commerciali, audit di terze parti, accreditamento di settore, scalabilità, trasparenza e governance futura, su cui collaboreremo con l'ecosistema e aggiorneremo di conseguenza le nostre domande frequenti pubbliche". In precedenza, ci occupiamo della documentazione frammentata. Rispondere ai requisiti commerciali nella sezione "Garanzie dei dati" è disponibile qui e alcuni prodotti Google Ads hanno condiviso i loro approcci. Ci occupiamo dei controlli di terze parti in base alla "Garanzia dell'integrità degli algoritmi" qui. In merito all'accreditamento, ci aspettiamo che questi organismi continuino ad accreditare i prodotti, incluso l'uso delle tecnologie, anziché le tecnologie in sé. Per quanto riguarda la scalabilità, continuiamo a essere aperti ai dati degli sviluppatori che evidenziano problemi. Per quanto riguarda la trasparenza e la governance, continuiamo a sviluppare in pubblico su GitHub e in forum come W3C, interagendo con la CMA nell'ambito degli Impegni.
Accedi con Google	Gli accessi a Google comporterebbero la possibilità per Google di utilizzare dati di accesso di identificazione incrociata in contrasto con gli impegni.	Accedi con Google non consente a Google di utilizzare dati contrari agli impegni.
Compatibilità	Quali sono i piani per il supporto delle API Privacy Sandbox e la compatibilità con le versioni precedenti e future?	Una volta che Chrome lancerà una funzione in disponibilità generale, cerchiamo di mantenere il supporto per tale funzione. Ovviamente non è sempre possibile mantenere la compatibilità con le versioni precedenti e, in questi casi, abbiamo una procedura chiara per il ritiro e la rimozione delle funzionalità esistenti, descritta qui. Ci aspettiamo di continuare ad aggiungere altre funzionalità alle API Privacy Sandbox nel corso del tempo, in risposta al feedback dell'ecosistema sui casi d'uso che potrebbero trarre vantaggio da una migliore assistenza. In questi casi tendiamo a includere una tecnica di rilevamento delle caratteristiche, in modo che una tecnologia pubblicitaria interessata a sperimentare una nuova funzionalità possa chiedere direttamente al browser se la funzionalità è supportata. Questo è meglio che chiedere agli sviluppatori di controllare un determinato numero di versione di Chrome, poiché alcune funzionalità potrebbero non essere implementate contemporaneamente per tutti gli utenti di Chrome. Ad esempio, il nostro lavoro di rilevamento delle funzionalità per l'API PA è disponibile qui.
Implementazione del server	Anziché adottare la propria implementazione, Chrome dovrebbe specificare i comportamenti che devono soddisfare un'implementazione soddisfacente di un server di indicatori attendibili, di un server di aggregazione e di qualsiasi altro componente non richiesto dal browser. Ciò consentirebbe l'innovazione rispettando i limiti della privacy accettabili.	Apprezziamo e accogliamo con favore il desiderio di innovazione da parte di soggetti esterni. Per tutte le API e tutti i servizi, puntiamo a fornire ai tecnici pubblicitari la flessibilità necessaria per implementare le loro funzionalità. Ad esempio, consentiamo alle tecnologie pubblicitarie di utilizzare informazioni aziendali riservate nella progettazione della logica di offerta per le aste. Inoltre, ci affidiamo costantemente al feedback delle tecnologie pubblicitarie e, ove giustificato, lo incorporiamo nei nostri progetti. Per consentire ad altri di eseguire il proprio codice in ambienti di esecuzione attendibili, Privacy Sandbox dovrà rivedere il codice (e le eventuali modifiche) per verificare che soddisfi le garanzie di privacy. Ciò richiederà un impegno significativo da parte del team di Privacy Sandbox. Pertanto, vorremmo capire quali vantaggi desidera ottenere lo stakeholder, ma quali non possiamo ancora raggiungere.
Euristica	Quali sono i piani a lungo termine per l'euristica?	In linea con quanto indicato da altri browser, alla fine intendiamo ritirare queste euristiche man mano che le soluzioni alternative vengono ampiamente utilizzate, soggetta a ulteriori analisi di fattibilità. Lo abbiamo condiviso qui.
Volume di test	Volume di traffico diverso quando si confrontano dimensioni diverse.	L'1% dell'esperimento ha criteri di esclusione che determinano differenze di idoneità per l'esperimento tra gruppi diversi di client Chrome. Ad esempio, l'esperimento esclude gli utenti di Chrome Enterprise, quindi si prevede che la frazione di traffico con le etichette dell'esperimento sarà più elevata nei fine settimana. È normale vedere diverse percentuali di traffico su diverse sezioni di dati (ad esempio dati geografici, data e piattaforma), ed è in linea con quanto osservato nei dati di Chrome.
Riattiva manualmente 3PC	I siti saranno in grado di sapere quanti utenti (%) hanno riattivato manualmente i cookie dopo l'applicazione della verifica 3PCD?	Gli utenti avranno la possibilità di riattivare l'accesso di 3PC a livello di sito tramite l'esclusione dell'utente in caso di interruzione. I 3PC possono anche essere riattivati mediante altre misure, come l'API Storage Access. Esistono misure tecniche, come hasStorageAccess(), che consentono ai siti di rilevare se i 3PC sono attivati o disattivati. Tuttavia, Chrome non offre ai siti web un modo per conoscere i motivi del reintegro.
Protezione antitracciamento	Per quanto tempo sarà disponibile la funzionalità UI Protezione antitracciamento di Chrome?	Si prevede che l'interfaccia utente Protezione antitracciamento nella barra degli indirizzi rimarrà dopo il ritiro dei 3PC.
(Segnalato anche nei trimestri precedenti) Supporto cross-browser	Altri fornitori di browser che adottano le API Privacy Sandbox.	Altri fornitori di browser, quali Apple, Mozilla e Microsoft, partecipano attivamente ai forum pubblici in cui vengono discussi i principi sulla privacy e gli approcci basati sui browser. Siamo incoraggiati dalle discussioni collaborative in forum come la recente riunione annuale del TPAC del W3C e i forum PATCG del W3C in corso, in cui vediamo segnali di convergenza. Ad esempio, Microsoft Edge ha annunciato di recente il suo piano che "punta a massimizzare la compatibilità sintattica" con l'API PA e ARA, offrendo al contempo funzionalità aggiuntive per gli sviluppatori.
Opzione di riserva per incorporamenti incompatibili dopo 3PCD	Fornisci hook API per rilevare se un iframe / incorporamento di terze parti è conforme o meno a 3PCD.	Stiamo discutendo della richiesta qui e ci piacerebbe ricevere ulteriori feedback dall'ecosistema.
Test	Richiesta di flag aggiuntivi nelle istanze gestite di Chrome che disattivano temporaneamente i comportamenti personalizzati.	Stiamo prendendo in considerazione questa richiesta per le istanze gestite di Chrome e accogliamo con favore input aggiuntivi dall'ecosistema, se un flag di questo tipo sarebbe utile.

Registrazione e attestazione

Tema feedback	Riepilogo	Risposta di Chrome
Verifica dell'attestazione	In che modo Google garantirà l'autenticità delle attestazioni?	Tutti i registranti sono tenuti a mantenere attivo il file di attestazione durante l'utilizzo delle API. Google verifica che il file sia corretto e che la sintassi sia corretta, ma non convalida il comportamento dell'ad tech in merito al linguaggio di attestazione.
Procedura di registrazione all'API Private Aggregation	Esiste un modo per controllare lo stato della registrazione all'API Private Aggregation?	Tutti gli iscritti approvati riceveranno una notifica via email dal team di assistenza per la registrazione una volta convalidata la registrazione. Se il registrante ha domande durante la procedura, può contattare il team di assistenza (con cui il registrante verrà contattato al momento dell'invio del modulo di registrazione). Il team di assistenza risponderà alle domande fornite e fornirà eventuali ulteriori indicazioni necessarie.

Mostra contenuti e annunci pertinenti

Argomenti

Tema feedback	Riepilogo	Risposta di Chrome
(Presentato anche nei trimestri precedenti) Sequenza temporale e documentazione della categoria di classificazione	Dovrebbe esserci un meccanismo per far esaminare la classificazione o per garantire almeno una maggiore trasparenza sul modo in cui la modalità di classificazione determina le categorie.	La nostra risposta è invariata rispetto ai trimestri precedenti: "Una classificazione errata dei siti potrebbe rendere l'indicatore Topics leggermente meno utile come indicatore nel complesso, ma i siti specifici classificati in modo errato non subiscono danni più e meno gravi rispetto a tutti gli altri siti. Ciò accade perché le informazioni contestuali di un sito saranno sempre disponibili per le aste del sito stesso, il che fornirebbe informazioni paragonabili all'argomento corretto, anche in caso di classificazione errata. Siamo lieti di ricevere feedback su questo argomento qui."
Google Ad Manager	Google Ad Manager è già incorporato nella maggior parte dei siti e avrà informazioni molto più ampie sugli argomenti degli utenti rispetto ai concorrenti che sono presenti su un numero inferiore di siti.	Il requisito di osservazione ha lo scopo di garantire che l'API Topics non comporti la condivisione dei dati utente con più entità rispetto alle tecnologie che l'API sostituisce (inclusi i 3 PC). Altre soluzioni di settore, come Prebid, funzionano con migliaia di siti e consentono ai partecipanti di mercato di chiamare l'API Topics tramite la propria tecnologia. Inoltre, vale la pena notare che il limite fino a 5 argomenti principali a settimana può avere un effetto di equalizzazione, in quanto i partecipanti al mercato presenti su molti siti che possono essere in grado di imparare più di 5 argomenti equivalenti utilizzando 3PC sarà limitato a 5.
(Presentato anche nei trimestri precedenti) Utilità per diversi tipi di stakeholder	Preoccupazioni sul valore creato e sulla distribuzione di tale valore per i siti in base al livello di traffico o alla specializzazione dei contenuti.	Sappiamo che i siti specializzati hanno maggiori probabilità di contribuire con argomenti più granulari rispetto ai domini di interesse generale. Tuttavia, non tutti i siti specializzati contribuiscono con argomenti di valore commerciale. Inoltre, questa dinamica riflette lo status quo ed è completamente indipendente dalla fine del supporto per 3PC in Chrome. Inoltre, nell'ambiente attuale, alcuni siti forniscono più valore di altri nei sistemi di pertinenza degli annunci basati su 3PC. Inoltre, gli argomenti tra siti specializzati possono essere reciprocamente vantaggiosi poiché inserzionisti diversi possono pubblicare campagne su insiemi diversi di argomenti e la logica di offerta può osservare il valore in una vasta gamma di argomenti.
Nomi host e URL completi	La classificazione è sufficientemente efficace in base ai nomi host dei siti web e riduce il rischio per la privacy rispetto agli URL completi?	Abbiamo preso in considerazione l'utilizzo di URL di informazioni o titoli di pagine oltre ai nomi host e abbiamo stabilito che i potenziali vantaggi sarebbero stati superati dai rischi per la privacy e la sicurezza degli utenti. Un esempio di rischi per la privacy degli utenti è la classificazione negli argomenti di un utente delle informazioni sensibili incluse nell'URL o nel titolo della pagina.
Argomenti come indicatore	Richiedi indicazioni su come combinare gli argomenti con altri indicatori e quali altri indicatori potrebbero essere utili.	Le soluzioni di tecnologia pubblicitaria possono sbloccare i risultati migliori combinando tutti gli strumenti disponibili, come il machine learning e gli indicatori nel rispetto della privacy provenienti da API incentrate sulla tutela della privacy, insieme a dati contestuali, dati delle creatività e dati proprietari. Ulteriori indicazioni in merito sono disponibili qui.

API Protected Audience (in precedenza FLEDGE)

Tema feedback	Riepilogo	Risposta di Chrome
Testa volume di traffico	I tester stanno segnalando un volume ridotto di risposte all'offerta per l'asta dell'API PA.	1. La densità dell'offerta è correlata alla partecipazione dell'ecosistema nell'API PA, che prevediamo continuerà ad aumentare nel corso del 2024 e oltre. Spetta in ultima analisi agli inserzionisti, alle loro agenzie e ai loro fornitori di tecnologia determinare come distribuire i budget delle campagne. Prevediamo che alcuni partecipanti all'ecosistema possano ritardare il loro investimento in varie soluzioni "senza cookie", tra cui l'API PA, fino a dopo 3PCD. A quel punto, prevediamo che possa aumentare l'allocazione del budget della campagna a queste soluzioni. 2. Il volume delle richieste di offerta nelle aste dell'API PA potrebbe essere influenzato dal (1) del fatto che i publisher e i loro fornitori di tecnologia pubblicitaria potrebbero decidere di non avviare aste dell'API PA se ritengono che la domanda sia bassa. Spetta ai publisher stabilire la priorità di aggiornare le proprie pagine e partecipare. Prevediamo che i publisher possano impiegare del tempo per testare e aumentare gradualmente il traffico per questi motivi. Questo rapporto include anche una risposta di Google Ad Manager in merito ai controlli dei publisher per la partecipazione all'API PA.
(Segnalato anche nei trimestri precedenti) Attività fraudolenta / abuso	In che modo l'ecosistema può ridurre i rischi e impedire a utenti malintenzionati o acquirenti di posizionarsi come pubblico desiderabile?	I meccanismi di segnalazione degli annunci API PA conservano le informazioni utilizzate per distinguere gli esseri umani dal traffico di bot odierni. Inoltre, nell'API PA è possibile utilizzare le attuali tecniche di inclusione o esclusione di domini basate sul dominio. Questo aspetto è descritto più dettagliatamente nella nostra risposta al report di IAB Tech Lab su Privacy Sandbox.
Limitazione della stessa origine sull'URL del proprietario di IG e della logica di offerta	Con il requisito della stessa origine, gli endpoint per un proprietario di IG dovranno passare attraverso lo stesso bilanciatore del carico, il che potrebbe comportare il rifiuto dei reindirizzamenti.	Il requisito della stessa origine per il caricamento degli script è un aspetto di protezione importante. Qui sono disponibili alcuni dettagli su una soluzione proposta che bilancia il feedback dell'ecosistema e altre considerazioni.
Asta privata multi-slot	C'è moltissimo margine per consentire le aste private multi-slot entro i limiti della privacy utilizzando il rumore e una maggiore integrazione con le prassi attuali degli annunci.	Stiamo prendendo in considerazione questo feedback e valutando la richiesta di aste multi-tag in base alla maggiore complessità e ai rischi per la privacy associati a questa funzionalità. Abbiamo discusso ulteriormente di questo problema durante una chiamata al WiCG (Web Incubator Community Group) dell'API PA qui.
Venditori di primo livello	L'attuale struttura dell'API PA fornisce a qualsiasi venditore di alto livello una quantità notevolmente maggiore di dati e di comprensione del valore relativo delle impressioni rispetto ai publisher o ai venditori di componenti.	In un'asta multi-venditore, ogni venditore farà l'offerta migliore. Inoltre, dall'ecosistema abbiamo appreso che i publisher potrebbero voler prendere in considerazione la domanda venduta direttamente accanto alle migliori offerte di ciascun venditore con cui collaborano. Per determinare quale annuncio pubblicare, è necessario esaminare tutte queste potenziali opportunità di monetizzazione. Questa situazione, in cui è necessario che alcuni attori visualizzino il set completo di opzioni per poter scegliere un annuncio da pubblicare, sono precedenti all'API PA. L'API PA mira a supportare le aste multi-venditore e il desiderio dei publisher di considerare l'offerta migliore di ciascun venditore accanto alle campagne pubblicitarie di vendita diretta, laddove quest'ultima è applicabile. Ciò significa che deve esistere un meccanismo per scegliere tra queste opportunità di monetizzazione come accade oggi. Non ritenevamo che debba essere il ruolo del browser selezionare l'annuncio da pubblicare. Pertanto, il concetto di venditore di alto livello è necessario per scegliere un annuncio vincente tra le numerose possibilità. La logica del venditore di alto livello deve essere in grado di considerare le migliori offerte di ciascun venditore con cui il publisher sceglie di collaborare. Inoltre, la logica del venditore potrebbe scegliere di fornire informazioni sulle campagne vendute direttamente del publisher, se disponibili. Tutte queste informazioni possono essere prese in considerazione nella logica di selezione degli annunci di primo livello. Ciò significa che la logica di primo livello vede le migliori offerte dell'asta dell'API PA e, ove applicabile, le eventuali opzioni di annunci venduti direttamente dal publisher per determinare un vincitore. In questo report, Google Ad Manager descrive in dettaglio la sua implementazione dell'API PA come venditore di primo livello in questo report sotto il tema "Accesso alle informazioni".
Separazione degli annunci della concorrenza	Richiesta di separazione degli annunci concorrenziali, ad esempio per impedire che gli annunci di brand concorrenti vengano visualizzati uno accanto all'altro.	Non conosciamo un modo per garantire la separazione competitiva nell'attuale ecosistema pubblicitario digitale multi-venditore, programmatico e con offerte. Tuttavia, l'API PA consente ai venditori di recuperare ulteriori indicatori in tempo reale basati su una combinazione di renderingURL e nome host (che rappresenta il dominio del publisher) che può essere utilizzata durante scoreAd() per assegnare un punteggio alle creatività. Questo campo può essere utilizzato dai venditori per impedire che gli annunci di brand concorrenti vengano visualizzati uno accanto all'altro, supponendo che il publisher voglia applicare questa regola.
Informazioni limitate	L'API PA riduce le informazioni disponibili per i publisher quali valore dell'annuncio, nome dell'acquirente del componente, nome dell'inserzionista, URL pagina di destinazione, dimensioni della creatività, tempo di risposta e tasso di offerta, nonché la perdita di offerte.	Abbiamo proposto alcune potenziali soluzioni qui e ci piacerebbe ricevere ulteriori feedback dall'ecosistema.
Report a livello di evento	I publisher non sono in grado di ottenere informazioni sufficienti sull'annuncio pubblicato dopo il ritiro dell'API PA report a livello di evento.	Siamo consapevoli dei diversi casi d'uso dei report che dobbiamo continuare a supportare quando i report a livello di evento verranno ritirati. Per questo motivo, abbiamo previsto che la data di ritiro dei report a livello di evento non sia antecedente al 2026. Nel frattempo, invitiamo a partecipare attivamente, mentre ci affidiamo all'ecosistema per intraprendere percorsi duraturi che potrebbero includere nuove idee per ottenere informazioni con un approccio incentrato sulla tutela della privacy.
Più SSP	Il valore aggiunto derivante dalla presenza di più SSP sarà troppo basso per i publisher.	Non riteniamo che questo sia corretto e ci piacerebbe ricevere ulteriori feedback dall'ecosistema per comprendere la motivazione di questa affermazione.
Attività di selezione	Le attività di selezione non sono possibili con l'API PA.	Abbiamo ricevuto feedback sulla possibilità per i venditori di utilizzare l'API PA per fornire informazioni sul pubblico agli acquirenti sul web (estensione del pubblico Alias). Riteniamo che questo sia possibile fin da oggi, utilizzando la funzionalità di delega dell'AP insieme agli accordi commerciali. Parallelamente, stiamo valutando attivamente se e come poter soddisfare meglio questi tipi di casi d'uso.
Disattivazione acquirente	La disattivazione predefinita dell'acquirente potrebbe causare risultati inferiori per le aste dei componenti.	Che si tratti di definire un'asta PA singolo venditore o multi-venditore, il venditore deve elencare esplicitamente gli acquirenti nel campo InterestGroupBuyers di AssociationConfig. Questo si basa sul feedback dell'ecosistema secondo cui i venditori hanno accordi contrattuali con alcuni acquirenti e non altri, quindi avrebbero bisogno di un controllo esplicito su quali acquirenti includere nell'asta. Saremo lieti di continuare a discutere su GitHub.
Dimensioni annuncio	Impossibile eseguire il pre-filtro in base a adsize e adSlotSize.	Stiamo lavorando per aggiungere questa funzionalità. Ulteriori dettagli sono disponibili qui.
Supporto per il targeting per parole chiave escluse	Un'API per supportare il targeting di parole chiave escluse: mostrare gli annunci solo se un utente non appartiene a una IG.	Questo problema GitHub proponeva un modo alternativo per implementare il targeting per esclusione, in cui il browser indicava direttamente all'ad server quali regole di targeting per esclusione dovrebbero essere in vigore per una determinata richiesta di annuncio. Sebbene questo approccio sembri interessante, tutte le versioni di questa idea che abbiamo esaminato consentono al server di identificare in modo univoco l'utente.
Digital Services Act	In che modo un publisher può utilizzare Fenced Frames ma anche impedire la visualizzazione di risposte contenenti informazioni soggette al Digital Services Act?	Come per ogni nuova tecnologia, ogni azienda è tenuta a garantire che il proprio utilizzo di Privacy Sandbox rispetti la legge; Google non è in grado di fornire consulenza legale ad altri. Per ogni API abbiamo pubblicato un'ampia documentazione tecnica che dovrebbe fornire le basi per effettuare le necessarie valutazioni legali. I Fenced Frames non devono essere utilizzati nell'API PA prima del 2026, il che concede più tempo agli stakeholder per assicurarsi che l'uso di questa tecnologia sia conforme a tutte le normative pertinenti.
Documentazione	La funzione updateAdInterestGroups() è temporanea?	Non abbiamo annunciato alcun piano per il ritiro di updateAdinterestGroup. In futuro, potremmo applicare protezioni della privacy simili a quelle di cui abbiamo parlato pubblicamente per altri meccanismi di aggiornamento IG, ad esempio l'utilizzo di un indirizzo IP anche per un proxy e l'aggiunta di un ritardo prima che si verifichi l'aggiornamento.
Supporto dei metadati e della proprietà logica degli acquirenti per le piattaforme DSP diverse	Richiesta di un modo per agire come proxy per le DSP.	Siamo a conoscenza di questo feedback proveniente da segmenti non DSP e stiamo prendendo in considerazione questa richiesta. Ci auguriamo di ricevere ulteriori feedback dall'ecosistema.
Report	Richiedi di aggiungere una funzionalità di gestore personalizzato per il bucket / il valore di indicatori nei report di aggregazione privata.	Siamo a conoscenza del fatto che questa richiesta di funzionalità è in attesa di ulteriore rilevamento. Saremo felici di ricevere ulteriori feedback dall'ecosistema qui.
Documentazione	Esiste un link in cui è possibile visualizzare tutte le intestazioni delle risposte che devono essere impostate dall'inserzionista e dal dominio del proprietario (delegato)?	Stiamo pianificando aggiornamenti della documentazione per chiarire questo aspetto e ricevere feedback aggiuntivi dall'ecosistema.
Offerte per più torri	Richiesta di spiegazione del flusso di lavoro (addestramento e inferenza) tramite un diagramma di architettura / blocco su come viene previsto l'approccio multi-tower nel contesto dell'API PA.	Grazie per il feedback. Abbiamo alcune presentazioni sull'argomento a partire dalle quali prevediamo di creare ulteriore documentazione.
Targeting per esclusione	Capacità di Privacy Sandbox di proteggere segmenti di pubblico sensibili e minorenni da annunci inappropriati, ad esempio giochi e scommesse.	L'API PA non prende in considerazione i contenuti degli annunci pubblicati. Questo controllo controlla gli sviluppatori di ad tech che utilizzano AP. In generale, il publisher e i suoi fornitori di tecnologia pubblicitaria possono bloccare le creatività degli annunci nelle aste Protected Audience utilizzando le informazioni contestuali provenienti dalla pagina e le serie di regole dei publisher. Ciò rispecchia la nostra comprensione dell'approccio dell'ecosistema a queste sfide oggi. Per gli acquirenti, la funzionalità di targeting basato su orientamento escluso può essere utile anche in alcuni casi d'uso per la conformità.
Progettazione delle API	Google sta respingendo la richiesta e vuole che le tecnologie pubblicitarie utilizzino una funzione di offerta universale, in modo da aumentare la latenza, invece di utilizzare BiddingLogicURL diversi in diversi IG, il che è consentito.	Nel corso delle nostre discussioni sulla latenza delle aste, abbiamo evidenziato che il riutilizzo dello stesso script in tutte le IG di un acquirente avrebbe reso più rapide le offerte per quell'acquirente. Queste informazioni sono descritte in maggiore dettaglio qui, insieme ad altri nostri consigli per migliorare la latenza dell'asta dell'API PA.
Marketing basato sull'account	L'API PA non è un'API pulita per i casi d'uso di marketing basato su account.	Siamo lieti di ricevere feedback dall'ecosistema su casi d'uso specifici che ritengono non possibili e incoraggiamo i partecipanti all'ecosistema a continuare questa discussione tramite il nostro repository GitHub pubblico o chiamate settimanali.
Test A/B	Quando l'API PA viene configurata in GAM per un publisher, al momento deve essere abilitata per tutto l'inventario o per nessuno. Ciò limita la capacità dei publisher di eseguire un test A/B attuabile.	Risposta fornita da Google Ad Manager: I controlli dell'API PA all'interno di Google Ad Manager (GAM) influiscono sulla capacità di GAM di utilizzare l'API, a condizione che l'API sia disponibile per l'uso. Di conseguenza, i publisher possono eseguire test A/B utilizzando la funzionalità dei criteri di autorizzazione di Chrome per disattivare l'uso dell'API su un sottoinsieme di traffico da utilizzare come gruppo di controllo per un test A/B.
Machine learning	I publisher hanno bisogno di un maggiore controllo sull'utilizzo del machine learning proposto da GAM.	Risposta fornita da Google Ad Manager: A gennaio 2024 abbiamo lanciato un controllo che offre ai publisher la possibilità di disattivare il nostro limitatore di machine learning e attivare le aste dell'API PA con venditori non Google su tutto il loro traffico. Puoi trovare ulteriori dettagli su questo controllo nel nostro Centro assistenza.
(Presentato anche nei trimestri precedenti) Aste di primo livello	Possibilità di utilizzare l'ad server del publisher di Google senza concedere anche a GAM il controllo dell'asta di primo livello dell'API PA.	Risposta fornita da Google Ad Manager: Per le ragioni spiegate nel report del terzo trimestre del 2023 di Google, i piani di GAM per l'integrazione dell'API PA non includono il supporto dei publisher che utilizzano GAM come ad server del publisher senza il controllo dell'asta di primo livello.
Accesso alle informazioni	GAM ha accesso a preziose informazioni della concorrenza, tra cui i prezzi contestuali delle aste, gli indicatori forniti dagli acquirenti alle SSP per l'asta dell'API PA e i parametri di configurazione delle SSP.	Risposta fornita da Google Ad Manager: Da anni ci siamo concentrati molto sull'equità nelle aste, con la nostra promessa che nessun prezzo di nessuna delle fonti pubblicitarie non garantite di un publisher, compresi i prezzi degli elementi pubblicitari non garantiti, verrà condiviso con un altro acquirente prima che presenti un'offerta nell'asta, cosa che in seguito abbiamo ribadito nel nostro impegno nei confronti della Competition Authority francese. Per le aste dell'API PA, intendiamo mantenere la nostra promessa e non condividere l'offerta dei partecipanti all'asta con altri partecipanti prima del completamento dell'asta nelle aste multi-venditore. Per essere chiari, non condivideremo il prezzo dell'asta contestuale con nessuna asta componente, inclusa la nostra, come spiegato in questo aggiornamento. Inoltre, nell'ambito della nostra asta, non utilizziamo le informazioni sulle configurazioni delle aste dei componenti, compresi gli indicatori forniti dagli acquirenti alle SSP. In effetti, saremmo lieti di apportare modifiche all'API PA che consentono ai venditori di componenti di specificare le configurazioni delle aste dei componenti in modo offuscato dal venditore di primo livello.
Aste dei componenti	In qualità di asta di primo livello, GAM controllerà quali SSP eseguono aste dei componenti per ogni opportunità di annuncio.	Risposta fornita da Google Ad Manager: In qualità di ad server del publisher, GAM offre un'API leggera per le SSP con cui un publisher potrebbe lavorare per specificare le configurazioni dell'asta dei componenti tramite l'API Tag publisher di Google (GPT). Puoi trovare ulteriori dettagli qui. Se una SSP fornisce una configurazione di asta per i componenti tramite questa API, verrà inclusa nell'elenco delle aste dei componenti per l'opportunità pubblicitaria in questione. GAM non impone alcuna restrizione alle aste dei componenti incluse. Qualsiasi SSP che desideri eseguire un'asta dei componenti potrà farlo, a condizione che il publisher abbia consentito l'esecuzione del codice necessario sulla pagina del publisher.
Aste dei componenti	GAM potrebbe applicare un prezzo minimo specifico e non dichiarato all'offerta vincente dell'asta di ciascun componente.	Risposta fornita da Google Ad Manager: GAM ha mantenuto da anni una forte attenzione all'equità nelle aste. Nell'ambito del mantenimento di un'asta equa e trasparente, non supportiamo i prezzi minimi applicabili solo a specifici segmenti di domanda. Questo è un principio coerente nel nostro prodotto e continuerà a esserlo per le aste dell'API PA.
Ad server di terze parti	Gli ad server di terze parti non avrebbero accesso alla partecipazione di Google all'asta di livello superiore, limitando la sua capacità di trarre vantaggio dalla domanda di SSP di Google nel contesto dell'API PA.	Risposta fornita da Google Ad Manager: Attualmente, GAM supporta il test dell'API PA con più venditori su GAM tramite l'API descritta qui. Al momento, la partecipazione di GAM come asta componente in altre aste di primo livello non è supportata.
(Segnalato anche nei trimestri precedenti) Rendimento delle aste dell'API PA	Report dei tester che le aste dell'API PA hanno un'alta latenza.	Abbiamo ascoltato le preoccupazioni relative alla latenza e questo è il motivo per cui abbiamo sviluppato una serie di funzionalità nell'API PA che consentiranno alle SSP di impostare limiti sulla latenza DSP e apportare miglioramenti che possono ridurre la latenza. Di recente abbiamo aggiornato la nostra guida alle best practice per la latenza, che include maggiori informazioni su come sfruttare queste funzionalità. Stiamo inoltre continuando a sviluppare nuovi miglioramenti della latenza, alcuni dei quali possono essere illustrati qui.
(Segnalato anche nei trimestri precedenti) Rendering video	Supporto per il rendering video utilizzando l'API PA e Fenced Frames.	A gennaio abbiamo pubblicato una demo del funzionamento dei video in-stream in un'asta PA, con ulteriori dettagli sugli approcci alternativi. Vediamo anche i player dell'ecosistema che iniziano a proporre come funziona il rendering video per i partner che si integrano con loro, come le proposte di GAM sulla creazione di URL di rendering compatibili con video o l'intero processo E2E. Inoltre, ascoltiamo i feedback dell'ecosistema sulle modifiche che possiamo fare per aumentare l'adozione e una questa modifica è descritta in dettaglio su GitHub. Rimaniamo attivamente coinvolti nell'ecosistema per identificare qualsiasi altro ostacolo e affrontarlo in modo tempestivo.
(Segnalato anche nei trimestri precedenti) Norme sulla gestione dei dati	Quali sono le norme sulla gestione dei dati per IG / API PA?	Nel design dell'API PA, tutti i dati memorizzati nelle IG o sui contenuti delle IG (i) rimangono sul dispositivo o (ii) vengono elaborati nei servizi di offerte e aste (B&A) in esecuzione all'interno di un Trusted Execution Environment (TEE). In entrambi i casi, i dati non possono essere letti da altre parti o utilizzati in modi diversi dalla generazione delle offerte per l'asta. Alcuni miglioramenti alla privacy esplorati da Chrome prevedono invece l'interazione con un server k-anonymity gestito da Google. Questa interazione è stata progettata con attenzione per evitare la condivisione di informazioni sugli utenti e per essere eseguita in un TEE per garantire la parità di informazioni nell'ecosistema pubblicitario. Google si è impegnata alla CMA a progettare e implementare le proposte di Privacy Sandbox in modo da non distorcere la concorrenza con l'autopreferimento dell'attività di Google e tenere conto dell'impatto sulla concorrenza nella pubblicità digitale e su publisher e inserzionisti. Continuiamo a lavorare a stretto contatto con la CMA per garantire che il nostro lavoro rispetti queste obbligazioni.
(Segnalato anche nei trimestri precedenti) IG lifetime	Richiesta di prolungare la vita delle IG da 30 a 90 giorni.	Un tale cambiamento richiede un'attenta valutazione, che deve valutare i vantaggi per il settore rispetto all'impatto sugli utenti di Chrome e sulle altre parti interessate. Stiamo prendendo in considerazione questa richiesta e accogliamo con favore un feedback aggiuntivo qui.
(Segnalato anche nei trimestri precedenti) modelingSignals	Richiedi un nuovo campo oltre a ModelingSignals che possano solo codificare le informazioni di visualizzazione e di clic.	Abbiamo risposto a questo feedback con una contronotifica qui. Stiamo collaborando attivamente con il settore per comprendere il loro punto di vista sulla nostra proposta e al momento stiamo valutando i vantaggi per il settore rispetto all'impatto sugli utenti di Chrome e su altri stakeholder.
Bit aggiuntivi in reportWin()	Fornisci in reportWin() bit aggiuntivi rispetto al limite attuale di 12 prima di 3PCD.	Attualmente stiamo esplorando degli approcci a supporto di questo caso d'uso. Ci vuole un po' di tempo anche perché stiamo cercando degli approcci che possano contribuire a garantire un piano sulla privacy a lungo termine.
Struttura dell'asta	Richieste per una singola asta che restituisce URL di rendering con il punteggio corrispondente.	Abbiamo considerato la condivisione di più URL di rendering e il relativo punteggio in un'unica asta PA, ma non abbiamo implementato per motivi di privacy. Comprendiamo il desiderio di evitare di mostrare lo stesso annuncio più volte a un utente su un'unica pagina e accogliamo con favore ulteriori discussioni su GitHub.
reportWin	registra campi arbitrari nella funzione reportWin().	Ciò avviene già oggi durante il periodo di test. Una volta che Chrome avrà terminato di supportare i 3PC, verrà eseguita la migrazione della versione forDebuggingOnly dell'API per attivare il debug sottocampionato, specificato qui.
Venditori di componenti	Disporre di un meccanismo indipendente per conteggiare le proprie impressioni e altri eventi e non dover essere in grado di dipendere esclusivamente dai report degli ad tech.	Questa richiesta di funzionalità è in attesa di ulteriore rilevamento. Non prevediamo di risolvere questo problema durante il periodo di test agevolato da Chrome.
Fatturazione costo per clic	Implementa la fatturazione costo per clic nell'API PA.	Stiamo prendendo in considerazione questa richiesta qui e al momento la consideriamo come una richiesta di suggerimenti su come implementarla con l'attuale piattaforma API.
browserSignals	Aggiungi pendingBidInSellerCurrency alle specifiche di reporting browserSignals per il venditore.	Stiamo prendendo in considerazione questa richiesta e accogliamo con favore un feedback aggiuntivo qui.
Supporto per metadati e proprietà logica lato acquirente per DSP diverse da DSP	L'attuale design dell'API potrebbe portare a un cambiamento significativo nelle campagne di retargeting a livello di prodotto, in cui potrebbe essere necessario eseguire la migrazione delle campagne su piattaforme che fungono sia da DSP che da fornitori di DCO.	Stiamo discutendo di questo problema e saremo lieti di ricevere feedback aggiuntivi qui .
Supporto per metadati e proprietà logica lato acquirente per DSP diverse da DSP	Condividi esempi in cui la DSP non è il proprietario dell'IG.	Comprendiamo che i non offerenti vorrebbero utilizzare alcune funzionalità di IG, ma non altre. Stiamo valutando attivamente le opzioni per risolvere questi casi d'uso e saremo lieti di ricevere feedback aggiuntivi qui.
Controlli per il timeout	I publisher devono essere in grado di dettare il numero di IG che possono partecipare e il timeout di primo livello / timeout globale.	Siamo consapevoli che desideri migliorare la visibilità e i controlli del timeout tra il venditore di primo livello e quello dei componenti e stiamo prendendo in considerazione questa richiesta.
Più dimensioni annuncio	Supporto dell'API PA per casi d'uso di più dimensioni di annunci.	Stiamo valutando questa richiesta e ci piacerebbe ricevere un feedback aggiuntivo dall'ecosistema.
Documentazione	Esiste un elenco di attributi IG soggetti a k-anon?	Abbiamo risposto a questa domanda qui.
Debug	Miglioramento delle funzionalità di debug per l'API PA.	Riconosciamo l'importanza di strumenti di debug efficaci per gli sviluppatori che lavorano con l'API PA. Ci impegniamo a migliorare l'esperienza degli sviluppatori esplorando modi per integrare meglio il recupero dei file .well-known con gli strumenti per sviluppatori. Il nostro obiettivo è offrire maggiore visibilità e funzionalità per la risoluzione dei problemi all'interno dell'ambiente di sviluppo. Stiamo discutendo di questo problema qui e ci piacerebbe ricevere ulteriori feedback.
Etichette	Le API Privacy Sandbox sono abilitate per tutti gli utenti nelle etichette di trattamento della modalità B?	Le assegnazioni dei gruppi sperimentali di Chrome vengono determinate in modo casuale e indipendenti dalle impostazioni di Chrome configurate dall'utente. Sebbene queste API possano essere disponibili per gli utenti all'interno di gruppi sperimentali specifici (ad es.treatment_1.*), la loro funzionalità può essere modificata o disattivata tramite le impostazioni di Chrome. Gruppo controllo_2 modalità B: l'inclusione in questo gruppo disattiva intrinsecamente le API di misurazione e pertinenza di Privacy Sandbox e questa impostazione non può essere sostituita dall'utente nelle impostazioni di Chrome.
Uso dell'API	La chiamata a reportWin() e il rendering dell'annuncio avvengono in parallelo o uno dopo l'altro?	reportWin() viene chiamato direttamente dopo il completamento di runAdauction(). Allo stesso tempo, il processo di rendering dell'annuncio può iniziare quando il risultato dell'asta viene posizionato all'interno di un iframe o di un frame fence. Dopo che reportWin() ha terminato l'esecuzione e ha iniziato il rendering dell'annuncio, verranno recuperati gli URL forniti a sendReportTo().
(Segnalato anche nei trimestri precedenti) Assistenza ai test A/B	Richiedi assistenza per i test A/B dell'API PA.	Stiamo discutendo di questa richiesta qui e ci piacerebbe ricevere ulteriori feedback.
Modell. di traffico	La proposta di Google di gestire il processo decisionale richiesto tramite il server KV non è utile, in quanto i venditori non sono in grado di interagire con il loro backend, il che rende difficile la modellazione del traffico.	Come discusso nel problema di GitHub, scoprire se una singola DSP ha IG presenti potrebbe avere problemi di fingerprinting degli utenti. Abbiamo suggerito altre alternative al problema e siamo disponibili a ricevere ulteriori suggerimenti.
Modell. di traffico	I meccanismi di memorizzazione nella cache aggiungono un livello significativo di complessità e impediscono alle DSP di conoscere la vera forma di traffico per cui fare offerte.	Il meccanismo di memorizzazione nella cache veniva semplicemente offerto come suggerimento. Il team AdTech può scegliere di utilizzare i suggerimenti più adatti al proprio caso d'uso e sarà felice di discuterne qui.
Etichette	Chrome deve condividere l'etichetta come parametro nelle richieste ai server attendibili dell'acquirente e del venditore.	Questa sembra essere una richiesta ragionevole, in quanto sembra essere ampiamente in linea con l'obiettivo di un utilizzo responsabile dei dati IG. Tuttavia, stiamo valutando la richiesta, soggetta a revisione interna, e forniremo aggiornamenti pubblici sull'argomento man mano che le discussioni progrediscono.
Uso dell'API	Chiarimento della definizione esplicita del gruppo "control_1" nel documento "Ulteriori linee guida CMA a terze parti in merito ai test". In particolare, si teme che una modifica nella formulazione possa essere interpretata erroneamente come richiesta dell'esclusione di tutte le API Privacy Sandbox dal controllo_1.	Abbiamo espresso le nostre opinioni in merito in questo thread GitHub. Detto questo, non siamo nella posizione di parlare a nome della CMA e ti suggeriamo di segnalare eventuali problemi relativi all'interpretazione delle linee guida per i test direttamente presso la CMA.
Uso dell'API	Chrome consente di chiamare joinAdinterestGroup() su una pagina vuota durante il reindirizzamento a un'altra risorsa?	Se un utente visita un sito, il proprietario del sito può delegare la possibilità di chiamare joinAdinterestGroup a una terza parte. Questa delega consente a una terza parte di creare IG senza dover aggiungere alcun tipo di reindirizzamento tramite una pagina vuota. Accogliamo con favore il feedback sui motivi specifici per creare IG nel mezzo di un reindirizzamento, invece di usare il meccanismo di delega previsto.
Uso dell'API	Le piattaforme di scambio devono essere in grado di scrivere le IG nelle pagine di proprietà dei publisher con cui collaborano e poi delegare l'autorizzazione a fare offerte per quell'IG a qualsiasi acquirente o DSP specifico.	Abbiamo ricevuto il feedback e stiamo valutando se la richiesta di questo tipo potrebbe essere supportata. Ci auguriamo di ricevere ulteriori feedback dall'ecosistema.
Uso dell'API	Non è presente una notifica di perdita di debug se nessuno vince un'asta dell'API PA.	Le funzioni reportWin e reportResult di Chrome sono progettate per la generazione di report sulle vincite a livello di evento nel sistema delle aste sulla privacy. Nei casi in cui tutte le offerte vengano rifiutate durante un'asta AP, non è previsto che queste funzioni vengano richiamate perché non è determinato alcun vincitore. Un recente aggiornamento a Chrome potrebbe spiegare le discrepanze in cui gli URL trasmessi a forDebuggingOnly.reportAdauctionLoss() non vengono visualizzati nel riquadro Network DevTools. Ti consigliamo di verificare questa funzionalità utilizzando una build del canale Canary o Dev di Chrome.
Uso dell'API	adCost restituito da generateBid può essere negativo (è già arrotondato stocastico a 2 byte)?	AdCost indica il costo di conversione o clic dell'inserzionista passato da generateBid() a reportWin(). Questo valore può essere Null o un doppio. I valori negativi verranno ignorati e non verranno passati. Il valore verrà arrotondato stocastico quando viene passato.
Miglioramento dell'API	È possibile utilizzare i server di esecuzione attendibili e crittografati per gestire targeting / coorti / attribuzione e aste anziché il browser Chrome?	Ti consigliamo di esplorare le opzioni e i componenti basati su TEE nell'API PA (ad es. server KV e servizi B&A), nonché i componenti basati su TEE dei report sull'attribuzione e dell'aggregazione privata (ad es. Aggregation Service) che rispondono a questa domanda.
Miglioramento dell'API	La risposta all'asta di Privacy Sandbox può essere una risposta all'offerta (come le offerte su intestazioni) anziché una risposta di annuncio (come i tag annuncio)?	Questo tipo di cambiamento modifica sostanzialmente le proprietà di privacy dell'API PA, quindi non è un aspetto che stiamo prendendo in considerazione.
Controlli dei publisher	I publisher possono bloccare le creatività dell'API PA sulle loro pagine?	Chrome propone una proposta per la scansione delle creatività in tempo reale che non è ancora disponibile per i test. Sebbene questa funzionalità non sia ancora disponibile, abbiamo notato che la maggior parte delle SSP ha creato delle soluzioni per farlo.
Uso dell'API	Qual è il limite di dimensioni per perBuyerSignals?	Nella sua forma classica, perBuyerSignals non ha limitazioni intrinseche in termini di dimensioni in Chrome. I vincoli primari prevedono che i dati rimangano seriali su JSON e non provochi un consumo eccessivo di memoria. Tuttavia, tieni presente che perBuyerSignals molto grandi e complessi possono influire negativamente sulle prestazioni. Esiste un metodo alternativo per trasmettere per BuyersSignals tramite directFromSellerSignalsHeaderAdSlot. Questo approccio trasmette perBuyerSignals all'interno di un'intestazione, con un limite di dimensione massimo di 10 kB per l'intera risposta dell'intestazione. Inoltre, i singoli server possono imporre le proprie restrizioni sulla dimensione massima dell'intestazione.
Documentazione	La documentazione sulla chiamata registryAdBeacon da generateBid deve essere modificata.	Abbiamo aggiornato questa documentazione il 17 febbraio.
Uso dell'API	In che modo reportEvent sceglie l'URL di beaconing corretto tra più opzioni registrate?	Ogni asta genera una configurazione distinta, che a sua volta genera una mappa di report distinta. Le singole aste (e i relativi frame risultanti) sono completamente distinte l'una dall'altra e non condividono dati. Il messaggio esplicativo "Report sugli annunci con frame fence" fornisce ulteriori dettagli su questo argomento.
UI di Chrome	Aggiungi un filtro nella scheda "Applicazione -> "Gruppi di interesse" di Chrome DevTools per filtrare i dati in base al proprietario delle IG (o anche in base al nome IG).	Stiamo valutando questa richiesta e ci piacerebbe ricevere ulteriori feedback dall'ecosistema.
Chrome headless	Supporto dell'API PA in Chrome headless.	Alcuni componenti dell'API PA sono collegati a Chrome, ad esempio le chiamate k-anon ai server di Google, che potrebbero non funzionare nel "vecchio" Chrome headless. Riteniamo che questo problema possa essere risolto dalla "nuova" versione di Chrome Headless rilasciata in Chrome 112.
Uso dell'API	Nel caso di report sulla perdita con reportAdauctionLoss, in molti casi osserviamo "topLevelWinnerBid=0". Qual è l'interpretazione?	Il valore topLevelWinnerBid deriva dalla funzione scoreAd() all'interno del componente venditore di primo livello. Questo valore gioca un ruolo importante nel determinare il risultato dell'asta di primo livello. Come spiegato nel testo esplicativo, un valore topLevelWinnerBid pari a zero o un numero negativo indica che l'annuncio corrispondente non è idoneo a vincere l'asta. Questo meccanismo può essere utilizzato, ad esempio, per filtrare gli annunci con targeting basato sul gruppo di interesse che non superano un candidato con targeting contestuale. Mentre un'offerta topLevelWinner con valore zero potrebbe indicare che ha prevalente un'asta contestuale, la specifica dell'API PA riconosce che altri fattori potrebbero contribuire a questo risultato.
Test A/B in modalità	Chiarimento sulle richieste di selezione e disattivazione del traffico in Modalità B e A.	I criteri di inclusione per la Modalità A e per la Modalità B sono gli stessi. L'obiettivo è creare gruppi rappresentativi del normale traffico di Chrome, purché supportino le API Privacy Sandbox e il metodo di etichettatura, poiché alcune configurazioni client non sono compatibili. Ai fini dell'esperimento, è importante confrontare il traffico etichettato con altro traffico etichettato. Gli utenti in modalità B hanno la funzionalità Protezione antitracciamento attivata e, come tali, ricevono una notifica relativa a questa funzionalità.
Miglioramento dell'API	È possibile includere "lifetimeMs" come proprietà diretta nella chiamata joinAdInterestGroup o gestirla come argomento separato?	Stiamo valutando attentamente il feedback della community di sviluppo web in merito alla funzionalità "joinAdInterestGroup" all'interno della proposta API PA. Un punto di discussione chiave si concentra sul metodo ottimale per gestire la durata di IG. Stiamo valutando i vantaggi di un argomento separato per il parametro "lifetimeMs", in quanto promuove flessibilità e adattabilità per potenziali miglioramenti futuri della specifica. Stiamo discutendo di questo problema qui e ci piacerebbe ricevere ulteriori feedback.
Uso dell'API	Potenziale di un aumento dei tassi di falsi negativi nel framework dell'API PA a causa di collisioni con ID browser a bassa entropia.	Il team di Chrome è attivamente coinvolto nel costante perfezionamento del framework dell'API PA. Apprezziamo la discussione relativa ai potenziali tassi di falsi negativi derivanti da collisioni tra ID browser. Stiamo valutando con attenzione questo feedback e ci adopereremo per garantire che le analisi aggiornate riflettano in modo esaustivo tutti i fattori pertinenti. Il nostro impegno è volto a trovare una soluzione che raggiunga i risultati auspicati in termini di privacy mantenendo accuratezza e affidabilità. Stiamo discutendo di questo problema qui e ci piacerebbe ricevere ulteriori feedback.
Uso dell'API	È necessario un identificatore del browser a bassa entropia per impedire ai clienti di inviare ripetutamente richieste di join per lo stesso oggetto in un sistema k-anonymity?	Riconosciamo e apprezziamo la discussione in corso sull'utilizzo degli identificatori del browser nell'implementazione dei sistemi k-anonymity. Comprendiamo le preoccupazioni sollevate sulle potenziali implicazioni per la privacy di questi identificatori. Sebbene la nostra implementazione iniziale utilizzasse un identificatore a bassa entropia come meccanismo anti-abuso, stiamo esplorando attivamente tecniche alternative, come i token di conteggio anonimo, che danno priorità alla privacy dell'utente mantenendo l'integrità del sistema. Ci impegniamo a trovare soluzioni che bilanciano l'utilizzo responsabile dei dati con solide protezioni della privacy e siamo lieti di poter continuare a dialogare con la comunità di ricerca. Ne stiamo discutendo qui e ci piacerebbe ricevere ulteriori feedback.
Uso dell'API	AMP (Accelerated Mobile Pages) supporta l'API PA.	Al momento AMP non supporta l'API PA in modo nativo. Se il supporto di AMP è una priorità assoluta, ci piacerebbe ricevere un ulteriore feedback dall'ecosistema.
Miglioramento dell'API	Valuta la possibilità di rimuovere il tipo dai controlli di k-anonymity.	Stiamo valutando attentamente il feedback sulla potenziale ottimizzazione delle strutture di richieste di k-anonymity. Comprendiamo il suggerimento di consolidare i parametri e potenzialmente unificare i tipi per semplificare il processo. Il nostro obiettivo è garantire efficienza e gestibilità e stiamo valutando tutte le opzioni durante lo sviluppo delle nostre soluzioni per la privacy. Stiamo discutendo di questo problema qui e ci piacerebbe ricevere ulteriori feedback.
UI di Chrome	Richiesta di un meccanismo per consentire agli utenti meno tecnici di visualizzare e gestire facilmente le IG a cui appartengono, inclusi potenziali controlli a livello di sito web per la disattivazione.	Riconosciamo l’importanza di fornire strumenti facili da usare per comprendere e gestire le IG. Abbiamo valutato attentamente vari metodi e abbiamo riscontrato che identificare le IG in base al sito web in cui sono state unite offra il miglior equilibrio tra chiarezza e protezione della privacy. Attualmente, la gestione globale delle IG si trova nelle impostazioni di Chrome. Siamo continuamente alla ricerca di modi per migliorare ulteriormente l'esperienza utente in questo ambito. Stiamo discutendo di questo problema qui e ci piacerebbe ricevere ulteriori feedback.
Sicurezza delle API	L'API PA è vulnerabile alle fughe di privacy attraverso interazioni con gli annunci con creatività, anche nel contesto di Fenced Frames?	Siamo consapevoli del potenziale di fuga di informazioni attraverso interazioni sofisticate con gli annunci. Stiamo studiando attivamente l'interazione tra Fenced Frames, l'API PA e i potenziali vettori d'attacco. Ridurre i rischi per la privacy è una priorità assoluta e ci impegniamo a sviluppare soluzioni solide che bilanciano innovazione e protezione degli utenti. Stiamo discutendo di questo problema qui e ci piacerebbe ricevere ulteriori feedback.
Latenza	Il timeout predefinito di 50 ms per la logica di offerta dell'acquirente è un valore realistico?	Riconosciamo le preoccupazioni sollevate in merito a potenziali incongruenze tra la specifica e le tempistiche delle richieste di rete per la logica di offerta. Stiamo esaminando attivamente le specifiche per verificarne l'accuratezza e stiamo esaminando le impostazioni di timeout predefinite ottimali per bilanciare prestazioni e fattibilità. Stiamo discutendo di questo problema qui e ci piacerebbe ricevere ulteriori feedback.
Documentazione	Potenziale perdita di tempo nella specifica in cui un sito web potrebbe dedurre se un annuncio non ha superato la soglia di k-anonymity, con potenziali implicazioni per il monitoraggio tra siti.	Riconosciamo il problema sollevato riguardo a una potenziale fuga di informazioni. Abbiamo confermato una discrepanza nella specifica e stiamo adottando le misure necessarie per garantire che lo stato di k-anonymity degli annunci venga determinato prima dell'asta al fine di evitare questo tipo di fuga di notizie. Prendiamo molto seriamente queste preoccupazioni e aggiorneremo la specifica di conseguenza. Stiamo discutendo di questo problema qui e ci piacerebbe ricevere ulteriori feedback.
Uso dell'API	Metodi per implementare una lista bloccata SSP all'interno dell'API PA.	Riconosciamo la necessità di meccanismi per gestire le limitazioni degli annunci da parte delle SSP. Incoraggiamo l'esplorazione di soluzioni che danno la priorità alla valutazione sul dispositivo e sfruttano i metadati degli annunci esistenti per proteggere la privacy degli utenti garantendo al contempo la flessibilità. Ci impegniamo a collaborare con gli sviluppatori per identificare gli approcci ottimali all'interno dell'API PA. Stiamo discutendo di questo problema qui e ci piacerebbe ricevere ulteriori feedback.
Uso dell'API	È possibile chiedere al browser di simulare l'API PA in un modo che i siti non sono in grado di rilevare?	Siamo consapevoli che, nella sua forma attuale, la disattivazione dell'API PA potrebbe essere rilevabile dai siti web. Stiamo lavorando attivamente a funzionalità quali le offerte aggiuntive e il targeting per esclusione, oltre al rendering dei frame Fenced, per migliorare la privacy e ci impegniamo a fornire opzioni di disattivazione non rilevabili. Stiamo discutendo di questo problema qui e ci piacerebbe ricevere ulteriori feedback.
Test A/B in modalità	Il traffico dei data center si spaccia per un trattamento 1.1.	Il team di Chrome ha confermato con il team GAM che questo traffico viene ora filtrato dall'esperimento. Stiamo discutendo di questo problema qui e ci piacerebbe ricevere ulteriori feedback.
Uso dell'API	Efficienza ed equità dell'implementazione di InterestGroupBuyers nell'API PA.	Riconosciamo la costante discussione sull'efficienza e la correttezza del campo "interestGroupBuyers" nelle aste dell'API PA. Riconosciamo i compromessi in termini di efficienza, privacy ed equità del mercato. Anche se i venditori devono gestire le relazioni commerciali con gli acquirenti, stiamo valutando nuovi modi per ottimizzare il processo di corrispondenza. Queste possono includere aggiustamenti dinamici basati su dati in tempo reale e modelli ibridi. Continuiamo a impegnarci a trovare soluzioni che danno la priorità alla privacy degli utenti e supportino un ecosistema pubblicitario competitivo. Stiamo discutendo di questo problema qui e ci piacerebbe ricevere ulteriori feedback.
UI di Chrome	Potenziali problemi di memoria e chiarezza dell'interfaccia utente relativi a IG in Chrome.	Comprendiamo le preoccupazioni sollevate sulla visualizzazione di IG in DevTools. Sebbene la visualizzazione corrente rifletta tutti gli eventi IG per il monitoraggio storico, riconosciamo l'importanza di fornire una visibilità più chiara dello stato attuale delle IG memorizzate. Esploreremo le ottimizzazioni e i potenziali miglioramenti dell'interfaccia utente per migliorare le informazioni per gli sviluppatori. Per quanto riguarda la gestione della memoria, l'implementazione di IG è progettata per evitare fughe di memoria, ma monitoriamo e ottimizziamo continuamente l'utilizzo delle risorse. Stiamo discutendo di questo problema qui e ci piacerebbe ricevere ulteriori feedback.
Documentazione	L'autore del post originale riscontra un errore durante il tentativo di utilizzare dimensioni annuncio con nome direttamente nel campo "sizeGroup" della funzione "joinAdInterestGroup". Vuole sapere se si tratta di un comportamento intenzionale.	Sappiamo che è importante semplificare la configurazione degli annunci all'interno della funzione "joinAdInterestGroup". Stiamo lavorando attivamente per risolvere questo limite e prevediamo di attivare questa funzionalità nei prossimi aggiornamenti. Questo miglioramento è in linea con il nostro impegno a fornire agli sviluppatori strumenti flessibili ed efficienti per la gestione degli annunci. Stiamo discutendo di questo problema qui e ci piacerebbe ricevere ulteriori feedback.
Etichetta di test agevolata da Chrome	Richiedi di avere dati diretti sulla Modalità A e B ed etichette esatte in sendReportTo, in modo da poter monitorare l'esperimento in modo coerente.	Stiamo discutendo di questa richiesta qui e ci piacerebbe ricevere ulteriori feedback
Documentazione	Il nome di dominio del venditore è incluso nelle richieste inviate al server attendibile di un venditore a scopo di convalida?	Riconosciamo l'omissione iniziale del parametro del nome host nella documentazione dell'API del server KV Protected Audience. Desideriamo rassicurare gli sviluppatori che il nome di dominio del venditore viene incluso automaticamente nelle richieste inviate al server attendibile del venditore. Questa funzionalità è essenziale per processi di convalida degli annunci efficaci. Abbiamo aggiornato la documentazione per risolvere questo problema e continueremo a dare la priorità a chiarezza e trasparenza per la community degli sviluppatori. Stiamo discutendo di questo problema qui e ci piacerebbe ricevere ulteriori feedback.
Uso dell'API	Potenziali metodi per includere il nome IG nelle chiamate di monitoraggio delle impressioni dell'annuncio ai fini della generazione di report.	Ci impegniamo a trovare il giusto equilibrio tra la necessità di meccanismi di segnalazione efficaci e il principio fondamentale della privacy degli utenti. L'inclusione di nomi IG nel monitoraggio delle impressioni degli annunci è soggetta a misure di salvaguardia del k-anonymity per impedire l'identificazione di individui. Continueremo a esplorare soluzioni di reporting innovative all'interno di questi vincoli relativi alla privacy. Stiamo discutendo di questo problema qui e ci piacerebbe ricevere ulteriori feedback.
Funzionalità API	Richiesta al server attendibile dell'acquirente di ricevere le intestazioni HTTP Client Hints.	Stiamo monitorando questa richiesta di funzionalità qui.
Uso dell'API	Se il file di delega deve richiedere il caricamento dell'intestazione "Access-Control-Allow-Origin" per caricare, dato che stabilisce il comportamento di appartenenza a IG per il browser?	Ci impegniamo ad allinearci alle best practice per la sicurezza web. Il requisito dell'intestazione "Access-Control-Allow-Origin" per i file di delega garantisce la coerenza con i principi CORS e impedisce l'esposizione involontaria di informazioni sensibili. Stiamo valutando dei modi per ottimizzare questo processo mantenendo un livello di sicurezza solido. Stiamo discutendo di questo problema qui e ci piacerebbe ricevere ulteriori feedback.
Uso dell'API	Consente agli ad server di personalizzare le creatività all'interno del framework dell'API PA.	Riconosciamo il ruolo che gli ad server possono svolgere nella personalizzazione delle creatività. Stiamo esplorando attivamente soluzioni per potenziare gli ad server all'interno dell'API PA, come il modello "joint IG" in cui è possibile combinare la logica di offerta e di selezione delle creatività degli annunci. Il nostro obiettivo è trovare un equilibrio tra l'attivazione di solide funzionalità per le creatività degli annunci e la tutela della privacy degli utenti. Accogliamo con entusiasmo ulteriori collaborazioni e feedback sull'evoluzione dell'API per soddisfare le esigenze di tutti gli stakeholder qui.
Preoccupazioni relative alla privacy	Disponibilità di identificatori alternativi (ad es. RampID, ID5) nelle richieste di offerta contestuali potrebbe minare gli obiettivi di privacy dell'API PA facilitando la raccolta dei dati tra siti.	Riconosciamo la potenziale tensione tra gli identificatori tra siti e gli obiettivi di privacy dell'API PA. Sebbene i publisher possano scegliere di condividere questi identificatori, il design dell'API PA mira fondamentalmente a disaccoppiare la selezione degli annunci dalla necessità del monitoraggio tra siti. Ci impegniamo a promuovere un ecosistema pubblicitario incentrato sulla privacy e incoraggiamo gli sviluppatori a dare la priorità all'approccio dell'API PA. Stiamo discutendo di questo problema qui e ci piacerebbe ricevere ulteriori feedback.
Memorizzazione nella cache	Esiste un modo per impedire il riutilizzo degli script di offerta in più aste?	Riconosciamo il comportamento di memorizzazione nella cache osservato per gli script di offerta all'interno del framework dell'API PA. Sebbene siano supportati i meccanismi standard di memorizzazione nella cache HTTP, il potenziale riutilizzo degli script nelle aste esiste a causa del comportamento di sospensione del dispositivo e del design degli esecutori delle offerte. Il team sta studiando soluzioni per fornire agli acquirenti un maggiore controllo sulla memorizzazione nella cache degli script per gestire in modo efficace le strategie di offerta. Stiamo discutendo di questo problema qui e ci piacerebbe ricevere ulteriori feedback.
Uso dell'API	Centralizza i report sull'attività di offerta in tutte le IG per una DSP, rispettando al contempo la privacy degli utenti.	Nella progettazione dell'API PA diamo la priorità alla privacy degli utenti. Sebbene non sia possibile generare report diretti su singoli eventi di offerta a causa dei rischi di monitoraggio tra siti, offriamo meccanismi come l'archiviazione condivisa e l'aggregazione privata. Queste funzionalità consentono alle DSP di ottenere informazioni aggregate sull'attività di offerta, nel rispetto della privacy degli utenti.
Uso dell'API	Il recupero da sendReportTo() in reportResult() avviene solo il 94% delle volte rispetto alla registrazione di un recupero con forDebuggingOnly.reportAdauctionWin().	Anche se potrebbero non avere la stessa tempistica, è possibile che entrambi gli URL vengano recuperati contemporaneamente. In alcuni casi, il worklet del componente del venditore è stato eliminato e deve essere ricaricato per poter eseguire la funzione reportResult(). Tuttavia, né il tempo necessario per recuperare la logica di punteggio né il tempo per il ricaricamento del worklet influiscono sul timeout di 50 ms di reportResult(). Tieni presente che Chrome utilizzerà le intestazioni di memorizzazione nella cache per definire il comportamento di recupero nei casi in cui sia necessario ricaricare il worklet. Per ulteriori informazioni sulle fasi di un'asta PA, fai clic qui.
K-anonimato	La richiesta di conferma che il nome del gruppo di interesse non influisca sul k-anonymity della pubblicazione degli annunci.	Affinché una creatività venga considerata k-anonymous, la tupla dell'URL del proprietario della pagina di destinazione, dell'URL dello script di offerta, dell'URL della creatività e della dimensione dell'annuncio deve raggiungere la soglia specificata (k) in un periodo di tempo passato (w). Lo stato k-anonymity viene aggiornato periodicamente (p).
UI di Chrome	Proposta di fornire il tipo di "visibilità interna" offerta da molti framework MVC, ORM e così via. Ad esempio, inizia con il logging semplice degli eventi interni selezionati in un nuovo riquadro nella sezione Strumenti di sviluppo --> Applicazione --> Applicazione.	Stiamo discutendo della proposta qui e ci piacerebbe ricevere ulteriori feedback.
UI di Chrome	L'unione a IG di Dev Tools non mostra elementi correlati alla priorità.	Abbiamo risolto questo problema qui.
Miglioramento dell'API	È preferibile consentire all'ad server della creatività di monitorare i propri eventi. È possibile configurare un elenco di domini di monitoraggio consentiti?	Abbiamo condiviso una proposta qui e ci piacerebbe ricevere ulteriori feedback dall'ecosistema.
Richiesta di funzionalità API	L'API PA può essere estesa per supportare le transazioni multimediali non RTB e per gestire casi d'uso critici come la pubblicazione di annunci e DCO?	Stiamo discutendo del problema qui e ci piacerebbe ricevere ulteriori feedback.
Timeout asta del publisher	I publisher devono controllare la durata dell'asta per evitare la perdita di impressioni, soprattutto nelle configurazioni di offerte su intestazioni in cui gli annunci vengono selezionati in sequenza.	Riconosciamo l'importanza di fornire ai publisher un controllo granulare sui timeout delle aste degli annunci. Stiamo esplorando attivamente come implementare un meccanismo di timeout globale dell'asta, potenzialmente all'interno dell'oggetto "auctionConfig", considerando con attenzione i casi limite. Questa funzione ha lo scopo di ottimizzare i tassi di riempimento delle impressioni per i publisher e continueremo a collaborare con la community per trovare la soluzione migliore. Stiamo discutendo del problema qui e ci piacerebbe ricevere ulteriori feedback.
Miglioramento dell'API	L'attuale design delle IG nell'API PA porta a metadati di grandi dimensioni a causa di lunghi URL di rendering. I tester vorrebbero un modo per comprimere questi URL per una maggiore efficienza.	Riconosciamo l'importanza dell'ottimizzazione delle dimensioni dei metadati IG, in particolare per le aste degli annunci sensibili all'efficienza. Riteniamo che una soluzione basata su modelli per la compressione degli URL di rendering offra un notevole potenziale. Valuteremo attentamente i design dei modelli proposti e ci assicureremo che qualsiasi soluzione implementata includa solidi meccanismi di prevenzione degli abusi per mantenere la stabilità del browser. Collaborare con la community degli standard web per sviluppare l'approccio ottimale, tenendo a mente queste considerazioni, rimane una priorità. Stiamo discutendo del problema qui e ci piacerebbe ricevere ulteriori feedback.
Uso dell'API	I tester che gestiscono i formati degli annunci nativi vogliono ottimizzare il processo di asta di Privacy Sandbox recuperando più risultati di annunci in una singola chiamata per ridurre il carico sulla rete e migliorare la velocità di rendering degli annunci.	Riconosciamo le preoccupazioni relative al rendimento sollevate per il rendering degli annunci nativi in Privacy Sandbox. Ci impegniamo a trovare un equilibrio tra efficienza e solide protezioni della privacy degli utenti. Anche se la restituzione di più annunci con punteggi completi compromette la privacy, stiamo esplorando attivamente dei modi per ottimizzare la procedura delle aste. Ci impegniamo a migliorare il supporto dell'API PA per i formati di annunci nativi e a esaminare meccanismi alternativi per migliorare l'efficienza rispettando i rigidi vincoli della privacy di Privacy Sandbox. Stiamo discutendo del problema qui e ci piacerebbe ricevere ulteriori feedback.
Uso dell'API	Flessibilità nel modo in cui le offerte per gli annunci vengono valutate e ordinate in Privacy Sandbox, in particolare per rappresentare i livelli di priorità o le regole del marketplace privato.	Comprendiamo la necessità di un controllo granulare sul punteggio e sull'ordinamento degli annunci all'interno di Privacy Sandbox, in particolare in scenari di offerta complessi. Riconosciamo le soluzioni proposte utilizzando tuple e funzioni matematiche per ottenere punteggi multidimensionali senza sacrificare la privacy dell'utente. Anche se questi approcci possono complicare l'esperienza degli sviluppatori, offrono la necessaria espressività. Ci impegniamo a esplorare modi per semplificare questi processi, potenzialmente attraverso funzioni o linee guida helper, al fine di garantire un utilizzo ottimale delle funzionalità di Privacy Sandbox per la logica di asta avanzata. Stiamo discutendo di questo problema qui e ci piacerebbe ricevere ulteriori feedback.
reportEvent()	Aggiungi un nuovo evento riservato (forse il beacon automatico) attivato dal browser dopo l'inizializzazione di un frame con una creatività dell'annuncio.	Stiamo discutendo di questa richiesta qui e ci piacerebbe ricevere ulteriori feedback.
adCost	È consentita la suddivisione di adCost.	Ogni valore di costo offre l'opportunità di inviare una quantità limitata di informazioni dall'asta. Consentire un intero elenco di N di tali costi sarebbe sufficiente per inviare un identificatore utente intero, il che consentirebbe il monitoraggio su più siti. Ne stiamo discutendo qui e ci piacerebbe ricevere un ulteriore feedback.
resolveToConfig	resolveToConfig deve essere ereditato dal livello superiore ed esposto in browserSignals?	Stiamo discutendo di questa richiesta qui e ci piacerebbe ricevere ulteriori feedback.
Strumenti ottimizzati	C'è qualcosa di simile a chrome://topics-internals ma per l'API PA?	Non c'è niente di identico. Tuttavia, esistono molti strumenti per sviluppatori per l'API PA.
Etichette	Chrome può utilizzare le etichette per identificare la popolazione di k-anon del 20%?	Stiamo valutando questa richiesta e ci piacerebbe ricevere un feedback aggiuntivo dall'ecosistema.
Documentazione	I worklet delle aste di Privacy Sandbox diventeranno tipi di worklet standard?	A causa di requisiti specifici di privacy e sicurezza, questi worklet differiscono in modo significativo dai tipi di worklet del browser standard, quindi non prevediamo che presto diventeranno tipi di worklet standard all'interno della specifica HTML. Ci impegniamo a migliorare le nostre risorse per sviluppatori con spiegazioni chiare sull'ambiente di implementazione ed esecuzione dei worklet per le aste, rendendo queste informazioni più accessibili per i partecipanti a Privacy Sandbox. Abbiamo discusso ulteriormente qui.
Server BYOS (Bring-Your-Own-Server)	Le parti potrebbero essere in grado di apprendere più IG (dallo stesso proprietario) uniti da un utente tramite query sui servizi KV in una configurazione di un servizio KV BYOS.	Questo non sarà più possibile quando i server di valori chiave saranno eseguiti nei TEE e possiamo garantire che rispettino il modello di attendibilità pubblicato.
userBiddingSignals	aggiornare parte di "userBiddingSignals" e mantenerne altri.	Ciò è già possibile senza che siano necessarie modifiche all'API.
Uso dell'API	Implementare la quota limite in più IG all'interno di Privacy Sandbox, utilizzando potenzialmente il server KV o modificando i dati "prevWinsMs".	Riconosciamo l'esigenza di funzionalità avanzate di quota limite all'interno di Privacy Sandbox. Siamo consapevoli che le attuali restrizioni alla condivisione dei dati tra le IG possono presentare sfide quando si implementano queste strategie. Sebbene il server KV fornisca un potenziale meccanismo con adeguate salvaguardie per la privacy, invitiamo gli sviluppatori a esplorare le soluzioni all'interno di un singolo modello IG. Stiamo discutendo di questo problema qui e ci piacerebbe ricevere ulteriori feedback.
Uso dell'API	I venditori di componenti (quelli che partecipano alle aste nidificate in Privacy Sandbox) devono avere visibilità sui timeout delle aste di primo livello per ottimizzare le proprie configurazioni ed evitare inutili ritardi.	Riconosciamo la necessità di migliorare il coordinamento del timeout tra venditori di alto livello e venditori di componenti all'interno di Privacy Sandbox. Stiamo esaminando attivamente l'aggiunta di nuovi meccanismi di timeout, tra cui un potenziale timeout di asta completa ed esplorando modi per applicare timeout di primo livello alle aste dei componenti. Il nostro obiettivo è migliorare l'efficienza e la prevedibilità per tutti i partecipanti al processo di asta di Privacy Sandbox. Stiamo discutendo di questo problema qui e ci piacerebbe ricevere ulteriori feedback.

Servizi Protected Audience

Tema feedback	Riepilogo	Risposta di Chrome
Ambienti di esecuzione attendibili (TEE, Trusted Execution Environment)	È più costoso eseguire TEE in cloud pubblici rispetto a data center ad tech on-premise?	La nostra risposta è simile ai trimestri precedenti: Il nostro attuale modello di sicurezza TEE trae vantaggio dalle pratiche delle implementazioni del cloud pubblico. In particolare, gli attuali TEE basati su hardware non proteggono da tutti gli attacchi fisici. I nostri attuali provider di servizi cloud pubblici supportati, AWS e GCP, hanno progettato e implementato mitigazioni per i rischi di accesso fisico, anche da parte dei dipendenti. Di seguito puoi trovare ulteriori dettagli relativi all'assistenza on-premise. Gli ad tech ci hanno detto che la gestione di servizi cloud è più costosa dei data center di tecnologia pubblicitaria on-premise. Anche se non siamo nella posizione di valutare queste dichiarazioni, accogliamo con favore un feedback aggiuntivo sui costi e continuiamo a valutare le opzioni per espandere la nostra assistenza TEE.
TEE	Supporto per TEE in ambienti cloud non pubblici	La nostra risposta è simile ai trimestri precedenti: Mentre continuiamo a esaminare il supporto per opzioni che vanno oltre le soluzioni basate su cloud pubblico, al momento non prevediamo di supportare i TEE on-premise. In questa fase, visti i requisiti di sicurezza di Privacy Sandbox e le significative sfide poste dai deployment on-premise, riteniamo che continuare a espandere e migliorare i deployment basati su cloud (ad esempio, supportare Google Cloud oltre ad AWS) sia il più vantaggioso per l'ecosistema. Tuttavia, ci piacerebbe ricevere ulteriori commenti sul motivo per cui tale requisito è necessario e fattibile, considerati i limiti di privacy e sicurezza.
Altri cloud provider	Assistenza per altri cloud provider	Siamo sempre aperti a ricevere suggerimenti da altri cloud provider, ma al momento stiamo pianificando di supportare almeno Google Cloud e AWS quando verrà applicato il 3PCD. Per ulteriori informazioni, consulta questa spiegazione.
API B&A Services	Qual è la direzione di Google in merito all'API B&A Services? Avrà la priorità sopra o sotto il livello di Protected Audience del browser Chrome nelle aste dei dispositivi?	La nostra risposta è simile a quella dei trimestri precedenti: Rispettiamo il nostro design attuale delle offerte on-device di Protected Audience. I servizi B&A sono stati proposti per esplorare possibili soluzioni per supportare un sottoinsieme di casi d'uso in cui la potenza di calcolo o la velocità di rete del dispositivo potrebbero essere limitate.
Standardizzazione	I servizi B&A non sono stati sottoposti a un processo di standardizzazione.	La proposta per i servizi B&A si trova in una fase del processo di standardizzazione e ci piacerebbe ricevere un ulteriore impegno a sostegno di questo obiettivo. Iniziata con una proposta (basata su proposte precedenti), è stata incubata pubblicamente attraverso un'ampia discussione aperta presso W3C e gli sviluppatori interessati possono iniziare a sperimentarla e a fornire feedback. Si tratta del solito schema per lo sviluppo di funzionalità web, come descritto ad esempio nel nostro post del blog qui.
Server KV	Esponi l'URL completo al server dei valori chiave dell'acquirente per il targeting basato sui contenuti, sul contesto o sul sito.	Stiamo discutendo di questa richiesta qui e ci piacerebbe ricevere ulteriori feedback dall'ecosistema.
Documentazione	La documentazione relativa a "Componenti attendibili/applicati e facoltativi" su GitHub crea confusione con alcuni ad tech che hanno il proprio set di immagini e infrastrutture di deployment.	Stiamo cercando di migliorare la documentazione relativa al confronto tra componenti attendibili/applicati e facoltativi e mi interessa conoscere l'ecosistema qualora fosse necessario dare priorità a questo lavoro.
Miglioramento dell'API	Il codice di stato HTTP di una chiamata del server KV deve essere disponibile anche per la funzione scoreAd() come parametro.	Stiamo valutando questa richiesta e ci piacerebbe ricevere ulteriori feedback dall'ecosistema.
Documentazione	Fornisci maggiori informazioni su come verranno gestiti i carichi di lavoro JS e WASM esattamente con l'esecuzione della funzione definita dall'utente.	Stiamo cercando di fornire queste informazioni e saremo lieti di ricevere un feedback aggiuntivo qui.
Documentazione	Richiedi di aggiornare il nome del repository.	Abbiamo rinominato il repository in "protect-auction-key-value-service". È in linea con il termine che indica la raccolta dei servizi a cui appartiene, che ha anche altri repository, come la dibattito di Protected Audience Services e i repository della documentazione relativa ai servizi di asta protetti.
Documentazione	Rimuovi il riferimento all'API Cloud Debugger in bidding_auction_services_gcp_guide.md.	Abbiamo aggiornato la documentazione e rimosso il riferimento.
Uso dell'API	La latenza introdotta dalla ricerca KV sta richiedendo più di 50 ms. Ci vogliono quasi 100 ms. Hai indicazioni su cosa ha funzionato bene per altri venditori? Hai qualche suggerimento su come misurare i timeout e le tempistiche?	La chiamata al server KV avviene all'interno del contesto degli script Runner, ovvero lo speciale ambiente protetto all'interno del browser Chrome. È destinato a mantenere protette le informazioni negli script runner da qualsiasi accesso non API. Puoi trovare una spiegazione dettagliata qui.
Uso dell'API	Esiste un timeout per la risposta del server KV in un orario specifico?	I venditori possono specificare il campo "perBuyerCumulativeTimeouts" nella configurazione dell'asta. Questo timeout include il tempo necessario per recuperare gli indicatori di offerta attendibili.
Latenza	In che modo sta lavorando il team di Privacy Sandbox per affrontare la latenza?	Per le strategie che stiamo valutando per mantenere la latenza entro limiti accettabili, leggi qui.

Misurazione degli annunci digitali

Attribution Reporting (e altre API)

Tema feedback	Riepilogo	Risposta di Chrome
Ottimizzazione manuale della campagna	L'ARA non supporta l'ottimizzazione manuale delle campagne.	Abbiamo discusso di questo scenario con la tecnologia pubblicitaria e mostrato come utilizzare l'ARA per supportare l'ottimizzazione manuale della campagna. L'ARA è stato realizzato in modo da consentire la personalizzazione della tecnologia pubblicitaria e la flessibilità necessaria per risolvere una serie di casi d'uso di tecnologia pubblicitaria. Alcuni dei suggerimenti forniti sono stati forniti utilizzando diverse configurazioni flessibili a livello di evento e l'utilizzo di report a livello di evento con report di riepilogo per ridurre l'impatto del rumore e soddisfare le esigenze di ottimizzazione manuale e automatica. Siamo disponibili a ricevere ulteriori feedback sull'ecosistema in merito alla personalizzazione e alla flessibilità delle configurazioni ARA.
Tipo di conversione	Google consente solo otto tipi di conversione, il che è un limite.	Abbiamo implementato la maggior parte dei report flessibili a livello di evento, che offrono ai tecnici pubblicitari una maggiore flessibilità in termini di numero di finestre di report, numero di report sull'attribuzione e bit di dati degli attivatori che possono utilizzare. Gli ad tech possono scegliere una configurazione che consente di misurare fino a 32 diversi tipi di conversione.
Limite di eventi del report aggregato	Il minimo numerico di 20 eventi di conversione per report aggregabile non è utilizzabile per gli inserzionisti più piccoli con budget limitato.	Non è necessario un numero minimo di eventi di conversione per ogni report aggregabile. Inoltre, è possibile prendere una serie di decisioni di progettazione per ottimizzare i report aggregabili per gli inserzionisti più piccoli, ad esempio modificare la struttura chiave / le dimensioni monitorate, testare diversi livelli di epsilon, testare frequenze di raggruppamento più lunghe e testare diverse allocazioni del budget a livello di evento tra gli obiettivi di misurazione. Le tecnologie pubblicitarie più piccole possono anche combinare i report a livello di evento e i report di riepilogo come un rumore di fondo.
Dati in tempo reale	Privare le DSP dei dati in tempo reale (ad es. su clic, sessioni e conversioni) utilizzate dalle DSP per adattare la propria strategia di offerta e migliorare l'efficacia delle campagne va contro l'impegno di mantenere le funzionalità esistenti.	Anche con l'ARA, i clic e le sessioni rimangono in tempo reale e le conversioni sono sempre in ritardo anche con i tre PC.
Campi mancanti	Requisiti mancanti nell'implementazione dell'evento completamente flessibile: i) campo Valuta e ii) campo orderID / ID transazione.	Al momento non prevediamo di supportare un campo Valuta o un campo ID ordine / ID transazione come parte del livello di evento completamente flessibile, in quanto esistono già modi per farlo con gli attuali report a livello di evento. Siamo disponibili a ricevere ulteriori feedback in merito a questi campi e prenderemo nuovamente in considerazione eventuali altri casi d'uso che li richiedono. Come utilizzare il design attuale dell'ARA per misurare le informazioni sulla valuta e sul tipo di ID ordine: 1. In base al feedback, la valuta viene determinata in base all'area geografica di un utente, che può essere aggiunta all'interno di source_event_id per determinare la valuta utilizzata. 2. In base al feedback, il campo ID ordine è necessario per garantire che le conversioni e i valori non vengano conteggiati due volte per errore, operazione possibile utilizzando le chiavi di deduplicazione.
Budget per la privacy	Il budget per la privacy ARA limita la possibilità di effettuare misurazioni su più dimensioni	L'ARA è stato progettato in modo da consentire agli ad tech di personalizzare le proprie configurazioni ARA per coprire una serie di scenari di attribuzione. Con l'attuale ARA design ad tech, i tecnici dovranno considerare il compromesso tra le dimensioni più cruciali per le loro misurazioni e l'impatto del rumore sui loro dati. Aggiungere rumore matematico ai dati in base alla granularità delle dimensioni che vengono misurate è essenziale per la privacy. Siamo disponibili a ricevere ulteriori feedback dell'ecosistema riguardo alla capacità di effettuare misurazioni in diverse dimensioni, ma dovremmo comprendere i casi d'uso specifici che lo richiedono.
Aggiorna specifica	Sebbene Google abbia dichiarato il passaggio dalla finestra fissa per la generazione di report sugli eventi flessibile, ciò non è stato riportato nelle specifiche tecniche di Google, che al momento prevedono ancora una finestra minima di un'ora.	Attualmente, la flessibilità dei report a livello di evento consente alle tecnologie pubblicitarie di modificare il numero di report sull'attribuzione per evento di origine, i bit dei dati degli attivatori e il numero/la lunghezza delle finestre di report. L'ARA ha comunque una finestra di segnalazione minima di 1 ora per i report a livello di evento, essenziale per mantenere la privacy e mitigare alcuni tipi di attacchi di ricostruzione della storia. Poiché i report di riepilogo forniscono informazioni in forma aggregata, i tecnici degli annunci possono scegliere di ricevere immediatamente report aggregabili senza ritardi, se necessario per i loro casi d'uso.
Progettazione delle API	Preoccupa che la riduzione delle informazioni nei report sulle conversioni e l'aggiunta di rumore possa influire sull'ecosistema più di Google.	Google si è impegnata nella CMA a progettare e implementare le proposte di Privacy Sandbox in modo da non distorcere la concorrenza con l'autopromozione dell'attività di Google e di tenere conto dell'impatto sulla concorrenza nella pubblicità digitale e su publisher e inserzionisti di tutte le dimensioni.
Correzione dell'attribuzione	L'ARA non consente al fornitore di tecnologia di controllare e verificare l'attribuzione corretta.	All'interno dell'ARA sono disponibili diverse soluzioni che offrono funzionalità di verifica: 1. I tecnici pubblicitari possono verificare che il comportamento dell'ARA soddisfi le loro aspettative: – Il codice lato client dell'ARA è open source. – Anche il codice lato server dell'ARA è open source e i coordinatori assicurano che solo le versioni consentite di Aggregation Service possano decriptare ed elaborare i report aggregabili. 2. Chrome ha fornito ai tecnici pubblicitari una libreria delle simulazioni per verificare il comportamento dell'attribuzione, in cui queste possono testare come l'ARA esegue l'attribuzione in un ambiente simulato. 3. L'ARA supporta una serie di indicatori di debug che aiutano a verificare se e perché l'elaborazione prevista potrebbe non essersi verificata.
(Segnalato anche nei trimestri precedenti) Rumore	Feedback che indica che il livello di rumore è troppo elevato e ciò influisce sull'utilità dei report.	Abbiamo parlato con gli ad tech con lo stesso feedback e siamo riusciti a identificare i modi in cui l'ARA può essere personalizzata per soddisfare al meglio i loro casi d'uso, anche con il rumore. Disponiamo di documentazione per gli sviluppatori che contiene la maggior parte delle decisioni di progettazione e delle personalizzazioni di cui abbiamo parlato con gli ad tech. L'ARA è stato progettato in modo da consentire ai tecnici pubblicitari di personalizzare le proprie configurazioni ARA per coprire una serie di scenari di attribuzione. Tuttavia, gli ad tech dovranno considerare il compromesso tra le dimensioni più importanti per loro misurare e l'impatto del rumore sui loro dati. Siamo disposti a ricevere ulteriori feedback sull'ecosistema per quanto riguarda l'impatto del rumore e possiamo fornire ulteriori indicazioni sui fattori di ARA che possono essere utilizzati per modificare l'impatto del rumore.
Attribuzione interdominio	Come si monitorano le attribuzioni interdominio?	Le ad tech possono reindirizzare a diversi URL dei report per risolvere questo caso d'uso. Siamo disponibili a ricevere ulteriori feedback sull'ecosistema in merito a questo aspetto di progettazione dell'ARA.
Miglioramento dell'API	Modifica regolarmente il fattore di scala utilizzato durante la registrazione dell'attribuzione per i report di riepilogo ARA.	In base alla discussione su GitHub, sembra che la gestione di più fattori di scala nel servizio di aggregazione probabilmente comporterà l'aggiunta di una quantità maggiore di rumore nei report di riepilogo rispetto alla funzionalità attuale. Siamo disponibili a ricevere ulteriori feedback sulla necessità di includere i fattori di scalabilità nell'ambito dei report aggregabili, ma vogliamo sottolineare il potenziale compromesso con maggiore rumore. Stiamo inoltre valutando se anche altre funzionalità ARA future potrebbero aiutare a risolvere questo caso d'uso.
Uso dell'API	Opportunità di unificare il modo in cui gli eventi di attribuzione vengono condivisi con tutti i partecipanti, il che è vantaggioso per SSP, DSP e così via.	Prevediamo di sincronizzarci con la tecnologia pubblicitaria per comprendere meglio i loro feedback e le eventuali limitazioni che si trovano a dover affrontare.
Testa volume di traffico	Il traffico di prova per la modalità B è stabile per Chrome?	L'inclusione in un gruppo sperimentale non è influenzata dalle impostazioni di Chrome (indipendentemente dalle).
Documentazione	Supporto ARA per i pixel.	Abbiamo pubblicato informazioni su come supportare questo caso d'uso e saremo lieti di ricevere feedback aggiuntivi dall'ecosistema.
Uso dell'API	L'ARA potrebbe non essere attribuito alla fonte corretta per i venditori di terze parti sulle piattaforme di e-commerce se la conversione non viene effettuata con l'ultimo touchpoint.	Le aziende possono utilizzare i filtri per evitare che si verifichino attribuzioni errate (dal momento che non verrà generato alcun report sulle conversioni). Stiamo inoltre lavorando a una proposta di filtro pre-attribuzione per facilitare questo caso d'uso.
Supporto dei browser	L'ARA sarà supportato in diversi browser?	Invitiamo altri browser ad adottare le API Privacy Sandbox e continuiamo a dedicare tempo a discutere del nostro approccio all'aperto in W3C. Abbiamo esplicitamente indicato l'interoperabilità come obiettivo per la spedizione di ARA e il suo design è inteso a essere indipendente dal browser con valori flessibili specificati dal fornitore per fornitori con diverse abitudini di privacy. Altri browser stanno facendo le proprie scelte su se fornire alternative attuabili ai contenuti digitali tra siti che possono essere utilizzati per gli identificatori. Siamo incoraggiati che Microsoft Edge abbia indicato che supporterà ARA.
Uso dell'API	Qual è il tipo di origine previsto per le registrazioni di origine ARA per registerAdBeacon/reportEvent (e beacon automatici navigazione_start/commit)?	Dipende se questi beacon sono automatici o manuali: - riservati.* (ossia automatici) gli eventi di tipo "navigazione" come origine. - Gli eventi attivati manualmente devono essere di tipo origine evento.
Uso dell'API	Qual è il limite massimo di report aggregabili per fonte per ogni evento di origine? Il limite è globale o giornaliero? Esiste un piano per aumentare il limite?	Il limite di 20 report aggregabili per fonte è un limite globale in cui è possibile creare report aggregabili per ciascuna fonte. Il limite è impostato dal browser e non può essere configurato. Lo scopo di questo limite è evitare di abusare della protezione dei report di attribuzione reali con report nulli. Abbiamo discusso ulteriormente qui.
Uso dell'API	Supporto per l'email marketing tramite ARA.	Al momento non esiste un supporto diretto per questo caso d'uso all'interno di ARA (se non controlli il sito di hosting dell'email). Ne stiamo discutendo qui e ci piacerebbe ricevere un ulteriore feedback.
Epsilon	Quando verrà determinato il valore di epsilon per l'API Aggregate?	L'attuale valore epsilon può essere configurato dagli ad tech fino a una soglia predeterminata definita da Privacy Sandbox (che attualmente è 64). Consigliamo di testare diversi valori di epsilon, identificare i punti di svolta per i tuoi casi d'uso e fornire feedback. Ci assicureremo di comunicare in anticipo ai tecnici pubblicitari qualsiasi modifica all'intervallo di valori epsilon.
Miglioramento dell'API	Supporta un caso d'uso in cui l'inserzionista può inserire un identificatore nel campo trigger_data per la corrispondenza con dati CRM esterni e consentire agli inserzionisti di verificare la qualità delle conversioni.	Stiamo discutendo della richiesta e accogliamo con favore un feedback aggiuntivo qui.
Uso dell'API	Come gestire gli URL di reindirizzamento come URL di destinazione.	I tecnici pubblicitari possono effettuare una delle seguenti operazioni: 1. Inserisci l'URL di destinazione finale nel campo di destinazione; 2. Nel campo di destinazione sono consentiti fino a tre URL, con cui puoi inserire nel campo più URL. Entrambe le opzioni richiedono di conoscere l'URL di destinazione finale. Abbiamo discusso ulteriormente qui .

Servizio di aggregazione

Tema feedback	Riepilogo	Risposta di Chrome
Meccanismo chiave di scoperta	Richiesta di un meccanismo di rilevamento delle chiavi	Abbiamo una proposta per una scoperta chiave e ci piacerebbe ricevere un feedback della proposta dell'ecosistema.
Uso dell'API	Roadmap per l'osservabilità su Aggregation Service	Stiamo valutando le opzioni per favorire una maggiore osservabilità e ricevere feedback dall'ecosistema qui.
Miglioramento dell'API	Richiesta di poter eseguire una nuova query sui report.	Aggregation Service sta lavorando a una proposta di riesecuzione di query in cui gli ad tech possono suddividere la loro puntata per ciascun report. Ciò può introdurre più rumore per query, ma consente agli ad tech di ripetere le query e mantenere la privacy.
Miglioramento dell'API	Vuoi essere in grado di associare più origini allo stesso ID AWS.	Aggregation Service ora consentirà l'onboarding di più siti sullo stesso account cloud (GCP o AWS). Ciò consentirà agli ad tech di utilizzare la stessa enclave di Aggregation Service per elaborare i report provenienti da più siti e da più origini dagli stessi siti.
Uso dell'API	In caso di errore dei batch aggregabili, non so se il budget viene consumato o meno e se il batch può essere rielaborato. Quando un servizio di aggregazione riscontra un errore di budget per report duplicati, gli altri report rimanenti vengono persi. Come ridurre al minimo questa perdita?	In uno scenario tipico, se l'intero job non va a buon fine, il budget non verrà consumato. Nel caso di un raro fallimento in cui il budget viene esaurito, gli ad tech possono richiedere il recupero del budget. Se l'ad tech riscontra malfunzionamenti frequenti con un errore di budget esaurito, deve confermare la propria strategia di raggruppamento. Le istruzioni su come raggruppare correttamente ed evitare report ed errori duplicati sono disponibili qui. Accogliamo con piacere un feedback sul recupero del budget qui.
Uso dell'API	L'utilizzo dell'API Private Aggregation con l'attivatore descritto qui produrrebbe un report aggregabile per ogni asta. Quali sono le funzionalità di scalabilità di Aggregation Service?	Il servizio di aggregazione non imposta un limite superiore al numero di chiavi o report in un batch, ma una scala di 10^14 report e 10^12 chiavi al momento non è supportata a causa della memoria necessaria. Le nostre linee guida sulle dimensioni indicano gli intervalli che abbiamo testato e consigliato per ottenere prestazioni ottimali in base al carico previsto e ai tipi di istanza Cloud VMware supportati.
Elaborazione dei dati	Se i dati criptati contengono informazioni personali, qual è l'accordo legale per fornire dati criptati al Servizio di aggregazione? Puoi indicare se è garantito che il coordinatore non acceda ai dati criptati?	Il servizio di aggregazione non condivide dati criptati / utente con il coordinatore. Il servizio di aggregazione utilizza il coordinatore per la gestione delle chiavi e la contabilità. Alcuni dettagli sul coordinatore sono disponibili qui. A fini di contabilità, il servizio di aggregazione condivide solo l'ID condiviso e l'origine dei report con la PBS per il consumo del budget. Una volta lanciato un sito multiplo, sostituiremo origine con sito. Tieni presente che il servizio di aggregazione viene eseguito in un TEE, l'unico in cui è possibile decriptare i report dei client. Il codice in esecuzione nel TEE è open source e controllato da parti esterne come descritto qui.

API Private Aggregation

Tema feedback	Riepilogo	Risposta di Chrome
Uso dell'API	Possibilità per i venditori di componenti di inviare report a più server di aggregazione all'interno di un TEE.	L'attuale stato dell'API Private Aggregation non supporta questa funzionalità. Abbiamo discusso ulteriormente questo problema qui.
Documentazione	Qual è il valore epsilon utilizzato nelle prove di Google?	Per l'API Private Aggregation, il valore meglio specificato in una query sul servizio di aggregazione corrisponde al budget di contributo L1 pari a 2^16 applicato in base a una cadenza di 10 minuti. C'è anche un budget per il contributo L1 "backstop" pari a 2^20 che viene applicato su base continuativa di 24 ore. Di conseguenza, in sostanza, il parametro di privacy è 1 su base continuativa di 10 minuti ed è 16 giorni su 24 ore (anziché 144 EV). Il servizio di aggregazione attualmente supporta un intervallo di valori β per i test (fino a 64) per consentire la sperimentazione di diverse strategie di aggregazione e fornire feedback sull'utilità del sistema con diversi parametri di privacy per l'aggregazione privata e altre API. Prevediamo di rivedere il valore massimo consentito di epsilon nel tempo man mano che riceviamo feedback dai tester e aggiungiamo funzionalità che consentono un utilizzo più efficiente del budget per la privacy.

Limita monitoraggio nascosto

Client hint user agent/Riduzione user agent

Nessun feedback ricevuto questo trimestre.

Protezione IP (in precedenza Gnatcatcher)

Tema feedback	Riepilogo	Risposta di Chrome
ID risoluzione	Privacy Sandbox deve essere più concreto per comunicare che gli ID risoluzione spesso basati sulla proprietà intellettuale non sono sostenibili per gli inserzionisti.	Privacy Sandbox ha chiarito che il nostro obiettivo è ridurre il monitoraggio tra siti. Le nostre iniziative pubbliche, che vanno oltre i cookie, vengono pubblicizzate sia su privacysandbox.com che su GitHub. Facciamo il possibile per ridurre il monitoraggio tra siti, compreso quello basato sugli indirizzi IP. Tuttavia, è in ultima analisi a essere il singolo sito web decidere se attivare proattivamente il monitoraggio tra siti. In un'epoca di maggiore controllo sulla conformità normativa, è prudente per le singole aziende comprendere le prassi adottate dai fornitori di servizi.
Chromecast	La protezione IP inciderà su Chromecast o su altri dispositivi Chrome?	Al momento non è prevista l'applicazione della protezione IP ai dispositivi Chromecast.
Elenco di protezione IP	L'elenco delle terze parti identificate che potrebbero utilizzare indirizzi IP per il monitoraggio tra siti web verrà pubblicato?	L'elenco verrà pubblicato una volta finalizzato, come spiegato qui.

Mitigazione del monitoraggio del rimbalzo

Tema feedback	Riepilogo	Risposta di Chrome
Esenzione Single Sign-On (SSO)	In che modo la mitigazione del monitoraggio del rimbalzo (BTM) verificherà i casi d'uso SSO per l'esenzione?	La funzionalità BTM verrà disattivata dall'euristica di Chrome. Per informazioni dettagliate, visita questa pagina.
Prova relativa al ritiro	BTM è abilitato per i siti che partecipano alla prova del ritiro di 3PC?	No, BTM rispetta le eccezioni ai cookie create dalla prova relativa al ritiro, come discusso qui.

Budget per la privacy

Come indicato nel video esplicativo di GitHub e nel sito per sviluppatori,il budget per la privacy non viene più considerato attivamente nell'ambito delle proposte di Privacy Sandbox.

Rafforza i confini della privacy tra siti

Insiemi di siti web correlati (in precedenza Insiemi proprietari)

Tema feedback	Riepilogo	Risposta di Chrome
Richiesta di funzionalità	L'accesso ai CHIP e / o al partizionamento dello spazio di archiviazione è automaticamente consentito nell'RWS, senza bisogno dell'API Storage Access né interazione da parte dell'utente.	Stiamo valutando i vantaggi e la fattibilità di una funzionalità che potrebbe svolgere questa funzione. Un aspetto da considerare è una potenziale lacuna nell'interoperabilità tra browser, che RWS risolve sfruttando l'API Storage Access. Al momento non esiste un equivalente di questa funzionalità richiesta supportata su altri browser. Invitiamo gli sviluppatori a inviare i loro casi d'uso su questo problema per facilitare la discussione qui.
Rimozione di insiemi non conformi	Qual è la procedura per rimuovere dal repository i set che diventano non conformi?	Stiamo lavorando alla definizione di una procedura per questa funzionalità e ti comunicheremo gli aggiornamenti non appena saranno disponibili.
Procedura di applicazione	Mancanza di chiarezza sul ruolo soggettivo di Google nella procedura di applicazione RWS.	Poiché RWS è un progetto continuo e continuiamo a ricevere nuove richieste, alcuni aspetti del processo e i nostri criteri sono ancora in fase di consolidamento. Accettiamo che sia importante che le nostre linee guida per l'invio definiscano completamente i nostri requisiti per l'invio e in futuro aggiungeremo maggiori dettagli alle nostre linee guida per l'invio per evitare ulteriore ambiguità e confusione. Il nostro obiettivo è fare in modo che la procedura di invio sia il più tecnica possibile, in modo da poter eliminare gradualmente il coinvolgimento umano e affidarci completamente ai controlli automatici. Le PR come questa richiedono maggiori interazioni umane perché includono comportamenti che non avevamo previsto, ma ci consentono di identificare più aree di automazione e i modi in cui possiamo correggere le nostre linee guida per evitare questi problemi in futuro.
Condivisione di dati	Richiesta di una funzionalità che consenta ai proprietari di domini di indicare che vogliono che una terza parte condivida anche i dati RWS, con il consenso dell'utente.	La funzionalità richiesta è già disponibile tramite API come FedCM e Storage Access che consentono l'accesso all'identità autenticata dopo che l'utente accetta una richiesta di autorizzazione. Siamo lieti di ricevere feedback dall'ecosistema su casi d'uso specifici che ritengono non possibili.
Altri metodi di archiviazione	Le informazioni salvate nello spazio di archiviazione locale o di sessione verranno anch'esse interpretate come 3PC?	Lo spazio di archiviazione locale, lo spazio di archiviazione di sessione e altre forme di archiviazione non basata sui cookie se utilizzati in contesti di terze parti sono stati partizionati in Chrome a partire dalla versione 115. Per ulteriori dettagli, leggi questo post del blog.
Limite di insiemi associati	Che cosa succede alle organizzazioni che inviano più di 5 domini anche se il limite è di 5 siti associati?	Questi set saranno accettati tramite il processo GitHub, ma il browser (Chrome) applicherà solo le regole di concessione automatica dell'API Storage Access ai primi cinque domini e ignorerà i domini rimanenti, come spiegato qui.
find_robots_txt	Il controllo Find_robots_txt non funziona con i reindirizzamenti.	Per risolvere il problema, è stata inviata una correzione qui.
Gesto dell'utente	Rimuovi il requisito dei gesti dell'utente per accessStorage().	Questo requisito è stato realizzato in base a un design simile applicato in tutti i principali browser per l'API requestStorageAccess. Invitiamo ulteriori feedback e casi d'uso in questo problema GitHub per aiutarci a definire la priorità di questa richiesta e consentire discussioni tra browser.
Gesto dell'utente	È necessario un gesto dell'utente per concedere l'autorizzazione per l'accesso allo spazio di archiviazione di terze parti dopo il riavvio di Chrome o OS?	Sì, ma siamo lieti di ricevere ulteriori feedback dall'ecosistema in merito alla possibilità di modificare questo comportamento qui.

API Fenced Frames

Tema feedback	Riepilogo	Risposta di Chrome
adComponent	Mancanza di documentazione e flessibilità per l'utilizzo di AdComponenti con Fenced Frames.	Stiamo cercando di condividere ulteriore documentazione su questo caso d'uso. Inoltre, i componenti degli annunci sono supportati nei frame Fenced utilizzando getNestedConfigs(), che è documentato nella specifica qui.
(Presentato anche nei trimestri precedenti) Esegui il rendering di adComponente	Richiesta di codici di esempio su come eseguire il rendering di adComponenti in Fenced Frame.	Stiamo lavorando per condividere alcuni codici di esempio qui.
Verifica degli annunci di terze parti	Il ruolo della verifica degli annunci di terze parti nel contesto di Fenced Frames richiede maggiori dettagli, soprattutto per quanto riguarda la sicurezza contestuale/del brand.	Attualmente, la generazione di report sugli annunci Fenced Frames consente alle DSP di inviare dati a livello di evento relativi a impressioni e aste agli strumenti di verifica degli annunci di terze parti per i controlli di sicurezza del brand e la fatturazione post-rendering.
Annunci espandibili	Richiesta di supportare gli annunci espandibili.	Se l'annuncio deve passare da una dimensione all'altra con le stesse proporzioni e non esiste una differenza funzionale tra le due (solo dimensioni), l'incorporamento può ridimensionare il frame fenceto con la seconda dimensione dell'annuncio e il browser scala di conseguenza l'elemento Fenced Frame.
(Presentato anche nei trimestri precedenti) Supporto dell'inventario video e nativo	Fenced Frames supporta l'inventario video e nativo?	La nostra risposta è simile a quella del trimestre precedente: L'API PA supporta il rendering video utilizzando un meccanismo che si basa sugli iframe. Tuttavia, non abbiamo ancora progettato una soluzione per il rendering degli annunci video e nativi che sia compatibile con Fenced Frames. Questo è uno dei motivi per cui abbiamo deciso di respingere l'applicazione di Fenced Frames al 2026. Ciò significa che se un partner decidesse di applicare subito Fenced Frames, il supporto per video e nativo sarebbe carente per quel partner.
Comitato consultivo	Richiede la creazione di un comitato consultivo di fornitori di annunci nativi per garantire che le implementazioni di Fenced Frames rispettino gli standard di settore.	I Fenced Frames non devono essere utilizzati nell'API PA prima del 2026. Il tempo aggiuntivo ci consente di continuare a collaborare con il settore per progettare e implementare l'assistenza per una gamma più ampia di casi d'uso critici. Come già detto in precedenza, svilupperemo Fenced Frames in anticipo rispetto al requisito di mantenere il supporto degli annunci video e nativi con l'API PA. In linea con i nostri impegni, ci impegneremo e avviseremo la CMA di tali modifiche e continueremo a interagire con il feedback dell'ecosistema prima di richiedere Fenced Frames. Il modello di coinvolgimento dell'ecosistema di W3C e le organizzazioni che applicano gli standard pubblicitari come IAB Tech Lab consentono a esperti del settore di tutti i tipi di guidare i progetti prima che siano richiesti.
(Segnalato anche nei trimestri precedenti) Differenza di dimensioni tra le piattaforme	Segnala che le dimensioni dei contenuti visualizzati nel Fenced Frame sono diverse tra computer e smartphone.	Si tratta di un problema noto di Chromium che stiamo esaminando. Ulteriori feedback sono disponibili qui.
Miglioramento dell'API	Il requisito dei frame Fenced è stato rinviato al 2025 in modo che gli annunci nativi siano ora supportati in Privacy Sandbox?	Come indicato nel nostro annuncio pubblico relativo all'applicazione di Fenced Frames non prima del 2026, avevamo appreso di un ampio "impegno significativo per adattarsi" a Fenced Frames. Certo, uno dei quali era nativo, ma non era l'unico fattore. Lo scopo era fornire più tempo per garantire la preparazione dell'ecosistema a supportare casi d'uso chiave, inclusi, a titolo esemplificativo, gli annunci nativi.

API Shared Storage

Tema feedback	Riepilogo	Risposta di Chrome
Rendimento	I tempi di restituzione dello spazio di archiviazione condiviso al di fuori del worklet sembrano dipendere dall'attività nel worklet.	Stiamo discutendo di questo risultato del test qui.
Adozione più ampia	Lo spazio di archiviazione condiviso deve essere uno standard di settore disponibile in tutti i browser.	Siamo lieti di ricevere questo feedback e di apprezzamento. Chrome continua a partecipare attivamente ai forum del W3C, tra cui il WICG, per sostenere la proposta, richiedere feedback e favorire l'adozione.
Worklet delle offerte	È possibile leggere dallo spazio di archiviazione condiviso all'interno di generateBid (che è già in esecuzione in un worklet) per applicare la decisione degli annunci / una logica di business (come la quota limite) in base alle informazioni tra siti e selezionare un sottoinsieme di annunci?	No, è impossibile leggere dallo spazio di archiviazione condiviso all'interno dei worklet delle offerte.

CHIPS

Tema feedback	Riepilogo	Risposta di Chrome
Capacità di partizione	Chiarisci il comportamento in caso di superamento della capacità di partizionamento.	Quando viene raggiunta la capacità, i cookie meno recenti vengono espulsi dai cookie a cui si è avuto accesso meno di recente per liberare memoria finché il limite non viene più superato. Gli sviluppatori vedranno l'intestazione Cookie aggiornata nelle richieste successive.
Accesso a iframe di terze parti	I contenuti iframe di terze parti incorporati che aprono una nuova scheda/finestra sullo stesso sito di terze parti devono avere accesso agli stessi cookie partizionati dell'elemento di apertura.	Stiamo discutendo di questo caso d'uso e saremo lieti di ricevere ulteriori feedback dall'ecosistema qui.
Cookie duplicati	Se sono presenti un cookie partizionato e un cookie non partizionato con lo stesso nome, quale valore chiave decide di inviare il browser?	Quando hai due cookie con lo stesso nome (uno partizionato e l'altro no), ottieni entrambi i cookie, purtroppo non c'è modo di distinguerli. Le specifiche RFC relative a questo argomento sono disponibili qui, il che spiega che non è possibile fare affidamento sull'ordine in cui vengono inviati i cookie.
Richiesta di funzionalità	Attiva i cookie partizionati nell'origine.	Stiamo valutando questa richiesta e accogliamo con favore un feedback aggiuntivo dall'ecosistema qui.

FedCM

Nessun feedback ricevuto questo trimestre.

Lotta allo spam e alle attività fraudolente

API Private State Token (e altre API)

Tema feedback	Riepilogo	Risposta di Chrome
Visualizzazione Web	I token di stato privati (PST) sono persistenti in più WebView sullo stesso dispositivo mobile (profilo)?	Ogni app che utilizza WebView avrà uno spazio di archiviazione locale diverso, il che significa che gli emittenti PST non possono emettere token in un'app WebView e successivamente in un'app separata, consentire l'utilizzo dei token. Questo vale anche per altre forme di dati memorizzati localmente nelle WebView, come i cookie. I file PST non sono ancora completamente disponibili in WebView. Prevediamo di fornire un aggiornamento al riguardo entro la fine del secondo trimestre.
Nuovo tipo di token	Proposta per un nuovo tipo di token.	Siamo grati per questa proposta e per la continua esplorazione delle applicazioni e degli adattamenti dei PST e non vediamo l'ora di saperne di più su questa proposta nei prossimi incontri del Gruppo della community antifrode nel secondo trimestre del 2024.
Identificazione utente	Come si impedisce che gli utenti vengano identificati in base ai PST specifici di un utente?	Attualmente questo è attenuato limitando i tentativi di riscatto su un sito a due emittenti, indipendentemente dal fatto che siano disponibili token di tale emittente. Devi conteggiare un emittente per il limite anche se non sono disponibili token, altrimenti il sito potrebbe eseguire l'iterazione tramite tutti gli emittenti fino a quando non trova una corrispondenza positiva.
Iscrizione	Quanto tempo è necessaria la registrazione per i PST?	La registrazione continuerà a essere obbligatoria per il prossimo futuro, come spiegato nel dettaglio qui.
Supporto per altri browser Chromium	La registrazione dell'emittente PST per altri browser basati su Chromium sarà supportata tramite il repository delle registrazioni degli emittenti di Chrome?	Chrome recupera gli impegni chiave e li distribuisce ai client Chrome tramite un meccanismo chiamato Autore aggiornamento componenti. Man mano che altri browser offrono un supporto più completo per l'API, dovranno stabilire un processo per ottenere gli impegni chiave per il client, mediante un metodo di aggiornamento dei componenti o un altro metodo. Questo argomento viene affrontato in maggiore dettaglio qui.