Indicatori di app protetti per supportare annunci per l'installazione di app pertinenti

Questa proposta è soggetta alla procedura di registrazione a Privacy Sandbox e alle attestazioni. Per ulteriori informazioni sulle attestazioni, consulta il link fornito. I futuri aggiornamenti di questa proposta descriveranno i requisiti per ottenere l'accesso a questo sistema.

Gli annunci per l'installazione di app mobile, noti anche come annunci per l'acquisizione di utenti, sono un tipo di pubblicità mobile progettata per incoraggiare gli utenti a scaricare un'app mobile. Questi annunci vengono in genere pubblicati per gli utenti in base ai loro interessi e dati demografici e spesso vengono visualizzati in altre app mobile come giochi, social media e app di notizie. Quando un utente fa clic su un annuncio per l'installazione di app, viene indirizzato direttamente allo store per scaricare l'app.

Ad esempio, un inserzionista che sta cercando di aumentare le nuove installazioni di una nuova app mobile di consegna di cibo negli Stati Uniti potrebbe indirizzare i propri annunci agli utenti la cui posizione si trova negli Stati Uniti e che in precedenza hanno interagito con altre app di consegna di cibo.

In genere, questa operazione viene implementata includendo indicatori contestuali, proprietari e di terze parti tra le tecnologie pubblicitarie per creare profili utente basati sugli ID pubblicità. I modelli di machine learning della tecnologia pubblicitaria utilizzano queste informazioni come input per scegliere gli annunci pertinenti per l'utente e con la più alta probabilità di generare una conversione.

Le seguenti API sono proposte per supportare annunci per l'installazione di app efficaci che migliorano la privacy degli utenti eliminando il ricorso a identificatori di utenti trasversali:

1. API Protected App Signals: si concentra sull'archiviazione e sulla creazione di funzionalità progettate con tecnologia pubblicitaria che rappresentano i potenziali interessi di un utente. Le tecnologie pubblicitarie memorizzano indicatori di eventi per app autodefiniti, come installazioni di app, prime aperture, azioni utente (livelli di gioco, obiettivi), attività di acquisto o tempo trascorso nell'app. Gli indicatori vengono scritti e memorizzati sul dispositivo per proteggere dalla perdita di dati e sono resi disponibili solo alla logica della tecnologia pubblicitaria che ha memorizzato il determinato indicatore durante un'asta protetta eseguita in un ambiente sicuro.
2. API Ad Selection: fornisce un'API per configurare ed eseguire un'asta protetta in un Trusted Execution Environment (TEE) in cui le tecnologie pubblicitarie recuperano i candidati per gli annunci, eseguono l'inferenza, calcolano le offerte ed eseguono lo scoring per scegliere un annuncio "vincente" utilizzando sia gli indicatori protetti delle app sia le informazioni contestuali in tempo reale fornite dall'editore.

Di seguito è riportata una panoramica generale del funzionamento degli indicatori delle app protetti per supportare annunci per l'installazione di app pertinenti. Le sezioni seguenti di questo documento forniscono maggiori dettagli su ciascuno di questi passaggi.

• Selezione degli indicatori: quando gli utenti utilizzano le app mobile, le tecnologie pubblicitarie selezionano gli indicatori memorizzando gli eventi app definiti dalla tecnologia pubblicitaria per pubblicare annunci pertinenti utilizzando l'API Protected App Signals. Questi eventi vengono archiviati in uno spazio di archiviazione protetto sul dispositivo, in modo simile ai segmenti di pubblico personalizzati, e vengono criptati prima di essere inviati dal dispositivo in modo che solo i servizi di aste e offerte in esecuzione in ambienti di esecuzione attendibili con il controllo di sicurezza e privacy appropriato possano decriptarli per le offerte e l'assegnazione di un punteggio agli annunci.
• Codifica degli indicatori: gli indicatori vengono preparati con una cadenza pianificata mediante una logica di tecnologia pubblicitaria personalizzata. Un job in background di Android esegue questa logica per eseguire la codifica on-device per generare un payload di Protected App Signals che può essere utilizzato in tempo reale per la selezione degli annunci durante un'asta protetta. Il payload viene memorizzato in modo sicuro sul dispositivo fino all'invio per un'asta.
• Selezione degli annunci: per selezionare gli annunci pertinenti per l'utente, gli SDK del venditore inviano un payload criptato di indicatori protetti delle app e configurano un'asta protetta. Nell'asta, la logica personalizzata dell'acquirente prepara gli indicatori delle app protetti insieme ai dati contestuali forniti dal publisher (dati in genere condivisi in una richiesta di annuncio Open-RTB) per progettare funzionalità destinate alla selezione degli annunci (recupero, inferenza e generazione delle offerte). Analogamente a Protected Audience, gli acquirenti inviano gli annunci al venditore per la valutazione finale in un'asta protetta.
  • Recupero degli annunci: gli acquirenti utilizzano gli indicatori protetti delle app e i dati contestuali forniti dai publisher per progettare funzionalità pertinenti agli interessi dell'utente. Queste funzionalità vengono utilizzate per trovare annunci che soddisfano i criteri di targeting. Gli annunci che non rientrano nel budget vengono filtrati. Vengono quindi selezionati i primi k annunci per le offerte.
  • Offerte: la logica di offerta personalizzata degli acquirenti prepara i dati contestuali forniti dall'editore e gli indicatori protetti delle app per progettare funzionalità che vengono utilizzate come input per i modelli di machine learning degli acquirenti per l'inferenza e le offerte sugli annunci candidati all'interno di limiti attendibili che preservano la privacy. L'acquirente restituirà quindi l'annuncio scelto al venditore.
  • Punteggio del venditore: la logica di assegnazione del punteggio personalizzata dei venditori assegna un punteggio agli annunci inviati dagli acquirenti partecipanti e sceglie un annuncio vincente da inviare all'app per il rendering.
• Report: i partecipanti all'asta ricevono i report sulle vittorie e sulle perdite applicabili. Stiamo esplorando meccanismi che preservano la privacy per includere i dati per l'addestramento del modello nel report sulle vittorie.

Cronologia

Curare Protected App Signals

Un indicatore è una rappresentazione di varie interazioni degli utenti in un'app che sono considerate utili dalla tecnologia pubblicitaria per pubblicare annunci pertinenti. Un'app o l'SDK integrato può archiviare o eliminare gli indicatori protetti delle app definiti dalle tecnologie pubblicitarie in base all'attività dell'utente, ad esempio aperture di app, obiettivi, attività di acquisto o tempo trascorso nell'app. Gli indicatori protetti delle app vengono archiviati in modo sicuro sul dispositivo e vengono criptati prima di essere inviati dal dispositivo in modo che solo i servizi di offerta e asta eseguiti in Trusted Execution Environment con controlli di sicurezza e privacy appropriati possano decriptarli per le offerte e l'assegnazione di punteggi agli annunci. Analogamente all'API Custom Audience, i segnali memorizzati su un dispositivo non possono essere letti o ispezionati da app o SDK; non esiste un'API per la lettura dei valori dei segnali e le API sono progettate per evitare la divulgazione della presenza di segnali. La logica personalizzata della tecnologia pubblicitaria ha accesso protetto agli indicatori curati per progettare funzionalità che fungono da base per la selezione degli annunci in un'asta protetta.

API Protected App Signals

L'API Protected App Signals supporta la gestione degli indicatori utilizzando un meccanismo di delega simile a quello utilizzato per i segmenti di pubblico personalizzati. L'API Protected App Signals consente di archiviare i segnali sotto forma di un singolo valore scalare o come serie temporale. Gli indicatori delle serie temporali possono essere utilizzati per memorizzare elementi come la durata della sessione utente. Gli indicatori delle serie temporali offrono un'utilità per applicare una determinata lunghezza utilizzando una regola di eliminazione FIFO (first in, first out). Il tipo di dati di un segnale scalare o di ciascuno degli elementi di un segnale di serie temporale è un array di byte. Ogni valore è arricchito con il nome del pacchetto dell'applicazione che ha memorizzato il segnale e il timestamp di creazione della chiamata API Store Signal. Queste informazioni aggiuntive sono disponibili in JavaScript di codifica degli indicatori. Questo esempio mostra la struttura degli indicatori di proprietà di una determinata tecnologia pubblicitaria:

Questo esempio mostra un segnale scalare e un segnale di serie temporale associati a adtech1.com:

• Un indicatore scalare con chiave valore Base64 "A1c" e valore "c12Z". L'archivio indicatori è stato attivato da com.google.android.game_app il giorno 1 giugno 2023.
• Un elenco di indicatori con la chiave "dDE" creati da due applicazioni diverse.

Le tecnologie pubblicitarie dispongono di una certa quantità di spazio per archiviare i segnali sul dispositivo. I segnali avranno un TTL massimo, che deve essere determinato.

Gli indicatori delle app protette vengono rimossi dallo spazio di archiviazione se l'applicazione che li genera viene disinstallata, se l'utilizzo dell'API Protected App Signals viene bloccato o se i dati dell'app vengono cancellati dall'utente.

L'API Protected App Signals è composta dalle seguenti parti:

• Un'API Java e JavaScript per aggiungere, aggiornare o rimuovere indicatori.
• un'API JavaScript per elaborare gli indicatori persistenti per prepararli per un'ulteriore ingegneria delle funzionalità in tempo reale durante un'asta protetta in esecuzione in un ambiente di esecuzione attendibile (TEE).

Aggiungere, aggiornare o rimuovere indicatori

Le tecnologie pubblicitarie possono aggiungere, aggiornare o rimuovere indicatori con l'API fetchSignalUpdates(). Questa API supporta la delega in modo simile alla delega del segmento di pubblico personalizzato di Protected Audience.

Per aggiungere un indicatore, le tecnologie pubblicitarie dell'acquirente che non hanno una presenza SDK nelle app devono collaborare con le tecnologie pubblicitarie che hanno una presenza sul dispositivo, come i partner di misurazione mobile (MMP) e le Supply-Side Platform (SSP). L'API Protected App Signals mira a supportare queste tecnologie pubblicitarie fornendo soluzioni flessibili per la gestione dei Protected App Signals consentendo ai chiamanti on-device di richiamare la creazione di Protected App Signals per conto degli acquirenti. Questa procedura è chiamata delega e utilizza l'API fetchSignalUpdates(). fetchSignalUpdates() accetta un URI e recupera un elenco di aggiornamenti dei segnali. Per illustrare, fetchSignalUpdates() invia una richiesta GET all'URI specificato per recuperare l'elenco degli aggiornamenti da applicare all'archivio dei segnali locali. L'endpoint URL, di proprietà dell'acquirente, risponde con un elenco JSON di comandi.

I comandi JSON supportati sono:

• put: inserisce o sostituisce un valore scalare per la chiave specificata.
• put_if_not_present: inserisce un valore scalare per la chiave specificata se non è già presente un valore memorizzato. Questa opzione potrebbe essere utile, ad esempio, per impostare un ID esperimento per l'utente specificato ed evitare di sostituirlo se è già stato impostato da un'altra applicazione.
• append: aggiunge un elemento alla serie temporale associata alla chiave specificata. Il parametro maxSignals specifica il numero massimo di indicatori nella serie temporale. Se la dimensione viene superata, gli elementi precedenti vengono rimossi. Se la chiave contiene un valore scalare, viene trasformata automaticamente in una serie temporale.
• remove: rimuove i contenuti associati alla chiave specificata.

{
   "put": {
    "A1c": "c12Z",
    "dDE": "d23d",
  },
  "put_if_not_present": {
    "aA9": "a1zfC3"
  }
  "append": {
    "bB1": {"values": ["gh12D", "d45g"], "maxSignals": 20}
  },
  "remove": ["c0D"]
}

Tutte le chiavi e i valori sono espressi in Base64.

Questi comandi elencati hanno lo scopo di fornire semantica di inserimento, sovrascrittura ed eliminazione per gli indicatori scalari e di inserimento, accodamento e sovrascrittura completa delle serie per gli indicatori delle serie temporali. La semantica di eliminazione e sovrascrittura su elementi specifici di un indicatore di serie temporale deve essere gestita durante il processo di codifica e compattazione; ad esempio, durante la codifica, ignorando i valori di una serie temporale che sono sostituiti o corretti da quelli più recenti ed eliminandoli durante il processo di compattazione.

Gli indicatori memorizzati vengono associati automaticamente all'applicazione che esegue la richiesta di recupero e al rispondente della richiesta (il "sito" o "origine" di una tecnologia pubblicitaria registrata), nonché all'ora di creazione della richiesta. Tutti gli indicatori sono soggetti a essere archiviati per conto di una tecnologia pubblicitaria registrata a Privacy Sandbox, l'URI "site"/"origin" deve corrispondere ai dati di una tecnologia pubblicitaria registrata. Se la tecnologia pubblicitaria richiedente non è registrata, la richiesta viene rifiutata.

Quota di spazio di archiviazione e sfratto

Ogni tecnologia pubblicitaria ha uno spazio limitato sul dispositivo dell'utente per archiviare i segnali. Questa quota è definita per tecnologia pubblicitaria, quindi i segnali curati da app diverse condividono la quota. Se la quota viene superata, il sistema libera spazio rimuovendo i valori degli indicatori precedenti in base all'ordine di arrivo. Per evitare che l'espulsione venga eseguita troppo spesso, il sistema implementa una logica di batch per consentire una quantità limitata di superamento della quota e per liberare spazio aggiuntivo una volta attivata la logica di espulsione.

Codifica on-device per la trasmissione dei dati

Per preparare gli indicatori per la selezione degli annunci, la logica personalizzata per acquirente ha accesso protetto agli indicatori e agli eventi per app archiviati. Un job in background del sistema Android viene eseguito ogni ora per eseguire la logica di codifica personalizzata per acquirente scaricata sul dispositivo. La logica di codifica personalizzata per acquirente codifica gli indicatori per app e poi li comprime in un payload conforme alla quota per acquirente. Il payload viene quindi criptato entro i limiti dello spazio di archiviazione protetto del dispositivo e poi trasmesso ai servizi di offerte e asta.

Le tecnologie pubblicitarie definiscono il livello di elaborazione degli indicatori gestito dalla propria logica personalizzata. Ad esempio, potresti instrumentare la tua soluzione per eliminare i segnali precedenti e aggregare segnali simili o di rinforzo provenienti da applicazioni diverse in nuovi segnali che utilizzano meno spazio.

Se un acquirente non ha registrato un codificatore di indicatori, questi non vengono preparati e nessuno degli indicatori curati sul dispositivo viene inviato ai servizi di aste e offerte.

Ulteriori dettagli su archiviazione, payload e quote di richieste saranno disponibili in un aggiornamento futuro. Inoltre, forniremo ulteriori informazioni su come fornire funzioni personalizzate.

Flusso di lavoro di selezione degli annunci

Con questa proposta, il codice personalizzato della tecnologia pubblicitaria può accedere solo ai Protected App Signals all'interno di un'asta protetta (API Ad Selection) in esecuzione in un TEE. Per supportare ulteriormente le esigenze del caso d'uso dell'installazione di app, gli annunci candidati vengono recuperati durante l'asta protetta in tempo reale. Ciò è in contrasto con il caso d'uso del remarketing, in cui gli annunci candidati sono noti prima dell'asta.

Questa proposta utilizza un flusso di lavoro di selezione degli annunci simile a quello della proposta Protected Audience con aggiornamenti per supportare il caso d'uso dell'installazione di app. Per supportare i requisiti di calcolo per l'ingegneria delle funzionalità e la selezione degli annunci in tempo reale, le aste per gli annunci di installazione di app devono essere eseguite sui servizi di offerte e aste in esecuzione in TEE. L'accesso ai Protected App Signals durante un'asta protetta non è supportato con le aste on-device.

Il flusso di lavoro di selezione degli annunci è il seguente:

1. L'SDK del venditore invia il payload criptato sul dispositivo degli indicatori protetti delle app.
2. Il server del venditore crea una configurazione dell'asta e la invia al servizio Trusted Bidding and Auction del venditore, insieme al payload criptato, per avviare un flusso di lavoro di selezione degli annunci.
3. Il servizio di offerte e aste del venditore trasmette il payload ai server frontend degli acquirenti attendibili partecipanti.
4. Il servizio di offerta dell'acquirente esegue la logica di selezione degli annunci lato acquisti
   1. Esecuzione della logica di recupero degli annunci lato acquisti.
   2. Esecuzione della logica di offerta lato acquirente.
5. Viene eseguita la logica di assegnazione del punteggio lato vendite.
6. L'annuncio viene visualizzato e viene avviata la generazione di report.

Avviare il flusso di lavoro di selezione degli annunci

Quando un'applicazione è pronta a mostrare un annuncio, l'SDK di tecnologia pubblicitaria (in genere le SSP) avvia il flusso di lavoro di selezione degli annunci inviando i dati contestuali pertinenti del publisher e i payload criptati per acquirente da includere nella richiesta da inviare all'asta protetta utilizzando la chiamata getAdSelectionData. Si tratta della stessa API utilizzata per il flusso di lavoro di remarketing e descritta nella proposta Integrazione di offerte e asta per Android.

Per avviare la selezione degli annunci, il venditore trasmette un elenco di acquirenti partecipanti e il payload criptato degli indicatori protetti delle app sul dispositivo. Con queste informazioni, l'ad server lato venditore prepara un SelectAdRequest per il proprio servizio SellerFrontEnd attendibile.

Il venditore imposta quanto segue:

• Il payload ricevuto da getAdSelectionData, che contiene gli indicatori protetti delle app.

• Gli indicatori contestuali che utilizzano:

  • auction_config.auction_signals (per informazioni sull'asta)

  • auction_config.seller_signals (per gli indicatori del venditore

  • auction_config.per_buyer_config["buyer"].buyer_signals (per gli indicatori degli acquirenti)

• L'elenco degli acquirenti inclusi nelle aste utilizzando il campo buyer_list.

Esecuzione della logica di selezione degli annunci lato acquisti

A livello generale, la logica personalizzata dell'acquirente utilizza i dati contestuali forniti dal publisher e gli indicatori protetti delle app per selezionare e applicare un'offerta agli annunci pertinenti per la richiesta di annuncio. La piattaforma consente agli acquirenti di restringere un ampio pool di annunci disponibili a quelli più pertinenti (i primi k), per i quali le offerte vengono calcolate prima che gli annunci vengano restituiti al venditore per la selezione finale.

Prima di fare offerte, gli acquirenti iniziano con un ampio pool di annunci. È troppo lento per calcolare un'offerta per ogni annuncio, quindi gli acquirenti devono prima selezionare i primi k candidati dal pool di grandi dimensioni. Successivamente, gli acquirenti devono calcolare le offerte per ciascuno dei primi k candidati. Quindi, gli annunci e le offerte vengono restituiti al venditore per la selezione finale.

1. Il servizio BuyerFrontEnd riceve una richiesta di annuncio.
2. Il servizio BuyerFrontEnd invia una richiesta al servizio di offerta dell'acquirente. Il servizio di offerta dell'acquirente esegue una UDF chiamata prepareDataForAdRetrieval(), che crea una richiesta per ottenere i primi k candidati dal servizio di recupero degli annunci. Il servizio di offerta invia questa richiesta all'endpoint del server di recupero configurato.
3. Il servizio di recupero degli annunci esegue la getCandidateAds() UDF, che filtra il set dei primi k annunci candidati, che vengono inviati al servizio di offerta dell'acquirente.
4. Il servizio di offerta dell'acquirente esegue la UDF generateBid(), che seleziona il miglior candidato, calcola la sua offerta e la restituisce al servizio BuyerFrontEnd.
5. Il servizio BuyerFrontEnd restituisce gli annunci e le offerte al venditore.

Esistono diversi dettagli importanti su questo flusso, in particolare per quanto riguarda il modo in cui le parti comunicano tra loro e il modo in cui la piattaforma fornisce funzionalità come la possibilità di fare previsioni di machine learning per recuperare i primi k annunci e calcolare le relative offerte.

Prima di esaminare in dettaglio alcune parti, ci sono alcune note architetturali importanti sulle TEE in questo diagramma.

Il servizio di offerta dell'acquirente contiene internamente un servizio di inferenza. Le tecnologie pubblicitarie possono caricare modelli di machine learning nel servizio di offerta dell'acquirente. Forniremo API JavaScript per consentire alle tecnologie pubblicitarie di fare previsioni o generare incorporamenti da questi modelli all'interno delle UDF eseguite sul servizio di offerta dell'acquirente. A differenza del servizio di recupero degli annunci, il servizio di offerta dell'acquirente non dispone di un servizio di valori chiave per archiviare i metadati degli annunci.

Il servizio di recupero degli annunci include internamente un servizio di coppie chiave-valore. Le tecnologie pubblicitarie possono materializzare le coppie chiave-valore in questo servizio dai propri server, al di fuori del limite della privacy. Forniremo un'API JavaScript per consentire alle tecnologie pubblicitarie di leggere questo servizio di coppie chiave-valore all'interno delle UDF in esecuzione nel servizio di recupero degli annunci. A differenza del servizio di offerta dell'acquirente, il servizio di recupero degli annunci non contiene un servizio di inferenza.

Una domanda centrale a cui risponde questo design è come fare previsioni al momento del recupero e dell'offerta. La risposta a entrambi può comportare una soluzione chiamata fattorizzazione del modello.

Fattorizzazione del modello

La fattorizzazione del modello è una tecnica che consente di suddividere un singolo modello in più parti e poi combinarle in una previsione. Nello scenario di utilizzo dell'installazione di app, i modelli spesso utilizzano tre tipi di dati: dati utente, dati contestuali e dati degli annunci.

Nel caso non fattorizzato, un singolo modello viene addestrato su tutti e tre i tipi di dati. Nel caso fattorizzato, dividiamo il modello in più parti. Solo la parte contenente i dati utente è sensibile. Ciò significa che solo il modello con la parte utente deve essere eseguito all'interno del perimetro di trust, nel servizio di inferenza del servizio di offerta dell'acquirente.

Ciò rende possibile il seguente design:

1. Dividi il modello in una parte privata (i dati utente) e una o più parti non private (i dati contestuali e degli annunci).
2. Se vuoi, passa alcuni o tutti i pezzi non privati come argomenti a una UDF che deve fare previsioni. Ad esempio, gli incorporamenti contestuali vengono trasferiti alle UDF in per_buyer_signals.
3. Se vuoi, le ad tech possono creare modelli per elementi non privati, quindi materializzare gli incorporamenti da questi modelli nell'archivio chiave-valore del servizio di recupero degli annunci. Le UDF nel servizio di recupero degli annunci possono recuperare questi incorporamenti in fase di runtime.
4. Per fare una previsione durante una UDF, combina gli incorporamenti privati del servizio di inferenza con gli incorporamenti non privati degli argomenti della funzione UDF o dell'archivio chiave-valore con un'operazione come un prodotto scalare. Questa è la previsione finale.

Ora che abbiamo spiegato questo concetto, possiamo esaminare ogni UDF in modo più dettagliato. Ti spiegheremo cosa fanno, come si integrano e come possono fare le previsioni necessarie per scegliere gli annunci top k e calcolare le relative offerte.

Funzione definita dall'utente prepareDataForAdRetrieval()

prepareDataForAdRetrieval() in esecuzione sul servizio di offerta dell'acquirente è responsabile della creazione del payload della richiesta che verrà inviato al servizio di recupero degli annunci per recuperare i primi k annunci candidati.

prepareDataForAdRetrieval() richiede le seguenti informazioni:

• Il payload per acquirente ricevuto da getAdSelectionData. Questo payload contiene i Protected App Signals.
• auction_signals dei segnali contestuali (per le informazioni sull'asta) e buyer_signals (per i campi segnali degli acquirenti).

prepareDataForAdRetrieval() svolge due funzioni:

• Featurizzazione: se è necessaria l'inferenza in fase di recupero, trasforma i segnali in entrata in funzionalità da utilizzare durante le chiamate al servizio di inferenza per ottenere incorporamenti privati per il recupero.
• Calcola gli incorporamenti privati per il recupero: se sono necessarie previsioni di recupero, effettua la chiamata al servizio di inferenza utilizzando queste funzionalità e ottiene un incorporamento privato per le previsioni in fase di recupero.

Resi a prepareDataForAdRetrieval():

• Protected App Signals: payload degli indicatori curati dalla tecnologia pubblicitaria.
• Indicatori specifici dell'asta: indicatori sell-side specifici della piattaforma e informazioni contestuali come auction_signals e per_buyer_signals (inclusi gli incorporamenti contestuali) di SelectAdRequest. Questo è simile ai segmenti di pubblico protetti.
• Segnali aggiuntivi: informazioni extra come incorporamenti privati recuperati dal servizio di inferenza.

Questa richiesta viene inviata al servizio di recupero degli annunci, che esegue la corrispondenza dei candidati e poi esegue la UDF getCandidateAds().

Funzione definita dall'utente getCandidateAds()

getCandidateAds() viene eseguito sul servizio di recupero degli annunci. Riceve la richiesta creata da prepareDataForAdRetrieval() nel servizio di offerta dell'acquirente. Il servizio esegue getCandidateAds() che recupera i primi k candidati per le offerte convertendo la richiesta in una serie di query di set, recuperi di dati ed eseguendo logica di business personalizzata e altra logica di recupero personalizzata.

getCandidateAds() richiede le seguenti informazioni:

• Protected App Signals: payload degli indicatori curati dalla tecnologia pubblicitaria.
• Indicatori specifici dell'asta: indicatori sell-side specifici della piattaforma e informazioni contestuali come auction_signals e per_buyer_signals (inclusi gli incorporamenti contestuali) di SelectAdRequest. Questo è simile ai segmenti di pubblico protetti.
• Segnali aggiuntivi: informazioni extra come incorporamenti privati recuperati dal servizio di inferenza.

getCandidateAds() esegue le seguenti operazioni:

1. Recupera un insieme iniziale di candidati annuncio: recuperati utilizzando criteri di targeting come lingua, area geografica, tipo di annuncio, dimensione dell'annuncio o budget, per filtrare i candidati annuncio.
2. Recupero dell'incorporamento di recupero: se gli incorporamenti del servizio chiave-valore sono necessari per fare una previsione al momento del recupero per la selezione dei primi k risultati, devono essere recuperati dal servizio chiave-valore.
3. Selezione dei primi k candidati: calcola un punteggio leggero per l'insieme filtrato di candidati annuncio in base ai metadati dell'annuncio recuperati dall'archivio chiave-valore e alle informazioni inviate dal servizio di offerta dell'acquirente e scegli i primi k candidati in base a questo punteggio. Ad esempio, il punteggio potrebbe essere la probabilità di installare un'app dato l'annuncio.
4. Recupero degli incorporamenti per le offerte: se il codice di offerta ha bisogno degli incorporamenti del servizio chiave-valore per fare previsioni al momento dell'offerta, questi possono essere recuperati dal servizio chiave-valore.

Tieni presente che il punteggio di un annuncio potrebbe essere il risultato di un modello predittivo che, ad esempio, prevede la probabilità che un utente installi un'app. Questo tipo di generazione di punteggio comporta una sorta di fattorizzazione del modello: poiché getCandidateAds() viene eseguito sul servizio di recupero degli annunci e poiché il servizio di recupero degli annunci non dispone di un servizio di inferenza, le previsioni potrebbero essere generate combinando:

• Incorporamenti contestuali passati utilizzando l'input indicatori specifici per l'asta.
• Incorporamenti privati passati utilizzando l'input indicatori aggiuntivi.
• Tutte le tecnologie pubblicitarie di incorporamento non private sono state materializzate dai loro server nel servizio di coppie chiave-valore del servizio di recupero degli annunci.

Tieni presente che la generateBid() UDF eseguita sul servizio di offerta dell'acquirente potrebbe applicare anche un proprio tipo di fattorizzazione del modello per fare le sue previsioni di offerta. Se sono necessari incorporamenti da un servizio di coppie chiave-valore per farlo, devono essere recuperati ora.

Resi a getCandidateAds():

• Annunci candidati: i primi k annunci da trasmettere a generateBid(). Ogni annuncio è composto da:
  • URL di rendering: endpoint per il rendering della creatività annuncio.
  • Metadati: metadati degli annunci specifici per la tecnologia pubblicitaria lato acquirente. Ad esempio, questo può includere informazioni sulla campagna pubblicitaria e sui criteri di targeting come località e lingua. I metadati possono includere incorporamenti facoltativi utilizzati quando è necessaria la fattorizzazione del modello per eseguire l'inferenza durante l'offerta.
• Segnali aggiuntivi: se vuoi, il servizio di recupero degli annunci può includere informazioni aggiuntive, come incorporamenti o segnali di spam da utilizzare in generateBid().

Stiamo esaminando altri metodi per fornire gli annunci da valutare, tra cui renderli disponibili nell'ambito della chiamata SelectAdRequest. Questi annunci possono essere recuperati utilizzando una richiesta di offerta RTB. Tieni presente che in questi casi gli annunci devono essere recuperati senza indicatori protetti delle app. Prevediamo che le tecnologie pubblicitarie valuteranno i compromessi prima di scegliere l'opzione migliore, tra cui le dimensioni del payload di risposta, la latenza, il costo e la disponibilità degli indicatori.

Funzione definita dall'utente generateBid()

Una volta recuperato l'insieme di annunci candidati e gli incorporamenti durante il recupero, puoi procedere con l'offerta, che viene eseguita nel servizio di offerta dell'acquirente. Questo servizio esegue la funzione definita dall'utente generateBid() fornita dall'acquirente per selezionare l'annuncio su cui fare un'offerta tra i primi k, quindi lo restituisce con la relativa offerta.

generateBid() richiede le seguenti informazioni:

• Annunci candidati: i primi k annunci restituiti dal servizio di recupero degli annunci.
• Indicatori specifici dell'asta: indicatori sell-side specifici della piattaforma e informazioni contestuali come auction_signals e per_buyer_signals (inclusi gli incorporamenti contestuali) di SelectAdRequest.
• Indicatori aggiuntivi: informazioni aggiuntive da utilizzare al momento dell'offerta.

L'implementazione di generateBid() dell'acquirente svolge tre funzioni:

• Featurizzazione: trasforma gli indicatori in funzionalità da utilizzare durante l'inferenza.
• Inferenza: genera previsioni utilizzando modelli di machine learning per calcolare valori come le percentuali di clic e di conversione previste.
• Offerte: combinazione di valori dedotti con altri input per calcolare l'offerta per un annuncio candidato.

Resi a generateBid():

• L'annuncio del candidato.
• L'importo dell'offerta calcolato.

Tieni presente che il generateBid() utilizzato per gli annunci per l'installazione di app e quello utilizzato per gli annunci di remarketing sono diversi.

Le sezioni seguenti descrivono in modo più dettagliato la generazione delle funzionalità, l'inferenza e le offerte.

Estrai caratteristiche

Gli indicatori dell'asta possono essere preparati da generateBid() in funzionalità. Queste funzionalità possono essere utilizzate durante l'inferenza per prevedere elementi come la percentuale di clic e i tassi di conversione. Stiamo anche esplorando meccanismi che tutelano la privacy per trasmettere alcuni di questi dati nel report sulle vittorie per l'utilizzo nell'addestramento dei modelli.

Inferenza

Durante il calcolo di un'offerta, è comune eseguire l'inferenza su uno o più modelli di machine learning. Ad esempio, i calcoli dell'eCPM effettivo spesso utilizzano modelli per prevedere le percentuali di clic e di conversione.

I clienti possono fornire una serie di modelli di machine learning insieme alla loro implementazione di generateBid(). Forniremo anche un'API JavaScript all'interno di generateBid() in modo che i client possano eseguire l'inferenza in fase di runtime.

L'inferenza viene eseguita sul servizio di offerta dell'acquirente. Ciò può influire sulla latenza e sul costo dell'inferenza, soprattutto perché gli acceleratori non sono ancora disponibili negli TEE. Alcuni clienti scopriranno che le loro esigenze vengono soddisfatte con modelli individuali eseguiti sul servizio di offerta dell'acquirente. Alcuni clienti, ad esempio quelli con modelli molto grandi, potrebbero voler prendere in considerazione opzioni come la fattorizzazione del modello per ridurre al minimo il costo e la latenza dell'inferenza al momento dell'offerta.

Ulteriori informazioni sulle funzionalità di inferenza, come i formati dei modelli supportati e le dimensioni massime, verranno fornite in un futuro aggiornamento.

Implementare la fattorizzazione del modello

In precedenza abbiamo spiegato la fattorizzazione del modello. Al momento dell'offerta, l'approccio specifico è:

1. Dividi il modello singolo in una parte privata (i dati utente) e una o più parti non private (i dati contestuali e degli annunci).
2. Passa i pezzi non privati a generateBid(). Questi possono provenire da per_buyer_signals o da incorporamenti che le tecnologie pubblicitarie calcolano esternamente, materializzano nell'archivio chiave-valore del servizio di recupero, recuperano al momento del recupero e restituiscono come parte degli indicatori aggiuntivi. Non sono inclusi i contenuti incorporati privati, in quanto non possono essere recuperati al di fuori del confine della privacy.
3. In generateBid():
   1. Esegui l'inferenza sui modelli per ottenere incorporamenti privati degli utenti.
   2. Combina gli incorporamenti privati degli utenti con gli incorporamenti contestuali di per_buyer_signals o gli incorporamenti contestuali e degli annunci non privati del servizio di recupero utilizzando un'operazione come un prodotto scalare. Questa è la previsione finale che può essere utilizzata per calcolare le offerte.

Utilizzando questo approccio, è possibile eseguire l'inferenza al momento dell'offerta rispetto a modelli che altrimenti sarebbero troppo grandi o lenti da eseguire sul servizio di offerta dell'acquirente.

Logica di assegnazione del punteggio lato vendite

In questa fase, gli annunci con le offerte ricevute da tutti gli acquirenti partecipanti vengono assegnati. L'output di generateBid() viene trasmesso al servizio aste del venditore per eseguire scoreAd() e scoreAd() prende in considerazione un solo annuncio alla volta. In base al punteggio, il venditore sceglie un annuncio vincente da restituire al dispositivo per il rendering.

La logica di assegnazione del punteggio è la stessa utilizzata per il flusso di remarketing Protected Audience ed è in grado di selezionare un vincitore tra i candidati per il remarketing e l'installazione di app.La funzione viene chiamata una volta per ogni annuncio candidato inviato nell'asta protetta. Per maggiori dettagli, consulta la spiegazione di Offerte e asta.

Runtime del codice di selezione degli annunci

Nella proposta, il codice di selezione degli annunci per l'installazione di app viene specificato nello stesso modo del flusso di remarketing Protected Audience. Per maggiori dettagli, consulta la sezione Configurazione di offerte e aste. Il codice di offerta sarà disponibile nella stessa posizione di Cloud Storage di quello utilizzato per il remarketing.

Rapporti

Questa proposta utilizza le stesse API di reporting della proposta di reporting Protected Audience (ad esempio reportImpression(), che attiva la piattaforma per inviare report di venditori e acquirenti).

Un caso d'uso comune per i report sul lato acquisto è l'ottenimento dei dati di addestramento per i modelli utilizzati durante la selezione degli annunci. Oltre alle API esistenti, la piattaforma fornirà un meccanismo specifico per l'uscita dei dati a livello di evento dalla piattaforma ai server di tecnologia pubblicitaria. Questi payload di uscita possono includere determinati dati dell'utente.

A lungo termine, stiamo studiando soluzioni che preservino la privacy per affrontare l'addestramento dei modelli con i dati utilizzati nelle aste protette senza inviare dati degli utenti a livello di evento al di fuori dei servizi eseguiti su TEE. Forniremo ulteriori dettagli in un aggiornamento successivo.

A breve, forniremo un modo temporaneo per eseguire l'uscita dei dati con rumore da generateBid(). Di seguito è riportata la nostra proposta iniziale, che verrà modificata (incluse possibili modifiche non compatibili con le versioni precedenti) in base al feedback del settore.

Tecnicamente, il funzionamento è il seguente:

1. Le tecnologie pubblicitarie definiscono uno schema per i dati che vogliono trasmettere.
2. In generateBid(), crea il payload di uscita scelto.
3. La piattaforma convalida il payload in uscita in base allo schema e applica limiti di dimensione.
4. La piattaforma aggiunge rumore al payload di uscita.
5. Il payload di uscita è incluso nel report sulla vittoria in formato wire, ricevuto sui server della tecnologia pubblicitaria, decodificato e utilizzato per l'addestramento del modello.

Definizione dello schema dei payload in uscita

Affinché la piattaforma applichi i requisiti di privacy in evoluzione, i payload di uscita devono essere strutturati in modo che la piattaforma possa comprenderli. Le tecnologie pubblicitarie definiranno la struttura dei payload di uscita fornendo un file JSON dello schema. Questo schema verrà elaborato dalla piattaforma e rimarrà riservato ai servizi di offerte e aste utilizzando gli stessi meccanismi di altre risorse di tecnologia pubblicitaria come UDF e modelli.

Forniremo un file CDDL che definisce la struttura del file JSON. Il file CDDL includerà un insieme di tipi di caratteristiche supportati (ad esempio, caratteristiche che sono booleane, numeri interi, bucket e così via). Verranno versionati sia il file CDDL che lo schema fornito.

Ad esempio, un payload di uscita costituito da una singola caratteristica booleana seguita da una caratteristica bucket di dimensione due avrebbe un aspetto simile a questo:

egressPayload = {
  features : [
    {
      type: "boolean_feature",
      value: false
    },
    {
      type: "bucket_feature",
      size: 2,
      value: [
        {
          value: false
        },
        {
          value: true
        }
      ]
    }
  ]
}

I dettagli sul set di tipi di funzionalità supportati sono disponibili su GitHub.

Creare payload in uscita in generateBid()

Tutti i Protected App Signals per un determinato acquirente sono disponibili per la relativa UDF generateBid(). Una volta che queste funzionalità sono state implementate, le tecnologie pubblicitarie creano il payload in formato JSON. Questo payload di uscita verrà incluso nel report sulla vittoria dell'acquirente per la trasmissione ai server di tecnologia pubblicitaria.

Un'alternativa a questo design è che il calcolo del vettore di uscita avvenga in reportWin() anziché in generateBid(). Esistono compromessi per ciascun approccio e finalizzeremo questa decisione in risposta al feedback del settore.

Convalida il payload in uscita

La piattaforma convaliderà qualsiasi payload di uscita creato dalla tecnologia pubblicitaria. La convalida verifica che i valori delle funzionalità siano validi per i relativi tipi, che i vincoli di dimensione siano rispettati e che i malintenzionati non stiano tentando di eludere i controlli della privacy inserendo informazioni aggiuntive nei payload di uscita.

Se un payload di uscita non è valido, verrà eliminato automaticamente dagli input inviati al report sulle vittorie. Questo perché non vogliamo fornire informazioni di debug a malintenzionati che tentano di eludere la convalida.

Forniremo un'API JavaScript per consentire alle tecnologie pubblicitarie di verificare che il payload di uscita creato in generateBid() superi la convalida della piattaforma:

validate(payload, schema)

Questa API JavaScript serve esclusivamente ai chiamanti per determinare se un determinato payload supererà la convalida della piattaforma. La convalida effettiva deve essere eseguita nella piattaforma per proteggersi dalle UDF generateBid() dannose.

Aggiungi rumore al payload in uscita

La piattaforma eseguirà il payload di uscita del rumore prima di includerlo nel report sulla vittoria. La soglia di rumore iniziale sarà dell'1% e questo valore potrebbe evolvere nel tempo. La piattaforma non fornirà alcuna indicazione in merito alla presenza di rumore in un determinato payload di uscita.

Il metodo di aggiunta di rumore è:

1. La piattaforma carica la definizione dello schema per il payload in uscita.
2. Verrà scelto l'1% dei payload in uscita per l'aggiunta di rumore.
3. Se non viene scelto un payload di uscita, viene conservato l'intero valore originale.
4. Se viene scelto un payload di uscita, il valore di ogni funzionalità verrà sostituito con un valore valido casuale per quel tipo di funzionalità (ad esempio, 0 o 1 per una funzionalità booleana).

Trasmissione, ricezione e decodifica del payload di uscita per l'addestramento del modello

Il payload in uscita con rumore convalidato verrà incluso negli argomenti di reportWin() e trasmesso ai server di tecnologia pubblicitaria dell'acquirente al di fuori del confine della privacy per l'addestramento del modello. Il payload in uscita sarà nel formato wire.

I dettagli sul formato wire per tutti i tipi di funzionalità e per il payload di uscita sono disponibili su GitHub.

Determinare le dimensioni del payload in uscita

Le dimensioni del payload di uscita in bit bilanciano l'utilità e la riduzione dei dati. Collaboreremo con il settore per determinare le dimensioni appropriate tramite la sperimentazione. Durante l'esecuzione di questi esperimenti, eseguiremo temporaneamente l'uscita dei dati senza limitazioni di dimensioni dei bit. Questi dati di uscita aggiuntivi senza limitazioni delle dimensioni dei bit verranno rimossi al termine degli esperimenti.

Il metodo per determinare le dimensioni è:

1. Inizialmente, supporteremo due payload in uscita in generateBid():
   1. egressPayload: il payload di uscita con limiti di dimensioni che abbiamo descritto finora in questo documento. Inizialmente, le dimensioni di questo payload di uscita saranno pari a 0 bit (il che significa che verrà sempre rimosso durante la convalida).
   2. temporaryUnlimitedEgressPayload: un payload di uscita temporaneo senza limiti di dimensioni per gli esperimenti sulle dimensioni. La formattazione, la creazione e l'elaborazione di questo payload di uscita utilizzano gli stessi meccanismi di egressPayload.
2. Ciascuno di questi payload di uscita avrà il proprio file JSON dello schema: egress_payload_schema.json e temporary_egress_payload_schema.json.
3. Forniamo un protocollo di esperimento e un insieme di metriche per determinare l'utilità del modello a varie dimensioni del payload di uscita (ad esempio, 5, 10, ... bit).
4. In base ai risultati dell'esperimento, determiniamo le dimensioni del payload di uscita con i compromessi corretti in termini di utilità e privacy.
5. Abbiamo impostato le dimensioni di egressPayload da 0 bit alle nuove dimensioni.
6. Dopo un periodo di migrazione prestabilito, rimuoviamo temporaryUnlimitedEgressPayload, lasciando solo egressPayload con le nuove dimensioni.

Stiamo esaminando ulteriori misure di salvaguardia tecniche per gestire questa modifica (ad esempio, la crittografia di egressPayload quando aumentiamo le sue dimensioni da 0 bit). Questi dettagli, insieme alle tempistiche dell'esperimento e alla rimozione di temporaryUnlimitedEgressPayload, verranno inclusi in un aggiornamento successivo.

Successivamente, spiegheremo un possibile protocollo sperimentale per finalizzare le dimensioni di egressPayload. Il nostro obiettivo è collaborare con il settore per trovare una dimensione che bilanci utilità e minimizzazione dei dati. L'artefatto prodotto da questi esperimenti è un grafico in cui l'asse x rappresenta la dimensione del payload di addestramento in bit e l'asse y la percentuale di entrate generate da un modello di quella dimensione rispetto a una baseline senza limiti di dimensione.

Supponiamo di addestrare un modello pInstall e che le nostre fonti di dati di addestramento siano i nostri log e i contenuti delle temporaryUnlimitedegressPayload che riceviamo quando vinciamo le aste. Il protocollo per le tecnologie pubblicitarie prevede innanzitutto esperimenti offline:

1. Determinare l'architettura dei modelli che utilizzeranno con Protected App Signals. Ad esempio, dovranno stabilire se utilizzare o meno la fattorizzazione del modello.
2. Definisci una metrica per misurare la qualità del modello. Le metriche suggerite sono la perdita AUC e la perdita logaritmica.
3. Definisci l'insieme di funzionalità che utilizzeranno durante l'addestramento del modello.
4. Utilizzando l'architettura del modello, la metrica di qualità e il set di funzionalità di addestramento, esegui studi di ablazione per determinare l'utilità contribuita per bit per ogni modello che vuoi utilizzare in PAS. Il protocollo suggerito per lo studio di ablazione è:
   1. Addestra il modello con tutte le funzionalità e misura l'utilità. Questo è il valore di riferimento per il confronto.
   2. Per ogni funzionalità utilizzata per produrre la baseline, addestra il modello con tutte le funzionalità tranne quella.
   3. Misura l'utilità risultante. Dividi la differenza per le dimensioni della funzionalità in bit; questa è l'utilità prevista per bit per quella funzionalità.
5. Determina le dimensioni dei payload di addestramento di interesse per la sperimentazione. Ti consigliamo [5, 10, 15, ..., size_of_all_training_features_for_baseline] bit. Ciascuna di queste rappresenta una possibile dimensione per egressPayload che verrà valutata dall'esperimento.
6. Per ogni dimensione possibile, seleziona un insieme di funzionalità minore o uguale a quella dimensione che massimizzino l'utilità per bit, utilizzando i risultati dello studio di ablazione.
7. Addestra un modello per ogni dimensione possibile e valuta la sua utilità in percentuale rispetto all'utilità del modello di base addestrato su tutte le funzionalità.
8. Traccia i risultati su un grafico in cui l'asse X è la dimensione del payload di addestramento in bit e l'asse Y è la percentuale di entrate generate da questo modello rispetto alla baseline.

Successivamente, le tecnologie pubblicitarie possono ripetere i passaggi 5-8 negli esperimenti sul traffico reale, utilizzando i dati delle funzionalità inviati tramite temporaryUnlimitedEgressPayload. Le società ad tech possono scegliere di condividere i risultati dei loro esperimenti sul traffico offline e live con Privacy Sandbox per informare la decisione sulla dimensione di egressPayload.

La cronologia di questi esperimenti, nonché la cronologia per l'impostazione delle dimensioni di egressPayload sul valore risultante, non rientra nell'ambito di questo documento e verrà inclusa in un aggiornamento successivo.

Misure di protezione dei dati

Applicheremo una serie di protezioni ai dati in uscita, tra cui:

1. Verranno aggiunti disturbi sia a egressPayload che a temporaryUnlimitedEgressPayload.
2. Per la minimizzazione e la protezione dei dati, temporaryUnlimitedEgressPayload sarà disponibile solo per la durata degli esperimenti sulle dimensioni, in cui determineremo le dimensioni corrette per egressPayload.

Autorizzazioni

Controllo utente

• La proposta intende dare agli utenti visibilità all'elenco delle app installate che hanno memorizzato almeno un indicatore protetto dell'app o un segmento di pubblico personalizzato.
• Gli utenti possono bloccare e rimuovere le app da questo elenco. Il blocco e la rimozione comportano quanto segue:
  • Cancella tutti i Protected App Signals e i segmenti di pubblico personalizzati associati all'app.
  • Impedisce alle app di archiviare nuovi Protected App Signals e segmenti di pubblico personalizzati
• Gli utenti hanno la possibilità di reimpostare completamente le API Protected App Signals e Protected Audience. Quando ciò accade, tutti i segnali protetti delle app e i segmenti di pubblico personalizzati esistenti sul dispositivo vengono cancellati.
• Gli utenti hanno la possibilità di disattivare completamente Privacy Sandbox su Android, incluse l'API Protected App Signals e l'API Protected Audience. In questo caso, le API Protected Audience e Protected App Signals restituiscono un messaggio di eccezione standard: SECURITY_EXCEPTION.

Autorizzazioni e controllo delle app

La proposta intende fornire alle app il controllo dei propri Protected App Signals:

• Un'app può gestire le proprie associazioni con Protected App Signals.
• Un'app può concedere alle piattaforme di tecnologia pubblicitaria di terze parti le autorizzazioni per gestire gli indicatori delle app protette per suo conto.

Controllo della piattaforma ad tech

Questa proposta delinea i modi in cui le tecnologie pubblicitarie possono controllare i propri Protected App Signals:

• Tutte le tecnologie pubblicitarie devono registrarsi a Privacy Sandbox e fornire un dominio "sito" o "origine" che corrisponda a tutti gli URL per Protected App Signals.
• Le tecnologie pubblicitarie possono collaborare con app o SDK per fornire token di verifica che vengono utilizzati per verificare la creazione di indicatori protetti delle app. Quando questa procedura viene delegata a un partner, la creazione di indicatori protetti delle app può essere configurata in modo da richiedere la conferma da parte della tecnologia pubblicitaria.