Domande frequenti su pertinenza e misurazione di Privacy Sandbox

Risposte alle domande frequenti relative alle API per pertinenza e misurazione di Privacy Sandbox.

Qual è la differenza tra Topics e i segmenti di pubblico definiti dal venditore (SDA)?

Topics e SDA forniscono tipi di informazioni complementari e sono entrambi sotto il controllo dell'editore. Non crediamo che siano in competizione tra loro. Entrambe lavorano invece affiancate o in contesti diversi per massimizzare le opportunità di acquisto. Gli acquirenti prendono in considerazione e utilizzano molti indicatori quando valutano le impressioni in modo programmatico e ci aspettiamo che Topics sia una di queste considerazioni. Storicamente i venditori non includono i segmenti di pubblico nelle aste aperte del marketplace, ma un luogo probabile in cui verrà utilizzato Topics. Invece, i venditori hanno reso i propri segmenti di pubblico disponibili per l'acquisto programmatico nei deal stipulati con inserzionisti, agenzie o DSP. In questi casi, il venditore e l'acquirente effettuano transazioni intenzionalmente sull'SDA. L'utilizzo di Topics in questi casi potrebbe essere dovuto a uno o più dei seguenti casi:

• Il venditore migliora la definizione di segmento di pubblico con Topics
• L'acquirente che utilizza gli argomenti come indicatore dell'importo dell'offerta
• L'acquirente utilizza Topics per verificare se l'SDA è accurato

Protected Audience consente a Google di controllare la creazione dei segmenti di pubblico?

No. I siti possono continuare a creare i propri segmenti di pubblico sia all'interno che all'esterno di Privacy Sandbox. Quando i siti creano segmenti di pubblico in Privacy Sandbox, il proprietario del sito o il proxy scelto determina chi può creare i segmenti di pubblico, quali sono, come vengono aggiornati, le modalità di offerta per questi segmenti di pubblico e se rimuovere gli utenti da un segmento.

Protected Audience supporta i gruppi di interesse creati dai publisher?

Sì. Sappiamo che oggi i publisher sono prudenti nel includere il proprio pubblico nelle aste basate su OpenRTB per timore di fughe di dati. Attualmente gli editori possono creare segmenti di pubblico in Protected Audience in modo che non offrano all'offerente una visualizzazione cross-site del singolo utente dell'editore. Siamo entusiasti di continuare a esplorare i modi in cui i publisher possono sfruttare l'ambiente ridotto di fuga di dati di Protected Audience.

Come vengono applicate le regole sulla qualità degli annunci nelle aste Protected Audience?

Esistono diversi modi in cui le regole sulla qualità degli annunci vengono applicate nelle aste Protected Audience. Ognuna di queste regole è simile al modo in cui le regole per la qualità degli annunci vengono attualmente applicate dalle SSP. Un modo è lasciare che un'asta con una creatività sconosciuta attivi la creatività in una coda per l'analisi. Abbiamo ascoltato il feedback secondo cui le SSP vorrebbero un supporto migliore per questo caso d'uso e stiamo progettando un meccanismo che possa creare un feed di renderUrls che l'SSP possa controllare fuori banda e di cui può archiviare le informazioni nel proprio server delle coppie chiave-valore. Un altro modo è richiedere la preregistrazione degli annunci. Come nel caso precedente, una volta eseguita l'analisi della creatività, i risultati possono essere collegati al server delle coppie chiave-valore. In seguito, in un secondo momento, quando un acquirente fa un'offerta per la creatività (come indicato da un ID creatività che probabilmente segue lo stesso formato di OpenRTB), la logica di punteggio del venditore può effettuare una ricerca nel server dei valori chiave e decidere quale punteggio assegnare di conseguenza.

Protected Audience supporta gli annunci video?

Sì. Gli URL VAST possono essere trasmessi dentro e fuori da Protected Audience. Quando esce un URL VAST, i tecnici lato vendite possono coordinare il modo in cui aggregano l'URL VAST dell'acquirente prima che venga inviato al player. In vista del requisito di passaggio a Fenced Frames (non prima del 2026) e di rafforzare ulteriormente le protezioni della privacy degli utenti, ci aspettiamo che l'ecosistema partecipi a discussioni sulla progettazione che includeranno sicuramente i video.

Protected Audience supporta gli annunci nativi?

Sì. Gli URL JSON possono essere trasmessi dentro e fuori da Protected Audience. Quando esce un URL JSON, i tecnici del lato vendita possono coordinare il modo in cui aggiungono gli eventi desiderati prima che il JSON finale venga passato al codice di rendering. In vista del requisito di passaggio a Fenced Frames (non prima del 2026) per rafforzare ulteriormente le protezioni della privacy degli utenti, ci aspettiamo che l'ecosistema partecipi a discussioni sulla progettazione che probabilmente includeranno gli annunci nativi.

Il rendering degli annunci Protected Audience inibisce l'innovazione?

No. Il rendering degli annunci si è sempre basato sulle tecnologie dei browser. Questo non cambia. Forse questo problema è specifico per i piani che prevedono di richiedere l'utilizzo di Fenced Frames in combinazione con Protected Audience in futuro. In parte, questi piani sono "in futuro" perché vogliamo che la tecnologia Fenced Frames supporti l'innovazione e la differenziazione degli ecosistemi quando si tratta di rendering degli annunci. Le aziende e gli sviluppatori interessati hanno il tempo di valutare la direzione di Fenced Frames, che include come possono essere supportati gli approcci agli annunci nativi.

Protected Audience consente approcci sofisticati al pacing e alla valutazione delle offerte attualmente in uso nelle aste tradizionali?

Protected Audience offre agli acquirenti un'opzione in tempo reale per comprendere il ritmo e i budget delle campagne. Dal punto di vista dell'inventario, il venditore può fornire indicatori dell'asta all'acquirente sul contesto della pagina e su qualsiasi altra cosa. Se un venditore sceglie di inviare una richiesta di offerta contestuale, l'acquirente può ottenere informazioni sull'inventario tramite questo meccanismo e poi fornire indicatori di contesto (tramite perBuyerSignals) che potrebbero essere utilizzati nella generazione di offerte di Protected Audience. Gli early adopter stanno già collegando i sistemi di machine learning a Protected Audience. Comprendiamo la necessità di tempo per ottimizzare questi sistemi per le offerte negli ambienti Protected Audience, ma è fondamentale notare che l'ottimizzazione è possibile e sta già avvenendo.

Lo standard OpenRTB funzionerà in Protected Audience?

Sì. Questo lavoro è in corso presso IAB Tech Lab tramite un gruppo ben seguito di DSP e SSP rappresentativi. Sembra che il percorso da seguire sarà l'utilizzo di parti del protocollo OpenRTB come standard di comunicazione nell'ambito delle aste Protected Audience e sappiamo che i primi utenti stanno già utilizzando questo approccio.

Protected Audience richiede alle aziende di mantenere due architetture separate per la pubblicazione di annunci?

No. Protected Audience non richiede la gestione di due architetture separate. Le scelte architettoniche sono personali. Con il progredire della pubblicità online nel corso degli anni, è cresciuta anche la complessità dei sistemi alla base. Rendere internet più privato per gli utenti introduce maggiore complessità e richiede lavoro. Le aziende di ad tech possono scegliere di mantenere due architetture separate o di creare Protected Audience in un'architettura combinata con aste tradizionali.

Che cosa succederà alle aste tradizionali quando le aziende di ad tech supporteranno Protected Audience?

Ci aspettiamo che le aste contestuali rimangano pertinenti per una miriade di motivi, tra cui deal, campagne con targeting per pubblico non proprietario e molti altri scenari contestuali. Inoltre, restano utili quando non sono presenti gruppi di interesse o le offerte in Protected Audience non raggiungono i prezzi minimi o rispettano le regole sulla qualità degli annunci.

L'asta Protected Audience è in contrasto con gli sforzi dell'ottimizzazione dei percorsi di fornitura (SPO) dell'ecosistema per ridurre la quantità totale di intermediari tra un inserzionista e un publisher e/o la duplicazione di una determinata opportunità pubblicitaria?

No. Un annuncio vincente in Protected Audience trasmetterà al massimo due entità venditore (ad esempio, una Supply-Side Platform (SSP) e un ad server del publisher) e il minimo di nessuno, se l'acquirente crea un'integrazione diretta con il publisher.

La duplicazione della stessa richiesta utilizzando più intermediari rimane una scelta dell'editore. Protected Audience non dovrebbe influire in un modo o nell'altro.

Le aste Protected Audience avvengono al di fuori dell'attuale sistema server-to-server in tempo reale per non far trapelare i dati utente tra i siti. Alcuni potrebbero dire che viene duplicata una richiesta di annuncio. Raggiungere una privacy tecnicamente dimostrabile richiede alcuni compromessi. Tuttavia, nel lungo periodo l'ecosistema potrebbe decidere di utilizzare Protected Audience senza le tradizionali aste lato server. Questa scelta potrebbe portare a percorsi di fornitura ancora più ottimizzati.

Protected Audience riduce il valore dell'infrastruttura esistente di modellazione del traffico?

Per quanto ci rendiamo conto, la cosa che cambia in merito alle query al secondo è che molte SSP utilizzano gli ID tra siti come funzionalità per determinare se inviare o meno una richiesta a una DSP. La riduzione degli ID tra siti influisce quindi sulle tecniche di formato di traffico esistenti. Questo vale se il publisher vuole eseguire o meno un'asta Protected Audience.

Abbiamo esplorato il formato di traffico con molte SSP e abbiamo trovato soluzioni come la memorizzazione nella cache e l'applicazione di filtri basati sul contesto. Nel tempo, ci aspettiamo che gli sviluppatori traggano vantaggio dall'aggregazione privata per comprendere meglio le preferenze di offerta DSP e applicare filtri di conseguenza.

Essenzialmente, alcune infrastrutture legacy basate su identificatori tra siti non saranno più utili.

Le nuove richieste derivanti da un'asta di Protected Audience affliggeranno la capacità dell'SSP?

Alcune SSP hanno appreso che la capacità non è un problema né un elemento importante di una proposta di valore dell'SSP dal punto di vista dell'integrazione. Le SSP preoccupate per le nuove chiamate nel processo di asta sono a conoscenza delle aziende che aiutano già le SSP a risolvere problemi di capacità e stanno cercando di espandere questi servizi per supportare Protected Audience. Facci sapere se vuoi che ti mettiamo in contatto con una di queste aziende.

Come viene gestita la priorità in Protected Audience quando sono presenti risorse concorrenti nel browser?

Protected Audience ha generalmente adottato un paradigma standard di creazione di controlli che consente ai venditori di decidere il tempo e le risorse che gli offerenti possono utilizzare, nonché di creare strumenti che permettono agli acquirenti di decidere come utilizzare al meglio le risorse a loro disposizione. Questi controlli e strumenti sono già disponibili, ma il loro pieno vantaggio si rifletterà dopo l'adozione da parte di acquirenti e venditori. Inoltre, Chrome continua a lavorare a una serie di miglioramenti dell'infrastruttura per la velocità delle aste (ad esempio: crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, 1crrev7.com).

In che modo Protected Audience affronta i problemi di latenza?

In passato, prima di Protected Audience, le offerte in tempo reale sui server facevano sì che i venditori specificassero timeout rigorosi per le risposte degli acquirenti per tenere sotto controllo la latenza. Abbiamo aggiunto a Protected Audience una serie di controlli di timeout specificati dal venditore molto simili (consulta la documentazione per perBuyerCumulativeTimeouts, perBuyerTimeouts e sellerTimeout) per raggiungere lo stesso obiettivo di tenere sotto controllo la latenza. Questi controlli incoraggiano inoltre i partecipanti alle aste a ottimizzare la propria logica per assicurarsi che le risorse vengano utilizzate in modo più efficiente per supportare l'ecosistema di tecnologia pubblicitaria e un'esperienza utente di alta qualità.

Chrome continua inoltre a lavorare a una serie di miglioramenti dell'infrastruttura per la velocità delle aste (ad es. crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev32/119). Invitiamo a inviare feedback su entrambe le parti di questo impegno in termini di latenza: strumenti aggiuntivi che acquirenti e venditori potrebbero trovare utili e segnalazioni dei colli di bottiglia osservati che gli ingegneri di Chrome devono esaminare.

Creare per Protected Audience on-device è uno sforzo sprecato quando esistono offerte e servizi di aste?

No. Il dispositivo on-device è sufficiente per i casi d'uso di ad tech. Asta e servizi di aste è una soluzione facoltativa su scala orizzontale quando gli ad tech vogliono investire di più nelle risorse di calcolo delle offerte di quanto non sia consentito dal browser. Lo sviluppo on-device è un buon investimento, perché la maggior parte del lavoro sarebbe riutilizzabile anche se gli sviluppatori decideranno in un secondo momento di partecipare agli ambienti dei servizi di asta e asta. La maggior parte dei tubi e dell'infrastruttura costruiti continuerà a funzionare allo stesso modo.

I requisiti del Trusted Execution Environment (TEE) basati su cloud per Protected Audience spingeranno le aziende a utilizzare Google Cloud?

Privacy Sandbox ha progettato le API per garantire privacy e sicurezza solide e non abbiamo preso alcuna decisione di progettazione a vantaggio di Google Cloud. Il nostro supporto ai provider di servizi cloud è iniziato con AWS perché riconosciamo quanti fornitori di tecnologia pubblicitaria scelgono Amazon. Oltre ad AWS e Google Cloud, prevediamo di supportare altri cloud provider in futuro e siamo aperti a ricevere suggerimenti per altri cloud provider. Se la latenza è un problema, i cloud offrono ai clienti scelte di geolocalizzazione che riducono le distanze da altri cloud provider.

Privacy Sandbox consentirà di utilizzare i Trusted Execution Environment (TEE) in data center cloud non pubblici?

I Trusted Execution Environment (TEE) verificabili fanno parte del nostro modello di privacy e sicurezza. Abbiamo iniziato con i TEE offerti dai provider di servizi cloud pubblici grazie a rigorose misure di sicurezza. Per essere chiari, le uniche API che richiedono l'uso di ambienti di esecuzione attendibili nel breve termine sono l'API Attribution Reporting e l'API Private Aggregation e nessuna delle due prevede la chiamata del TEE in tempo reale in un'asta. Stiamo continuando a esplorare le opzioni di supporto oltre alle soluzioni pubbliche basate su cloud.

Non sarebbe più costoso eseguire ambienti di esecuzione attendibili nei cloud pubblici rispetto ai data center on-premise di ad tech?

Il nostro attuale modello di privacy TEE trae vantaggio dalle pratiche di sicurezza delle implementazioni del cloud pubblico e mettiamo in discussione l'ipotesi che sia meno costoso gestire un ambiente di esecuzione affidabile on-premise. Ecco alcune considerazioni sui costi per queste pratiche:

I provider di servizi cloud pubblici devono rispettare un livello di sicurezza molto elevato. Ad esempio, AWS è un cloud provider affidabile con pratiche di sicurezza consolidate. In particolare, AWS Nitro ha un modello di sicurezza documentato per garantire che le enclave nitro impediscano agli operatori di accedere ai dati elaborati nell'enclave e le risorse protette (come le chiavi di decrittografia) sono disponibili solo per il codice autorizzato in esecuzione nell'enclave. C'è anche l'accesso fisico da considerare. AWS ha progettato e implementato mitigazioni per i rischi di accesso fisico, anche da parte dei dipendenti di Amazon. I TEE esistenti basati su hardware potrebbero non difendere da tutti gli attacchi fisici, cosa che i cloud pubblici sono progettati per eseguire. Inoltre, Amazon di recente ha incaricato NCC Group, uno studio di ricerca indipendente, di esaminare i propri progetti Nitro, incentrati sulle richieste di sicurezza relative all'accesso da parte dei dipendenti interni. Il report pubblico indica che i design AWS soddisfano le loro dichiarazioni.

L'implementazione, l'assistenza e il miglioramento nel tempo hanno un costo. Con cloud pubblici distribuiti a livello globale e ampiamente disponibili, questi costi si estendono su un'ampia base di clienti.

Privacy Sandbox cambia la fatturazione?

No. Le società di ad tech e gli altri chiamanti dell'API possono continuare a vedere se viene eseguito il rendering di qualcosa in una pagina e a quale prezzo.

È possibile applicare una quota limite in Privacy Sandbox?

Protected Audience supporta la quota limite su più siti all'interno dello stesso gruppo di interesse tramite l'oggetto prevWinsMs. La funzione generateBid() di un acquirente nell'asta Protected Audience può creare una logica in grado di definire la strategia di offerta in base al risultato di esposizioni di annunci precedenti per lo stesso browser.

Esistono alcune soluzioni che possono essere utilizzate per la quota limite al di fuori di Protected Audience, ma non sono perfettamente compatibili con le tecniche cross-site che gli ad tech hanno a disposizione con i cookie di terze parti.

• Cookie proprietari: gli ad tech possono usare i dati proprietari per stabilire la quota limite sul proprio sito
• CHIP: gli ad tech possono gestire le quote limite a livello di sito utilizzando un cookie partizionato
• Spazio di archiviazione condiviso SelectURL(): dopo che un ad tech ha vinto un'asta e prima che venga visualizzata la creatività, può chiamare lo spazio di archiviazione condiviso per accedere ai dati cross-site e scegliere la creatività giusta in base alla frequenza attraverso la porta di output Seleziona URL.

Una soluzione di quota limite di Pubblico non protetto e con priorità alla privacy che fornisca un'utilità significativa della tecnologia pubblicitaria è complicata per i seguenti motivi:

• In base al feedback della tecnologia pubblicitaria, al momento non è chiaro se un segnale di frequenza può tollerare i rumori.
• Abbiamo ricevuto feedback coerenti sulla tecnologia pubblicitaria secondo cui un indicatore di frequenza tra siti dovrebbe essere disponibile al momento dell'asta, il che richiede che gli indicatori cross-site senza rumore siano disponibili per l'utilizzo in qualsiasi asta pubblicitaria. Ciò potrebbe rivelare una grande quantità di informazioni sull'attività di un utente nei vari siti, minando gli obiettivi di privacy di Privacy Sandbox.
• Siamo sensibili all'introduzione di latenza e una soluzione on-device che potrebbe fornire questo indicatore potrebbe causare latenza e interrompere l'ambiente delle aste.
• Una soluzione dovrebbe essere una nuova API, che deve passare attraverso il processo di proposta W3C.

Pertanto, non è prevista la creazione di una soluzione per la quota limite al di fuori di Protected Audience, ma siamo aperti a ricevere feedback sulle possibili soluzioni di questo caso d'uso.

E i casi d'uso che non sono coperti da Privacy Sandbox?

Le API Privacy Sandbox forniscono componenti di base fondamentali per una pubblicità che tutela la privacy, in cui gli sviluppatori hanno la flessibilità per determinare come devono essere uniti. L'approccio basato sui componenti di base permette alle aziende di innovare e sviluppare soluzioni che apportano valore. Privacy Sandbox non è una soluzione end-to-end per tutti i casi d'uso. Riteniamo che sarebbe un esito negativo. Sviluppatori e aziende continueranno a dare vita alle loro idee tramite una varietà di tecnologie, tra cui le API Privacy Sandbox che integrano nelle loro soluzioni.