Report trimestrale del 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 sulla procedura di coinvolgimento degli stakeholder per le sue proposte di 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, il modulo di feedback reso disponibile su privacysandbox.com, incontri con gli stakeholder del settore e forum sugli standard web. Chrome accoglie con favore i feedback ricevuti dall'ecosistema e sta esplorando attivamente i modi per integrare le informazioni nelle decisioni di progettazione.
I temi dei feedback sono classificati in base alla prevalenza per API. Ciò viene fatto aggregando la quantità di feedback che il team di Chrome ha ricevuto su un determinato tema e organizzandoli in ordine decrescente di quantità. I temi comuni dei feedback sono stati identificati esaminando gli argomenti di discussione delle riunioni pubbliche (W3C, PatCG, IETF), i feedback diretti, GitHub e le domande frequenti che sono emerse dai team interni e dai moduli pubblici di Google.
Nello specifico, sono stati esaminati i verbali delle riunioni degli organismi di standard web e, per i feedback diretti, sono stati presi in considerazione i dati di Google relativi alle riunioni 1:1 con gli stakeholder, le email ricevute dai singoli ingegneri, la mailing list dell'API e il modulo di feedback pubblico. Google ha poi coordinato i team coinvolti in queste varie attività di sensibilizzazione per determinare la prevalenza relativa dei temi emergenti in relazione a ogni API.
Le spiegazioni delle risposte di Chrome ai feedback sono state sviluppate a partire dalle domande frequenti pubblicate, dalle risposte effettive date ai problemi sollevati dagli stakeholder e dalla determinazione di una posizione specifica ai fini di questo esercizio di segnalazione pubblica. In linea con 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 di generazione dei report corrente potrebbero non essere stati ancora considerati come risposta di Chrome.
Glossario di acronimi
- ARA
- API Attribution Reporting
- CHIPS
- Cookie con stato partizionato indipendente
- DSP
- Demand-Side Platform
- FedCM
- Federated Credential Management
- f/s
- Insiemi proprietari
- IAB
- Interactive Advertising Bureau
- IDP
- Provider di identità
- IETF
- Internet Engineering Task Force
- IP
- Indirizzo IP
- openRTB
- Offerte in tempo reale
- TS
- Prova di Origin
- API PAT
- API Protected Audience (in precedenza FLEDGE)
- PatCG
- Gruppo della community per la tecnologia pubblicitaria privata
- RP
- Parte attendibile
- RWS
- Insiemi di siti web correlati (in precedenza Insiemi proprietari)
- SSP
- Supply-Side Platform
- TEE
- Trusted Execution Environment
- UA
- Stringa user agent
- UA-CH
- User-Agent Client Hints
- W3C
- World Wide Web Consortium
- WIPB
- Blindness IP intenzionale
Feedback generale, nessuna API o tecnologia specifica
| Theme del feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Governance | Interesse per un periodo di commenti pubblici per eventuali aggiornamenti alla governance di Privacy Sandbox. | Siamo aperti a feedback ragionevoli da parte 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 1% di test facilitati da Chrome. | Non intendiamo offrire test facilitati da Chrome oltre l'attuale 1% del traffico di Chrome attivato dall'inizio di gennaio. |
| Web to App | La 3PCD sui dispositivi mobili non deve avvenire prima che venga raggiunta la piena interoperabilità tra web e app. | Siamo d'accordo sul fatto che sia auspicabile supportare l'interoperabilità tra app e web e abbiamo lanciato la misurazione dell'attribuzione cross-app e web e stiamo esplorando soluzioni di targeting web-to-app. Tuttavia, non abbiamo in programma di ritardare l'implementazione del 3PCD sul web mobile. Non abbiamo un obiettivo di copertura del 100% alla fine del 3PCD. Prevediamo invece che la compatibilità su Android per la misurazione cross-app e web sia ragionevolmente elevata con 3PCD e che aumenti nel tempo man mano che gli utenti aggiornano i propri smartphone. |
| Ruolo del browser | Sembra che Chrome stia assumendo il ruolo di un 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 integrare la propria logica di offerta e di punteggio. |
| Indicazioni per i casi d'uso | Indicazioni più chiare sui casi d'uso che saranno supportati dalle API Privacy Sandbox. | All'inizio del progetto Privacy Sandbox, la documentazione per gli sviluppatori era incentrata principalmente sull'inclusione degli sviluppatori nelle procedure di discussione e feedback per tutte le proposte. Ciò significa che i contenuti erano generalmente strutturati in base alla comprensione della motivazione e dei concetti alla base del progetto, seguiti dai dettagli dello sviluppo iniziale e dei test per ogni proposta. Questo approccio è stato efficace per creare una collaborazione reale dell'ecosistema nello sviluppo delle proposte, ma con l'avanzamento delle API fino alla disponibilità generale, è nato un nuovo pubblico di sviluppatori che si occupa principalmente di creare soluzioni basate sulle API anziché contribuire allo sviluppo sottostante. Di recente abbiamo aggiornato la navigazione del sito per sviluppatori di Privacy Sandbox in modo che sia incentrata sui casi d'uso, utilizzando classificazioni simili a quelle del Tech Lab di IAB nel recente report del gruppo di lavoro Privacy Sandbox. Questo approccio alla documentazione basato sui casi d'uso è qualcosa che continueremo a utilizzare in futuro. |
| Ambiente di sviluppo locale | Come faccio a continuare a sviluppare e testare il frontend localmente su http://localhost quando il cookie è SameSite=Secure e il backend è preceduto da una CDN? | Stiamo discutendo di questo problema qui e accogliamo con favore ulteriori feedback dall'ecosistema. |
| Mitigazione dei problemi relativi ai dati proprietari di terze parti | Esiste un modo programmatico per sapere se i cookie di terze parti sono bloccati o se le procedure di euristica sono attive? | In Chrome, sia il rilevamento delle funzionalità sia document.hasStorageAccess chiamato in un iframe consentono a uno sviluppatore di sapere se l'origine nell'iframe ha accesso ai 3PC. |
| Test video | Al momento non è possibile testare gli annunci video in Privacy Sandbox. | Chrome ha pubblicato una discussione e una dimostrazione di diversi modi possibili per realizzare video con l'API PA oggi (vedi 242 e 254 nel nostro repository di demo su GitHub). Tieni presente che non si tratta di codice di esempio che le ad tech potrebbero adottare in blocco, ma piuttosto di una prova del concetto e una dimostrazione delle tecniche che potrebbero supportare il rendering video VAST con l'API PA. Nel corso di questa discussione, è emerso chiaramente che, sebbene il rendering video sia già possibile oggi, ci sono modifiche che Chrome potrebbe apportare per semplificare l'implementazione con l'API PA. Ad esempio, gli aggiornamenti alla sostituzione delle macro (discututi qui), che già pianificavamo di implementare in base al feedback sui casi d'uso relativi alla sicurezza del brand dei verificatori di annunci di terze parti, risolverebbero anche i feedback nel caso d'uso video, in cui l'acquirente cerca le macro del venditore da utilizzare nel 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 è molto più semplice. Al momento, gli annunci nativi sembrano ricevere meno attenzione rispetto ai video, ma si tratta solo di una questione di priorità del settore ad tech, non di un ostacolo tecnico all'implementazione. |
| Misurazione non pubblicitaria | I 3PCD potrebbero influire sulle soluzioni di misurazione dei segmenti di pubblico non correlate agli annunci. | Le API di misurazione non richiedono che il caso d'uso sia correlato agli annunci. Sebbene l' ARA sia più specifica per un tipico percorso pubblicitario,l' aggregazione privata è generica. Questi due componenti di base possono essere utilizzati per gestire una vasta gamma di attività di misurazione. |
| Creatori di contenuti | Privacy Sandbox è strutturato per incoraggiare i creator a realizzare più contenuti per YouTube e meno sui propri siti. | L'iniziativa Privacy Sandbox si concentra sulla tutela della privacy delle persone su un internet aperto e senza costi. Sappiamo che i publisher si affidano agli annunci per produrre contenuti e renderli disponibili il più ampiamente possibile. Gli inserzionisti aiutano le persone a scoprire nuovi prodotti o offerte che potrebbero interessare loro. Le funzionalità di Privacy Sandbox consentono a 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 terze parti, senza rivelare l'identità dell'utente a queste terze parti. |
| Tempistiche più chiare | Programmazioni di rilascio più chiare e dettagliate per le tecnologie di Privacy Sandbox. | La documentazione dell'API Privacy Sandbox include pagine relative allo stato e alla disponibilità dell'API. Queste pagine elencano le funzionalità imminenti e le relative tempistiche (ad es. API PA, ARA). Qui puoi visualizzare una vista centrale di questi stati. |
| Machine learning | Le tecnologie pubblicitarie non sono in grado di addestrare correttamente i modelli di machine learning finché il 3PCD non supera l'1%. | L'espansione di 3PCD ad altri browser per i test non garantirebbe un aumento dell'utilizzo delle API, che è presumibilmente ciò che le ad tech stanno cercando per addestrare ulteriormente i modelli di machine learning. Se l'utilizzo di un ecosistema più ampio non è ciò che le ad tech cercano per addestrare ulteriormente i modelli di machine learning, non c'è motivo di espandere i 3PCD, poiché un'ad tech che vuole addestrare i modelli su più traffico può farlo oggi senza aumentare i 3PCD. Questo può essere fatto senza che Chrome appaia in stato avanzato su 3PCD prima della fine della modalità inattiva. |
| Caso d'uso non supportato | Al momento non sono presi in considerazione i casi d'uso delle DSP self-service. | Esistono diversi sistemi DSP self-service che forniscono regolarmente feedback pubblici sulle API. Diverse di queste DSP che forniscono regolarmente feedback pubblici si sono anche registrate come tester. Inoltre, Chrome si occupa attivamente di argomenti tipici delle DSP self-service, come gli ad server video e di terze parti. Le chiamate settimanali recenti all'API PA hanno trattato questi argomenti. |
| Prova dell'origine | Richiesta di OT per i siti che vogliono una copertura di test e un'implementazione più aggressive per 3PCD. | Chrome sta attualmente sviluppando un OT proprietario che consentirà alle origini di attivare il comportamento di ritiro graduale dei cookie di terze parti. Le origini di primo livello che si registrano per questa prova e che implementano i token avranno i 3PC bloccati come se sul dispositivo dell'utente fosse attivata la Protezione antitracciamento. Questo OT offrirà ai siti un'opportunità preziosa per eseguire test più ampi di alternative a lungo termine ai cookie di terze parti, prima dell'eventuale ritiro dei cookie di terze parti previsto dopo la consultazione con la CMA. Stiamo ancora lavorando per finalizzare le tempistiche di implementazione dell'OT. |
| Report del Tech Lab di IAB | Feedback su Privacy Sandbox ricevuto dal report del Tech Lab di IAB. | Abbiamo risposto in dettaglio al report di IAB Tech Lab qui. Abbiamo anche 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 ci impegneremo con l'ecosistema e aggiorneremo di conseguenza le nostre domande frequenti pubbliche". Abbiamo affrontato la documentazione frammentata in precedenza. Qui affrontiamo i requisiti commerciali nella sezione "Garanzia dei dati" e alcuni prodotti Google Ads hanno condiviso i loro approcci. Qui puoi trovare informazioni sulle verifiche di terze parti nella sezione "Garanzia di integrità dell'algoritmo". Per quanto riguarda l'accreditamento, ci aspettiamo che questi enti continuino ad accreditare i prodotti, incluso il loro utilizzo delle tecnologie, anziché le tecnologie stesse. In merito alla scalabilità, continuiamo ad accettare i dati degli sviluppatori che dimostrano problemi. Per quanto riguarda la trasparenza e la governance, continuiamo a sviluppare in modo aperto su GitHub e in forum come W3C, collaborando con la CMA nell'ambito degli impegni. |
| Accedi con Google | Gli accessi a Google potrebbero consentire a Google di utilizzare i dati di accesso per l'identificazione incrociata in violazione degli impegni. | Accedi con Google non consente a Google di utilizzare i dati in modo contrario agli impegni. |
| Compatibilità | Quali sono i piani per il supporto delle API Privacy Sandbox e la compatibilità con le versioni precedenti e successive? | Una volta che Chrome lancia una funzionalità in disponibilità generale, il nostro obiettivo è mantenere il supporto per quella funzionalità. 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. Prevediamo di continuare ad aggiungere altre funzionalità alle API Privacy Sandbox nel tempo, in risposta al feedback dell'ecosistema sui casi d'uso che potrebbero trarre vantaggio da un supporto migliore. In questi casi tendiamo a includere una sorta di tecnica di rilevamento delle funzionalità, in modo che un fornitore di tecnologia pubblicitaria interessato a sperimentare una nuova funzionalità possa chiedere direttamente al browser se è supportata. È meglio che chiedere agli sviluppatori di verificare la presenza di 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é accoppiarsi alla propria implementazione, Chrome deve specificare i comportamenti che un'implementazione soddisfacente di un server Trusted Signals, di un server di aggregazione e di qualsiasi altro componente non del browser richiesto deve soddisfare. Ciò consentirebbe l'innovazione nei limiti della privacy accettabili. | Apprezziamo e accogliamo con favore il desiderio di innovazione da parte di terze parti. Per tutte le API e i servizi, il nostro obiettivo è fornire alle ad tech la flessibilità necessaria per implementare le proprie funzionalità. Ad esempio, consentiamo alle ad tech di utilizzare informazioni aziendali riservate per progettare la logica di offerta per le aste. Inoltre, prendiamo continuamente in considerazione i feedback delle tecnologie pubblicitarie e, se giustificati, li incorporiamo nei nostri progetti. Per consentire ad altri di eseguire il proprio codice in ambienti di esecuzione attendibili, Privacy Sandbox dovrà esaminare il codice (e le eventuali modifiche) per confermare che soddisfi le garanzie della privacy. Ciò richiederà uno sforzo significativo da parte del team di Privacy Sandbox. Pertanto, vorremmo capire quali vantaggi lo stakeholder vuole ottenere, che al momento non sono soddisfatti. |
| Euristiche | Quali sono i piani a lungo termine per le strategie di ricerca? | In linea con quanto indicato da altri browser, intendiamo ritirare queste strategie quando le soluzioni alternative diventeranno di uso comune, in base a ulteriori analisi di fattibilità. Abbiamo condiviso queste informazioni qui. |
| Volume di test | Volume di traffico diverso quando si confrontano dimensioni diverse. | L'esperimento sull'1% ha criteri di esclusione che determinano differenze di idoneità tra le diverse popolazioni di client Chrome. Ad esempio, l'esperimento esclude gli utenti di Chrome Enterprise, pertanto è previsto che la frazione di traffico con le etichette dell'esperimento sia più elevata nei fine settimana. È normale che vengano registrate percentuali diverse di traffico in diversi segmenti di dati (ad esempio geografici, di data e di piattaforma) e questo è in linea con quanto stiamo osservando nei dati di Chrome. |
| Riattivare manualmente 3 computer | I siti potranno sapere quanti utenti (%) hanno riattivato manualmente i cookie dopo l'applicazione del ritiro dei cookie di terze parti? | Gli utenti avranno la possibilità di riattivare l'accesso di terze parti a livello di sito tramite il Bypass utente se riscontrano interruzioni. I cookie di terze parti possono essere riattivati anche da 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 fornirà ai siti web un modo per conoscere i motivi della riattivazione. |
| Protezione antitracciamento | Per quanto tempo sarà disponibile la funzionalità dell'interfaccia utente della Protezione antitracciamento di Chrome? | L'interfaccia utente di Protezione antitracciamento nella barra degli indirizzi dovrebbe rimanere anche dopo il ritiro dei 3PC. |
| (Registrato anche nei trimestri precedenti) Supporto multibrowser |
Altri fornitori di browser che adottano le API Privacy Sandbox. | Altri fornitori di browser, come Apple, Mozilla e Microsoft, partecipano attivamente ai forum pubblici in cui vengono discussi i principi della privacy e gli approcci basati su browser. Siamo incoraggiati dalle discussioni collaborative in forum come la recente riunione annuale TPAC del W3C e i forum PATCG del W3C in corso, dove notiamo segnali di convergenza. Ad esempio, di recente Microsoft Edge ha annunciato il suo piano che "mira a massimizzare la compatibilità sintattica" con l'API PA e ARA, offrendo al contempo funzionalità aggiuntive per gli sviluppatori. |
| Opzione di riserva per gli elementi incorporati incompatibili dopo il 3PCD | Fornisci hook API per rilevare se un iframe / embed di terze parti è conforme o meno ai 3PCD. | Stiamo discutendo della richiesta qui e accogliamo con favore ulteriori feedback dall'ecosistema. |
| Test | Richiesta di flag aggiuntivi nelle istanze gestite di Chrome che disattivano temporaneamente i comportamenti personalizzati. | Stiamo valutando questa richiesta per le istanze gestite di Chrome e accogliamo con favore ulteriori input dall'ecosistema se un flag del genere fosse utile. |
Registrazione e attestazione
| Theme del feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Verifica dell'attestazione | In che modo Google garantirà l'autenticità delle attestazioni? | Tutti i registranti sono tenuti a mantenere il file di attestazione in vigore durante l'utilizzo delle API. Google convalida che il file sia presente e che la sintassi sia corretta, ma non convalida il comportamento della tecnologia pubblicitaria rispetto al linguaggio di attestazione. |
| Procedura di registrazione all'API Private Aggregation | Esiste un modo per controllare lo stato della registrazione all'API Private Aggregation? | Una volta convalidata la registrazione, tutti gli utenti approvati ricevono una notifica via email dal team di assistenza per le registrazioni. Se il registrante ha domande durante la procedura, può contattare il team di assistenza (con cui viene messo in contatto dopo aver inviato il modulo di registrazione). Il team di assistenza risponderà alle domande e fornirà le indicazioni aggiuntive necessarie. |
Mostrare annunci e contenuti pertinenti
Argomenti
| Theme del feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| (Registrato anche nei trimestri precedenti) Tempistiche e documentazione del classificatore |
Dovrebbe esistere una qualche forma di meccanismo per la revisione della classificazione o almeno una maggiore trasparenza su come la modalità di classificazione determina le categorie. | La nostra risposta rimane invariata rispetto ai trimestri precedenti: "La classificazione errata dei siti potrebbe rendere l'indicatore Topics leggermente meno utile nel complesso, ma i siti specifici classificati erroneamente non sono né più né meno danneggiati da questo rispetto ad altri siti. Questo perché le informazioni contestuali di un sito saranno sempre disponibili per le aste sul sito, fornendo informazioni paragonabili all'argomento corretto, anche in caso di classificazione errata. Saremo lieti di ricevere il tuo 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 presenti su un numero inferiore di siti. | Il requisito di osservazione esiste per garantire che l'API Topics non comporti la condivisione dei dati utente con più entità rispetto alle tecnologie sostituite dall'API (inclusi i cookie di terze parti). Altre soluzioni di settore, come Prebid, funzionano con decine di migliaia di siti e consentono ai partecipanti al mercato di chiamare l'API Topics tramite la loro tecnologia. Inoltre, vale la pena notare che il limite di massimo 5 argomenti principali a settimana potrebbe avere un effetto di livellamento, in quanto i partecipanti al mercato presenti su molti siti che potrebbero essere in grado di apprendere più di 5 argomenti equivalenti utilizzando 3 PC saranno limitati a 5. |
| (Segnalato anche nei trimestri precedenti) Utilità per diversi tipi di stakeholder |
Preoccupazioni sul valore creato e sulla sua distribuzione per i siti a seconda del livello di traffico o del livello di specializzazione dei contenuti. | Siamo consapevoli 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 dal ritiro del supporto per i 3PC in Chrome. Anche nell'ambiente attuale, alcuni siti offrono più valore di altri nei sistemi di pertinenza degli annunci basati su terze parti. Inoltre, gli argomenti dei siti specializzati possono essere reciprocamente vantaggiosi perché inserzionisti diversi possono pubblicare campagne in insiemi diversi di argomenti e la logica delle offerte può osservare il valore in un'ampia gamma di argomenti. |
| Nomi host e URL completi | La classificazione in base ai nomi host dei siti web è sufficientemente efficace e riduce il rischio per la privacy rispetto agli URL completi? | Abbiamo preso in considerazione l'utilizzo di URL di informazioni o titoli di pagina oltre agli host name 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 dell'utente è la classificazione di informazioni sensibili incluse nell'URL o nel titolo della pagina negli argomenti di un utente. |
| Argomenti come indicatore | Richiedi indicazioni su come combinare Topics con altri indicatori e su quali altri indicatori potrebbero essere utili. | Le soluzioni di tecnologia pubblicitaria possono ottenere i risultati migliori combinando tutti gli strumenti disponibili, come il machine learning e gli indicatori incentrati sulla tutela della privacy delle API che tutelano la privacy, insieme a dati contestuali, dati sulle creatività e dati proprietari. Qui sono disponibili ulteriori indicazioni in merito. |
API Protected Audience (in precedenza FLEDGE)
| Theme del feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Volume del traffico di test | I tester stanno segnalando un volume ridotto di risposte all'offerta per l'asta dell'API PA. | 1. La densità delle offerte è correlata alla partecipazione dell'ecosistema all'API PA, che prevediamo continuerà ad aumentare per tutto il 2024 e oltre. Spetta infine agli inserzionisti, alle loro agenzie e ai fornitori di tecnologia stabilire come allocare i budget delle campagne. Prevediamo che alcuni partecipanti all'ecosistema potrebbero ritardare l'investimento in varie soluzioni "senza cookie", inclusa l'API PA, fino a dopo il 3PCD. In quel momento, prevediamo che potrebbero 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 da (1) in quanto i publisher e i loro fornitori di tecnologia pubblicitaria potrebbero decidere di non avviare le aste dell'API PA se ritengono che la domanda sia bassa. Spetta ai publisher stabilire la priorità dell'aggiornamento delle loro pagine e della partecipazione. Per questi motivi, prevediamo che i publisher potrebbero impiegare del tempo per testare e aumentare gradualmente il traffico. Questo report include anche una risposta di Google Ad Manager sui controlli dei publisher per la partecipazione all'API PA. |
| (segnalate anche nei trimestri precedenti) Attività fraudolenta / comportamento illecito |
In che modo l'ecosistema può ridurre i rischi e impedire a malintenzionati o acquirenti di presentarsi come un pubblico desiderabile? | I meccanismi di generazione di report degli annunci dell'API PA mantengono le informazioni attualmente utilizzate per distinguere gli utenti umani dal traffico dei bot. Inoltre, nell'API PA è possibile utilizzare le attuali tecniche basate su domini per includere o escludere i domini. Questo aspetto è descritto più dettagliatamente nella nostra risposta al report di IAB Tech Lab su Privacy Sandbox. |
| Limitazione di origine uguale per l'URL del proprietario dell'inserzione di gruppo di annunci e della logica di offerta | Con il requisito della stessa origine, gli endpoint di un proprietario di un feed di Instagram saranno costretti a passare dallo stesso bilanciatore del carico, il che potrebbe comportare il rifiuto dei reindirizzamenti. | Il requisito della stessa origine per il caricamento degli script è una misura di sicurezza importante. Qui puoi trovare alcuni dettagli su una soluzione proposta che bilancia il feedback dell'ecosistema e altre considerazioni. |
| Asta privata multi-slot | Esistono ampi margini per consentire le aste private multi-slot nei limiti della privacy utilizzando il rumore e un'integrazione più stretta con le pratiche pubblicitarie attuali. | Stiamo prendendo in considerazione questo feedback e valutando la richiesta di aste multitag rispetto alla maggiore complessità e ai rischi per la privacy associati a questa funzionalità. Abbiamo discusso ulteriormente di questo problema durante una chiamata del gruppo della community WICG (Web Incubator Community Group) dell'API PA qui. |
| Venditori di primo livello | La struttura attuale dell'API PA fornisce a qualsiasi venditore di primo livello dati e informazioni molto più approfonditi sul valore relativo delle impressioni rispetto ai publisher o ai venditori di componenti. | In un'asta multi-venditore, ogni venditore avrà un'offerta migliore. Inoltre, dall'ecosistema abbiamo appreso che i publisher potrebbero voler prendere in considerazione la domanda venduta direttamente insieme alle offerte migliori di ciascun venditore con cui collaborano. È necessario esaminare tutte queste potenziali opportunità di monetizzazione per determinare quale annuncio pubblicare. Questa situazione, in cui è necessario che un attore veda l'intero insieme di opzioni per scegliere un annuncio da pubblicare, è precedente all'API PA. L'API PA mira a supportare le aste con più venditori e la volontà dei publisher di prendere in considerazione l'offerta migliore di ciascun venditore accanto alle campagne pubblicitarie vendute direttamente, se applicabili. Ciò significa che deve esistere un meccanismo per scegliere tra le opportunità di monetizzazione, come avviene oggi. Non riteniamo che sia compito del browser selezionare l'annuncio da pubblicare. Pertanto, il concetto di un venditore di primo livello è necessario per selezionare un annuncio vincente tra molte possibilità. La logica del venditore di primo livello deve essere in grado di prendere in considerazione le offerte migliori di ciascun venditore con cui il publisher sceglie di collaborare. La logica del venditore può scegliere di fornire informazioni sulle campagne vendute direttamente dal publisher, se disponibili. Tutte queste informazioni potrebbero essere prese in considerazione nella logica di selezione degli annunci di primo livello. Ciò significa che la logica di primo livello prende in considerazione le offerte migliori dell'asta dell'API PA e, se applicabili, le opzioni di annunci venduti direttamente dal publisher per determinare un vincitore. Google Ad Manager illustra la propria implementazione dell'API PA come venditore di primo livello in questo report, nel tema "Accesso alle informazioni". |
| Separazione degli annunci della concorrenza | Richiesta di separazione degli annunci concorrenti, ad esempio per impedire la visualizzazione di annunci di brand concorrenti uno accanto all'altro. | Non siamo a conoscenza di un modo per garantire la separazione della concorrenza nell'attuale ecosistema pubblicitario digitale programmatico, basato su aste e con più venditori. Tuttavia, l'API PA consente ai venditori di recuperare indicatori in tempo reale aggiuntivi in base a una combinazione di renderURL e hostname (che rappresenta il dominio del publisher) che possono essere utilizzati durante la valutazione dell'annuncio (scoreAd()) al momento della valutazione delle creatività. I venditori possono utilizzarla per impedire la pubblicazione di annunci di brand concorrenti uno accanto all'altro, a condizione che il publisher voglia applicare questa regola. |
| Informazioni limitate | L'API PA riduce le informazioni disponibili per i publisher, ad esempio valore dell'annuncio, nome dell'acquirente del componente, nome dell'inserzionista, URL pagina di destinazione, dimensioni della creatività, tempo di risposta e frequenza di offerta, nonché le offerte perse. | Abbiamo proposto alcune potenziali soluzioni qui e accogliamo con favore 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 per i 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 fissato come data di ritiro dei report a livello di evento non prima del 2026. Nel frattempo, invitiamo alla partecipazione attiva mentre interagiamo con l'ecosistema su percorsi duraturi che potrebbero includere nuove idee per ottenere informazioni nel rispetto della privacy. |
| Più SSP | Il valore aggiunto derivante dall'utilizzo di più SSP sarà troppo basso per i publisher. | Non riteniamo che questa affermazione sia corretta e saremmo lieti di ricevere ulteriori feedback dall'ecosistema per comprendere il fondamento 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 le informazioni sul proprio pubblico agli acquirenti sul web (ovvero l'estensione del pubblico). Riteniamo che oggi sia possibile, utilizzando la funzionalità di delega della PA insieme ai contratti commerciali. Allo stesso tempo, stiamo valutando attivamente se e come possiamo soddisfare meglio questi tipi di casi d'uso. |
| Disattivazione da parte dell'acquirente | La disattivazione predefinita dell'acquirente potrebbe causare risultati inferiori per le aste dei componenti. | Indipendentemente dal fatto che venga definita un'asta PA con un singolo venditore o con più venditori, il venditore deve elencare esplicitamente gli acquirenti nel campo interestGroupBuyers di AuctionConfig. Questo si basa sul feedback dell'ecosistema secondo cui i venditori hanno contratti con alcuni acquirenti e non con altri, quindi avrebbero bisogno di un controllo esplicito sugli acquirenti da includere nell'asta. Invitiamo a ulteriori discussioni su GitHub. |
| Dimensioni annuncio | Impossibile applicare il prefiltro in base ad adsize e adSlotSize. | Stiamo lavorando per aggiungere questa funzionalità e ulteriori dettagli sono disponibili qui. |
| Supporto del targeting per IG escluso | Un'API per supportare il targeting per gruppo di interesse escluso: gli annunci vengono mostrati solo se un utente non appartiene a un gruppo di interesse. | Questo problema di GitHub propone un modo alternativo per implementare il targeting per esclusioni, in cui il browser indica direttamente all'ad server quali regole di targeting per esclusioni devono essere in vigore per una determinata richiesta di annunci. Sebbene questo possa sembrare un approccio 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 i frame delimitati, ma anche impedire il rendering delle risposte contenenti informazioni soggette al Digital Services Act? | Come per qualsiasi nuova tecnologia, è responsabilità di ogni azienda garantire che l'utilizzo di Privacy Sandbox sia conforme alla legge; Google non è in grado di fornire consulenza legale. Per ogni API abbiamo pubblicato una vasta documentazione tecnica, che dovrebbe fornire le basi per effettuare le valutazioni legali necessarie. I frame delimitati non sono obbligatori per l'utilizzo nell'API PA prima del 2026, il che consente agli stakeholder di avere più tempo per assicurarsi che l'utilizzo di questa tecnologia sia conforme a tutta la legislazione pertinente. |
| Documentazione | updateAdInterestGroups() è temporaneo? | Non abbiamo annunciato piani per ritirare updateAdInterestGroup. In futuro, potremmo applicare protezioni della privacy simili a quelle di cui abbiamo parlato pubblicamente per altri meccanismi di aggiornamento di IG, ad esempio utilizzando un indirizzo IP anche come proxy e aggiungendo un po' di ritardo prima dell'aggiornamento. |
| Supporto della proprietà della logica e dei metadati lato acquirente per le piattaforme non DSP | Richiedi un modo per agire come proxy per i fornitori di servizi pubblicitari. | Siamo a conoscenza di questo feedback da parte di segmenti non DSP e stiamo valutando la richiesta. Accogliamo con favore ulteriori feedback dall'ecosistema. |
| Rapporti | Richiesta di aggiunta della funzionalità di gestore personalizzato per il bucket / valore degli indicatori nei report di aggregazione privata. | Siamo a conoscenza della richiesta e la stiamo valutando per ulteriori approfondimenti. Saremo lieti di ricevere ulteriori feedback dall'ecosistema qui. |
| Documentazione | Esiste un link in cui è possibile visualizzare tutte le intestazioni di risposta che devono essere impostate dall'inserzionista e dal dominio del proprietario (delegato)? | Stiamo pianificando aggiornamenti alla documentazione per chiarire la questione e saremo lieti di ricevere ulteriori feedback dall'ecosistema. |
| Multi-tower Bidding | Richiesta di una spiegazione del flusso di lavoro (addestramento e inferenza) tramite un diagramma di architettura / blocchi su come è previsto un approccio multi-tower nel contesto dell'API PA. | Grazie per il feedback. Abbiamo alcune presentazioni sull'argomento da cui prevediamo di creare ulteriore documentazione. |
| Targeting per esclusione | La capacità di Privacy Sandbox di proteggere i segmenti di pubblico sensibili e i minorenni da annunci inappropriati, ad esempio quelli relativi a giochi e scommesse. | L'API PA non prende in considerazione i contenuti degli annunci mostrati. Questo è sotto il controllo degli sviluppatori di tecnologia pubblicitaria che utilizzano Protected Audience. 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 della pagina e gli insiemi di regole del publisher. Questo rispecchia la nostra comprensione dell'approccio dell'ecosistema a queste sfide oggi. Per i buyer, la funzionalità di targeting per gli interessi negativi può essere utile anche per alcuni casi d'uso relativi alla conformità. |
| Progettazione API | Google sta resistendo e vuole che le ad tech utilizzino una funzione di offerte universali, aumentando così la latenza, anziché URL biddingLogic diversi in gruppi di inserzionisti diversi, il che è consentito. | Durante le nostre discussioni sulla latenza dell'asta, abbiamo sottolineato che il riutilizzo dello stesso script in tutti gli IG di un acquirente velocizzerebbe le offerte dell'acquirente. Queste informazioni sono riportate in maggiore dettaglio qui, insieme ad altri consigli per migliorare la latenza delle aste dell'API PA. |
| Marketing basato sugli account | L'API PA non è un'API pulita per i casi d'uso di marketing basato sugli account. | Accogliamo con favore i feedback dell'ecosistema su casi d'uso specifici che ritengono non possibili e invitiamo i partecipanti dell'ecosistema a continuare questa discussione tramite il nostro repository pubblico GitHub o le chiamate settimanali. |
| Test A/B | Quando l'API PA è configurata in GAM per un publisher, al momento deve essere attivata per tutto l'inventario o per nessuno. Ciò limita la capacità dei publisher di eseguire un test A/B valido. | Risposta fornita da Google Ad Manager: i controlli dell'API PA in Google Ad Manager (GAM) influiscono sulla capacità di GAM di utilizzare l'API, a condizione che l'API sia disponibile per l'utilizzo. Pertanto, i publisher possono eseguire test A/B utilizzando la funzionalità dei criteri di autorizzazione di Chrome per disattivare l'utilizzo dell'API su un sottoinsieme di traffico da utilizzare come gruppo di controllo per un test A/B. |
| Machine learning | Gli editori hanno bisogno di un maggiore controllo sull'utilizzo proposto del machine learning da parte di GAM. | Risposta fornita da Google Ad Manager: a gennaio 2024 abbiamo lanciato un controllo che offre ai publisher la possibilità di disattivare il nostro regolatore del 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. |
| (registrato anche nei trimestri precedenti) Aste di primo livello |
Possibilità di utilizzare l'ad server per i publisher di Google senza concedere a GAM il controllo dell'asta dell'API PA di primo livello. | Risposta fornita da Google Ad Manager: per i motivi spiegati 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 informazioni preziose della concorrenza, inclusi i prezzi delle aste contestuali, 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 impegniamo a garantire l'equità delle aste, inclusa la promessa che nessun prezzo di nessuna delle origini pubblicitarie non garantite di un publisher, inclusi i prezzi degli elementi pubblicitari non garantiti, verrà condiviso con un altro acquirente prima che faccia un'offerta nell'asta, impegno che abbiamo poi riaffermato nei nostri impegni assunti con l'Autorità francese della concorrenza. Per le aste con API PA, intendiamo mantenere la nostra promessa e non condividere l'offerta di nessun partecipante dell'asta con nessun altro partecipante prima del completamento dell'asta nelle aste con più venditori. Per essere chiari, non condivideremo il prezzo dell'asta contestuale con nessuna asta di componenti, inclusa la nostra, come spiegato in questo aggiornamento. Inoltre, non utilizziamo le informazioni sulle configurazioni delle aste componenti, inclusi gli indicatori forniti dagli acquirenti alle SSP, nell'ambito della nostra asta. In effetti, accetteremmo modifiche all'API PA che consentano ai venditori di componenti di specificare le configurazioni delle aste dei componenti in modo che non siano visibili al venditore di primo livello. |
| Aste di componenti | In qualità di asta di primo livello, GAM controlla le SSP che gestiscono le aste componenti per ogni opportunità pubblicitaria. | 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 collaborare per specificare le configurazioni delle aste dei componenti tramite l'API del tag publisher di Google (GPT). Puoi trovare ulteriori dettagli qui. Se una piattaforma SSP fornisce una configurazione dell'asta di componenti tramite questa API, verrà inclusa nell'elenco delle aste di componenti per l'opportunità pubblicitaria in questione. GAM non impone limitazioni alle aste dei componenti incluse. Qualsiasi SSP che voglia eseguire un'asta di componenti potrà farlo, a condizione che il publisher abbia consentito l'esecuzione del codice necessario sulla sua pagina. |
| Aste di componenti | GAM potrebbe applicare un prezzo minimo specifico e non divulgato a ogni offerta vincente dell'asta del componente. | Risposta fornita da Google Ad Manager: da anni GAM si impegna a garantire l'equità delle aste. Nell'ambito del mantenimento di un'asta equa e trasparente, non supportiamo i prezzi minimi che si applicano solo a segmenti specifici della domanda. Si tratta di un principio coerente del 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 loro capacità di trarre vantaggio dalla domanda della SSP di Google nel contesto dell'API PA. | Risposta fornita da Google Ad Manager: al momento, GAM supporta il test dell'API PA con più venditori su GAM tramite l'API descritta qui. La partecipazione di GAM come asta di componenti in altre aste di primo livello non è attualmente supportata. |
| (Registrato anche nei trimestri precedenti) Rendimento delle aste dell'API PA |
Report dei tester che indicano che le aste dell'API PA hanno una latenza elevata. | Abbiamo preso atto dei dubbi sulla latenza e questo è uno dei motivi per cui abbiamo sviluppato una serie di funzionalità nell'ambito dell'API PA che consentiranno alle SSP di impostare limiti alla latenza della DSP e di apportare miglioramenti che possono ridurla. Di recente abbiamo aggiornato la nostra guida alle best practice sulla latenza, che include ulteriori informazioni su come sfruttare queste funzionalità. Stiamo anche continuando a sviluppare nuovi miglioramenti della latenza, alcuni dei quali sono disponibili qui. |
| (registrato anche nei trimestri precedenti) Rendering video |
Supporto per il rendering video utilizzando l'API PA e i frame delimitati. | A gennaio abbiamo pubblicato una demo di come potrebbe funzionare un video in-stream in un'asta PA, con ulteriori dettagli sugli approcci alternativi. Inoltre, notiamo che gli attori dell'ecosistema stanno iniziando a proporre il funzionamento del rendering video per i partner che si integrano con loro, come le proposte di GAM per la creazione di URL di rendering compatibili con i video o il processo E2E completo. Inoltre, stiamo ascoltando il feedback dell'ecosistema sulle modifiche che possiamo apportare per aumentare l'adozione e una di queste modifiche è descritta in dettaglio su GitHub. Continuiamo a interagire attivamente con l'ecosistema per identificare eventuali altri ostacoli all'adozione che potremmo incontrare e risolverli in modo tempestivo. |
| (segnalato anche nei trimestri precedenti) Norme sulla gestione dei dati |
Quali sono le norme relative alla gestione dei dati per le API IG / PA? | Nel design dell'API PA, tutti i dati memorizzati negli IG o sulle persone che si trovano negli IG (i) rimangono sul dispositivo o (ii) vengono elaborati nei servizi di offerta e asta (B&A) in esecuzione in un ambiente di esecuzione attendibile (TEE). In entrambi i casi, i dati non possono essere letti da altre parti né utilizzati in alcun altro modo se non per generare offerte nell'asta. Alcuni miglioramenti alla privacy in fase di esplorazione da parte di Chrome prevedono l'interazione con un server di anonimizzazione k gestito da Google. Questa interazione è stata progettata con attenzione per evitare la condivisione di informazioni sugli utenti e per essere eseguita in un TEE al fine di garantire la parità delle informazioni nell'ecosistema pubblicitario. Google si è impegnata con la CMA a progettare e implementare le proposte di Privacy Sandbox in modo da non distorcere la concorrenza dando un vantaggio alla propria attività e a prendere in considerazione l'impatto sulla concorrenza nella pubblicità digitale e su publisher e inserzionisti. Continuiamo a collaborare strettamente con la CMA per garantire che le nostre attività siano conformi a queste obbligazioni. |
| (Registrato anche nei trimestri precedenti) Vita dell'IG |
Richiesta di estendere la durata degli IG da 30 a 90 giorni. | Una modifica di questo tipo richiede un'attenta valutazione, in cui vengono messi a confronto i vantaggi per il settore e l'impatto sugli utenti di Chrome e su altri stakeholder. Stiamo valutando questa richiesta e saremo lieti di ricevere ulteriori feedback qui. |
| (segnalato anche nei trimestri precedenti) modelingSignals |
Richiedi un nuovo campo oltre a modelingSignals che può codificare solo le informazioni su impressioni e clic. | Abbiamo risposto a questo feedback con una controproposta qui. Stiamo collaborando attivamente con il settore per comprendere le sue opinioni sulla nostra proposta e al momento stiamo valutando i vantaggi per il settore rispetto all'impatto sugli utenti di Chrome e su altri stakeholder. |
| Elementi aggiuntivi in reportWin() | Fornisci bit aggiuntivi in reportWin() rispetto al limite attuale di 12 prima di 3PCD. | Al momento stiamo valutando approcci per supportare questo caso d'uso. Ci stiamo prendendo del tempo perché stiamo anche cercando approcci che ci consentano di avere un piano per la privacy a lungo termine. |
| Progettazione dell'asta | Richieste per una singola asta che restituisce gli URL di rendering con il relativo punteggio. | Abbiamo preso in considerazione la possibilità di condividere più URL di rendering e il relativo punteggio da una singola asta PA, ma non l'abbiamo implementata per motivi di privacy. Comprendiamo la necessità di evitare di mostrare lo stesso annuncio più volte a un utente in una singola pagina e saremo lieti di ulteriori discussioni su GitHub. |
| reportWin | registrare campi arbitrari nella funzione reportWin(). | Questo accade già oggi durante il periodo di test. Una volta terminato il supporto dei 3PC in Chrome, verrà eseguita la migrazione della versione forDebuggingOnly dell'API per abilitare il debug con campionamento ridotto, come specificato qui. |
| Venditori di componenti | Avere un meccanismo indipendente per conteggiare le proprie impressioni e altri eventi e non dover fare affidamento esclusivamente sui report delle tecnologie pubblicitarie. | Questa richiesta di funzionalità è in coda per ulteriori accertamenti. Non prevediamo di risolvere il problema durante il periodo di test agevolato da Chrome. |
| Fatturazione costo per clic | Implementa la fatturazione basata sul costo per clic nell'API PA. | Stiamo valutando questa richiesta qui e al momento la consideriamo una richiesta di suggerimenti su come implementarla con l'attuale API. |
| browserSignals | Aggiungi incomingBidInSellerCurrency alla specifica browserSignals per i report per il venditore. | Stiamo valutando questa richiesta e saremo lieti di ricevere ulteriori feedback qui. |
| Supporto della proprietà della logica e dei metadati lato acquirente per le piattaforme non DSP | L'attuale progettazione dell'API potrebbe comportare un cambiamento significativo nelle campagne di retargeting a livello di prodotto, in quanto potrebbe essere necessario eseguirne la migrazione a piattaforme che fungono sia da DSP che da fornitori di DCO. | Stiamo discutendo di questo problema e saremo lieti di ricevere ulteriori feedback qui . |
| Supporto della proprietà della logica e dei metadati lato acquirente per le piattaforme non DSP | Condividi esempi in cui la DSP non è il proprietario dell'IG. | Sappiamo che gli utenti che non fanno offerte vorrebbero utilizzare alcune funzionalità degli IG, ma non altre. Stiamo valutando attivamente le opzioni per risolvere questi casi d'uso e saremo lieti di ricevere ulteriori feedback qui. |
| Controlli di timeout | I publisher devono essere in grado di stabilire il numero di IG in grado di partecipare e il timeout di primo livello / globale. | Siamo consapevoli che esiste la necessità di controlli e visibilità avanzati dei timeout tra il venditore di primo livello e il venditore di componenti e stiamo valutando questa richiesta. |
| Più dimensioni degli annunci | Supporto dell'API PA per i casi d'uso relativi a più dimensioni degli annunci. | Stiamo valutando questa richiesta e accogliamo con favore ulteriori feedback dall'ecosistema. |
| Documentazione | Esiste un elenco di attributi IG soggetti a k-anon? | Abbiamo risposto a questa domanda qui. |
| Debug | Funzionalità di debug migliorate per l'API PA. | Riconosciamo l'importanza di strumenti di debug solidi per gli sviluppatori che lavorano con l'API PA. Ci impegniamo a migliorare l'esperienza degli sviluppatori esplorando modi per integrare meglio i recuperi dei file .well-known con gli strumenti per sviluppatori. Il nostro obiettivo è fornire una maggiore visibilità e funzionalità di risoluzione dei problemi nell'ambiente di sviluppo. Stiamo discutendo ulteriormente di questo problema qui e saremo lieti di ricevere ulteriori feedback. |
| Etichette | Per tutti gli utenti delle etichette del trattamento in modalità B sono state attivate le API Privacy Sandbox? | Le assegnazioni ai gruppi sperimentali di Chrome vengono determinate in modo casuale e sono indipendenti dalle impostazioni di Chrome configurate dall'utente. Sebbene queste API possano essere disponibili per gli utenti all'interno di gruppi di trattamento specifici (ad es. treatment_1.*), la loro funzionalità può essere modificata o disattivata tramite le impostazioni di Chrome. Gruppo control_2 della 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 inserito in un iframe o in un frame delimitato. Una volta terminata l'esecuzione di reportWin() e iniziato il rendering dell'annuncio, verranno recuperati gli URL forniti a sendReportTo(). |
| (Segnalato anche nei trimestri precedenti) Assistenza per i test A/B |
Richiedi assistenza per i test A/B dell'API PA. | Stiamo discutendo di questa richiesta qui e saremo lieti di ricevere ulteriori feedback. |
| Formattazione del traffico | La proposta di Google per gestire la presa di decisioni necessaria tramite il server KV non è utile, in quanto i venditori non sono in grado di interagire con il proprio backend, il che rende difficile la definizione del traffico. | Come discusso nel problema di GitHub, l'indicazione dell'eventuale presenza di IG nelle singole DSP potrebbe comportare problemi di fingerprinting degli utenti. Abbiamo suggerito altre alternative nel problema e siamo aperti ad altri suggerimenti. |
| Formattazione del traffico | I meccanismi di memorizzazione nella cache aggiungono un livello significativo di complessità e impediscono alle DSP di conoscere la vera forma del traffico per cui fanno offerte. | Il meccanismo di memorizzazione nella cache è stato semplicemente proposto come suggerimento. Le tecnologie pubblicitarie possono scegliere di utilizzare i suggerimenti più adatti al loro caso d'uso e invitiamo a partecipare alla discussione qui. |
| Etichette | Chrome deve condividere l'etichetta come parametro nelle richieste ai server attendibili di acquirenti e venditori. | Sembra una richiesta ragionevole, in quanto sembra essere in linea con l'obiettivo di un utilizzo responsabile dei dati di Instagram. Tuttavia, stiamo valutando la richiesta, soggetta a revisione interna, e forniremo aggiornamenti pubblici in merito man mano che le discussioni proseguono. |
| Uso dell'API | Chiarimento della definizione esplicita del gruppo "control_1" nel documento "Indicazioni aggiuntive del CMA per terze parti sui test". Nello specifico, c'è il timore che una modifica del testo possa essere interpretata erroneamente come un'esclusione di tutte le API Privacy Sandbox da control_1. | Abbiamo espresso le nostre opinioni in questo thread di GitHub. Detto questo, non siamo in grado di parlare per conto della CMA e ti consigliamo di segnalare eventuali problemi relativi all'interpretazione delle linee guida per i test direttamente alla CMA. |
| Uso dell'API | Chrome consentirà di chiamare joinAdInterestGroup() in una pagina vuota durante il reindirizzamento a un'altra risorsa? | Se un utente visita un sito, il proprietario del sito può delegare a terze parti la possibilità di chiamare joinAdInterestGroup. Questa delega consente a terze parti di creare IG senza dover aggiungere alcun tipo di reindirizzamento tramite una pagina vuota. Accogliamo con favore i feedback su motivi specifici per creare IG nel mezzo di un reindirizzamento anziché utilizzare il meccanismo di delega previsto. |
| Uso dell'API | Le piattaforme di scambio pubblicitario devono essere in grado di scrivere gli IG nelle pagine di proprietà dei publisher con cui collaborano e poi delegare l'autorizzazione a fare offerte per l'IG a qualsiasi acquirente o DSP. | Abbiamo ricevuto il feedback e stiamo valutando se è possibile supportare una richiesta di questo tipo. Accogliamo con favore ulteriori feedback dall'ecosistema. |
| Uso dell'API | Non viene inviata alcuna 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 vittorie a livello di evento all'interno del sistema di asta per la privacy (PA). In circostanze in cui tutte le offerte vengono rifiutate durante un'asta PA, non è previsto che queste funzioni vengano richiamate perché non viene determinato alcun vincitore. Un recente aggiornamento di Chrome potrebbe spiegare le discrepanze in cui gli URL passati a forDebuggingOnly.reportAdAuctionLoss() non vengono visualizzati nel riquadro Rete di DevTools. Ti consigliamo di verificare questa funzionalità utilizzando una build del canale Canary o Dev di Chrome. |
| Uso dell'API | Il valore adCost restituito da generateBid può essere negativo (è già arrotondato in modo stocastico a 2 byte)? | AdCost è il costo per clic o di conversione dell'inserzionista passato da generateBid() a reportWin(). Questo valore può essere Null o un numero a virgola mobile. I valori negativi verranno ignorati e non trasmessi. Il valore verrà arrotondato in modo stocastico quando viene passato. |
| Miglioramento dell'API | I server di esecuzione attendibili e criptati possono essere utilizzati per gestire il targeting, le coorti, l'attribuzione e le aste anziché il browser Chrome? | Ti consigliamo di esplorare i componenti e le opzioni basati su TEE nell'API PA (ad es. server KV e servizi B&A), nonché i componenti basati su TEE di Attribution Reporting e Private Aggregation (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 all'annuncio (come i tag annuncio)? | Questo tipo di modifica cambia radicalmente le proprietà della privacy dell'API PA, pertanto non è una soluzione che stiamo prendendo in considerazione. |
| Controlli dei publisher | I publisher possono bloccare le creatività dell'API PA sulle loro pagine? | Chrome ha una proposta per la scansione delle creatività in tempo reale che non è ancora disponibile per i test. Anche se questa funzionalità non è ancora disponibile, abbiamo notato che la maggior parte delle SSP ha creato soluzioni per abilitarla. |
| Uso dell'API | Qual è il limite di dimensioni per perBuyerSignals? | Nella sua forma classica, perBuyerSignals non presenta limitazioni intrinseche di dimensioni in Chrome. I vincoli principali sono che i dati rimangono serializzabili in JSON e non causano un consumo eccessivo di memoria. Tuttavia, tieni presente che perBuyerSignals molto grandi e complessi potrebbero influire negativamente sul rendimento. Esiste un metodo alternativo per trasmettere perBuyerSignals tramite directFromSellerSignalsHeaderAdSlot. Questo approccio trasmette perBuyerSignals all'interno di un'intestazione, rispettando un limite massimo di dimensioni di 10 KB per l'intera risposta dell'intestazione. Inoltre, i singoli server potrebbero imporre le proprie limitazioni alle dimensioni massime dell'intestazione. |
| Documentazione | La documentazione relativa alla chiamata registerAdBeacon dall'interno di generateBid deve essere modificata. | Abbiamo aggiornato questa documentazione il 17 febbraio. |
| Uso dell'API | In che modo reportEvent sceglie l'URL beacon corretto tra più opzioni registrate? | Ogni asta genera una configurazione separata, che a sua volta genera una mappa dei report separata. Le singole aste (e i relativi frame) sono completamente separate l'una dall'altra e non condividono dati. L'articolo "Report sugli annunci con frame delimitati" fornisce ulteriori dettagli su questo argomento. |
| Interfaccia utente di Chrome | Aggiungi un filtro nella scheda "Applicazione -> Gruppi di interesse" di DevTools di Chrome, che consente di filtrare in base al proprietario del gruppo di interesse (o forse anche al nome del gruppo di interesse). | Stiamo valutando questa richiesta e accogliamo con favore ulteriori feedback dall'ecosistema. |
| Chrome headless | Supporto dell'API PA in Chrome headless. | Alcuni componenti dell'API PA sono legati a Chrome, ad esempio le chiamate k-anon ai server di Google, che potrebbero non funzionare nella "vecchia" versione di Chrome headless. Riteniamo che questo problema possa essere risolto con la "nuova" versione di Chrome headless rilasciata in Chrome 112. |
| Uso dell'API | Nel caso di segnalazione delle perdite con reportAdAuctionLoss, in molti casi viene visualizzato "topLevelWinningBid=0". Qual è l'interpretazione di questa situazione? | Il valore topLevelWinningBid proviene dalla funzione scoreAd() all'interno del componente del venditore di primo livello. Questo valore è importante per determinare l'esito dell'asta di primo livello. In base alla spiegazione, un valore topLevelWinningBid pari a zero o a 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 basati sul gruppo di interesse che non superano un candidato basato sul targeting per contesto. Anche se un valore topLevelWinningBid pari a zero può indicare che è stata scelta un'asta contestuale, la specifica dell'API PA riconosce che altri fattori potrebbero contribuire a questo risultato. |
| Test A/B delle modalità | Chiarimento sui prompt di attivazione e disattivazione della selezione del traffico per la modalità B e la modalità A. | I criteri di inclusione per la modalità A e la modalità B sono gli stessi. L'obiettivo è avere gruppi rappresentativi del normale traffico di Chrome, purché supportino le API Privacy Sandbox e il metodo di etichettatura, pertanto alcune configurazioni dei client non sono compatibili. Ai fini dell'esperimento, è importante confrontare solo il traffico etichettato con altro traffico etichettato. Gli utenti in modalità B hanno attivato la funzionalità Protezione antitracciamento e, di conseguenza, ricevono una notifica relativa a questa funzionalità. |
| Miglioramento dell'API | "lifetimeMs" può essere incluso come proprietà diretta all'interno della chiamata joinAdInterestGroup o gestito come argomento separato? | Stiamo valutando attentamente il feedback della community di sviluppo web in merito alla funzionalità "joinAdInterestGroup" all'interno della proposta dell'API PA. Un punto di discussione chiave riguarda il metodo ottimale per gestire la durata degli IG. Stiamo valutando i vantaggi di un argomento separato per il parametro "lifetimeMs ", in quanto favorisce la flessibilità e l'adattabilità per potenziali miglioramenti futuri della specifica. Stiamo discutendo di questo problema qui e saremo lieti di ricevere ulteriori feedback. |
| Uso dell'API | Potenziale 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 impegnato nel perfezionamento continuo del framework dell'API PA. Apprezziamo la discussione sui potenziali tassi di falsi negativi derivanti da collisioni di ID browser. Stiamo valutando attentamente questo feedback e ci impegneremo a garantire che le analisi aggiornate riflettano in modo completo tutti i fattori pertinenti. Il nostro impegno è offrire una soluzione che garantisca i risultati in termini di privacy desiderati, mantenendo al contempo accuratezza e affidabilità. Stiamo discutendo di questo problema qui e saremo lieti di ricevere ulteriori feedback. |
| Uso dell'API | È necessario un identificatore del browser a bassa entropia per impedire ai client di inviare ripetutamente richieste di "join" per lo stesso oggetto in un sistema di k-anonimizzazione? | Siamo consapevoli e apprezziamo la discussione in corso sull'utilizzo degli identificatori dei browser nell'implementazione di sistemi di anonimizzazione k. Siamo consapevoli delle preoccupazioni sollevate in merito alle potenziali implicazioni sulla privacy di questi identificatori. Sebbene la nostra implementazione iniziale abbia utilizzato un identificatore a bassa entropia come meccanismo anti-abuso, stiamo esplorando attivamente tecniche alternative, come gli Anonymous Counting Token, che danno la priorità alla privacy degli utenti mantenendo l'integrità del sistema. Ci impegniamo a trovare soluzioni che bilancino l'utilizzo responsabile dei dati con solide misure di tutela della privacy e accogliamo con favore il dialogo continuo con la community di ricerca. Ne stiamo discutendo qui e saremo lieti di ricevere ulteriori feedback . |
| Uso dell'API | AMP (Accelerated Mobile Pages) supporta l'API PA. | Al momento AMP non supporta in modo nativo l'API PA. Siamo lieti di ricevere ulteriori feedback dall'ecosistema se l'assistenza di AMP è una priorità elevata. |
| Miglioramento dell'API | Valuta la possibilità di rimuovere il tipo dai controlli di k-anonimità. | Stiamo valutando attentamente il feedback sulla potenziale ottimizzazione delle strutture delle richieste di anonimizzazione k. Comprendiamo il suggerimento di consolidare i parametri e potenzialmente unificare i tipi per semplificare la procedura. Il nostro obiettivo è garantire efficienza e manutenibilità e stiamo valutando tutte le opzioni mentre continuiamo a sviluppare le nostre soluzioni per la privacy. Stiamo discutendo di questo problema qui e saremo lieti di ricevere ulteriori feedback. |
| Interfaccia utente di Chrome | Richiesta di un meccanismo per consentire agli utenti meno tecnici di visualizzare e gestire facilmente i gruppi di interesse a cui appartengono, inclusi potenziali controlli a livello di sito web per la disattivazione. | Siamo consapevoli dell'importanza di fornire strumenti intuitivi per comprendere e gestire gli IG. Abbiamo valutato attentamente diversi metodi e abbiamo riscontrato che l'identificazione dei gruppi tramite il sito web a cui sono stati aggiunti offre il miglior equilibrio tra chiarezza e protezione della privacy. Attualmente, la gestione globale degli IG si trova nelle impostazioni di Chrome. Stiamo continuamente cercando modi per migliorare ulteriormente l'esperienza utente in questo ambito. Stiamo discutendo di questo problema qui e saremo lieti di ricevere ulteriori feedback. |
| Sicurezza delle API | L'API PA è vulnerabile alle fughe di dati sulla privacy tramite le interazioni con gli annunci delle creatività, anche nel contesto dei frame delimitati? | Siamo consapevoli della potenziale fuga di informazioni tramite interazioni con gli annunci sofisticate. Stiamo esaminando attivamente l'interazione tra i frame delimitati, l'API PA e i potenziali vettori di attacco. L'attenuazione dei rischi per la privacy è una priorità assoluta e ci impegniamo a sviluppare soluzioni solide che bilancino l'innovazione con la protezione degli utenti. Stiamo discutendo di questo problema qui e saremo lieti di ricevere ulteriori feedback. |
| Latenza | Il valore predefinito di 50 ms per il timeout della logica di offerta dell'acquirente è realistico? | Siamo consapevoli dei dubbi sollevati in merito a potenziali incongruenze tra la specifica e i tempi delle richieste di rete per la logica di offerta. Stiamo esaminando attivamente le specifiche per assicurarne l'accuratezza e stiamo studiando le impostazioni di timeout predefinite ottimali per bilanciare prestazioni e fattibilità. Stiamo discutendo di questo problema qui e saremo lieti di ricevere ulteriori feedback. |
| Documentazione | Potenziale fuga di dati sulle tempistiche nella specifica, in cui un sito web potrebbe dedurre se un annuncio non ha superato la soglia di k-anonimità e le potenziali implicazioni per il monitoraggio tra siti. | Siamo a conoscenza del problema sollevato in merito a una potenziale fuga di dati sui tempi. Abbiamo confermato una discrepanza nella specifica e stiamo adottando misure per garantire che lo stato di anonimità k degli annunci venga determinato prima dell'asta per evitare fughe di dati simili. Prendiamo molto seriamente questi problemi e aggiorneremo la specifica in base a queste modifiche. Stiamo discutendo di questo problema qui e saremo lieti di ricevere ulteriori feedback. |
| Uso dell'API | Metodi per implementare una lista bloccata di SSP all'interno dell'API PA. | Siamo consapevoli della necessità di meccanismi per gestire le limitazioni degli annunci da parte delle SSP. Ti invitiamo a esplorare 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 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 saremo lieti di ricevere ulteriori feedback. |
| Uso dell'API | Un utente può chiedere al proprio browser di fingere di utilizzare l'API PA in un modo che i siti non possano rilevare? | Siamo consapevoli che, nella sua forma attuale, la disattivazione dell'API PA potrebbe essere rilevabile dai siti web. Stiamo lavorando attivamente a funzionalità come le offerte aggiuntive e il targeting per esclusione, oltre al rendering dei frame delimitati, per migliorare la privacy e offrire opzioni di disattivazione non rilevabili. Stiamo discutendo di questo problema qui e saremo lieti di ricevere ulteriori feedback. |
| Test A/B delle modalità | Traffico del data center che si presume sia del trattamento 1.1. | Il team di Chrome ha confermato con il team di GAM che questo traffico viene ora escluso dall'esperimento. Stiamo discutendo di questo problema qui e saremo lieti di ricevere ulteriori feedback. |
| Uso dell'API | Efficacia e equità dell'implementazione di interestGroupBuyers nell'API PA. | Siamo consapevoli della discussione in corso sull'efficienza e sull'equità del campo "interestGroupBuyers" nelle aste dell'API PA. Siamo consapevoli dei compromessi tra efficienza, privacy ed equità del mercato. Sebbene i venditori debbano gestire i rapporti commerciali con gli acquirenti, stiamo esplorando modi per ottimizzare la procedura di corrispondenza. Potrebbero essere inclusi aggiustamenti dinamici basati su dati in tempo reale e modelli ibridi. Ci impegniamo a trovare soluzioni che diano la priorità alla privacy degli utenti e supportino un ecosistema pubblicitario competitivo. Stiamo discutendo di questo problema qui e saremo lieti di ricevere ulteriori feedback. |
| Interfaccia utente di Chrome | Potenziali problemi di memoria e chiarezza dell'interfaccia utente relativi all'IG in Chrome. | Siamo consapevoli dei dubbi sollevati in merito alla visualizzazione degli IG in DevTools. Sebbene la visualizzazione attuale rifletta tutti gli eventi IG per il monitoraggio storico, siamo consapevoli del valore di fornire una visibilità più chiara sullo stato attuale degli IG archiviati. Esamineremo le ottimizzazioni e i potenziali miglioramenti dell'interfaccia utente per migliorare le informazioni per gli sviluppatori. In merito alla gestione della memoria, l'implementazione dell'IG è progettata per evitare perdite di memoria, ma monitoriamo e ottimizziamo continuamente l'utilizzo delle risorse. Stiamo discutendo di questo problema qui e saremo lieti di ricevere ulteriori feedback. |
| Documentazione | L'autore del post originale riscontra un errore quando tenta di utilizzare dimensioni degli annunci denominate direttamente nel campo "sizeGroup" della funzione "joinAdInterestGroup". Vuole sapere se si tratta di un comportamento previsto. | Siamo consapevoli dell'importanza di semplificare la configurazione degli annunci all'interno della funzione "joinAdInterestGroup". Stiamo lavorando attivamente per risolvere questo problema 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 saremo lieti di ricevere ulteriori feedback. |
| Etichetta di test facilitata da Chrome | Richiedi di avere dati diretti sulla modalità A rispetto alla modalità B e sulle etichette esatte in sendReportTo per consentirci di monitorare l'esperimento in modo coerente. | Stiamo discutendo di questa richiesta qui e saremo lieti di ricevere ulteriori feedback. |
| Documentazione | Il nome di dominio del venditore è incluso nelle richieste inviate al server attendibile di un venditore a scopo di convalida? | Siamo consapevoli dell'omissione iniziale del parametro nome host dalla documentazione dell'API KV Server di Protected Audience. Vogliamo rassicurare gli sviluppatori che il nome di dominio del venditore è incluso automaticamente nelle richieste al server attendibile del venditore. Questa funzionalità è essenziale per procedure di convalida degli annunci efficaci. Abbiamo aggiornato la documentazione per risolvere questo problema e continueremo a dare la priorità alla chiarezza e alla trasparenza per la community degli sviluppatori. Stiamo discutendo di questo problema qui e saremo lieti di ricevere ulteriori feedback. |
| Uso dell'API | Potenziali metodi per includere il nome dell'IG nelle chiamate di monitoraggio delle impressioni degli annunci a fini di generazione di report. | Ci impegniamo a trovare il giusto equilibrio tra la necessità di meccanismi di generazione di report solidi e il principio fondamentale della privacy degli utenti. L'inclusione dei nomi degli utenti di Instagram nel monitoraggio delle impressioni degli annunci è soggetta a misure di protezione di k-anonymity progettate per impedire l'identificazione delle persone. Continueremo a esplorare soluzioni di generazione di report innovative nel rispetto di questi vincoli relativi alla privacy. Stiamo discutendo di questo problema qui e saremo lieti di ricevere ulteriori feedback. |
| API Feature | Richiedi al server attendibile dell'acquirente di ricevere le intestazioni HTTP di Client Hints. | Monitoriamo questa richiesta di funzionalità qui. |
| Uso dell'API | Se il file di delega deve richiedere il caricamento dell'intestazione "Access-Control-Allow-Origin", dato che detta il comportamento dell'abbonamento 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 esplorando dei metodi per ottimizzare questa procedura mantenendo una solida postura di sicurezza. Stiamo discutendo di questo problema qui e saremo lieti di ricevere ulteriori feedback. |
| Uso dell'API | Consente agli ad server di personalizzare le creatività all'interno del framework dell'API PA. | Siamo consapevoli del 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 "IG combinato" in cui è possibile combinare la logica di selezione delle offerte e delle creatività degli annunci. Il nostro obiettivo è trovare un equilibrio tra l'attivazione di funzionalità solide per le creatività degli annunci e la salvaguardia della privacy degli utenti. Qui accogliamo con favore ulteriori collaborazioni e feedback sull'evoluzione dell'API per soddisfare le esigenze di tutti gli stakeholder. |
| Problemi di privacy | Disponibilità di identificatori alternativi (ad es. RampID, ID5) nelle richieste di offerta contestuale potrebbero minare gli obiettivi di privacy dell'API Protected Audience facilitando la raccolta dei dati su più siti. | Siamo consapevoli della potenziale tensione tra gli identificatori tra siti e gli obiettivi di privacy dell'API PA. Sebbene i publisher possano scegliere di condividere questi identificatori, lo scopo fondamentale della progettazione dell'API PA è disaccoppiare la selezione degli annunci dalla necessità del monitoraggio tra siti. Ci impegniamo a promuovere un ecosistema pubblicitario incentrato sulla privacy e invitiamo gli sviluppatori a dare la priorità all'approccio dell'API PA. Stiamo discutendo di questo problema qui e saremo lieti di ricevere ulteriori feedback. |
| Memorizzazione nella cache | Esiste un modo per impedire il riutilizzo degli script di offerta in più aste? | Siamo a conoscenza del comportamento di memorizzazione nella cache osservato degli script di offerta all'interno del framework dell'API PA. Sebbene siano supportati i meccanismi di memorizzazione nella cache HTTP standard, esiste la possibilità di riutilizzare gli script nelle aste a causa del comportamento di sospensione del dispositivo e della progettazione degli esecutori delle offerte. Il team sta studiando soluzioni per offrire agli acquirenti un maggiore controllo sulla memorizzazione nella cache dello script per gestire in modo efficace le loro strategie di offerta. Stiamo discutendo di questo problema qui e saremo lieti di ricevere ulteriori feedback. |
| Uso dell'API | Centralizzare la generazione di report sull'attività di offerta in tutti gli IG per una DSP, rispettando al contempo la privacy degli utenti. | Diamo la priorità alla privacy degli utenti durante la progettazione dell'API PA. Sebbene la generazione di report diretti sui singoli eventi di offerta non sia fattibile a causa dei rischi di monitoraggio tra siti, offriamo meccanismi come lo spazio di archiviazione condiviso e l'aggregazione privata. In questo modo, le DSP possono ottenere approfondimenti aggregati sulle attività di offerta, nel rispetto della privacy degli utenti. |
| Uso dell'API | Il recupero da sendReportTo() in reportResult() si verifica solo il 94% delle volte rispetto a un recupero registrato con forDebuggingOnly.reportAdAuctionWin(). | Sebbene possano non avere lo stesso tempismo, è possibile che entrambi gli URL vengano recuperati contemporaneamente. In alcuni casi, il worklet del venditore del componente è 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 necessario per ricaricare il worklet influiscono sul timeout di 50 ms di reportResult(). Tieni presente che Chrome utilizzerà le intestazioni di memorizzazione nella cache per definire il proprio comportamento di recupero nei casi in cui il worklet debba essere ricaricato. Scopri di più sulle fasi di un'asta PA qui. |
| K-anonymity | Richiesta di conferma che il nome del gruppo di interesse non influisca sull'anonimizzazione k della pubblicazione degli annunci. | Affinché una creatività sia considerata k-anonima, la tupla di URL del proprietario dell'IG, URL dello script di offerta, URL della creatività e dimensioni dell'annuncio deve soddisfare la soglia specificata (k) in un periodo di tempo passato (w). Lo stato di k-anonimità viene aggiornato periodicamente (p). |
| Interfaccia utente di Chrome | Proposta per fornire il tipo di "visibilità interna" offerto da molti framework MVC, ORM e così via. Ad esempio, inizia con la registrazione semplice di eventi interni selezionati in un nuovo riquadro nella sezione Strumenti per gli sviluppatori --> Applicazione --> Applicazione | Stiamo discutendo della proposta qui e saremo lieti di ricevere ulteriori feedback. |
| Interfaccia utente di Chrome | L'unione all'IG di Dev Tools non mostra gli elementi relativi alla priorità. | Abbiamo risolto il 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 saremo lieti di ricevere ulteriori feedback dall'ecosistema. |
| Richiesta di funzionalità API | L'API PA può essere estesa per supportare le transazioni multimediali non RTB e mantenere casi d'uso critici come la pubblicazione di annunci e la DCO? | Stiamo discutendo del problema qui e saremo lieti di ricevere ulteriori feedback. |
| Tempo di attesa dell'asta publisher | I publisher devono avere il controllo sulla durata dell'asta per evitare la perdita di impressioni, in particolare nelle configurazioni di asta basata su header in cui gli annunci vengono selezionati in sequenza. | Siamo consapevoli dell'importanza di offrire ai publisher un controllo granulare sui timeout delle aste di annunci. Stiamo valutando attivamente come implementare un meccanismo di timeout dell'asta globale, potenzialmente all'interno dell'oggetto "auctionConfig", tenendo conto con attenzione dei casi limite. Lo scopo di questa funzionalità è ottimizzare il tasso 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 saremo lieti di ricevere ulteriori feedback. |
| Miglioramento dell'API | L'attuale design degli IG nell'API PA comporta dimensioni dei metadati elevate a causa di renderURL di grandi dimensioni. I tester vorrebbero un modo per comprimere questi URL per una maggiore efficienza. | Siamo consapevoli dell'importanza di ottimizzare le dimensioni dei metadati di Instagram, in particolare per le aste di annunci sensibili all'efficienza. Riteniamo che una soluzione basata su modelli per la compressione di renderURL offra un potenziale significativo. Valuteremo attentamente i design dei modelli proposti e ci assicureremo che qualsiasi soluzione implementata includa meccanismi solidi di prevenzione degli abusi per mantenere la stabilità del browser. La collaborazione con la community degli standard web per sviluppare l'approccio ottimale, tenendo presenti queste considerazioni, rimane una priorità. Stiamo discutendo del problema qui e saremo lieti di ricevere ulteriori feedback. |
| Uso dell'API | I tester che gestiscono i formati degli annunci nativi vogliono ottimizzare la procedura di asta di Privacy Sandbox recuperando più risultati di annunci in una singola chiamata per ridurre il carico della rete e migliorare la velocità di rendering degli annunci. | Siamo consapevoli dei problemi di rendimento sollevati per il rendering degli annunci nativi in Privacy Sandbox. Ci impegniamo a trovare un equilibrio tra efficienza e misure efficaci di tutela della privacy degli utenti. Sebbene la restituzione di più annunci con punteggi completi comprometta la privacy, stiamo esplorando attivamente modi per ottimizzare la procedura di asta. Ci impegniamo a migliorare il supporto dell'API PA per i formati degli annunci nativi e a studiare meccanismi alternativi per migliorare l'efficienza nel rispetto dei rigidi vincoli di privacy di Privacy Sandbox. Stiamo discutendo del problema qui e saremo lieti di ricevere ulteriori feedback. |
| Uso dell'API | Flessibilità nella modalità di assegnazione del punteggio e di ordinamento delle offerte per gli annunci in Privacy Sandbox, in particolare per rappresentare i livelli di priorità o le regole del marketplace privato. | Siamo consapevoli della necessità di un controllo granulare sul punteggio e sull'ordinamento degli annunci in Privacy Sandbox, in particolare in scenari di offerta complessi. Siamo consapevoli che le soluzioni proposte utilizzano tuple e funzioni matematiche per ottenere un punteggio multidimensionale senza sacrificare la privacy degli utenti. Sebbene questi approcci possano aggiungere complessità per gli sviluppatori, offrono l'espressività necessaria. Ci impegniamo a esplorare modi per semplificare queste procedure, potenzialmente tramite funzioni di assistenza o linee guida, per garantire un utilizzo ottimale delle funzionalità di Privacy Sandbox per la logica delle aste avanzate. Stiamo discutendo di questo problema qui e saremo lieti di ricevere ulteriori feedback. |
| reportEvent() | Aggiungi un nuovo evento riservato (ad esempio un beacon automatico) attivato dal browser una volta inizializzato un frame con una creatività dell'annuncio. | Stiamo discutendo di questa richiesta qui e saremo lieti di ricevere ulteriori feedback. |
| adCost | Consente la suddivisione di adCost. | Ogni valore del costo è un'opportunità per inviare una quantità limitata di informazioni dall'asta. Consentire un intero elenco di N di questi costi sarebbe sufficiente per inviare un intero identificatore utente, il che consentirebbe il monitoraggio tra siti. Ne stiamo discutendo qui e saremo lieti di ricevere ulteriori feedback. |
| resolveToConfig | resolveToConfig deve essere ereditato dal livello superiore ed essere esposto in browserSignals? | Stiamo discutendo di questa richiesta qui e saremo lieti di ricevere ulteriori feedback. |
| Strumenti ottimizzati | Esiste qualcosa di simile a chrome://topics-internals, ma per l'API PA? | Non esiste niente di esattamente uguale. Tuttavia, sono disponibili strumenti per sviluppatori completi per l'API PA . |
| Etichette | Chrome può utilizzare le etichette per identificare il 20% della popolazione k-anon? | Stiamo valutando questa richiesta e accogliamo con favore ulteriori feedback dall'ecosistema. |
| Documentazione | I worklet di asta di Privacy Sandbox diventeranno tipi di worklet standard? | A causa di requisiti unici di privacy e sicurezza, questi worklet sono molto diversi dai tipi di worklet del browser standard, pertanto non prevediamo che diventeranno presto tipi di worklet standard all'interno della specifica HTML. Ci impegniamo a migliorare le nostre risorse per gli sviluppatori con spiegazioni chiare sull'ambiente di implementazione ed esecuzione dei worklet delle aste, rendendo queste informazioni più accessibili per i partecipanti a Privacy Sandbox. Abbiamo discusso ulteriormente di questo qui. |
| Server KV Bring Your Own Server (BYOS) | Le parti potrebbero essere in grado di apprendere più IG (dello stesso proprietario) uniti da un utente tramite query sui servizi KV in una configurazione del servizio KV BYOS. | Ciò non sarà più possibile quando i server KV vengono eseguiti in TEE e potremo garantire che rispettino il modello di attendibilità pubblicato. |
| userBiddingSignals | aggiornare parte di "userBiddingSignals" mantenendone altri. | Questa operazione è già possibile senza alcuna modifica all'API. |
| Uso dell'API | Implementare la quota limite in più IG all'interno di Privacy Sandbox, potenzialmente utilizzando il server KV o i dati "prevWinsMs" modificati. | Siamo consapevoli della necessità di funzionalità avanzate di limitazione della frequenza in Privacy Sandbox. Siamo consapevoli che le attuali limitazioni alla condivisione dei dati tra gli IG possono comportare delle difficoltà durante l'implementazione di queste strategie. Sebbene il server KV fornisca un potenziale meccanismo con misure di salvaguardia della privacy appropriate, incoraggiamo gli sviluppatori a esplorare le soluzioni all'interno di un singolo modello IG. Stiamo discutendo di questo problema qui e saremo lieti di 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 ritardi non necessari. | Siamo consapevoli della necessità di migliorare la coordinazione del timeout tra i venditori di primo livello e i venditori di componenti all'interno di Privacy Sandbox. Stiamo esaminando attivamente l'aggiunta di nuovi meccanismi di timeout, incluso un potenziale timeout per l'intera asta, e stiamo cercando modi per applicare timeout di primo livello alle aste dei componenti. Il nostro obiettivo è migliorare l'efficienza e la prevedibilità per tutti i partecipanti alla procedura di asta di Privacy Sandbox. Stiamo discutendo di questo problema qui e saremo lieti di ricevere ulteriori feedback. |
Servizi Protected Audience
| Theme del feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Trusted Execution Environment (TEE) | È più costoso eseguire TEE nei cloud pubblici rispetto ai data center di ad tech on-premise? | La nostra risposta è simile a quella dei trimestri precedenti: il nostro attuale modello di sicurezza TEE trae vantaggio dalle pratiche di implementazione del cloud pubblico. In particolare, gli attuali TEE basati su hardware non proteggono da tutti gli attacchi fisici. I nostri fornitori di cloud pubblico supportati esistenti, AWS e Google Cloud, hanno progettato e implementato mitigazioni per i rischi di accesso fisico, inclusi quelli dei dipendenti. Consulta i seguenti dettagli sull'assistenza on-premise. Gli esperti di ad tech ci hanno comunicato che l'utilizzo di servizi cloud è più costoso rispetto ai data center di ad tech on-premise. Anche se non siamo in grado di valutare queste affermazioni, accogliamo con favore ulteriori feedback sui costi e continuiamo a valutare le opzioni per espandere il nostro supporto per i TEE. |
| TEEs | Supporto per le TEE in ambienti cloud non pubblici | La nostra risposta è simile a quella dei trimestri precedenti: sebbene continuiamo a esplorare il supporto per opzioni oltre le soluzioni basate su cloud pubblico, al momento non abbiamo in programma di supportare i TEE on-premise. A questo punto, dati i requisiti di sicurezza di Privacy Sandbox e le notevoli 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 la soluzione più vantaggiosa per l'ecosistema. Tuttavia, accogliamo con favore ulteriori feedback sul motivo per cui questo requisito è necessario e fattibile, dati i vincoli di privacy e sicurezza. |
| Altri cloud provider | Supporto per altri provider cloud | Siamo sempre aperti a suggerimenti per altri provider cloud, ma prevediamo 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 per l'API B&A Services? Verrà data la priorità sopra o sotto Protected Audience del browser Chrome nelle aste di dispositivi? | La nostra risposta è simile a quella dei trimestri precedenti: rimaniamo impegnati con l'attuale design 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 hanno subito una procedura di standardizzazione. | La proposta di servizi B&A è nel bel mezzo di una fase del processo di standardizzazione e accogliamo con favore un maggiore coinvolgimento a supporto di questo obiettivo. È iniziata con una proposta (basata su proposte precedenti), è in fase di incubazione pubblica tramite ampie discussioni aperte al W3C e gli sviluppatori interessati possono iniziare a sperimentarla e fornire feedback. Questo è il pattern usuale per lo sviluppo di funzionalità web, come descritto ad esempio nel nostro post del blog qui. |
| Server KV | Esponi l'URL completo al server KV dell'acquirente per il targeting per contenuti, contestuale o per sito. | Stiamo discutendo di questa richiesta qui e saremo lieti di ricevere ulteriori feedback dall'ecosistema. |
| Documentazione | La documentazione relativa a "Componenti attendibili/obbligatori rispetto a facoltativi" su GitHub genera confusione tra alcuni professionisti del settore pubblicitario che dispongono di un proprio insieme di immagini di deployment e infrastrutture. | Stiamo cercando di migliorare la documentazione relativa ai "componenti attendibili/obbligatori rispetto a quelli facoltativi" e vorremmo sapere dall'ecosistema se questo lavoro deve essere dato la priorità. |
| Miglioramento dell'API | Il codice di stato HTTP di una chiamata al server KV deve essere disponibile anche per la funzione scoreAd() come parametro. | Stiamo valutando questa richiesta e accogliamo con favore ulteriori feedback dall'ecosistema. |
| Documentazione | Fornisci ulteriori informazioni su come vengono gestiti esattamente i carichi di lavoro JS e WASM con l'esecuzione delle funzioni UDF. | Stiamo valutando la possibilità di fornire queste informazioni e saremo lieti di ricevere ulteriori feedback qui. |
| Documentazione | Richiesta di aggiornamento del nome del repository. | Abbiamo rinominato il repository in "protected-auction-key-value-service". Questo è in linea con il termine della raccolta di servizi a cui appartiene, che include anche altri repository come la discussione sui servizi Protected Audience e i repository della documentazione di Protected Auction Services. |
| 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 richiede più di 50 ms. Ci vogliono quasi 100 ms. Hai qualche consiglio su cosa sta funzionando bene per altri venditori? Hai suggerimenti su come misurare i timeout e i tempi? |
La chiamata al server KV avviene nel contesto degli Script Runner, ovvero l'ambiente protetto speciale all'interno del browser Chrome. Lo scopo è mantenere le informazioni in questi runner di script protette da qualsiasi accesso non API. Abbiamo fornito una spiegazione dettagliata qui. |
| Uso dell'API | Esiste un timeout per la risposta del server KV in un determinato momento? | 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 il team di Privacy Sandbox sta lavorando per risolvere il problema della latenza? | Per le strategie che stiamo valutando per mantenere la latenza entro limiti accettabili, vedi qui. |
Misurare gli annunci digitali
Attribution Reporting (e altre API)
| Theme del feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Ottimizzazione manuale delle campagne | ARA non supporta l'ottimizzazione manuale delle campagne. | Abbiamo discusso di questo scenario con l'ad tech e abbiamo mostrato i modi in cui l'ARA può essere utilizzato per supportare l'ottimizzazione manuale delle campagne. L'ARA è stato progettato in modo da consentire la personalizzazione e la flessibilità della tecnologia pubblicitaria per risolvere una serie di casi d'uso. Alcuni suggerimenti forniti includevano l'utilizzo di 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 aperti a 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 è limitante. | Abbiamo implementato la maggior parte dei report flessibili a livello di evento, che offrono agli esperti di tecnologia pubblicitaria una maggiore flessibilità in termini di numero di finestre di generazione di report, numero di report sull'attribuzione e bit di dati di attivazione che possono utilizzare. Gli esperti di tecnologia pubblicitaria possono scegliere una configurazione che consenta di misurare fino a 32 diversi tipi di conversione. |
| Limite di eventi aggregabili dei report | Il numero minimo di 20 eventi di conversione per report aggregabile non è applicabile agli inserzionisti più piccoli con budget limitato. | Non è necessario un numero minimo di eventi di conversione per report aggregabili. Inoltre, è possibile prendere una serie di decisioni di progettazione per ottimizzare i report aggregabili per gli inserzionisti più piccoli, ad esempio modificare la struttura / le dimensioni chiave monitorate, testare diversi livelli di epsilon, testare frequenze di raggruppamento più lunghe e testare diverse allocazioni del budget di contributo tra gli obiettivi di misurazione. Le ad tech più piccole possono anche sperimentare la combinazione di report a livello di evento e report di riepilogo per ridurre l'impatto del rumore. |
| Dati in tempo reale | Privare le DSP dei dati in tempo reale (ad es. su clic, sessioni e conversioni) che utilizzano per adattare la strategia di offerta e migliorare l'efficacia delle campagne va contro l'impegno di mantenere le funzionalità esistenti. | Anche con l'API Attribution Reporting, i clic e le sessioni rimangono in tempo reale e le conversioni sono sempre posteriori, anche con i 3PC. |
| Campi mancanti | Requisiti mancanti nell'implementazione dell'evento Full Flexible: i) campo Valuta e ii) campo orderID / TransactionID. | Al momento non prevediamo di supportare un campo Valuta o un campo ID ordine / ID transazione nell'ambito del livello di evento completamente flessibile perché esistono già modi per farlo con i report attuali a livello di evento. Siamo aperti a ulteriori feedback in merito a questi campi e li riconsidereremo se ci saranno altri casi d'uso che li richiedono. I modi per utilizzare il design attuale di ARA per misurare le informazioni sulla valuta e sul tipo di ID ordine: 1. In base al feedback, la valuta è determinata dalla posizione geografica di un utente, che può essere aggiunta come parte 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 per errore due volte, il che può essere fatto utilizzando le chiavi di deduplica. |
| Budget di privacy | Il budget per la privacy ARA limita la possibilità di misurare su più dimensioni | L'ARA è stato progettato in modo da consentire agli esperti di tecnologia pubblicitaria di personalizzare le proprie configurazioni ARA per coprire una serie di scenari di attribuzione. Con il design attuale dell'ARA, le aziende di tecnologia pubblicitaria dovranno valutare il trade-off tra le dimensioni più importanti da misurare e l'impatto del rumore sui dati. L'aggiunta di rumore ai dati, a seconda della granularità delle dimensioni misurate, è essenziale per la privacy. Siamo aperti a ulteriori feedback dell'ecosistema in merito alla possibilità di misurare in più dimensioni, ma dobbiamo comprendere i casi d'uso specifici che richiedono questa operazione. |
| Aggiorna specifica | Sebbene Google abbia dichiarato di aver abbandonato le finestre di generazione di report sugli eventi fisse per passare a quelle flessibili, questo non è stato riportato nelle specifiche tecniche di Google, che attualmente hanno ancora una finestra minima di un'ora. | I report flessibili a livello di evento attualmente consentono alle ad tech di modificare il numero di report sull'attribuzione per evento di origine, i bit di dati di attivazione e il numero/la durata delle finestre dei report. ARA ha ancora una finestra minima di generazione dei report di 1 ora per i report a livello di evento, che è essenziale per mantenere la privacy e mitigare determinati tipi di attacchi di ricostruzione della cronologia. Poiché i report di riepilogo forniscono informazioni aggregate, le tecnologie pubblicitarie possono attivare la ricezione immediata dei report aggregabili senza ritardi, se necessario per i loro casi d'uso. |
| Progettazione API | Il timore che la riduzione delle informazioni nei report sulle conversioni e l'aggiunta di rumore possano influire sull'ecosistema più che su Google. | Google si è impegnata nei confronti della CMA a progettare e implementare le proposte di Privacy Sandbox in modo da non distorcere la concorrenza dando la priorità alla propria attività e a prendere in considerazione l'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. | In ARA sono disponibili molte soluzioni che offrono funzionalità di verifica: 1. Gli esperti di tecnologia pubblicitaria possono verificare che il comportamento di ARA corrisponda alle loro aspettative: – Il codice lato client di ARA è open source. – Anche il codice lato server di 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 alle ad tech una libreria di simulazione per verificare il comportamento dell'attribuzione, in cui l'ad tech può testare il modo in cui l'ARA esegue l'attribuzione in un ambiente simulato. 3. ARA supporta una serie di indicatori di debug che aiutano a verificare se e perché l'elaborazione prevista potrebbe non essere avvenuta. |
| (segnalato anche nei trimestri precedenti) Rumore |
Feedback che indica che il livello di rumore è troppo elevato e sta influenzando l'utilità dei report. | Abbiamo parlato con gli esperti di tecnologia pubblicitaria che ci hanno fornito lo stesso feedback e siamo riusciti a identificare i modi in cui l'ARA può essere personalizzata per adattarsi meglio ai loro casi d'uso, anche in presenza di rumore. La nostra documentazione per gli sviluppatori contiene la maggior parte delle decisioni di progettazione e delle personalizzazioni che abbiamo discusso con gli esperti di tecnologia pubblicitaria. L'ARA è stato progettato in modo da consentire agli esperti di tecnologia pubblicitaria di personalizzare le proprie configurazioni ARA per coprire una serie di scenari di attribuzione. Tuttavia, le ad tech dovranno valutare il trade-off tra le dimensioni più importanti da misurare e l'impatto del rumore sui dati. Siamo aperti a ulteriori feedback dell'ecosistema sull'impatto del rumore e possiamo fornire ulteriori indicazioni sulle leve ARA che possono essere utilizzate per modificarne l'impatto. |
| Attribuzione cross-domain | Come monitorare le attribuzioni interdominio? | Le tecnologie pubblicitarie possono reindirizzare a diversi URL dei report per risolvere questo caso d'uso. Siamo aperti a ulteriori feedback sull'ecosistema in merito a questo aspetto del design di ARA. |
| Miglioramento dell'API | Modifica regolarmente il fattore di scala utilizzato per registrare l'attribuzione per i report di riepilogo ARA. | In base alla discussione su GitHub, sembra che la gestione di più fattori di scalabilità nel servizio di aggregazione provochi con ogni probabilità un aumento del rumore nei report di riepilogo rispetto alla funzionalità attuale. Siamo aperti a ulteriori feedback in merito alla necessità di fattori di scalabilità all'interno dei report aggregabili, ma vogliamo segnalare il potenziale compromesso con l'aumento del rumore. Stiamo anche valutando se altre funzionalità ARA future possano contribuire a risolvere anche 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. | Abbiamo in programma di sincronizzarci con le aziende di tecnologia pubblicitaria per comprendere meglio i loro feedback e eventuali limitazioni riscontrate. |
| Volume del traffico di test | Il traffico di test per la modalità B per tutti i browser Chrome è stabile? | L'inclusione in un gruppo sperimentale non è influenzata (è indipendente) dalle impostazioni di Chrome. |
| Documentazione | Supporto ARA per i Pixel. | Abbiamo pubblicato informazioni su come supportare questo caso d'uso e accogliamo con favore ulteriori feedback dall'ecosistema. |
| Uso dell'API | L'ARA potrebbe non essere attribuita alla sorgente corretta per i venditori di terze parti sulle piattaforme di e-commerce se la conversione non viene eseguita dall'ultimo tocco. | Le aziende possono utilizzare i filtri per evitare un'attribuzione errata (in quanto non verrà generato alcun report sulle conversioni). Stiamo anche lavorando a una proposta per il filtro pre-attribuzione per supportare questo caso d'uso. |
| Supporto dei browser | L'ARA sarà supportato in browser diversi? | Invitiamo altri browser ad adottare le API Privacy Sandbox e continuiamo a dedicare tempo alla discussione del nostro approccio in modo aperto al W3C. Abbiamo dichiarato esplicitamente che l'interoperabilità è un obiettivo per l'implementazione dell'ARA e che il design dell'ARA è pensato per essere indipendente dal browser, con valori flessibili specificati dal fornitore per i fornitori con posizioni diverse in materia di privacy. Altri browser stanno facendo le proprie scelte in merito alla possibilità di fornire alternative valide agli identificatori cross-site che possano supportare l'ecosistema digitale di contenuti e servizi. Siamo incoraggiati dal fatto che Microsoft Edge ha indicato che supporterà l'RA. |
| Uso dell'API | Qual è il tipo di origine previsto per le registrazioni delle origini ARA per registerAdBeacon/reportEvent (e i beacon automatici navigation_start/commit)? | Dipende se questi indicatori sono automatici o manuali:
- riservato.* (ovvero automatici) devono essere di tipo origine navigazione. - Gli eventi attivati manualmente devono essere di tipo origine evento. |
| Uso dell'API | Il limite massimo di 20 report aggregabili per origine si riferisce a ogni evento sorgente? Il limite è globale o giornaliero? È previsto un aumento del limite? | Il limite di 20 report aggregabili per origine è un limite globale che consente di creare 20 report aggregabili per ogni origine. Il limite è impostato dal browser e non è configurabile. Lo scopo di questo limite è evitare di abusare della protezione dei report sull'attribuzione reale con report null. Abbiamo discusso ulteriormente di questo qui. |
| Uso dell'API | Supporto per l'email marketing che utilizza ARA. | Al momento non è disponibile il supporto diretto per questo caso d'uso in ARA (se non controlli il sito di hosting email). Ne stiamo discutendo qui e saremo lieti di ricevere ulteriori feedback. |
| Epsilon | Quando verrà determinato il valore di epsilon per l'API Aggregate? | Il valore epsilon corrente può essere configurato dalle tecnologie pubblicitarie fino a una soglia predeterminata definita da Privacy Sandbox (attualmente 64). Ti consigliamo di testare diversi valori di epsilon, identificare i punti di flesso per i tuoi casi d'uso e fornire un feedback. Ci assicureremo di comunicare in anticipo alle ad tech qualsiasi modifica all'intervallo di valori di epsilon. |
| Miglioramento dell'API | Supportare un caso d'uso in cui l'inserzionista può inserire un identificatore nel campo trigger_data per la corrispondenza con i dati CRM esterni al fine di consentire agli inserzionisti di verificare la qualità delle conversioni. | Stiamo discutendo della richiesta e saremo lieti di ricevere ulteriori feedback qui. |
| Uso dell'API | Come gestire gli URL di reindirizzamento come URL di destinazione. | Gli esperti di tecnologia pubblicitaria possono eseguire una delle seguenti operazioni: 1. Inserisci l'URL di destinazione finale nel campo di destinazione. 2. Il campo Destinazione consente di inserire fino a tre URL, il che ti consente di inserire più URL nel campo. Entrambe le opzioni richiedono di conoscere l'URL di destinazione finale. Abbiamo discusso ulteriormente di questo qui . |
Servizio di aggregazione
| Theme del feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Meccanismo di rilevamento delle chiavi | Richiesta di un meccanismo di rilevamento delle chiavi | Abbiamo una proposta per la scoperta delle chiavi e accogliamo con favore i feedback dell'ecosistema in merito. |
| Uso dell'API | Roadmap per l'osservabilità nel servizio di aggregazione | Stiamo esaminando le opzioni per supportare una maggiore osservabilità e accogliamo con favore i feedback dell'ecosistema qui. |
| Miglioramento dell'API | Richiesta di poter eseguire nuovamente query sui report. | Il servizio di aggregazione sta lavorando a una proposta di richiesta in cui le tecnologie pubblicitarie possono suddividere l'errore epsilon per ogni report. Ciò può introdurre più rumore per query, ma consentirà alle tecnologie pubblicitarie di eseguire nuove query e mantenere la privacy. |
| Miglioramento dell'API | Vorrei poter associare più origini allo stesso ID AWS. | Ora il servizio di aggregazione consente di eseguire l'onboarding di più siti nello stesso account cloud (Google Cloud o AWS). In questo modo, gli esperti di tecnologia pubblicitaria potranno utilizzare la stessa enclave del servizio di aggregazione per elaborare i report di più siti e di più origini dagli stessi siti. |
| Uso dell'API | Quando i batch aggregabili non vanno a buon fine, non è chiaro se il budget è stato utilizzato o meno e se è possibile elaborare nuovamente il batch. Quando un servizio di aggregazione rileva un errore di budget per i 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à utilizzato. In caso di errori rari in cui il budget viene esaurito, le ad tech possono richiedere il recupero del budget. Se l'ad tech riscontra frequenti errori di esecuzione dei job con l'errore di esaurimento del budget, deve verificare la propria strategia di raggruppamento. Le istruzioni su come eseguire correttamente l'aggregazione ed evitare report duplicati ed errori sono disponibili qui. Accogliamo con favore i 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à del servizio di aggregazione? | Il servizio di aggregazione stesso non impone un limite superiore al numero di chiavi o report in un batch, ma una scala di 10^14 report e 10^12 chiavi non è attualmente supportata a causa della memoria richiesta. Le nostre indicazioni per la scelta delle dimensioni indicano gli intervalli che abbiamo testato e consigliamo per prestazioni ottimali in base al carico previsto e ai tipi di istanze VM cloud supportati. |
| Elaborazione dati | Se i dati criptati contengono informazioni personali, qual è la disposizione legale per la fornitura di dati criptati al Servizio di aggregazione? Puoi dirmi se è garantito che il coordinatore non accederà ai dati criptati? |
Il servizio di aggregazione non condivide dati criptati / degli utenti con il Coordinatore. Il servizio di aggregazione utilizza il coordinatore per la gestione e la contabilità delle chiavi. Puoi trovare alcuni dettagli sul coordinatore qui. Per la contabilità, il servizio di aggregazione condivide solo l'ID condiviso e l'origine report con PBS per il consumo del budget. Una volta lanciato un sito multisito, sostituiremo l'origine con il sito. Tieni presente che il servizio di aggregazione viene eseguito in un TEE, l'unico luogo in cui è possibile decriptare i report dei client. Il codice in esecuzione nel TEE è open source e sottoposto a controllo da parte di terze parti, come descritto qui. |
API Private Aggregation
| Theme del 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. | Lo stato attuale dell'API Private Aggregation non supporta questa funzionalità. Abbiamo discusso ulteriormente di questo problema qui. |
| Documentazione | Qual è il valore epsilon utilizzato nei trial di Google? | Per l'API Private Aggregation, il valore ε specificato in una query del servizio di aggregazione corrisponde al budget dei contributi L1 di 2^16 applicato su base continuativa di 10 minuti. Esiste anche un budget di contributo L1 di riserva pari a 2^20 che viene applicato su base continuativa di 24 ore. Quindi, in sostanza, il parametro della privacy è ε su base continuativa di 10 minuti ed è 16ε su base continuativa di 24 ore (anziché 144ε). Il servizio di aggregazione attualmente supporta un intervallo di ε 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 della privacy per l'aggregazione privata e altre API. Abbiamo intenzione 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 il monitoraggio nascosto
Riduzione dello user agent/client hint dello user agent
Nessun feedback ricevuto in questo trimestre.
Protezione IP (in precedenza Gnatcatcher)
| Theme del feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| ID risoluzione | Privacy Sandbox deve fare di più per far capire che gli ID risoluzione spesso basati sull'IP 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. Ci impegniamo a ridurre il monitoraggio tra siti, incluso quello basato sugli indirizzi IP. Tuttavia, è compito dei singoli siti web decidere se attivare in modo proattivo il monitoraggio tra siti. In un'epoca di maggiore attenzione alla conformità alle normative, è consigliabile che le singole aziende comprendano le pratiche adottate dai loro fornitori di servizi. |
| Chromecast | La Protezione IP influirà 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 di terze parti identificate come potenzialmente in uso di indirizzi IP per il monitoraggio tra siti su tutto il web verrà pubblicato? | L'elenco verrà pubblicato una volta completato, come discusso qui. |
Mitigazione del monitoraggio del rimbalzo
| Theme del feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Esenzione per Single Sign-On (SSO) | In che modo la mitigazione del monitoraggio dei rimbalzi (BTM) verificherà i casi d'uso SSO per l'esenzione? | La funzionalità BTM verrà disattivata dalle strategie di euristica di Chrome. Consulta la spiegazione per maggiori dettagli. |
| Prova relativa al ritiro | La funzionalità BTM è attivata per i siti inclusi nella prova relativa al ritiro dei cookie di terze parti? | No, BTM rispetta le eccezioni per i cookie create dalla prova di ritiro, come discusso qui. |
Budget di privacy
Come indicato nella spiegazione di GitHub e nel sito per sviluppatori,il budget della privacy non è più preso in considerazione attivamente nell'ambito delle proposte di Privacy Sandbox.
Rafforzare i confini della privacy tra siti
Insiemi di siti web correlati (in precedenza Insiemi proprietari)
| Theme del feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Richiesta di funzione | È consentito accedere automaticamente ai CHIP e / o alla partizione dello spazio di archiviazione in tutta la RWS, senza la necessità dell'API Storage Access né dell'interazione dell'utente. | Stiamo valutando i vantaggi e la fattibilità di una funzionalità che potrebbe svolgere questa funzione. Un aspetto da considerare è un potenziale vuoto nell'interoperabilità tra browser, che RWS risolve sfruttando l'API Storage Access. Al momento non esiste un equivalente a questa funzionalità richiesta supportata su altri browser. Invitiamo gli sviluppatori a inviare i loro casi d'uso relativi a 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 per definire una procedura e condivideremo gli aggiornamenti non appena saranno disponibili. |
| Procedura di applicazione | Non è chiaro il ruolo soggettivo di Google nella procedura di applicazione delle norme relative alle RWS. | Poiché la RWS è un progetto in corso e continuiamo a ricevere nuovi contenuti, alcuni aspetti della procedura e i nostri criteri sono ancora in fase di definizione. Siamo d'accordo sul fatto che sia importante che le nostre linee guida per i contenuti inviati descrivano in modo completo i requisiti per l'invio e, in futuro, aggiungeremo ulteriori dettagli per evitare ulteriore ambiguità e confusione. Il nostro obiettivo è che la procedura di invio sia il più tecnica possibile, in modo da eliminare gradualmente il coinvolgimento umano e fare affidamento esclusivamente su controlli automatici. RP come questa richiedono una maggiore interazione umana perché includono comportamenti che non avevamo previsto, ma ci consentono di identificare più aree per l'automazione e modi per correggere le nostre linee guida in modo da evitare questi problemi in futuro. |
| Condivisione di dati | Richiesta di una funzionalità che consenta ai proprietari di domini di indicare che vogliono che anche una terza parte condivida i dati RWS, con il consenso dell'utente. | La funzionalità richiesta è già disponibile tramite API come FedCM e API di accesso allo spazio di archiviazione che consentono l'accesso all'identità autenticata dopo che l'utente ha accettato una richiesta di autorizzazione. Accogliamo con favore i feedback dell'ecosistema su casi d'uso specifici che ritiene non possibili. |
| Altri metodi di archiviazione | Le informazioni salvate nella memoria locale o nella memoria di sessione verranno interpretate anche come 3PC? | Lo spazio di archiviazione locale, lo spazio di archiviazione della sessione e altre forme di archiviazione diverse dai cookie, se utilizzati in contesti di terze parti, sono stati suddivisi in Chrome dalla versione 115. Per ulteriori dettagli, consulta questo post del blog. |
| Limite di insiemi associati | Cosa succede alle organizzazioni che inviano più di 5 domini, anche se il numero massimo consentito è 5 siti associati? | Questi set verranno accettati tramite la procedura di GitHub, ma il browser (Chrome) applicherà le nostre regole di concessione automatica dell'API Accesso allo spazio di archiviazione solo ai primi 5 domini e ignorerà i domini rimanenti, come discusso qui. |
| find_robots_txt | Il controllo find_robots_txt non funziona con i reindirizzamenti. | Per risolvere il problema è stata inviata una correzione qui. |
| Gesto utente | Rimuovi il requisito del gesto dell'utente per accessStorage(). | Questo requisito è stato creato in base a un design simile implementato in tutti i principali browser per l'API requestStorageAccess. Ti invitiamo a fornire ulteriori feedback e casi d'uso in questo problema di GitHub per aiutarci a dare la priorità a questa richiesta e consentire discussioni su più browser. |
| Gesto utente | È richiesta un'azione dell'utente per concedere l'autorizzazione di accesso allo spazio di archiviazione di terze parti dopo un riavvio di Chrome o del sistema operativo? | Sì, ma accogliamo con favore ulteriori feedback dall'ecosistema sulla possibilità di modificare questo comportamento qui. |
API Fenced Frames
| Theme del feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| adComponent | Mancanza di documentazione e flessibilità nell'utilizzo di AdComponents con frame delimitati. | Stiamo cercando di condividere ulteriore documentazione su questo caso d'uso. Inoltre, i componenti degli annunci sono supportati nei frame delimitati utilizzando getNestedConfigs(), che è documentato nella specifica qui. |
| (Registrato anche nei trimestri precedenti) Render adComponent |
Richiesta di codici di esempio su come eseguire il rendering di adComponents in un riquadro delimitato. | 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 dei frame delimitati richiede maggiori dettagli, in particolare in merito alla sicurezza del brand/contestuale. | Attualmente, i report sugli annunci con frame delimitati consentono alle DSP di inviare dati a livello di evento relativi a impressioni e aste a verificatori di annunci di terze parti per i controlli post-rendering della sicurezza del brand e la fatturazione. |
| Annunci espandibili | Richiedi il supporto degli annunci espandibili. | Se l'annuncio deve passare da due dimensioni con le stesse proporzioni e non esiste alcuna differenza funzionale tra le due (solo le dimensioni), l'utente che esegue l'embed potrebbe ridimensionare il riquadro delimitato con le dimensioni del secondo annuncio e il browser ridimensiona di conseguenza l'elemento riquadro delimitato. |
| (Segnalato anche nei trimestri precedenti) Supporto per l'inventario video e nativo |
I frame delimitati supportano l'inventario video e nativo? | La nostra risposta è simile a quella dei trimestri precedenti: l'API PA supporta il rendering dei video utilizzando un meccanismo basato su iframe. Tuttavia, non abbiamo ancora progettato una soluzione per il rendering di annunci video e nativi compatibile con i frame delimitati e questo è uno dei motivi per cui abbiamo deciso di posticipare l'applicazione dei frame delimitati al 2026. Ciò significa che se un partner decide di applicare subito i frame delimitati, non potrà più supportare gli annunci video e nativi. |
| Consiglio 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 frame delimitati non sono obbligatori per l'utilizzo nell'API PA prima del 2026. Il tempo aggiuntivo ci consente di continuare a collaborare con il settore per progettare e implementare il supporto per una gamma più ampia di casi d'uso critici. In precedenza abbiamo dichiarato che svilupperemo i frame delimitati prima che sia necessario mantenere il supporto per gli annunci video e nativi con l'API PA. In base ai nostri impegni, informeremo la CMA di eventuali modifiche e continueremo a raccogliere i feedback dell'ecosistema prima di richiedere i frame delimitati. Il nostro modello di coinvolgimento dell'ecosistema presso il W3C e le organizzazioni di standard pubblicitari come IAB Tech Lab consente a esperti del settore di ogni tipo di guidare i progetti prima che vengano richiesti. |
| (Registrata anche nei trimestri precedenti) Differenza di dimensioni tra le piattaforme |
Segnala che le dimensioni dei contenuti visualizzati nel riquadro delimitato sono diverse su computer e smartphone. | Si tratta di un problema noto di Chromium che stiamo esaminando. Ti invitiamo a inviare un feedback aggiuntivo qui. |
| Miglioramento dell'API | Il requisito dei frame delimitati è stato posticipato al 2025 in modo che gli annunci nativi siano ora supportati in Privacy Sandbox? | Come indicato nel nostro annuncio pubblico relativo all'applicazione delle norme relative ai frame delimitati non prima del 2026, siamo venuti a conoscenza di un "impegno significativo per supportare" i frame delimitati. Sicuramente, uno di questi era nativo, ma non è stato l'unico fattore. L'intento era di concedere più tempo per garantire l'idoneità dell'ecosistema a supportare casi d'uso chiave, inclusi, a titolo esemplificativo, i casi d'uso nativi. |
API Shared Storage
| Theme del feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Prestazioni | I tempi di risposta dello spazio di archiviazione condiviso al di fuori del worklet sembrano dipendere dall'attività nel worklet. | Qui puoi trovare una discussione su questo risultato del test. |
| Adozione più ampia | Lo spazio di archiviazione condiviso dovrebbe essere uno standard di settore disponibile su tutti i browser. | Apprezziamo molto il tuo feedback. Chrome continua a partecipare attivamente ai forum del W3C, tra cui il WICG, per sostenere la proposta, cercare feedback e promuovere l'adozione. |
| Worklet per le offerte | È possibile leggere da Shared Storage all'interno di generateBid (che è già in esecuzione in un worklet) per applicare la logica di business / decisione sugli annunci (ad es. il limite di frequenza) in base alle informazioni su più siti e selezionare un sottoinsieme di annunci? | No, non è possibile leggere dallo spazio di archiviazione condiviso all'interno dei worklet di offerta. |
CHIPS
| Theme del feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Capacità della partizione | Chiarire il comportamento in caso di superamento della capacità della partizione. | Quando viene raggiunta la capacità, i cookie meno recenti vengono espulsi dai cookie a cui è stato effettuato l'accesso meno di recente per liberare memoria finché il limite non viene più superato. Gli sviluppatori visualizzano l'intestazione Cookie aggiornata nelle richieste successive. |
| Accesso iframe di terze parti | I contenuti iFrame di terze parti incorporati che aprono una nuova scheda/finestra per lo stesso sito di terze parti devono avere accesso agli stessi cookie partizionati dell'elemento che li apre. | Stiamo discutendo di questo caso d'uso e accogliamo con favore ulteriori feedback dall'ecosistema qui. |
| Cookie duplicati | Se sono presenti un cookie partizionato e un cookie non partizionato con lo stesso nome, quale valore della chiave decide di inviare il browser? | Se hai due cookie con lo stesso nome (uno partizionato e uno no), riceverai entrambi i cookie. Purtroppo, non è possibile distinguerli. La specifica RFC in merito è disponibile qui e spiega che non bisogna fare affidamento sull'ordine in cui vengono inviati i cookie. |
| Richiesta di funzione | Attivare i cookie con stato partizionato in base all'origine. | Stiamo valutando questa richiesta e accogliamo con favore ulteriori feedback dall'ecosistema qui. |
FedCM
Nessun feedback ricevuto in questo trimestre.
Combattere lo spam e le attività fraudolente
API Private State Tokens (e altre API)
| Theme del feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Visualizzazione Web | I token di stato privato (PST) vengono mantenuti su più visualizzazioni web sullo stesso dispositivo mobile (profilo)? | Ogni app che utilizza WebView avrà uno spazio di archiviazione locale diverso, il che significa che gli emittenti di PST non possono emettere token nel WebView di un'app e poi in un'app separata, consentendo il rimborso dei token. Questo vale anche per altre forme di dati memorizzati localmente nelle visualizzazioni web, come i cookie. I PST non sono ancora completamente disponibili in WebView. Prevediamo di fornire un aggiornamento in merito 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 scoprire di più su questa proposta nei prossimi incontri del gruppo della community Anti-Fraud nel secondo trimestre del 2024. |
| Identificazione utente | Come faccio a impedire l'identificazione degli utenti in base ai PST specifici di cui dispongono? | Al momento, questo problema viene attenuato limitando i tentativi di utilizzo su un sito a due emittenti, indipendentemente dal fatto che siano disponibili token di quell'emittente. Devi conteggiare un emittente rispetto al limite anche se non sono disponibili token, altrimenti il sito potrebbe eseguire l'iterazione di tutti gli emittenti finché non trova una corrispondenza positiva. |
| Registrazione | Per quanto tempo sarà necessaria la registrazione per i PST? | La registrazione continuerà a essere obbligatoria per il prossimo futuro, come spiegato più dettagliatamente qui. |
| Supporto per altri browser Chromium | La registrazione degli emittenti PST per altri browser basati su Chromium sarà supportata tramite il repository di registrazione degli emittenti Chrome? | Chrome recupera i principali impegni e li distribuisce ai client di Chrome tramite un meccanismo chiamato Programma di aggiornamento dei componenti. Man mano che altri browser aggiungono un supporto più completo per l'API, dovranno stabilire una procedura per ottenere gli impegni chiave per il client, tramite un metodo di aggiornamento dei componenti o un altro metodo. Scopri di più qui. |