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

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

Gli annunci per l'installazione di app mobili, noti anche come annunci di acquisizione utenti, sono un tipo di pubblicità mobile studiata per incoraggiare gli utenti a scaricare un'app mobile. Questi annunci vengono generalmente mostrati agli utenti in base ai loro interessi e dati demografici 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 all'app store per scaricare l'app.

Ad esempio, un inserzionista che sta cercando di incrementare le nuove installazioni di una nuova app per la consegna di cibo a domicilio negli Stati Uniti potrebbe scegliere come target dei suoi annunci utenti la cui sede si trova negli Stati Uniti e che hanno precedentemente interagito con altre app per la consegna di cibo a domicilio.

In genere, questo viene implementato includendo indicatori contestuali, proprietari e di terze parti tra i tecnici pubblicitari per creare profili utente in base agli ID pubblicità. I modelli di machine learning di ad tech utilizzano queste informazioni come input per scegliere annunci pertinenti per l'utente e con le maggiori probabilità di generare una conversione.

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

  1. API Protected App Signals: si concentra sull'archiviazione e sulla creazione di funzionalità progettate ad tech che rappresentano i potenziali interessi di un utente. Gli 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 nell'app. Gli indicatori vengono scritti e archiviati sul dispositivo per evitare fughe di dati e vengono resi disponibili soltanto alla logica di tecnologia pubblicitaria che ha archiviato un determinato indicatore 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 gli annunci candidati, eseguono l'inferenza, calcolano le offerte e assegnano punteggi per scegliere un annuncio "vincente" utilizzando sia gli indicatori dell'app protetti sia le informazioni contestuali in tempo reale fornite dal publisher.
Diagramma che mostra il flusso di installazione di app con indicatori protetti
Diagramma di flusso che mostra gli indicatori delle app protetti e il flusso di lavoro per la selezione degli annunci in Privacy Sandbox su Android.

Ecco una panoramica generale del funzionamento degli indicatori di app protetti per supportare annunci per l'installazione di app pertinenti. Le seguenti sezioni del documento forniscono ulteriori dettagli su ciascuno di questi passaggi.

  • Selezione degli indicatori: man mano che gli utenti usano le app mobile, le tecnologie pubblicitarie selezionano gli indicatori archiviando gli eventi delle app definiti per la tecnologia pubblicitaria per pubblicare annunci pertinenti utilizzando l'API Protected App Signals. Questi eventi vengono archiviati in uno spazio di archiviazione sul dispositivo protetto, come nei segmenti di pubblico personalizzati, e vengono criptati prima di essere inviati dal dispositivo in modo che solo i servizi di offerte e aste in esecuzione all'interno di ambienti di esecuzione attendibili con i controlli di sicurezza e privacy appropriati possano decriptarli per gli annunci con punteggio e offerte.
  • Codifica degli indicatori: gli indicatori vengono preparati con una cadenza programmata in base a una logica di tecnologia pubblicitaria personalizzata. Un job in background di Android esegue questa logica per eseguire la codifica on-device per generare un payload di Protected App Signals che potrà essere utilizzato successivamente in tempo reale per la selezione degli annunci durante un'asta protetta. Il payload viene archiviato in modo sicuro sul dispositivo finché non viene inviato per un'asta.
  • Selezione degli annunci: per selezionare gli annunci pertinenti per l'utente, gli SDK del venditore inviano un payload criptato di indicatori di app protetti e configura un'asta protetta. Nell'asta, la logica personalizzata dell'acquirente prepara gli indicatori dell'app protetti insieme ai dati contestuali forniti dal publisher (dati generalmente condivisi in una richiesta di annuncio Open RTB) per progettare le funzionalità destinate alla selezione degli annunci (recupero degli annunci, inferenza e generazione di offerte). Come per Protected Audience, gli acquirenti inviano annunci al venditore per il punteggio finale di un'asta protetta.
    • Recupero degli annunci: gli acquirenti utilizzano gli indicatori dell'app protetti e i dati contestuali forniti dal publisher per progettare funzionalità pertinenti agli interessi dell'utente. Queste funzioni vengono usate per associare gli annunci che soddisfano i criteri di targeting. Gli annunci che non rientrano nel budget vengono esclusi. Gli annunci con il rendimento migliore vengono quindi selezionati per le offerte.
    • Offerte: la logica delle offerte personalizzate degli acquirenti prepara i dati contestuali forniti dal publisher e gli indicatori di app protetti per progettare funzionalità che vengono utilizzate come input per i modelli di machine learning dell'acquirente per l'inferenza e le offerte sugli annunci candidati all'interno di confini attendibili che garantiscono la tutela della privacy. L'acquirente restituisce quindi al venditore l'annuncio che ha scelto.
    • Punteggio del venditore: gli annunci inviati dagli Acquirenti partecipanti in base alla logica di punteggio personalizzato dei venditori e scelgono un annuncio vincente da inviare all'app per il rendering.
  • Report: i partecipanti all'asta ricevono report sulle vincite e report sulle perdite applicabili. Stiamo esplorando meccanismi che tutelano la privacy per includere i dati per l'addestramento del modello nel report sui risultati finali.

Sequenza temporale

Anteprima per gli sviluppatori Beta
Funzionalità T4'23 T1'24 T2'24 T3'24
API per la cura dei segnali API di archiviazione on-device Logica della quota di spazio di archiviazione on-device

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

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

Debug, metriche e monitoraggio autorizzati
Servizio di inferenza in un TEE

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

Possibilità di eseguire il deployment e prototipare modelli ML statici utilizzando Tensorflow e PyTorch 		Disponibile su AWS

Deployment di modelli prodotti per i modelli Tensorflow e PyTorch

Telemetria, debug con consenso e monitoraggio
Supporto di offerte e 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 autorizzati

Seleziona indicatori dell'app protetti

Un indicatore è una rappresentazione di varie interazioni degli utenti in un'app che determinate dalla tecnologia pubblicitaria sono utili per la pubblicazione di annunci pertinenti. Un'app o l'SDK integrato può archiviare o eliminare gli indicatori dell'app protetti definiti dagli ad tech in base all'attività utente, ad esempio apertura dell'app, obiettivi, attività di acquisto o tempo nell'app. Gli indicatori dell'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 aste eseguiti all'interno di ambienti di esecuzione attendibili con sicurezza e controllo della privacy adeguati possano decriptarli per gli annunci per le offerte e il punteggio. Analogamente all'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 sono progettate per evitare di perdere la presenza di indicatori. La logica personalizzata di ad tech ha protetto l'accesso ai loro 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 l'archiviazione dei segnali sotto forma di singolo valore scalare o serie temporale. Gli indicatori delle serie temporali possono essere utilizzati per archiviare elementi come la durata delle sessioni utente. Gli indicatori delle serie temporali offrono un'utilità per applicare una determinata lunghezza utilizzando una regola di rimozione. Il tipo di dati di un segnale scalare, o ciascuno degli elementi di un segnale serie temporale, è un array di byte. Ogni valore è arricchito con il nome del pacchetto dell'applicazione che ha archiviato l'indicatore e il timestamp di creazione della chiamata API dell'indicatore del negozio. Queste informazioni aggiuntive sono disponibili nel codice JavaScript di codifica degli indicatori. Questo esempio mostra la struttura degli indicatori di proprietà di una determinata tecnologia pubblicitaria:

Questo esempio mostra un indicatore scalare e un indicatore di serie temporale associato a adtech1.com:

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

Alle tecnologie pubblicitarie viene assegnata una certa quantità di spazio per memorizzare i segnali sul dispositivo. Gli indicatori avranno un TTL massimo, che deve essere determinato.

I Protected App Signals vengono rimossi dallo spazio di archiviazione se l'applicazione di generazione viene disinstallata, se l'API Protected App Signals viene bloccata o se i dati dell'app vengono cancellati dall'utente.

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

  • un'API Java e JavaScript per aggiungere, aggiornare o rimuovere indicatori.
  • Un'API JavaScript per elaborare gli indicatori persistenti in modo da prepararli ad ulteriori feature engineering in tempo reale durante un'asta protetta in esecuzione 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 la delega in modo simile alla delega dei segmenti di pubblico personalizzati di Protected Audience.

Per aggiungere un indicatore, i tecnici pubblicitari degli acquirenti che non hanno una presenza di SDK nelle app devono collaborare con i tecnici pubblicitari che hanno una presenza on-device, come i partner di misurazione mobile (MMP) e Supply-Side Platform (SSP). L'API Protected App Signal ha lo scopo di supportare queste ad tech fornendo soluzioni flessibili per la gestione di Protected App Signal, consentendo ai chiamanti sul dispositivo di richiamare la creazione di Protected App Signal per conto degli acquirenti. Questa procedura è chiamata delega e utilizza l'API fetchSignalUpdates(). fetchSignalUpdates() prende un URI e recupera un elenco di aggiornamenti degli indicatori. Per spiegare meglio, fetchSignalUpdates() invia una richiesta GET all'URI specificato per recuperare l'elenco degli aggiornamenti da applicare all'archiviazione locale degli indicatori. L'endpoint URL, di proprietà dell'acquirente, risponde con un elenco JSON di comandi.

I comandi JSON supportati sono:

  • put: inserisce o sovrascrive un valore scalare per la chiave specificata.
  • put_if_not_present: inserisce un valore scalare per la chiave specificata se non esiste già alcun valore archiviato. Questa opzione può essere utile, ad esempio, per impostare un ID esperimento per l'utente in questione ed evitare di sostituirlo se era già impostato da un'altra applicazione.
  • aggiungi: aggiunge un elemento alla serie temporale associata alla chiave specificata. Il parametro maxSignals specifica il numero massimo di indicatori nella serie temporale. Se vengono superate le dimensioni, gli elementi precedenti vengono rimossi. Se la chiave contiene un valore scalare, viene automaticamente trasformata in una serie temporale.
  • rimuovi: 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 dell'inserimento, la sovrascrittura e l'eliminazione della semantica per gli indicatori scalari e di inserire, aggiungere e sovrascrivere serie complete per gli indicatori di serie temporali. L'eliminazione e la sovrascrittura della semantica su elementi specifici di un segnale di serie temporale deve essere gestita durante il processo di codifica e compattazione; ad esempio, durante la codifica ignorando i valori in una serie temporale che sono sostituiti o corretti da quelli più recenti ed eliminandoli durante il processo di compattazione.

Gli indicatori archiviati vengono associati automaticamente all'applicazione che esegue la richiesta di recupero e all'utente che ha risposto della richiesta (il "sito" o l'"origine" di una tecnologia pubblicitaria registrata), oltre all'ora di creazione della richiesta. Tutti gli indicatori sono soggetti a memorizzazione per conto di una tecnologia pubblicitaria registrata a Privacy Sandbox, l'URI "sito"/"origine" deve corrispondere ai dati di una tecnologia pubblicitaria registrata. Se l'ad tech richiedente non viene registrata, la richiesta viene rifiutata.

Quota di archiviazione ed eliminazione

Ogni tecnologia pubblicitaria ha una quantità limitata di spazio sul dispositivo dell'utente per memorizzare gli indicatori. Questa quota è definita per ad tech, pertanto gli indicatori selezionati da app diverse condividono la quota. Se la quota viene superata, il sistema libera spazio rimuovendo i valori degli indicatori precedenti in base all'ordine di arrivo. Per evitare che l'eliminazione venga eseguita troppo spesso, il sistema implementa una logica di raggruppamento per consentire una quantità limitata di scoperto di quota e liberare spazio in più una volta attivata la logica di rimozione.

Codifica on-device per la trasmissione dati

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

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

Se un acquirente non ha registrato un codificatore di indicatori, gli indicatori non sono preparati e nessuno degli indicatori selezionati on-device viene inviato ai servizi di offerte e aste.

Ulteriori dettagli sulle quote di spazio di archiviazione, payload e richieste saranno disponibili in un futuro aggiornamento. Forniremo inoltre ulteriori informazioni su come fornire funzioni personalizzate.

Flusso di lavoro per la selezione degli annunci

Con questa proposta, il codice personalizzato ad tech può accedere agli indicatori dell'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 per l'installazione di app, gli annunci candidati vengono recuperati durante l'asta protetta in tempo reale. Ciò è in contrasto con il caso d'uso del remarketing in cui gli annunci candidati sono noti prima dell'asta.

Questa proposta utilizza un flusso di lavoro per la selezione degli annunci simile alla proposta Protected Audience con aggiornamenti per supportare il caso d'uso per l'installazione di app. Per supportare i requisiti di calcolo per il feature engineering e la selezione di annunci in tempo reale, le aste per gli annunci per l'installazione di app devono essere eseguite sui servizi di offerte e aste in esecuzione in TEE. L'accesso agli indicatori delle app protetti durante un'asta protetta non è supportato per le aste on-device.

Illustrazione del flusso di lavoro di selezione degli annunci.
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 on-device degli indicatori di app protetti.
  2. Il server del venditore crea una configurazione dell'asta e la invia al servizio Trusted Bidding e alle aste 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 passa il payload ai server frontend degli acquirenti attendibili partecipanti.
  4. Il servizio di offerte dell'acquirente esegue la logica di selezione degli annunci lato acquisto
    1. Esecuzione della logica di recupero degli annunci lato acquisto.
    2. Esecuzione della logica di offerta lato acquisto.
  5. Viene eseguita la logica del punteggio lato vendite.
  6. L'annuncio viene visualizzato e vengono avviati i report.

Avvia flusso di lavoro per la selezione degli annunci

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

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

Il venditore imposta quanto segue:

Esecuzione della logica di selezione degli annunci lato acquirente

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

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

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

  1. Il servizio BuyersFrontEnd riceve una richiesta di annuncio.
  2. Il servizio BuyersFrontEnd invia una richiesta al servizio di offerte dell'acquirente. Il servizio di offerta dell'acquirente esegue una funzione definita dall'utente denominata prepareDataForAdRetrieval(), che crea una richiesta per ottenere i primi k candidati dal Servizio di recupero annunci. Il servizio di offerta invia questa richiesta all'endpoint del server di recupero configurato.
  3. Il servizio di recupero degli annunci esegue la funzione definita dall'utente getCandidateAds(), che filtra in base all'insieme dei primi k annunci candidati, che vengono inviati al servizio di offerta dell'acquirente.
  4. Il servizio offerte dell'acquirente esegue la funzione definita dall'utente generateBid(), che sceglie il candidato migliore, calcola l'offerta e la restituisce al servizio BuyersFrontEnd.
  5. Il servizio BuyersFrontEnd restituisce gli annunci e le offerte al venditore.

Questo flusso presenta diversi dettagli importanti, in particolare per quanto riguarda il modo in cui gli elementi comunicano tra loro e il modo in cui la piattaforma offre funzionalità come la capacità di effettuare previsioni di machine learning per recuperare gli annunci top-k e calcolare le loro offerte.

Prima di esaminare in dettaglio queste parti, ci sono alcune importanti note sull'architettura relative ai TEE nel diagramma qui sopra.

Il servizio di offerta dell'acquirente contiene internamente un servizio di inferenza. I tecnici pubblicitari possono caricare i modelli di machine learning nel servizio di offerta dell'acquirente. Forniremo API JavaScript agli ad tech per fare previsioni o generare incorporamenti da questi modelli all'interno delle funzioni definite dall'utente 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 chiave-valore per archiviare i metadati degli annunci.

Il servizio di recupero annunci include internamente un servizio valore-chiave. Gli ad tech possono materializzare le coppie chiave-valore in questo servizio dai propri server, al di fuori dei confini della privacy. Forniremo un'API JavaScript che i tecnici pubblicitari potranno leggere da questo servizio chiave-valore dall'interno delle funzioni definite dall'utente in esecuzione sul servizio di recupero degli annunci. A differenza del servizio di offerta dell'acquirente, il servizio di recupero degli annunci non contiene un servizio di inferenza.

Una domanda centrale affrontata da questa progettazione è come prevedere i tempi di recupero e di offerta. La risposta a entrambe le domande può prevedere una soluzione chiamata fattorizzazione del modello.

fattorizzazione del modello

La fattorizzazione dei modelli è una tecnica che consente di suddividere un singolo modello in più parti e poi combinarle in una previsione. Nel caso d'uso dell'installazione di app, i modelli spesso usano tre tipi di dati: dati utente, dati contestuali e dati pubblicitari.

Nel caso dei modelli non fattorizzati, 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 parte utente deve essere eseguito all'interno del confine di attendibilità, sul servizio di inferenza del servizio di offerte dell'acquirente.

Ciò rende possibile il seguente design:

  1. Suddividi il modello in un elemento privato (i dati utente) e in una o più parti non private (dati contestuali e pubblicitari).
  2. Se vuoi, passa alcune o tutte le parti non private come argomenti a una funzione definita dall'utente che deve eseguire previsioni. Ad esempio, gli incorporamenti contestuali vengono passati alle funzioni definite dall'utente in per_buyer_signals.
  3. Facoltativamente, gli ad tech possono creare modelli per parti non private e poi materializzare gli incorporamenti di questi modelli nell'archivio chiave-valore del servizio di recupero degli annunci. Le funzioni definite dall'utente del servizio di recupero annunci possono recuperare questi incorporamenti in fase di runtime.
  4. Per effettuare una previsione durante una funzione definita dall'utente, combina gli incorporamenti privati del servizio di inferenza con incorporamenti non privati provenienti dagli argomenti delle funzioni definite dall'utente o dall'archivio di coppie chiave-valore con un'operazione come un prodotto scalare. Questa è la previsione finale.

Detto ciò, possiamo esaminare ciascuna funzione definita dall'utente in modo più dettagliato. Spiegheremo che cosa fanno, come si integrano e come può fare le previsioni necessarie per scegliere i migliori annunci e calcolare le loro offerte.

La funzione definita dall'utente prepareDataForAdRetrieval()

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

prepareDataForAdRetrieval() prende le seguenti informazioni:

  • Il payload per acquirente ricevuto da getAdSelectionData. Questo payload contiene gli indicatori di app protetti.
  • Gli indicatori di contesto auction_signals (per le informazioni sull'asta) e buyer_signals (per i campi Indicatori degli acquirenti).

prepareDataForAdRetrieval() esegue due operazioni:

  • Caratterizzazione: se è necessaria l'inferenza del tempo di recupero, trasforma gli indicatori in entrata in funzionalità da utilizzare durante le chiamate al servizio di inferenza per ottenere incorporamenti privati per il recupero.
  • Calcola gli incorporamenti privati per il recupero: se sono necessarie previsioni di recupero, esegue la chiamata al servizio di inferenza utilizzando le funzionalità riportate sopra e ottiene un incorporamento privato per le previsioni dei tempi di recupero.

Resi di prepareDataForAdRetrieval():

  • Indicatori dell'app protetti: payload di indicatori curati dalla tecnologia pubblicitaria.
  • Indicatori specifici per le aste: indicatori lato vendite specifici per piattaforma e informazioni contestuali come auction_signals e per_buyer_signals (inclusi gli incorporamenti contestuali) da SelectAdRequest. Questa procedura è simile a Protected Audiences.
  • Indicatori aggiuntivi: informazioni aggiuntive come gli incorporamenti privati recuperati dal servizio di inferenza.

Questa richiesta viene inviata al servizio di recupero annunci, che effettua la corrispondenza con i candidati, quindi esegue la funzione definita dall'utente 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 migliori candidati per l'offerta convertendo la richiesta in una serie di query predefinite, recuperi di dati ed eseguendo una logica di business personalizzata e altre logiche di recupero personalizzate.

getCandidateAds() prende le seguenti informazioni:

  • Indicatori dell'app protetti: payload di indicatori curati dalla tecnologia pubblicitaria.
  • Indicatori specifici per le aste: indicatori lato vendite specifici per piattaforma e informazioni contestuali come auction_signals e per_buyer_signals (inclusi gli incorporamenti contestuali) da SelectAdRequest. Questa procedura è simile a Protected Audiences.
  • Indicatori aggiuntivi: informazioni aggiuntive come gli incorporamenti privati recuperati dal servizio di inferenza.

getCandidateAds():

  1. Recupero di un insieme iniziale di annunci candidati: viene recuperato utilizzando criteri di targeting come lingua, dati geografici, tipo di annuncio, dimensioni dell'annuncio o budget, per filtrare i candidati dell'annuncio.
  2. Recupero dell'incorporamento del recupero: se sono necessari incorporamenti dal servizio chiave-valore per effettuare una previsione del tempo di recupero per la selezione top-k, questi devono essere recuperati dal servizio chiave-valore.
  3. Selezione dei candidati migliori: calcola un punteggio minimo per l'insieme di annunci candidati filtrati in base ai metadati degli annunci recuperati dall'archivio chiave-valore e alle informazioni inviate dal servizio di offerte dell'acquirente, per scegliere i primi k candidati in base a tale punteggio. Ad esempio, il punteggio potrebbe essere la possibilità di installare un'app dopo aver visto l'annuncio.
  4. Recupero dell'incorporamento delle offerte: se il codice delle offerte ha bisogno di incorporamenti dal servizio chiave-valore per fare previsioni al momento delle offerte, questi 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 di punteggio prevede una sorta di fattorizzazione del modello: dato che getCandidateAds() viene eseguito sul servizio di recupero degli annunci e dato che il servizio di recupero degli annunci non dispone di un servizio di inferenza, le previsioni possono essere generate combinando:

  • Incorporamenti contestuali trasferiti utilizzando l'input degli indicatori specifici dell'asta.
  • Incorporamenti privati trasmessi utilizzando l'input di indicatori aggiuntivi.
  • Eventuali incorporamenti non privati vengono materializzati dai propri server nel servizio chiave-valore del servizio di recupero annunci.

Tieni presente che la funzione definita dall'utente generateBid() eseguita sul servizio di offerta dell'acquirente può applicare anche il proprio tipo di fattorizzazione del modello per effettuare le previsioni delle offerte. Per farlo, se 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 è composto da:
    • URL di rendering: endpoint per il rendering della creatività dell'annuncio.
    • Metadati: metadati degli annunci specifici per gli acquirenti e per tecnologia pubblicitaria. Ad esempio, potrebbero essere incluse informazioni sulla campagna pubblicitaria e criteri di targeting come località e lingua. I metadati possono includere incorporamenti facoltativi utilizzati quando è necessaria la scomposizione del modello per eseguire l'inferenza durante l'offerta.
  • Indicatori aggiuntivi: facoltativamente, il servizio di recupero degli annunci può includere informazioni aggiuntive, come incorporamenti aggiuntivi o indicatori di spam da utilizzare in generateBid().

Stiamo studiando altri metodi per fornire gli annunci a cui assegnare un punteggio, tra cui renderli disponibili nell'ambito della chiamata SelectAdRequest. Questi annunci possono essere recuperati utilizzando una richiesta di offerta RTB. Tieni presente che in questi casi, gli annunci devono essere recuperati senza Protected App Signals. Prevediamo che gli ad tech valuteranno i compromessi prima di scegliere l'opzione migliore, tra cui dimensioni del payload di risposta, latenza, costo e disponibilità degli indicatori.

La funzione definita dall'utente generateBid()

Dopo aver recuperato l'insieme di annunci candidati e gli incorporamenti durante il recupero, puoi procedere con l'asta, che viene eseguita nel servizio di offerta dell'acquirente. Questo servizio esegue la funzione definita dall'utente generateBid() fornita dall'acquirente per selezionare l'annuncio per cui fare un'offerta dal top k, poi restituirlo con la relativa offerta.

generateBid() prende le seguenti informazioni:

  • Annunci candidati: i primi k di annunci restituiti dal servizio di recupero degli annunci.
  • Indicatori specifici per le aste: indicatori lato vendite specifici per 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 delle offerte.

L'implementazione generateBid() dell'acquirente esegue tre operazioni:

  • Caratterizzazione: trasforma gli indicatori in funzionalità da usare durante l'inferenza.
  • Inferenza: genera previsioni utilizzando modelli di machine learning per calcolare valori come i tassi di conversione e i clickthrough previsti.
  • Offerte: combinazione di valori dedotti con altri input per calcolare l'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 in modo più dettagliato le funzionalità, l'inferenza e le offerte.

Funzionalità

Gli indicatori delle aste possono essere preparati entro il giorno generateBid() in funzionalità. Queste funzionalità possono essere utilizzate durante l'inferenza per prevedere, ad esempio, i clickthrough e i tassi di conversione. Stiamo anche esplorando meccanismi che tutelano la privacy per trasmetterne alcuni nel report sulle vincite al fine di utilizzarli nell'addestramento del modello.

Inferenza

Durante il calcolo di un'offerta, è frequente eseguire inferenze su uno o più modelli di machine learning. Ad esempio, i calcoli dell'eCPM effettivo spesso usano modelli per prevedere i tassi di clickthrough e di conversione.

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

L'inferenza viene eseguita sul servizio di offerta dell'acquirente. Questo può influenzare la latenza e i costi di inferenza, soprattutto perché gli acceleratori non sono ancora disponibili nei TEE. Alcuni clienti troveranno che le loro esigenze sono soddisfatte con modelli individuali in esecuzione sul servizio di offerta 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 i costi di deduzione e la latenza 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.

Implementare la fattorizzazione del modello

In precedenza abbiamo spiegato la scomposizione del modello. Al momento delle offerte, l'approccio specifico è il seguente:

  1. Suddividi il singolo modello in un dato privato (i dati utente) e una o più parti non private (dati contestuali e pubblicitari).
  2. Trasmetti pezzi non privati a generateBid(). Queste possono provenire da per_buyer_signals o da incorporamenti calcolati esternamente dagli ad tech, che si materializzano nell'archivio chiave-valore del servizio di recupero, recuperano al momento del recupero e ritornano come parte degli indicatori aggiuntivi. Non sono inclusi gli incorporamenti privati, che non possono essere estratti al di fuori dei confini della privacy.
  3. Tra generateBid():
    1. Esegui l'inferenza sui modelli per ottenere incorporamenti di utenti privati.
    2. Combina gli incorporamenti di utenti privati con incorporamenti contestuali di per_buyer_signals o annunci non privati ed incorporamenti contestuali dal servizio di recupero utilizzando un'operazione come un prodotto scalare. Questa è la previsione finale che può essere utilizzata per calcolare le offerte.

Utilizzando questo approccio, è possibile eseguire un'inferenza al momento delle offerte 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, viene assegnato un punteggio agli annunci con offerte ricevute da tutti gli acquirenti partecipanti. L'output di generateBid() viene trasmesso al servizio di aste del venditore per eseguire scoreAd() e scoreAd() prende in considerazione un solo annuncio alla volta. In base al punteggio, il venditore sceglie un annuncio vincente da restituire sul 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 l'installazione di app.La funzione viene chiamata una volta per ogni annuncio candidato inviato nell'asta protetta. Per i dettagli, consulta la sezione Offerte e aste.

Tempo di esecuzione del codice per la selezione degli annunci

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

Reporting

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

Un caso d'uso comune per la generazione di report sul 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 il traffico in uscita 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 incentrate sulla tutela della privacy per affrontare l'addestramento di modelli con dati utilizzati nelle aste protette senza inviare dati utente a livello di evento al di fuori dei servizi in esecuzione sui TEE. Forniremo maggiori dettagli in un aggiornamento successivo.

Nel breve termine, forniremo un modo temporaneo per inviare dati con rumore in uscita da generateBid(). La nostra proposta iniziale in tal senso è riportata di seguito e la svilupperemo (incluse eventuali modifiche incompatibili con le versioni precedenti) in risposta al feedback del settore.

Tecnicamente, funziona:

  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 in base allo schema e applica i limiti di dimensione.
  4. La piattaforma aggiunge rumore al payload in uscita.
  5. Il payload in uscita viene incluso nel report sulle vincite in formato bonifico, ricevuto sui server di ad tech, decodificato e utilizzato per l'addestramento del modello.

Definizione dello schema dei payload in uscita

Affinché la piattaforma possa applicare requisiti di privacy in continua evoluzione, i payload in uscita devono essere strutturati in modo da essere comprensibili alla piattaforma. Gli ad tech definiranno la struttura dei payload in uscita fornendo un file JSON dello schema. Questo schema verrà elaborato dalla piattaforma e rimarrà riservato ai servizi di asta e di asta utilizzando gli stessi meccanismi di altre risorse di tecnologia pubblicitaria come funzioni definite dall'utente e modelli.

Forniremo un file CDDL che definisce la struttura di tale JSON. Il file CDDL includerà un insieme di tipi di funzionalità supportati (ad esempio, caratteristiche booleane, numeri interi, bucket e così via). Verrà eseguito il controllo delle versioni sia del file CDDL sia dello schema fornito.

Ad esempio, un payload in uscita costituito da una singola caratteristica booleana seguita da una funzionalità del bucket di dimensione 2 avrebbe il seguente aspetto:

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

I dettagli sugli insiemi di tipi di funzionalità supportati sono disponibili su GitHub.

Crea payload in uscita in generateBid()

Tutti gli indicatori dell'app protetti per un determinato acquirente sono disponibili per la sua UDF generateBid(). Una volta resi disponibili, i tecnici pubblicitari creano il loro payload in formato JSON. Questo payload in uscita verrà incluso nel report sulle vincite dell'acquirente per la trasmissione ai server di ad tech.

Un'alternativa a questo design è che il calcolo del vettore di uscita venga eseguito in reportWin() anziché in generateBid(). Ogni approccio prevede dei compromessi e finalizziamo questa decisione in risposta al feedback del settore.

Convalidare il payload in uscita

La piattaforma convaliderà qualsiasi payload in uscita creato dall'ad tech. La convalida assicura che i valori delle funzionalità siano validi per i rispettivi tipi, che i limiti di dimensioni siano soddisfatti e che gli utenti 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à automaticamente eliminato dagli input inviati al report sui risultati finali. Questo perché non vogliamo fornire informazioni di debug a utenti malintenzionati che tentano di annullare la convalida.

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

validate(payload, schema)

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

Rumore del payload in uscita

La piattaforma rileverà il rumore dei payload in uscita prima di includerli nel report sui risultati finali. La soglia di rumore iniziale sarà dell'1% e questo valore potrebbe evolversi nel tempo. La piattaforma non fornirà alcuna indicazione sull'eventuale rumore di un particolare payload in uscita.

Il metodo di rumore è:

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

Trasmettere, ricevere e decodificare il payload in uscita per l'addestramento del modello.

Il payload in uscita convalidato con rumore sarà incluso negli argomenti a reportWin() e trasmesso ai server ad tech dell'acquirente al di fuori dei confini della privacy per l'addestramento del modello. Il payload in uscita sarà in formato di rete.

I dettagli sul formato dei cavi per tutti i tipi di funzionalità e per il payload in uscita in sé sono disponibili su GitHub.

Determinare le dimensioni del payload in uscita

La dimensione del payload in uscita in bit bilancia utilità e minimizzazione dei dati. Collaboreremo con il settore per determinare le dimensioni appropriate tramite sperimentazione. Durante l'esecuzione di questi esperimenti, trasferiremo temporaneamente i dati senza limitazioni di dimensione in bit. I dati in uscita aggiuntivi senza limitazioni di dimensione in bit verranno rimossi al termine degli esperimenti.

Il metodo per determinare le dimensioni è:

  1. Inizialmente, supporteremo due payload in uscita in generateBid():
    1. egressPayload: il payload in uscita con dimensioni limitate descritto finora in questo documento. Inizialmente, la dimensione del payload in uscita sarà pari a 0 bit (ovvero verrà sempre rimosso durante la convalida).
    2. temporaryUnlimitedEgressPayload: un payload in uscita temporaneo con dimensione illimitata 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 set di metriche per determinare l'utilità del modello con varie dimensioni di payload in uscita (ad esempio 5, 10 e... bit).
  4. In base ai risultati degli esperimenti, determiniamo la dimensione del payload in uscita con l'utilità corretta e i compromessi in termini di privacy.
  5. Abbiamo impostato la dimensione di egressPayload da 0 bit alla nuova dimensione.
  6. Dopo un periodo di migrazione prestabilito, rimuoviamo temporaryUnlimitedEgressPayload, lasciando solo egressPayload con la nuova dimensione.

Stiamo esaminando ulteriori misure di protezione tecnica per la gestione di questa modifica (ad esempio, criptando egressPayload quando ne aumentiamo le dimensioni da 0 bit). Questi dettagli, insieme alle tempistiche dell'esperimento e della rimozione di temporaryUnlimitedEgressPayload, saranno inclusi in un aggiornamento successivo.

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

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

  1. Determinare l'architettura dei modelli che utilizzeranno con gli indicatori di app protetti. Ad esempio, dovranno determinare se utilizzeranno o meno la fattorizzazione del modello.
  2. Definisci una metrica per misurare la qualità del modello. Le metriche suggerite sono la perdita di AUC e la perdita di log.
  3. Definisci 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, esegui studi sull'ablazione per determinare l'utilità per bit contribuito per ogni modello da utilizzare nel PAS. Il protocollo suggerito per lo studio sull'ablazione è:
    1. Addestra il modello con tutte le caratteristiche e misura l'utilità; questa è la base di riferimento per il confronto.
    2. Per ogni caratteristica utilizzata per produrre la base di riferimento, addestra il modello con tutte le caratteristiche, tranne quella caratteristica.
    3. Misurare l'utilità risultante. Dividi il delta per la dimensione della caratteristica in bit; questa è l'utilità prevista per bit per quella caratteristica.
  5. Determina le dimensioni dei payload di addestramento di interesse per la sperimentazione. Suggeriamo [5, 10, 15, ..., size_of_all_training_features_for_baseline] bit. Ognuna di queste dimensioni rappresenta una possibile dimensione per egressPayload che verrà valutata dall'esperimento.
  6. Per ogni dimensione possibile, seleziona un insieme di caratteristiche minori o uguali alla dimensione che massimizza l'utilità per bit, utilizzando i risultati dello studio sull'ablazione.
  7. Addestra un modello per ogni dimensione possibile e valutane l'utilità come percentuale dell'utilità del modello di riferimento addestrato su tutte le caratteristiche.
  8. Traccia i risultati su un grafico in cui l'asse x corrisponde alla dimensione del carico utile dell'addestramento in bit e l'asse y è la percentuale di entrate generate da quel modello rispetto alla base di riferimento.

Successivamente, le tecnologie pubblicitarie possono ripetere i passaggi 5-8 negli esperimenti sul traffico in tempo reale, utilizzando i dati sulle funzionalità inviati tramite temporaryUnlimitedEgressPayload. Le tecnologie pubblicitarie possono scegliere di condividere i risultati dei loro esperimenti sul traffico offline e in tempo reale con Privacy Sandbox per prendere decisioni più consapevoli sulle dimensioni di egressPayload.

La sequenza temporale di questi esperimenti, così come quella per l'impostazione delle dimensioni di egressPayload sul valore risultante, esula dall'ambito di questo documento e saranno disponibili in un aggiornamento successivo.

Misure di protezione dei dati

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

  1. Verrà emesso un rumore sia di egressPayload sia di temporaryUnlimitedEgressPayload.
  2. Per la minimizzazione e la protezione dei dati, temporaryUnlimitedEgressPayload sarà disponibile solo per la durata degli esperimenti sulle dimensioni, in cui stabiliremo la dimensione corretta per egressPayload.

Autorizzazioni

Controllo utente

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

Autorizzazioni e controllo delle app

La proposta intende fornire alle app il controllo sui relativi indicatori di app protetti:

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

Controllo della piattaforma di tecnologia pubblicitaria

Questa proposta descrive i modi in cui i tecnici pubblicitari possono controllare gli indicatori dell'app protetti:

  • Tutti i tecnici pubblicitari devono registrarsi a Privacy Sandbox e fornire un dominio di "sito" o "origine" che corrisponda a tutti gli URL per gli indicatori dell'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 delegato a un partner, la creazione di indicatori di app protetti può essere configurata in modo da richiedere l'accettazione da parte dell'ad tech.