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

Questa proposta è soggetta alla procedura di registrazione a Privacy Sandbox e le attestazioni. Per ulteriori informazioni relative alle attestazioni, fai riferimento al link dell'attestazione fornito. Gli aggiornamenti futuri a questa proposta descrivere i requisiti per ottenere l'accesso al sistema.

Gli annunci per l'installazione di app mobili, 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 gli annunci vengono generalmente mostrati agli utenti in base ai loro interessi e dati demografici. vengono spesso visualizzati in altre app mobile come giochi, social media e notizie app. Quando un utente fa clic su un annuncio per l'installazione di app, viene indirizzato direttamente alla store per scaricare l'app.

Ad esempio, un inserzionista che sta cercando di generare nuove installazioni per un nuovo dispositivo mobile app per la consegna di cibo negli Stati Uniti potrebbe indirizzare i propri annunci agli utenti la cui la sede si trova negli Stati Uniti e in passato si sono occupati della consegna di cibo a domicilio app.

Questa opzione viene implementata in genere includendo le informazioni contestuali, proprietarie e indicatori di terze parti tra le tecnologie pubblicitarie per creare profili utente in base agli ID pubblicità. I modelli di machine learning ad tech utilizzano queste informazioni come input per scegliere gli annunci pertinenti per l'utente e che hanno maggiori probabilità di generare e conversione in blocco.

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

  1. API Protected App Signals: si concentra sullo spazio di archiviazione e Creazione di funzionalità progettate ad tech che rappresentano il potenziale di un utente interessi. I tecnici pubblicitari memorizzano indicatori di eventi specifici per app, come le app installazioni, prime aperture, azioni degli utenti (livelli in-game, obiettivi), attività di acquisto o tempo trascorso nell'app. Gli indicatori vengono scritti e memorizzati su dispositivo per proteggersi dalle fughe di dati e sono messi a disposizione soltanto dei logica ad tech che ha memorizzato l'indicatore specificato durante un'asta protetta in esecuzione in un ambiente sicuro.
  2. API Ad Selection: fornisce un'API per configurare ed eseguire un Asta protetta in esecuzione in un Trusted Execution Environment (TEE) in cui i tecnici pubblicitari recuperano i candidati per gli annunci, eseguono l'inferenza, calcolano le offerte e punteggio per scegliere un "vincente" utilizzando sia gli indicatori dell'app Protected informazioni contestuali fornite dall'editore in tempo reale.
di Gemini Advanced.
Diagramma che mostra il flusso di installazione dell'app con indicatori protetti
Diagramma di flusso che mostra gli indicatori delle app protette e il flusso di lavoro per la selezione degli annunci in Privacy Sandbox su Android.

Ecco una panoramica generale di come funzionano gli indicatori di app protette annunci per l'installazione di app pertinenti. Le seguenti sezioni di questo documento forniscono ulteriori su ciascuno di questi passaggi.

  • Selezione degli indicatori: man mano che gli utenti utilizzano le app mobile, le tecnologie pubblicitarie selezionano gli indicatori. archiviando gli eventi delle app definiti per la tecnologia pubblicitaria per la pubblicazione di annunci pertinenti utilizzando API Protected App Signals. Questi eventi vengono memorizzati di archiviazione, simili ai segmenti di pubblico personalizzati, e vengono criptati prima di essere inviato dal dispositivo in modo che solo i servizi di offerte e aste in esecuzione all'interno degli ambienti di esecuzione affidabili, con le il controllo della privacy può decriptarli per gli annunci con asta e punteggio.
  • Codifica del segnale: gli indicatori vengono preparati secondo una cadenza programmata in base a una logica personalizzata delle tecnologie pubblicitarie. Un job in background Android esegue questa logica per Eseguire la codifica on-device per generare un payload di indicatori di app protetti che possono essere successivamente utilizzati in tempo reale per la selezione degli annunci durante una Asta. Il payload viene memorizzato in modo sicuro sul dispositivo fino a quando non viene inviato per un in un'asta.
  • Selezione degli annunci: per selezionare annunci pertinenti per l'utente, gli SDK del venditore. invia un payload criptato di indicatori dell'app protetta e configura un in un'asta protetta. Nell'asta, la logica personalizzata dell'acquirente prepara lo strumento Indicatori dell'app insieme ai dati contestuali forniti dal publisher (dati in genere condivise in una richiesta di annuncio Open RTB) funzionalità destinate alla selezione degli annunci (recupero degli annunci, inferenza e generazione di testi). Come per Protected Audience, gli acquirenti inviano gli annunci al venditore per il punteggio finale in un'asta protetta.
    • Recupero degli annunci: gli acquirenti utilizzano indicatori di app protetti e dati contestuali forniti dal publisher alle funzionalità per tecnici pertinenti agli interessi dell'utente. Queste funzionalità vengono usate per abbinare gli annunci che soddisfano i criteri di targeting. Gli annunci che non rientrano nel budget vengono omessi. Gli annunci top-k vengono quindi selezionati per le offerte.
    • Offerte: la logica delle offerte personalizzate dati contestuali forniti dal publisher e indicatori dell'app protetti per progettare e progettare che vengono usate come input per i modelli di machine learning dell'acquirente inferenza e offerte per gli annunci candidati in un ambiente affidabile che tutela la privacy confini. L'acquirente restituirà al venditore l'annuncio che ha scelto.
    • Punteggio del venditore: si riferisce al venditore annunci con punteggi logici per punteggio personalizzato inviato dagli Acquirenti partecipanti e sceglie un annuncio vincente da inviare all'app per il rendering.
  • Report: i partecipanti alle aste ricevono i report sulle vincite applicabili e report sulle perdite. Stiamo esplorando meccanismi incentrati sulla tutela della privacy per includere dati per l'addestramento del modello nel report Win.

Cronologia

Anteprima per gli sviluppatori Beta
Funzionalità T4'23 T1'24 T2'24 T3'24
API di selezione di indicatori API di archiviazione on-device Logica della quota di spazio di archiviazione sul dispositivo

Aggiornamenti giornalieri della logica personalizzata sul dispositivo 		N/D Disponibile per l'1% di dispositivi T+
Server di recupero degli annunci in un TEE MVP Disponibile su Google Cloud

Supporto per Top-K
produzione delle funzioni definite dall'utente 		Disponibile su AWS

Debug, metriche e monitoraggio con consenso
Servizio di inferenza in un TEE

Supporto per l'esecuzione di modelli di ML e il loro utilizzo per le offerte in un TEE 		In fase di sviluppo Disponibile su Google Cloud

Può eseguire il deployment prototipazione di modelli ML statici utilizzando Tensorflow e PyTorch 		Disponibile su AWS

Deployment di modelli in produzione per i modelli Tensorflow e PyTorch

Telemetria, debug con consenso e monitoraggio
Supporto per le offerte e le aste in un TEE

 Disponibile su Google Cloud Integrazione del recupero di annunci PAS-B&A e TEE (con crittografia gRPC e TEE<>TEE)

Supporto del recupero degli annunci tramite percorso contestuale (include il supporto B&A<>K/V su TEE) 		Disponibile su AWS

Report di debug

Debug, metriche e monitoraggio con consenso

Selezionare indicatori delle app protette

Un indicatore è una rappresentazione di varie interazioni degli utenti in un'app che sono ritenuti utili dalla tecnologia pubblicitaria per pubblicare annunci pertinenti. Un'app o l'SDK integrato può archiviare o eliminare gli indicatori delle app protetti definiti dai tecnici pubblicitari in base all'attività utente, ad esempio aperture di app, obiettivi, attività di acquisto o di tempo nell'app. Gli indicatori delle app protette vengono memorizzati in modo sicuro sul dispositivo e criptati prima di essere inviati dal dispositivo, in modo che solo le offerte e le aste in esecuzione all'interno di ambienti di esecuzione attendibili con una sicurezza adeguata e il controllo della privacy possono decriptarli per gli annunci con offerte e punteggi. Simile al API Custom Audience, gli indicatori memorizzati su un dispositivo non possono essere letti o ispezionati da app o SDK; non esiste un'API per la lettura dei valori degli indicatori e le API progettati per evitare la fuga di indicatori. La logica personalizzata ad tech accesso protetto ai propri indicatori selezionati per progettare le caratteristiche che fungono da 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. La L'API Protected App Signals consente l'archiviazione dei segnali sotto forma di singolo scalare o come serie temporale. Gli indicatori delle serie temporali consentono di memorizzare elementi come durata della sessione utente. Gli indicatori delle serie temporali offrono un'utilità per applicare usando una regola di eliminazione "first in, first out". Il tipo di dati di uno scalare o ognuno degli elementi di un segnale di serie temporali, è un array di byte. Ciascuna viene arricchito con il nome del pacchetto dell'applicazione in cui è stato archiviato e il timestamp di creazione della chiamata all'API Store Signals. Questo extra sono disponibili nel JavaScript di codifica del segnale. 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 associato con adtech1.com:

  • Un segnale scalare con la chiave di valore base64 "A1c" e il valore "c12Z". L'indicatore Il negozio è stato attivato da com.google.android.game_app il 1° giugno 2023.
  • Un elenco di indicatori con la chiave "dDE" creati da due diversi diverse applicazioni.

Ai tecnici pubblicitari viene assegnata una determinata quantità di spazio per archiviare gli indicatori sul dispositivo. Gli indicatori avranno un TTL massimo, che deve essere determinato.

Gli indicatori dell'app protetta vengono rimossi dallo spazio di archiviazione se l'applicazione di generazione viene disinstallata, non può utilizzare l'API Protected App Signals o se i dati dell'app autorizzato 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 e prepararli ulteriore feature engineering in tempo reale durante un'asta protetta in corso in un ambiente di esecuzione affidabile (TEE).

Aggiungere, aggiornare o rimuovere indicatori

I tecnici pubblicitari possono aggiungere, aggiornare o rimuovere indicatori con l'API fetchSignalUpdates(). Questa API supporta una delega simile al segmento di pubblico personalizzato Protected Audience delega.

Per aggiungere un indicatore, i tecnici pubblicitari dell'acquirente che non hanno una presenza di SDK nelle app devono collaborare con tecnici pubblicitari che hanno una presenza sul dispositivo, come i dispositivi mobili partner di misurazione (MMP) e Supply-Side Platform (SSP). L'app Protected L'API Signals ha lo scopo di supportare queste tecnologie pubblicitarie fornendo soluzioni flessibili per Gestione protetta degli indicatori di app attivando la chiamata sul dispositivo da parte dei chiamanti Creazione di indicatori di app protetti per conto degli acquirenti. Questo processo è chiamato delega e sfrutta l'API fetchSignalUpdates(). fetchSignalUpdates() prende un URI e recupera un elenco di aggiornamenti di indicatori. Per spiegarci meglio, fetchSignalUpdates() emette una richiesta GET all'URI specificato per recuperare elenco di aggiornamenti da applicare allo spazio di archiviazione dei segnali locali. L'endpoint URL, di proprietà di l'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 sono presenti è già memorizzato. Questa opzione può essere utile, ad esempio, per impostare l'ID esperimento per l'utente specificato ed evita di sostituirlo se lo era già 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 nel tempo Google Cloud. Se le dimensioni vengono superate, gli elementi precedenti vengono rimossi. Se la chiave contiene un valore scalare che viene automaticamente trasformato 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.

I comandi elencati in precedenza hanno lo scopo di fornire inserimento, sovrascrittura ed eliminazione la semantica per i segnali scalari e la sovrascrittura con inserimento, aggiunta e serie completa indicatori delle serie temporali. Eliminare e sovrascrivere la semantica su elementi specifici di una il segnale delle serie temporali deve essere gestito durante il processo di codifica e compattazione; ad esempio, durante la codifica, i valori di una serie temporale che sostituite o corrette da altre più recenti, eliminandole durante di compattazione.

Gli indicatori memorizzati vengono associati automaticamente all'applicazione che esegue di recupero dell'account e l'utente che ha inviato la richiesta (il "sito" o l'"origine" di un ad tech registrato), oltre all'ora di creazione della richiesta. Tutti gli indicatori sono soggetta all'archiviazione per conto di una tecnologia pubblicitaria registrata a Privacy Sandbox, l'URI "site"/"origin" deve corrispondere ai dati di una tecnologia pubblicitaria registrata. Se che richiede non è registrata, la richiesta è stata rifiutata.

Quota di spazio di archiviazione ed eliminazione

Ogni tecnologia pubblicitaria ha una quantità limitata di spazio sul dispositivo dell'utente per archiviare i segnali. Questa quota viene definita per tecnologia pubblicitaria, quindi gli indicatori selezionati da diverse app condividono quota. Se la quota viene superata, il sistema libera spazio rimuovendolo prima i valori degli indicatori in base all'ordine di ricezione. Per impedire che l'espulsione troppo frequente, il sistema implementa una logica di batch per consentire una quantità limitata di scoperto di quota e per liberare spazio aggiuntivo una volta viene attivata la logica di eliminazione.

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. È in esecuzione un job in background di un sistema Android ogni ora per eseguire una logica di codifica personalizzata per acquirente che viene scaricata dispositivo. La logica di codifica personalizzata per acquirente codifica gli indicatori per app. quindi comprime gli indicatori per app in un payload conforme per acquirente. Il payload viene quindi criptato spazio di archiviazione protetto sul dispositivo e poi trasmesse ai servizi di offerte e aste.

I tecnici pubblicitari definiscono il livello di elaborazione degli indicatori logica. Ad esempio, potresti predisporre la soluzione per l'eliminazione in anticipo e aggregano quelli simili o rafforzando quelli provenienti da in nuovi indicatori che usano meno spazio.

Se un acquirente non ha registrato un codificatore di indicatori, questi non saranno preparati. e nessuno degli indicatori selezionati on-device viene inviato alle offerte e alle aste i servizi di machine learning.

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

Flusso di lavoro per la selezione degli annunci

Con questa proposta, il codice personalizzato ad tech può accedere soltanto all'app protetta Indicatori all'interno di un'asta protetta (API di selezione degli annunci) in esecuzione in un TEE. A a supporto delle esigenze del caso d'uso relativo all'installazione di app, gli annunci candidati sono recuperati durante l'asta protetta in tempo reale. Ciò contrasta con 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 di Protected Audience proposta con aggiornamenti per supportare il caso d'uso di installazione di app. Per supportare requisiti di computing per il feature engineering e la selezione degli annunci in tempo reale, aste per annunci per l'installazione di app devono essere pubblicate in offerte e aste in esecuzione nei TEE. Accedere agli indicatori dell'app Protected durante una sessione L'asta non è supportata con le aste on-device.

Illustrazione del flusso di lavoro di selezione degli annunci.
Il flusso di lavoro per la selezione degli annunci in Privacy Sandbox su Android.

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

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

Avvia flusso di lavoro di selezione degli annunci

Quando un'applicazione è pronta per mostrare un annuncio, l'SDK ad tech (in genere le SSP) avvia il flusso di lavoro di selezione degli annunci inviando tutti i dati contestuali pertinenti i payload criptati per publisher e per acquirente da includere nella richiesta da inviare all'asta protetta utilizzando la chiamata getAdSelectionData. Questo è la stessa API utilizzata per il flusso di lavoro di remarketing e descritta nella sezione Offerte e proposta di integrazione delle aste per Android.

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

Il venditore imposta quanto segue:

Esecuzione della logica di selezione degli annunci lato acquisti

A livello generale, la logica personalizzata dell'acquirente utilizza i dati contestuali forniti publisher e indicatori dell'app protetta 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 rispetto a quelli più pertinenti (i primi k), per i quali vengono calcolate le offerte prima che gli annunci vengano restituiti al venditore per la selezione finale.

Illustrazione della logica di esecuzione della selezione degli annunci lato acquisti.
Logica di esecuzione della selezione degli annunci lato acquisti in Privacy Sandbox su Android.

Prima di fare offerte, gli acquirenti iniziano con un ampio pool di annunci. È troppo lento calcolare un'offerta per ogni annuncio, quindi gli acquirenti devono prima selezionare i primi k candidati dalla grande piscina. Successivamente, gli acquirenti devono calcolare le offerte per ciascuna di queste top-k candidati. Successivamente, questi annunci e offerte vengono restituiti al venditore per la selezione.

    .
  1. Il servizio BuyerFrontEnd riceve una richiesta di annuncio.
  2. Il servizio BuyerFrontEnd invia una richiesta al servizio di offerte dell'acquirente. Il servizio di asta dell'acquirente esegue una funzione definita dall'utente denominata prepareDataForAdRetrieval(), che crea una richiesta per recuperare le prime k candidati dal recupero annunci assistenza. Il servizio di offerte invia questa richiesta al recupero configurato endpoint server.
  3. Il servizio di recupero degli annunci esegue la funzione definita dall'utente getCandidateAds(), che filtra fino all'insieme di annunci candidati top-k, che vengono inviati al prompt di offerta.
  4. Il servizio di offerte dell'acquirente esegue la funzione definita dall'utente generateBid(), che seleziona miglior candidato, calcola la sua offerta e poi la restituisce a BuyerFrontEnd completamente gestito di Google Cloud.
  5. Il servizio BuyerFrontEnd restituisce gli annunci e le offerte al venditore.

Ci sono diversi dettagli importanti su questo flusso, soprattutto in relazione al il modo in cui i pezzi parlano tra loro e in che modo la piattaforma offre funzionalità quali possibilità di fare previsioni con il machine learning per recuperare gli annunci top-k e calcolare le loro offerte.

Prima di passare a questo aspetto più nel dettaglio, ci sono alcuni importanti sull'architettura delle TEE riportate nel diagramma in alto.

Il servizio di offerta dell'acquirente contiene internamente un servizio di inferenza. Tecnologie pubblicitarie possono caricare i modelli di machine learning nel servizio di offerte dell'acquirente. Lo faremo Fornire API JavaScript per consentire alle tecnologie pubblicitarie di fare previsioni o generare incorporamenti da questi modelli dalle funzioni definite dall'utente eseguite nel servizio di asta dell'acquirente. A differenza del servizio di recupero degli annunci, il servizio di offerte dell'acquirente non dispone di una chiave-valore per archiviare tutti i metadati degli annunci.

Il servizio di recupero annunci include internamente un servizio chiave-valore. Gli ad tech possono materializzare le coppie chiave-valore in questo servizio dai rispettivi server, all'esterno il confine della privacy. Forniremo un'API JavaScript per consentire ai tecnici pubblicitari di leggere questo servizio di coppie chiave-valore dall'interno delle funzioni definite dall'utente eseguite nel servizio di recupero annunci. A differenza del servizio di offerta dell'acquirente, il servizio di recupero annunci non contiene un servizio di inferenza.

Una domanda centrale che questo progetto affronta è come rendere il tempo di recupero previsioni al momento dell'offerta. Entrambe le opzioni possono consistere in una soluzione chiamata fattorizzazione del modello.

fattorizzazione del modello

La fattorizzazione del modello è una tecnica che consente di interrompere una singola del modello in più parti per poi combinarle in una previsione. Nella caso d'uso di App Install, i modelli utilizzano spesso tre tipi di dati: dati, dati contestuali e dati pubblicitari.

Nel caso non fattoriale, un singolo modello viene addestrato su tutti e tre i tipi di e i dati di Google Cloud. Nel caso scomposto, il modello viene suddiviso in più parti. Solo l'elemento che contiene i dati utente è sensibile. Ciò significa che solo il modello la sezione utente deve essere eseguita all'interno del confine di attendibilità, in base alle offerte dell'acquirente, di inferenza del servizio.

Ciò rende possibile la progettazione seguente:

  1. Suddividi il modello in un elemento privato (i dati utente) e uno o più parti non private (i dati contestuali e pubblicitari).
  2. Facoltativamente, passa alcuni o tutti i pezzi non privati come argomenti a una funzione definita dall'utente che devono fare previsioni. Ad esempio, gli incorporamenti contestuali passato alle funzioni definite dall'utente in per_buyer_signals.
  3. Facoltativamente, i tecnici pubblicitari possono creare modelli per elementi non privati, quindi materializzare gli incorporamenti di tali modelli nel di archiviazione di coppie chiave-valore. Le funzioni definite dall'utente nel servizio di recupero annunci possono recuperare questi incorporamenti in fase di runtime.
  4. Per fare una previsione durante una funzione definita dall'utente, combina gli incorporamenti privati di inferenza con incorporamenti non privati da argomenti di funzioni delle funzioni definite dall'utente o con un'operazione come un prodotto scalare. Questa è la versione finale la previsione.

Detto questo, possiamo esaminare ciascuna funzione definita dall'utente in modo più dettagliato. Spiegheremo cosa cosa fanno, come si integrano e come possono fare le previsioni necessarie scelgono gli annunci top-k e calcolano le relative offerte.

La funzione definita dall'utente prepareDataForAdRetrieval()

prepareDataForAdRetrieval() in esecuzione nel servizio di offerta dell'acquirente è responsabile della creazione del payload che verrà inviato all'annuncio per recuperare i primi k annunci candidati.

prepareDataForAdRetrieval() richiede le seguenti informazioni:

  • Il payload per acquirente ricevuto da getAdSelectionData. Questo payload contiene gli indicatori di app protette.
  • Gli indicatori di contesto auction_signals (per informazioni sull'asta) e buyer_signals (per acquirenti indicatori).

prepareDataForAdRetrieval() esegue due operazioni:

  • Caratterizzazione: se è necessaria l'inferenza in fase di recupero, trasforma segnali in arrivo nelle caratteristiche da utilizzare durante le chiamate al servizio di inferenza per ottenere incorporamenti privati per il recupero.
  • Calcola gli incorporamenti privati per il recupero: se le previsioni di recupero vengono utilizzati, effettua la chiamata contro il servizio di inferenza utilizzando e ottiene un incorporamento privato per le previsioni al momento del recupero.

Resi di prepareDataForAdRetrieval():

  • Indicatori delle app protette: payload di indicatori curati dalla tecnologia degli annunci.
  • Indicatori specifici per asta: indicatori lato vendite specifici della piattaforma e informazioni contestuali come auction_signals e per_buyer_signals (inclusi gli incorporamenti contestuali) da SelectAdRequest. È simile a Protected Audience.
  • Indicatori aggiuntivi: informazioni aggiuntive come gli incorporamenti privati recuperati. dal servizio di inferenza.

Questa richiesta viene inviata al servizio di recupero annunci, che esegue la corrispondenza dei candidati quindi esegue la funzione definita dall'utente getCandidateAds().

La funzione definita dall'utente getCandidateAds()

getCandidateAds() viene eseguito nel servizio di recupero degli annunci. Riceve la richiesta creato da prepareDataForAdRetrieval() nel servizio di offerta dell'acquirente. La il servizio esegue getCandidateAds() che recupera i candidati top-k per le offerte convertendo la richiesta in una serie di query ed eseguire una logica di business personalizzata e altre logiche di recupero personalizzate.

getCandidateAds() richiede le seguenti informazioni:

  • Indicatori delle app protette: payload di indicatori curati dalla tecnologia degli annunci.
  • Indicatori specifici per asta: indicatori lato vendite specifici della piattaforma e informazioni contestuali come auction_signals e per_buyer_signals (inclusi gli incorporamenti contestuali) da SelectAdRequest. È simile a Protected Audience.
  • Indicatori aggiuntivi: informazioni aggiuntive come gli incorporamenti privati recuperati. dal servizio di inferenza.

getCandidateAds() effettua le seguenti operazioni:

  1. Recupera un insieme iniziale di candidati per l'annuncio: recuperato utilizzando i criteri di targeting come lingua, dati geografici, tipo di annuncio, dimensione dell'annuncio o budget, per filtrare i candidati.
  2. Recupero degli incorporamenti di recupero: se gli incorporamenti del servizio chiave-valore vengono necessarie per fare una previsione del tempo di recupero per la selezione top-k, devono essere recuperate dal servizio chiave-valore.
  3. Selezione dei candidati Top-k: calcola un punteggio leggero per i insieme di candidati di annunci sulla base dei metadati degli annunci recuperati dall'archivio coppie chiave-valore informazioni inviate dal servizio di offerta dell'acquirente e per scegliere top-k candidati in base a quel punteggio. Ad esempio, il punteggio potrebbe essere la possibilità installare un'app in base all'annuncio.
  4. Recupero dell'incorporamento dell'asta: se gli incorporamenti del servizio chiave-valore vengono necessari dal codice di offerta per fare previsioni sul momento dell'offerta, potrebbero essere recuperate dal servizio chiave-valore.

Tieni presente che il punteggio di un annuncio può essere l'output di un modello predittivo, che per un esempio di previsione della probabilità che un utente installi un'app. Questo tipo di punteggio comporta una sorta di fattorizzazione del modello: dato che getCandidateAds() viene eseguito nel servizio di recupero annunci e poiché quest'ultimo non ha un servizio di inferenza, le previsioni possono essere generate combinando:

  • Incorporamenti contestuali trasmessi utilizzando gli indicatori specifici per l'asta di testo.
  • Incorporamenti privati trasmessi utilizzando l'input degli indicatori aggiuntivi.
  • Qualsiasi tecnologia pubblicitaria con incorporamenti non privati è stata materializzata dai propri server nel servizio chiave-valore del servizio di recupero annunci.

Tieni presente che la funzione definita dall'utente generateBid() eseguita nel servizio di offerte dell'acquirente potrebbe applica anche un proprio tipo di fattorizzazione del modello per fare in modo che le offerte per le previsioni. Se per farlo sono necessari incorporamenti da un servizio chiave-valore, devono essere recuperati ora.

Resi di getCandidateAds():

  • Annunci candidati: annunci top-k da trasmettere a generateBid(). Ogni annuncio viene composta da:
    • URL di rendering: endpoint per il rendering della creatività dell'annuncio.
    • Metadati: metadati degli annunci lato acquisti, specifici per la tecnologia pubblicitaria. Ad esempio, questo possono includere informazioni sulla campagna pubblicitaria e sui criteri di targeting come località e lingua. I metadati possono includere facoltativi incorporamenti utilizzati quando è necessaria la fattorizzazione del modello per eseguire l'inferenza durante l'offerta.
  • Indicatori aggiuntivi: facoltativamente, il servizio di recupero degli annunci può includere l'uso di informazioni aggiuntive come incorporamenti aggiuntivi o indicatori di spam a generateBid().

Stiamo studiando altri metodi per fornire agli annunci un punteggio, ad esempio: rendendolo disponibile come parte della chiamata SelectAdRequest. Questi annunci possono essere recuperate utilizzando una richiesta di offerta RTB. Tieni presente che, in questi casi, gli annunci devono essere recuperate senza indicatori di app protette. Prevediamo che i tecnici pubblicitari valutare i compromessi prima di scegliere l'opzione migliore, incluso il payload di risposta dimensioni, latenza, costo e disponibilità degli indicatori.

La funzione definita dall'utente generateBid()

Dopo aver recuperato l'insieme di annunci candidati e gli incorporamenti durante recupero, puoi procedere con l'asta, che viene eseguita nelle offerte completamente gestito di Google Cloud. Questo servizio esegue il generateBid() fornito dall'acquirente funzione definita dall'utente per selezionare l'annuncio per cui fare un'offerta tra i primi k, quindi restituirlo con la relativa offerta.

generateBid() richiede le seguenti informazioni:

  • Annunci candidati: i primi k annunci restituiti dal recupero annunci di recupero. completamente gestito di Google Cloud.
  • Indicatori specifici per asta: indicatori lato vendite specifici della piattaforma e informazioni contestuali come auction_signals e per_buyer_signals (inclusi gli incorporamenti contestuali) da SelectAdRequest.
  • Indicatori aggiuntivi: informazioni aggiuntive da utilizzare al momento dell'offerta.

L'implementazione di generateBid() dell'acquirente fa tre cose:

  • Caratterizzazione: trasforma gli indicatori in funzionalità da utilizzare durante l'inferenza.
  • Inferenza: genera previsioni utilizzando modelli di machine learning per calcolare valori come la percentuale di clic prevista e i tassi di conversione.
  • Offerte: combinando i valori dedotti con altri input per calcolare il fare un'offerta per un annuncio candidato.

Resi di generateBid():

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

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

Le seguenti sezioni descrivono la funzionalità, l'inferenza e l'offerta in dettaglio.

Funzionalità

Gli indicatori delle aste possono essere preparati da generateBid() nelle funzionalità. Queste funzionalità possono essere utilizzate durante l'inferenza per prevedere elementi come i clickthrough e tassi di conversione. Stiamo inoltre esplorando meccanismi incentrati sulla tutela della privacy per ne trasmetti alcune nel report di successo per utilizzarle nell'addestramento del modello.

Inferenza

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

I clienti possono fornire una serie di modelli di machine learning insieme Implementazione di generateBid(). Forniremo anche un'API JavaScript all'interno 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 sull'inferenza latenza e costi, soprattutto perché gli acceleratori non sono ancora disponibili nei TEE. Alcuni clienti scopriranno che le loro esigenze vengono soddisfatte grazie ai singoli modelli in esecuzione dal servizio di offerta dell'acquirente. Alcuni clienti, ad esempio quelli con aziende di grandi dimensioni. Potresti voler prendere in considerazione opzioni come la fattorizzazione del modello per ridurre al minimo e latenza dell'inferenza al momento dell'offerta.

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

Implementare la fattorizzazione del modello

In precedenza abbiamo spiegato la fattorizzazione del modello. Al momento dell'offerta, lo specifico è il seguente:

  1. Suddividi il singolo modello in un elemento privato (i dati utente) e uno o più parti non private (i dati contestuali e pubblicitari).
  2. Passa a generateBid() pezzi non privati. Questi possono provenire da per_buyer_signals, oppure da incorporamenti calcolati esternamente, materializzare nell'archivio chiave-valore del servizio di recupero, recuperare al momento del recupero in tempo reale e ritorna come parte degli indicatori aggiuntivi. Ciò non include incorporamenti privati poiché non possono essere ricavati dall'esterno del confine.
  3. Tra generateBid():
    1. Effettua l'inferenza sui modelli per ottenere incorporamenti di utenti privati.
    2. Combina gli incorporamenti di utenti privati con incorporamenti contestuali da per_buyer_signals o annunci non privati e incorporamenti contestuali dal di recupero dei dati utilizzando un'operazione come un prodotto scalare. Questo è il previsione finale utilizzabile per calcolare le offerte.

Utilizzando questo approccio, è possibile eseguire l'inferenza al momento dell'offerta rispetto altrimenti troppo grandi o lenti da eseguire sulla base di offerta.

Logica di punteggio lato vendite

In questa fase gli annunci con offerte ricevute da tutti gli acquirenti partecipanti vengono con punteggi di valutazione. L'output di generateBid() viene trasmesso al servizio di aste del venditore per pubblicare scoreAd() e che scoreAd() prenda in considerazione un solo annuncio alla volta. Sede nel punteggio, il venditore sceglie un annuncio vincente da restituire al dispositivo per per il rendering delle immagini.

La logica di valutazione è la stessa utilizzata per il remarketing di Protected Audience flusso di lavoro e può selezionare un vincitore tra remarketing e installazioni di app La funzione viene chiamata una volta per ogni annuncio candidato inviato in un'asta protetta. Consulta la spiegazione su Offerte e aste per i dettagli.

Tempo di esecuzione del codice di selezione degli annunci

Nella proposta, il codice di selezione degli annunci per l'installazione di app è specificato nello stesso per il flusso di remarketing di Protected Audience. Per maggiori dettagli, consulta Offerte e configurazione delle aste. Il codice di offerta sarà disponibile nella stessa posizione di archiviazione sul cloud di quello utilizzato per il remarketing.

Rapporti

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

Un caso d'uso comune per la generazione di report sul lato acquisti è il recupero dei dati di addestramento per i modelli usati durante la selezione degli annunci. Oltre alle API esistenti, la piattaforma fornirà un meccanismo specifico per il traffico in uscita dei dati a livello di evento ai server ad tech. Questi payload in uscita possono includere e i dati di Google Cloud.

A lungo termine, stiamo studiando soluzioni incentrate sulla tutela della privacy per risolvere dell'addestramento del modello con dati utilizzati nelle aste protette senza inviare a livello di evento dati utente al di fuori di servizi in esecuzione su TEE. Forniremo ulteriori dettagli in un aggiornamento successivo.

Nel breve termine, forniremo un modo temporaneo per estrarre i dati dal rumore generateBid(). Di seguito è riportata la nostra proposta iniziale in merito, che verrà poi perfezionata. (incluse eventuali modifiche incompatibili con le versioni precedenti) in risposta alle esigenze del settore feedback.

Tecnicamente, il funzionamento è il seguente:

  1. I tecnici pubblicitari definiscono uno schema per i dati che vogliono trasmettere.
  2. In generateBid(), creano il payload in uscita desiderato.
  3. La piattaforma convalida il payload in uscita rispetto allo schema e applica limiti di dimensione.
  4. La piattaforma aggiunge rumore al payload in uscita.
  5. Il payload in uscita è incluso nel report Win, in formato di bonifico, ricevuto il ad tech, decodificati e usati per l'addestramento del modello.

definizione dello schema dei payload in uscita

Affinché la piattaforma applichi requisiti di privacy in continua evoluzione, i payload in uscita devono strutturata in modo da essere comprensibili per la piattaforma. I tecnici pubblicitari definiranno struttura dei payload in uscita fornendo un file JSON di schema. Quello schema verranno elaborati dalla piattaforma e rimarranno riservati dall'asta e i servizi di aste che usano gli stessi meccanismi delle altre risorse di tecnologia pubblicitaria. come funzioni definite dall'utente e modelli.

Ti forniremo un file CDDL che definisce la struttura del file JSON. La Il file CDDL includerà un insieme di tipi di elementi supportati (ad esempio, caratteristiche booleani, numeri interi, bucket e così via). Sia il file CDDL che verrà eseguito il controllo delle versioni dello schema fornito.

Ad esempio, un payload in uscita che consiste in una singola caratteristica booleana. seguita da una caratteristica del bucket di dimensione due avrebbe questo aspetto:

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

I dettagli dell'insieme di tipi di funzionalità supportati sono disponibili su GitHub.

Crea payload in uscita in generateBid()

Tutti gli indicatori delle app protette per un determinato acquirente sono disponibili per Funzionalità definita dall'utente generateBid(). Una volta implementate, le tecnologie pubblicitarie creano il loro payload JSON. Questo payload in uscita verrà incluso nel report sui premi dell'acquirente per la trasmissione ai server ad tech.

Un'alternativa a questa progettazione è che il calcolo del vettore in uscita venga eseguito in reportWin() anziché generateBid(). Ci sono dei compromessi per ogni finale e finalizziamo questa decisione in risposta ai feedback del settore.

Convalida il payload in uscita

La piattaforma convaliderà qualsiasi payload in uscita creato dalla tecnologia pubblicitaria. Convalida assicura che i valori delle caratteristiche siano validi per i loro tipi, che i vincoli di dimensione siano soddisfatti e che i malintenzionati non stiano cercando di superare i controlli sulla privacy di pacchettizzare informazioni aggiuntive nei loro payload in uscita.

Se un payload in uscita non è valido, verrà eliminato automaticamente dagli input inviati al report sulle vittorie. perché non vogliamo fornire il servizio di informazioni a qualsiasi malintenzionato che tenta di annullare la convalida.

Forniremo un'API JavaScript per gli ad tech per garantire il payload in uscita che La creazione in generateBid() supererà la convalida della piattaforma:

validate(payload, schema)

Questa API JavaScript consente ai chiamanti di determinare se un particolare payload supererà la convalida della piattaforma. La convalida effettiva deve essere eseguita nella piattaforma per bloccare le funzioni definite dall'utente di generateBid() dannose.

Rumore del payload in uscita

La piattaforma sottoporrà il rumore ai payload in uscita prima di includerli nel report Win. La soglia del rumore iniziale sarà dell'1% e questo valore potrebbe evolvere nel tempo. La non fornirà indicazioni se un determinato payload in uscita è stato disturbato.

Il metodo del rumore è:

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

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

Il payload in uscita convalidato con rumore sarà incluso negli argomenti per reportWin() e trasmessi ai server ad tech dell'acquirente al di fuori della privacy limite per l'addestramento del modello. Il payload in uscita sarà nel suo formato di cavo.

Dettagli sul formato del cavo per tutti i tipi di caratteristiche e per il payload in uscita sono disponibili su GitHub.

Determina la dimensione del payload in uscita

Le dimensioni del payload in uscita in bit bilanciano l'utilità e la minimizzazione dei dati. Collaboreremo con il settore per determinare le dimensioni appropriate tramite degli esperimenti. Durante l'esecuzione di questi esperimenti, per i dati in uscita senza limiti di dimensione in bit. Questi ulteriori dati in uscita Il limite di dimensioni verrà rimosso al termine degli esperimenti.

Il metodo per determinare la dimensione è:

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

Stiamo esaminando ulteriori misure tecniche per gestire questa modifica (ad esempio, crittografare egressPayload quando ne aumentiamo le dimensioni da 0 bit). Questi dettagli, insieme alle tempistiche dell'esperimento e alla rimozione dei temporaryUnlimitedEgressPayload -- verrà inclusa in un aggiornamento successivo.

Ora spiegheremo un possibile protocollo dell'esperimento per finalizzare la dimensione egressPayload. Il nostro obiettivo è collaborare con il settore per trovare una dimensione in grado di trovare un equilibrio l'utilità e la minimizzazione dei dati. L'artefatto prodotto da questi esperimenti grafico in cui l'asse x è la dimensione del payload di addestramento in bit, L'asse y è la percentuale di entrate generate da un modello di quella dimensione rispetto a a una base di riferimento illimitata.

Supporremo di addestrare un modello pInstalla e le nostre origini di dati di addestramento sono i nostri log e i contenuti dei temporaryUnlimitedegressPayload che riceviamo quando vinciamo un'asta. Il protocollo per la tecnologia pubblicitaria innanzitutto riguarda il offline esperimenti:

  1. Determinare l'architettura dei modelli che utilizzeranno con Protected App. Indicatori. Ad esempio, dovranno determinare se utilizza la fattorizzazione del modello.
  2. Definisci una metrica per misurare la qualità del modello. Le metriche suggerite sono la perdita AUC e la perdita di log.
  3. Definire l'insieme di caratteristiche che utilizzeranno durante l'addestramento del modello.
  4. Utilizzando l'architettura del modello, la metrica di qualità e l'insieme di caratteristiche di addestramento, eseguire studi di ablazione per determinare l'utilità che ha contribuito per bit per ogni modello da usare nel PAS. Protocollo suggerito per lo studio sull'ablazione è:
    1. Addestrare il modello con tutte le caratteristiche e misurare l'utilità; questo è il di riferimento per il confronto.
    2. Per ogni caratteristica utilizzata per produrre la base, addestra il modello con tutte elementi tranne quella.
    3. Misurare l'utilità risultante. Dividi il delta per la dimensione della caratteristica in bit; questa è l'utilità prevista in bit per quella caratteristica.
  5. Determina le dimensioni dei payload di addestramento di interesse per la sperimentazione. Me suggerisci [5, 10, 15, ..., size_of_all_training_features_for_baseline] bit. Ognuna di queste rappresenta una dimensione possibile per egressPayload che l'esperimento valuterà.
  6. Per ogni dimensione possibile, seleziona un insieme di caratteristiche minori o uguali a quella dimensioni che massimizzano l'utilità per bit, utilizzando i risultati dello studio di ablazione.
  7. Addestra un modello per ogni dimensione possibile e valutane l'utilità come percentuale dell'utilità del modello di base addestrato su tutte le caratteristiche.
  8. Traccia i risultati su un grafico in cui l'asse x è la dimensione dell'addestramento payload in bit, e l'asse y è la percentuale di entrate generate del modello rispetto alla base di riferimento.

Successivamente, i tecnici pubblicitari possono ripetere i passaggi 5-8 negli esperimenti sul traffico in tempo reale, utilizzando dati inviati tramite temporaryUnlimitedEgressPayload. I tecnici pubblicitari possono scegliere di condividere i risultati degli esperimenti sul traffico offline e in tempo reale con Privacy Sandbox per prendere una decisione sulle dimensioni di egressPayload.

La sequenza temporale di questi esperimenti, nonché quella per l'impostazione delle dimensioni di egressPayload al valore risultante, esula dall'ambito di questo documento e sarà disponibile in un aggiornamento successivo.

Misure di protezione dei dati

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

  1. Sia egressPayload che temporaryUnlimitedEgressPayload emetterà un rumore.
  2. Per minimizzare e proteggere i dati, temporaryUnlimitedEgressPayload sarà disponibile solo per la durata degli esperimenti sulle dimensioni, durante la quale determina la dimensione corretta per egressPayload.

Autorizzazioni

Controllo utenti

  • La proposta intende dare agli utenti visibilità sull'elenco delle app installate che hanno archiviato almeno un indicatore di app Protected o un segmento di pubblico personalizzato.
  • Gli utenti possono bloccare e rimuovere app da questo elenco. Il blocco e la rimozione seguenti:
    • Cancella tutti gli indicatori di app protetti e i segmenti di pubblico personalizzati associati a l'app.
    • Impedisce alle app di archiviare nuovi indicatori di app protetti e personalizzati segmenti di pubblico
  • Gli utenti possono reimpostare gli indicatori dell'app Protected e Protected API Audience. In questi casi, le app protette esistenti Gli indicatori e i segmenti di pubblico personalizzati sul dispositivo sono stati cancellati.
  • Gli utenti hanno la possibilità di disattivare completamente Privacy Sandbox su Android, che include l'API Protected App Signals e Protected Audience tramite Google Cloud CLI o tramite l'API Compute Engine. In questo caso, gli indicatori Protected Audience e app protette Le API restituiscono un messaggio di eccezione standard: SECURITY_EXCEPTION.

Autorizzazioni e controllo delle app

La proposta intende fornire alle app il controllo sugli indicatori di app protette:

  • Un'app può gestire le proprie associazioni con gli indicatori di app protette.
  • Un'app può concedere alle piattaforme di tecnologia pubblicitaria di terze parti le autorizzazioni di gestione Indicatori dell'app protetta per suo conto.

Controllo della piattaforma ad tech

Questa proposta descrive i modi in cui i tecnici pubblicitari possono controllare gli indicatori delle app protette:

  • Tutti i tecnici pubblicitari devono registrarsi a Privacy Sandbox e fornire un "sito" o "origin" che corrisponde a tutti gli URL per gli indicatori di app protetti.
  • I tecnici pubblicitari possono collaborare con app o SDK per fornire token di verifica che vengono utilizzati per verificare la creazione di indicatori di app protetti. Quando questo processo viene delegata a un partner, la creazione di indicatori di app protetti può essere configurata richiedono l'accettazione da parte della tecnologia pubblicitaria.