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

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Questa proposta è soggetta alla procedura di registrazione e alle attestazioni di Privacy Sandbox. Per ulteriori informazioni sulle attestazioni, consulta il link all'attestazione 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 generalmente pubblicati in base agli interessi e ai dati demografici degli utenti e spesso appaiono 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 scegliere come target dei suoi annunci gli utenti che si trovano negli Stati Uniti e che in precedenza hanno interagito con altre app di consegna di cibo.

In genere, questo viene implementato includendo indicatori di contesto, proprietari e di terze parti tra le tecnologie pubblicitarie per creare profili utente in base agli 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 probabilità più alta di generare una conversione.

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

1. API Protected App Signals: incentrata sullo stoccaggio e sulla creazione di funzionalità di tecnologia pubblicitaria che rappresentano i potenziali interessi di un utente. Le ad tech memorizzano indicatori di eventi per app definiti autonomamente, come installazioni di app, prime aperture, azioni utente (livelli in-game, obiettivi), attività di acquisto o tempo in app. Gli indicatori vengono scritti e archiviati sul dispositivo per proteggersi dalle fughe di dati e vengono resi disponibili solo alla logica ad tech che ha archiviato l'indicatore in questione durante un'asta protetta in esecuzione in un ambiente sicuro.
2. API di selezione degli annunci: fornisce un'API per configurare ed eseguire un'asta protetta in un Trusted Execution Environment (TEE) in cui le tecnologie pubblicitarie recuperano gli annunci candidati, eseguono l'inferenza, calcolano le offerte e assegnano un punteggio per scegliere un annuncio "vincente" utilizzando sia gli indicatori delle app protette sia le informazioni contestuali in tempo reale fornite dal publisher.

Ecco una panoramica generale del funzionamento di Protected App Signals per supportare gli annunci per l'installazione di app pertinenti. Le sezioni seguenti di questo documento forniscono maggiori dettagli su ciascuno di questi passaggi.

• Curazione degli indicatori: quando gli utenti utilizzano le app mobile, le ad tech curano gli indicatori memorizzando gli eventi app definiti dalle ad tech 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 offerta e asta in esecuzione in ambienti di esecuzione attendibili con il controllo di sicurezza e della privacy appropriato possano decriptarli per le offerte e il calcolo del punteggio degli annunci.
• Codifica degli indicatori: gli indicatori vengono preparati con cadenza programmata in base alla logica ad tech personalizzata. Un job in background di Android esegue questa logica per eseguire la codifica on-device al fine di generare un payload di indicatori delle app protette che può essere utilizzato in un secondo momento 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 delle app protetti e configurano un'asta protetta. Nell'asta, la logica personalizzata dell'acquirente prepara gli indicatori delle app protette insieme ai dati contestuali forniti dal publisher (dati tipicamente condivisi in una richiesta di annuncio Open-RTB) per progettare funzionalità destinate alla selezione degli annunci (recupero degli annunci, inferenza e generazione di offerte). Come in Protected Audience, gli acquirenti inviano gli annunci al venditore per il calcolo del punteggio finale in un'asta protetta.
  • Riempimento degli annunci: gli acquirenti utilizzano gli indicatori delle app protette e i dati contestuali forniti dai publisher per creare funzionalità pertinenti agli interessi dell'utente. Queste funzionalità vengono utilizzate per associare gli annunci che soddisfano i criteri di targeting. Gli annunci non in linea con il budget vengono filtrati. Gli annunci migliori vengono selezionati per le offerte.
  • Offerte: la logica di offerta personalizzata degli acquirenti prepara i dati contestuali forniti dai publisher e gli indicatori delle app protette per progettare funzionalità che vengono utilizzate come input per i modelli di machine learning degli acquirenti per l'inferenza e le offerte per gli annunci candidati all'interno di confini attendibili che preservano la privacy. L'acquirente restituirà quindi l'annuncio scelto al venditore.
  • Scoring del venditore: la logica di punteggio personalizzata dei venditori assegna un punteggio agli annunci inviati dagli acquirenti partecipanti e sceglie un annuncio vincente da inviare nuovamente all'app per il rendering.
• Report: i partecipanti all'asta ricevono i report sulle offerte vinte e perse applicabili. Stiamo esplorando meccanismi che tutelano la privacy per includere i dati per l'addestramento dei modelli nel report sulle vittorie.

Cronologia

Organizzare gli indicatori delle app protette

Un indicatore è una rappresentazione di varie interazioni utente in un'app che sono determinate dalla tecnologia pubblicitaria come utili per la pubblicazione di annunci pertinenti. Un'app o l'SDK integrato possono memorizzare o eliminare indicatori delle app protetti definiti dalle tecnologie pubblicitarie in base all'attività utente, ad esempio aperture di app, obiettivi, attività di acquisto o tempo di utilizzo dell'app. Gli indicatori delle app protetti vengono archiviati in modo sicuro sul dispositivo e criptati prima di essere inviati dal dispositivo in modo che solo i servizi di offerta e asta in esecuzione in ambienti di esecuzione attendibili con controlli di sicurezza e privacy appropriati possano decriptarli per le offerte e il calcolo del punteggio degli annunci. Come per l'API Custom Audience, gli indicatori archiviati su un dispositivo non possono essere letti o ispezionati da app o SDK; non esiste un'API per leggere i valori degli indicatori e le API sono progettate per evitare la fuga di informazioni sulla presenza di indicatori. La logica personalizzata della tecnologia pubblicitaria ha protetto l'accesso ai propri indicatori selezionati 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 gli indicatori sotto forma di un singolo valore scalare o come serie temporali. Gli indicatori delle serie temporali possono essere utilizzati per memorizzare, ad esempio, la durata della sessione utente. Gli indicatori delle serie temporali offrono un'utilità per applicare una determinata lunghezza utilizzando una regola di espulsione 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 viene arricchito con il nome del pacchetto dell'applicazione che ha archiviato l'indicatore e il timestamp di creazione della chiamata all'API indicatore dello Store. Queste informazioni aggiuntive sono disponibili nel codice JavaScript per la 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 temporali associato con adtech1.com:

• Un indicatore scalare con chiave del valore base64 "A1c" e valore "c12Z". Lo store di indicatori è stato attivato da com.google.android.game_app il 1° giugno 2023.
• Un elenco di indicatori con chiave "dDE" creati da due diverse applicazioni.

Alle tecnologie pubblicitarie viene assegnata una certa quantità di spazio per archiviare gli indicatori sul dispositivo. Gli indicatori 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 dai seguenti componenti:

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

Aggiungere, aggiornare o rimuovere indicatori

Gli esperti di tecnologia pubblicitaria possono aggiungere, aggiornare o rimuovere indicatori con l'API fetchSignalUpdates(). Questa API supporta la delega in modo simile alla delega dei segmenti di pubblico personalizzati di Protected Audience.

Per aggiungere un indicatore, le tecnologie pubblicitarie per gli acquirenti che non hanno un SDK nelle app devono collaborare con quelle che hanno una presenza on-device, come i partner di misurazione mobile (MMP) e le Supply-Side Platform (SSP). L'API Protected App Signals ha lo scopo di supportare queste tecnologie pubblicitarie fornendo soluzioni flessibili per la gestione degli indicatori di app protette, consentendo agli utenti che chiamano l'app di invocare la creazione di indicatori di app protette per conto degli acquirenti. Questa procedura è chiamata delega e sfrutta l'API fetchSignalUpdates(). fetchSignalUpdates() accetta un URI e recupera un elenco di aggiornamenti degli indicatori. A titolo esemplificativo, fetchSignalUpdates() invia una richiesta GET all'URI specificato per recuperare l'elenco degli aggiornamenti da applicare allo spazio di archiviazione degli indicatori locali. L'endpoint URL, di proprietà del compratore, 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à memorizzato alcun valore. Questa opzione può essere utile, ad esempio, per impostare un ID esperimento per l'utente specificato ed evitare di sovrascriverlo 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 le dimensioni vengono superate, 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.

I comandi elencati sopra hanno lo scopo di fornire la semantica di inserimento, sovrascrittura ed eliminazione per i segnali scalari e di inserimento, accodamento e sovrascrittura completa della serie per i segnali delle serie temporali. La semantica di eliminazione e sovrascrittura di elementi specifici di un indicatore delle serie temporali deve essere gestita durante il processo di codifica e compattazione; ad esempio, durante la codifica è possibile ignorare i valori di una serie temporale che sono superati o corretti da altri più recenti ed eliminarli durante il processo di compattazione.

Gli indicatori archiviati vengono associati automaticamente all'applicazione che esegue la richiesta di recupero e all'utente che risponde alla richiesta ("sito" o "origine" di una tecnologia pubblicitaria registrata), oltre al momento di creazione della richiesta. Tutti gli indicatori sono soggetti a essere archiviati per conto di una tecnologia pubblicitaria registrata in 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 ed espulsione

Ogni tecnologia pubblicitaria ha uno spazio limitato sul dispositivo dell'utente per archiviare gli indicatori. Questa quota è definita per ad tech, pertanto i dati selezionati da app diverse condividono la quota. Se la quota viene superata, il sistema libera spazio rimuovendo i valori degli indicatori precedenti in base al criterio di primo arrivato, primo servito. Per evitare che l'espulsione venga eseguita troppo di frequente, il sistema implementa una logica di raggruppamento per consentire un superamento della quota limitato e per liberare un po' di spazio extra 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 nei limiti dello spazio di archiviazione protetto del dispositivo e trasmesso ai servizi di offerte e aste.

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

Se un acquirente non ha registrato un codificatore di indicatori, gli indicatori non vengono preparati e nessuno degli indicatori selezionati sul dispositivo viene inviato ai servizi di asta e offerta.

Ulteriori dettagli su quote di archiviazione, payload e richieste saranno disponibili in un futuro aggiornamento. 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 ai Segnali di app protetti solo all'interno di un'asta protetta (API Ad Selection) in esecuzione in un TEE. Per supportare ulteriormente le esigenze del caso d'uso di installazione di app, gli annunci candidati vengono recuperati in tempo reale durante l'asta protetta. 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 di installazione di app. Per supportare i requisiti di calcolo per la creazione di funzionalità e la selezione degli annunci in tempo reale, le aste per gli annunci di installazione di app devono essere eseguite su servizi di offerte e aste in esecuzione in TEE. L'accesso a 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 on-device degli indicatori delle app protette.
2. Il server del venditore crea una configurazione dell'asta e la invia al servizio di aste e offerte affidabili 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 offerte dell'acquirente esegue la logica di selezione degli annunci lato acquirente.
   1. Esecuzione della logica di recupero degli annunci lato acquirente.
   2. Esecuzione della logica di offerta lato acquirente.
5. Viene eseguita la logica di punteggio lato vendite.
6. L'annuncio viene visualizzato e viene avviata la generazione di report.

Avvia il 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 eventuali 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 di integrazione di offerte e aste per Android.

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

Il venditore imposta quanto segue:

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

• Gli indicatori di contesto 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 di acquirenti inclusi nelle aste utilizzando il buyer_list campo.

Esecuzione della logica di selezione degli annunci lato acquisti

A un livello generale, la logica personalizzata dell'acquirente utilizza i dati contestuali forniti dal publisher e gli indicatori delle app protette 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 vengono calcolate le offerte 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 k candidati migliori dal pool di annunci di grandi dimensioni. Successivamente, gli acquirenti devono calcolare le offerte per ciascuno di questi candidati migliori. Successivamente, questi annunci e queste 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 offerte dell'acquirente. Il servizio di offerte dell'acquirente esegue una UDF chiamata prepareDataForAdRetrieval(), che crea una richiesta per ottenere i k candidati migliori dal Servizio di recupero annunci. Il servizio di offerte invia questa richiesta all'endpoint del server di recupero configurato.
3. Il servizio di recupero degli annunci esegue la UDF getCandidateAds(), che filtra gli annunci candidati migliori k, che vengono inviati al servizio di offerte dell'acquirente.
4. Il servizio di offerte dell'acquirente esegue la UDF generateBid(), che sceglie il candidato migliore, ne calcola l'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 in merito al modo in cui i componenti comunicano tra loro e in cui la piattaforma fornisce funzionalità come la possibilità di fare previsioni di machine learning per recuperare i k annunci migliori e calcolare le relative offerte.

Prima di esaminare alcune parti più nel dettaglio, ecco alcune note di architettura importanti sui TEE nel diagramma sopra.

Il servizio di offerte dell'acquirente contiene internamente un servizio di inferenza. Le tecnologie pubblicitarie possono caricare modelli di machine learning nel servizio di offerte dell'acquirente. Forniremo API JavaScript per consentire alle ad tech di fare previsioni o generare embedding da questi modelli all'interno delle UDF in esecuzione nel 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 valore chiave per archiviare i metadati degli annunci.

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

Una domanda centrale affrontata da questo design è come fare previsioni sul momento del recupero e sul momento dell'offerta. La risposta per entrambi può comportare una soluzione chiamata factorizzazione del modello.

Fattorizzazione del modello

La fattorizzazione del modello è una tecnica che consente di suddividere un singolo modello in più parti e poi di combinarle in una previsione. Nel caso d'uso Installazione di app, i modelli utilizzano spesso tre tipi di dati: dati degli utenti, 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, suddividiamo il modello in più parti. Solo la parte contenente i dati utente è sensibile. Ciò significa che solo il modello con la componente utente deve essere eseguito all'interno del confine di attendibilità, nel servizio di inferenza del servizio di offerta dell'acquirente.

Ciò rende possibile il seguente design:

1. Suddividi il modello in un componente privato (i dati utente) e uno o più componenti non privati (i dati contestuali e sugli annunci).
2. Se vuoi, puoi passare alcuni o tutti i componenti non privati come argomenti a una UDF che deve fare previsioni. Ad esempio, gli embedding contestuali vengono passati alle UDF in per_buyer_signals.
3. Se vuoi, le tecnologie pubblicitarie possono creare modelli per elementi non privati, quindi materializzare gli embedding da questi modelli nello store di chiavi e valori del Servizio di recupero annunci. Le funzioni UDF nel servizio di recupero degli annunci possono recuperare questi incorporamenti in fase di esecuzione.
4. Per fare una previsione durante una UDF, combina gli embedding privati del servizio di inferenza con gli embedding non privati degli argomenti della funzione UDF o dello spazio dati chiave-valore con un'operazione come il prodotto scalare. Questa è la previsione finale.

Dopo questa spiegazione, possiamo esaminare ogni UDF in modo più dettagliato. Ti spiegheremo che cosa fanno, come si integrano e come possono fare le previsioni necessarie per scegliere i k annunci migliori e calcolare le relative offerte.

La funzione definita dall'utente prepareDataForAdRetrieval()

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

prepareDataForAdRetrieval() accetta le seguenti informazioni:

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

prepareDataForAdRetrieval() fa due cose:

• Caratterizzazione: se è necessaria l'inferenza al momento del recupero, trasforma i segnali in arrivo in funzionalità da utilizzare durante le chiamate al servizio di inferenza per ottenere embedding privati per il recupero.
• Calcola gli embedding privati per il recupero: se sono necessarie le previsioni di recupero, effettua la chiamata al servizio di inferenza utilizzando le funzionalità sopra indicate e ottiene un embedding privato per le previsioni al momento del recupero.

prepareDataForAdRetrieval() restituisce:

• Protected App Signals: payload degli indicatori selezionati da ad tech.
• Indicatori specifici per l'asta: indicatori sell-side specifici della piattaforma e informazioni contestuali come auction_signals e per_buyer_signals (inclusi gli embedding contestuali) di SelectAdRequest. È simile ai segmenti di pubblico protetti.
• Indicatori aggiuntivi: informazioni aggiuntive come gli embedding 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().

La funzione definita dall'utente getCandidateAds()

getCandidateAds() viene eseguito sul servizio di recupero degli annunci. Riceve la richiesta creata da prepareDataForAdRetrieval() sul servizio di offerta dell'acquirente. Il servizio esegue getCandidateAds(), che recupera i candidati migliori per le offerte convertendo la richiesta in una serie di query impostate, recupero dei dati ed esecuzione di logica aziendale e di recupero personalizzata.

getCandidateAds() accetta le seguenti informazioni:

• Protected App Signals: payload degli indicatori selezionati da ad tech.
• Indicatori specifici per l'asta: indicatori sell-side specifici della piattaforma e informazioni contestuali come auction_signals e per_buyer_signals (inclusi gli embedding contestuali) di SelectAdRequest. È simile ai segmenti di pubblico protetti.
• Indicatori aggiuntivi: informazioni aggiuntive come gli embedding privati recuperati dal servizio di inferenza.

getCandidateAds() esegue le seguenti operazioni:

1. Recupero di un insieme iniziale di annunci candidati: vengono recuperati utilizzando criteri di targeting come lingua, posizione geografica, tipo di annuncio, dimensione dell'annuncio o budget per filtrare gli annunci candidati.
2. Recupero dell'embedding: se gli embedding del servizio chiave-valore sono necessari per fare una previsione del tempo di recupero per la selezione dei primi k, devono essere recuperati dal servizio chiave-valore.
3. Selezione dei candidati migliori k: calcola un punteggio ridotto per l'insieme filtrato di annunci candidati in base ai metadati degli annunci recuperati dallo store key-value e alle informazioni inviate dal servizio di offerte dell'acquirente e scegli i candidati migliori k in base a questo punteggio. Ad esempio, il punteggio potrebbe essere la probabilità di installare un'app in base all'annuncio.
4. Recupero degli embedding per le offerte: se gli embedding del servizio chiave-valore sono necessari per il codice delle offerte per fare previsioni al momento dell'offerta, possono essere recuperati dal servizio chiave-valore.

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

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

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

getCandidateAds() restituisce:

• Annunci candidati: i k annunci migliori da passare a generateBid(). Ogni annuncio è composto da:
  • URL di rendering: endpoint per il rendering della creatività dell'annuncio.
  • Metadati: metadati degli annunci lato acquirente specifici per la tecnologia pubblicitaria. Ad esempio, possono essere incluse informazioni sulla campagna pubblicitaria e sui criteri di targeting, come località e lingua. I metadati possono includere embeddings facoltativi utilizzati quando è necessaria la fattorizzazione del modello per eseguire l'inferenza durante le offerte.
• Indicatori aggiuntivi: facoltativamente, il Servizio di recupero annunci può includere informazioni aggiuntive, come incorporamenti o indicatori di spam aggiuntivi da utilizzare in generateBid().

Stiamo valutando altri metodi per fornire gli annunci da valutare, ad esempio rendendoli 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 delle app protette. 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.

La funzione definita dall'utente generateBid()

Dopo aver recuperato l'insieme di annunci candidati e gli embedding durante il recupero, puoi procedere con le offerte, che vengono eseguite nel servizio di offerte dell'acquirente. Questo servizio esegue la UDF generateBid() fornita dall'acquirente per selezionare l'annuncio per cui fare un'offerta tra i primi k, quindi lo restituisce con l'offerta.

generateBid() accetta le seguenti informazioni:

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

L'implementazione di generateBid() dell'acquirente consente di svolgere tre attività:

• Caratterizzazione: trasforma gli indicatori in funzionalità da utilizzare durante l'inferenza.
• Deduzione: 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.

generateBid() restituisce:

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

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

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

Featurization

Gli indicatori di asta possono essere preparati da generateBid() in funzionalità. Queste funzionalità possono essere utilizzate durante l'inferenza per prevedere, ad esempio, la percentuale di clic e i tassi di conversione. Stiamo anche esplorando meccanismi per la tutela della privacy per trasmettere alcuni di questi dati nel report sulle conversioni vincenti per utilizzarli 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 i tassi di clic e di conversione.

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

L'inferenza viene eseguita nel servizio di offerte dell'acquirente. Ciò può influire sulla latenza e sul costo dell'inferenza, soprattutto perché gli acceleratori non sono ancora disponibili nei TEE. Alcune esigenze dei clienti possono essere soddisfatte con singoli modelli eseguiti sul servizio di offerte dell'acquirente. Alcuni clienti, ad esempio quelli con modelli molto grandi, potrebbero 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 aggiornamento futuro.

Implementa la fattorizzazione del modello

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

1. Suddividi il singolo modello in un componente privato (i dati utente) e uno o più componenti non privati (i dati contestuali e sugli annunci).
2. Passa i componenti non privati a generateBid(). Possono provenire da per_buyer_signals o da embedding calcolati esternamente dagli esperti di tecnologia pubblicitaria, materializzarsi nello spazio dati chiave-valore del servizio di recupero, essere recuperati al momento del recupero e restituiti come parte degli indicatori aggiuntivi. Non sono inclusi gli elementi incorporati privati, poiché non possono provenire dall'esterno del perimetro della privacy.
3. In generateBid():
   1. Esegui l'inferenza sui modelli per ottenere gli embedding degli utenti privati.
   2. Combina gli embedding degli utenti privati con gli embedding contestuali di annunci per_buyer_signals o non privati e gli embedding contestuali del servizio di recupero utilizzando un'operazione come il prodotto scalare. Si tratta della predizione finale che può essere utilizzata per calcolare le offerte.

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

Logica di punteggio lato vendite

In questa fase, gli annunci con le offerte ricevute da tutti gli acquirenti partecipanti vengono assegnati un punteggio. L'output di generateBid() viene passato al servizio di asta 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 punteggio è la stessa utilizzata per il flusso di remarketing di Protected Audience ed è in grado di selezionare un vincitore tra i candidati per il remarketing e le installazioni di app.La funzione viene chiamata una volta per ogni annuncio candidato inviato nell'asta Protected. Per maggiori dettagli, consulta la sezione Offerte e aste.

Esecuzione del codice di selezione degli annunci

Nella proposta, il codice di selezione degli annunci per l'installazione di app viene specificato nello stesso modo come per il flusso di remarketing di Protected Audience. Per maggiori dettagli, consulta la sezione Offerte e configurazione dell'asta. Il codice per le offerte sarà disponibile nella stessa posizione di archiviazione sul cloud di quello utilizzato per il remarketing.

Rapporti

Questa proposta utilizza le stesse API di generazione di report della proposta relativa ai report di Protected Audience (ad es. reportImpression(), che attiva l'invio di report da parte della piattaforma a venditori e acquirenti).

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

A lungo termine, stiamo studiando soluzioni che garantiscano la tutela della privacy per l'addestramento dei modelli con i dati utilizzati nelle aste protette senza inviare i dati utente a livello di evento ai servizi esterni in esecuzione su TEE. Forniremo ulteriori dettagli in un aggiornamento successivo.

A breve, forniremo un modo temporaneo per esportare i dati con rumore dagenerateBid(). La nostra proposta iniziale è riportata di seguito e la svilupperemo (incluse possibili modifiche non compatibili con le versioni precedenti) in base al feedback del settore.

Tecnicamente, il funzionamento è il seguente:

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

Definizione dello schema dei payload in uscita

Affinché la piattaforma possa applicare i requisiti di privacy in evoluzione, i payload in uscita devono essere strutturati in modo che la piattaforma possa comprenderli. Le aziende di tecnologia pubblicitaria definiranno la struttura dei loro payload in uscita fornendo un file JSON dello schema. Lo schema verrà elaborato dalla piattaforma e verrà mantenuto riservato dai servizi di offerta e asta utilizzando gli stessi meccanismi di altre risorse di ad tech come i modelli e le UDF.

Forniremo un file CDDL che definisce la struttura del JSON. Il file CDDL includerà un insieme di tipi di funzionalità supportati (ad esempio, funzionalità booleane, interi, bucket e così via). Sia il file CDDL sia lo schema fornito verranno sottoposti a controllo della versione.

Ad esempio, un payload in uscita costituito da una singola caratteristica booleana followed da una caratteristica bucket di dimensione 2 avrà il seguente aspetto:

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

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

Creare payload in uscita in generateBid()

Tutti gli indicatori delle app protette per un determinato acquirente sono disponibili per il relativo generateBid() UDF. Una volta che sono state implementate, le tecnologie pubblicitarie creano il proprio payload in formato JSON. Questo payload in uscita verrà incluso nel report sulle offerte vinte dell'acquirente per la trasmissione ai server di tecnologia pubblicitaria.

Un'alternativa a questo design è che il calcolo del vettore di uscita venga eseguito in reportWin() anziché in generateBid(). Esistono compromessi per ogni approccio e prenderemo la decisione definitiva in base al feedback del settore.

Convalida il payload in uscita

La piattaforma convaliderà qualsiasi payload in uscita creato dall'ad tech. La convalida garantisce che i valori delle funzionalità siano validi per i relativi tipi, che i vincoli di dimensione siano soddisfatti e che gli attori malintenzionati non stiano tentando di aggirare i controlli della privacy inserendo informazioni aggiuntive nei payload in uscita.

Se un payload in uscita non è valido, verrà ignorato silenziosamente dagli input inviati al report sulle conversioni. Questo perché non vogliamo fornire informazioni di debugging a malintenzionati che tentano di aggirare la convalida.

Forniremo un'API JavaScript per le ad tech per garantire che il payload in uscita creato in generateBid() superi la convalida della piattaforma:

validate(payload, schema)

Questa API JavaScript è interamente destinata agli utenti chiamanti per determinare se un determinato payload supererà la convalida della piattaforma. La convalida effettiva deve essere eseguita nella piattaforma per proteggerti dalle UDF generateBid() dannose.

Aggiungi rumore al payload in uscita

La piattaforma aggiungerà rumore ai payload in uscita prima di includerli nel report sulle conversioni. La soglia di rumore iniziale sarà dell'1% e questo valore potrebbe evolversi nel tempo. La piattaforma non fornirà alcuna indicazione sull'eventuale presenza di rumore in un determinato payload in uscita.

Il metodo di applicazione del rumore è:

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

Trasmissione, ricezione e decodifica del payload in 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 del cavo per tutti i tipi di funzionalità e per il payload di uscita sono disponibili su GitHub.

Determina le dimensioni 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 sperimentazioni. Durante la realizzazione di questi esperimenti, eseguiremo temporaneamente l'esportazione dei dati senza limitazioni di dimensione in bit. Questi dati di uscita aggiuntivi senza limitazioni di dimensione in bit verranno rimossi al termine degli esperimenti.

Il metodo per determinare le dimensioni è il seguente:

1. Inizialmente, supporteremo due payload in uscita in generateBid():
   1. egressPayload: il payload in uscita con dimensioni limitate descritto finora in questo documento. Inizialmente, le dimensioni di questo payload in 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 in uscita utilizzano gli stessi meccanismi di egressPayload.
2. Ciascuno di questi payload in uscita avrà il proprio file JSON dello schema: egress_payload_schema.json e temporary_egress_payload_schema.json.
3. Forniamo un protocollo sperimentale e un insieme di metriche per determinare l'utilità del modello con vari dimensioni del payload in uscita (ad es. 5, 10, ... bit).
4. In base ai risultati dell'esperimento, determiniamo le dimensioni del payload in uscita con i compromessi di utilità e privacy corretti.
5. Impostiamo le dimensioni di egressPayload da 0 bit alle nuove dimensioni.
6. Dopo un periodo di migrazione impostato, 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 ne aumentiamo le dimensioni da 0 bit). Questi dettagli, insieme alle tempistiche dell'esperimento e alla rimozione di temporaryUnlimitedEgressPayload, verranno inclusi in un aggiornamento successivo.

Di seguito 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'elemento che verrà prodotto da questi esperimenti è un grafico in cui l'asse x indica le dimensioni del payload di addestramento in bit e l' asse y indica la percentuale di entrate generate da un modello di queste dimensioni rispetto a un valore di riferimento illimitato.

Supponiamo di addestrare un modello pInstall e che le nostre origini di dati di addestramento siano i nostri log e i contenuti dei temporaryUnlimitedegressPayload che riceviamo quando vinciamo le aste. Il protocollo per le ad tech prevede innanzitutto esperimenti offline:

1. Determinare l'architettura dei modelli che verranno utilizzati con Protected App Signals. Ad esempio, dovrà stabilire se utilizzare o meno la factorizzazione del modello.
2. Definisci una metrica per misurare la qualità del modello. Le metriche suggerite sono la perdita AUC e la perdita logaritmica.
3. Definire l'insieme di funzionalità da utilizzare durante l'addestramento del modello.
4. Utilizzando l'architettura del modello, la metrica di qualità e l'insieme di funzionalità di addestramento, eseguire studi di ablazione per determinare l'utilità apportata per bit per ogni modello che vogliono 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 caratteristica utilizzata per produrre la linea di base, addestra il modello con tutte le caratteristiche tranne quella in questione.
   3. Misura l'utilità risultante. Dividi il delta per le dimensioni della funzionalità in bit. Questa è l'utilità prevista per bit per la funzionalità.
5. Determina le dimensioni del payload di addestramento di interesse per la sperimentazione. Ti consigliamo [5, 10, 15, ..., size_of_all_training_features_for_baseline] bit. Ognuna di queste rappresenta una possibile dimensione per egressPayload che verrà valutata dall'esperimento.
6. Per ogni dimensione possibile, seleziona un insieme di funzionalità inferiori o uguali a quella dimensione che massimizza l'utilità per bit, utilizzando i risultati dello studio di ablazione.
7. Addestra un modello per ogni dimensione possibile e valuta la sua utilità come percentuale dell'utilità del modello di riferimento addestrato su tutte le funzionalità.
8. Grafica i risultati su un grafico in cui l'asse x indica le dimensioni del payload di addestramento in bit e l'asse y la percentuale di entrate generate da quel modello rispetto al valore di riferimento.

Successivamente, le ad tech possono ripetere i passaggi da 5 a 8 negli esperimenti sul traffico in tempo reale utilizzando i dati sulle funzionalità inviati tramite temporaryUnlimitedEgressPayload. Le aziende di ad tech possono scegliere di condividere con Privacy Sandbox i risultati dei loro esperimenti sul traffico offline e in tempo reale per supportare la decisione relativa alle dimensioni di egressPayload.

Le tempistiche di questi esperimenti, nonché le tempistiche per l'impostazione della dimensione di egressPayload sul valore risultante, non rientrano nell'ambito di questo documento e verranno fornite in un aggiornamento successivo.

Misure di protezione dei dati

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

1. Sia egressPayload che temporaryUnlimitedEgressPayload verranno resi rumorosi.
2. Per la minimizzazione e la protezione dei dati, temporaryUnlimitedEgressPayload sarà disponibile solo per la durata degli esperimenti sulle dimensioni, durante i quali determineremo la dimensione corretta per egressPayload.

Autorizzazioni

Controllo utente

• La proposta intende dare agli utenti la visibilità dell'elenco delle app installate che hanno archiviato almeno un indicatore di app protette o un segmento di pubblico personalizzato.
• Gli utenti possono bloccare e rimuovere le app da questo elenco. La funzionalità Blocca e rimuovi consente di:
  • Cancella tutti gli indicatori Protected App Signals e i segmenti di pubblico personalizzati associati all'app.
  • Impedisce alle app di memorizzare nuovi indicatori Protected App Signals e segmenti di pubblico personalizzati
• Gli utenti hanno la possibilità di reimpostare completamente l'API Protected App Signals e Protected Audience. In questo caso, tutti gli indicatori sulle app protette e i segmenti di pubblico personalizzati esistenti sul dispositivo vengono cancellati.
• Gli utenti hanno la possibilità di disattivare completamente Privacy Sandbox su Android, incluse le API Protected App Signals e Protected Audience. In questi casi, 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 sui propri indicatori Protected App Signals:

• Un'app può gestire le sue associazioni con gli indicatori delle app protette.
• Un'app può concedere alle piattaforme di ad tech di terze parti le autorizzazioni per gestire gli indicatori delle app protette per suo conto.

Controllo della piattaforma ad tech

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

• Tutte le tecnologie pubblicitarie devono registrarsi a Privacy Sandbox e fornire un dominio "site" o "origin" che corrisponda a tutti gli URL per gli indicatori delle app protette.
• Le tecnologie pubblicitarie possono collaborare con app o SDK per fornire token di verifica utilizzati per verificare la creazione di indicatori delle app protette. Quando questa procedura viene delegata a un partner, la creazione dell'indicatore di app protetta può essere configurata in modo da richiedere il riconoscimento da parte della tecnologia pubblicitaria.