Nella proposta iniziale di Protected Audience, le offerte e l'asta per la domanda di annunci di remarketing vengono eseguite localmente sul dispositivo. Questo requisito può richiedere requisiti di calcolo che potrebbero non essere attuabili su dispositivi con potenza di elaborazione limitata o potrebbero essere troppo lenti per selezionare e visualizzare gli annunci a causa della latenza di rete.
La proposta di servizi di asta e aste (B&A) delinea un modo per consentire che il calcolo di Protected Audience avvenga su server cloud in un ambiente di esecuzione affidabile (TEE), anziché in locale sul dispositivo di un utente. La proposta B&A mira a supportare un flusso unificato per considerare la domanda di annunci contestuali e di remarketing. Il trasferimento del calcolo ai server può contribuire a ottimizzare l'asta Protected Audience liberando cicli di calcolo e la larghezza di banda della rete per un dispositivo.
Google fornirà i componenti di B&A, che saranno resi disponibili come open source. Le tecnologie pubblicitarie interessate possono ospitare le proprie istanze con i provider di servizi cloud pubblici supportati. Puoi scoprire di più sulla proposta B&A su GitHub. Tieni presente che le date presentate nel documento riflettono l'implementazione per Chrome e in futuro pubblicheremo ulteriori informazioni sull'integrazione con Android. Questo documento serve da introduzione alla B&A e le nuove API che Android metterà a disposizione. Pubblicheremo ulteriori informazioni tecniche su come utilizzare queste nuove API nei prossimi aggiornamenti.
Dove si integrano i servizi B&A
B&A offre un'opzione aggiuntiva per eseguire un'asta all'interno di server attendibili di proprietà di ad tech che eseguono un programma binario open source fornito da Google. I dati utente sono ancora presenti sul dispositivo e Google fornirà le API per spostare in sicurezza questi dati nel TEE. Scopri di più sulla nostra strategia di crittografia di seguito.
Ciò significa che alcune parti del processo di asta avvengono sul dispositivo, altre nel cloud. Dal punto di vista di DSP, i segmenti di pubblico personalizzati (inclusi gli annunci candidati per le campagne di remarketing) vengono comunque gestiti sul dispositivo utilizzando le stesse API di gestione dei segmenti di pubblico personalizzati utilizzate per l'esecuzione dell'asta sul dispositivo. Dal punto di vista delle SSP, le richieste vengono comunque attivate sul dispositivo e questo documento descrive le nuove API che verranno utilizzate. Per tutte le parti, la registrazione del risultato di un'asta inizia comunque sul dispositivo, una volta completata la chiamata B&A.
La differenza principale riguarda il luogo in cui viene eseguita la logica di generazione degli URL per offerte, punteggio e report. Anziché eseguire sul dispositivo la logica di offerta, asta e generazione di report, nel TEE viene eseguita la logica generateBid()
, scoreAd()
, reportResult()
e reportWin()
. La logica di offerta di un acquirente e la logica di punteggio del venditore vengono eseguite all'interno del proprio ambiente B&A, nel bel mezzo del flusso di asta di Protected Audience:
Crittografia dei dati
Con B&A, le informazioni su Protected Audience, come i segmenti di pubblico personalizzati e gli importi delle offerte, passano dal dispositivo, attraverso i server ad tech del venditore, ai server di tecnologia pubblicitaria degli acquirenti e tornano al dispositivo. Per questo motivo, la piattaforma cripta i dati indirizzati ai servizi Protected Audience e può essere decriptata solo dai servizi attestati. Scopri di più sulle strategie di crittografia su GitHub.
Architettura e flusso delle aste
Questa proposta include la necessità di diversi nuovi componenti descritti in dettaglio su GitHub, incluso il flusso di dati dal dispositivo alla B&A.
A livello generale, il flusso di dati è descritto come segue:
- Sul dispositivo, i venditori raccolgono informazioni da Protected Audience utilizzando l'API
getAdSelectionData
. - L'SDK on-device invia una richiesta al servizio pubblicitario del venditore. Questa richiesta include payload contestuale e
ProtectedAudienceInput
criptato. - Il servizio di annunci del venditore invia una richiesta al servizio di offerte in tempo reale (RTB) degli acquirenti, eseguito al di fuori di un TEE, per ottenere annunci contestuali dei candidati, poi assegna un punteggio e seleziona un annuncio contestuale vincente.
- Il servizio di annunci del venditore invia una richiesta al servizio SellerFrontEnd in esecuzione in un TEE.
- Il servizio SellerFrontEnd invia richieste con dati specifici dell'acquirente ai servizi BuyersFrontEnd.
- Gli acquirenti utilizzano il proprio servizio chiave/valore e il servizio offerte, che genera offerte per i candidati dell'annuncio provenienti dal dispositivo per tutti i segmenti di pubblico personalizzati presi in considerazione per il remarketing.
- Il servizio SellerFrontEnd legge dal proprio servizio chiave/valore e assegna un punteggio agli annunci candidati. Il risultato viene criptato e restituito al servizio Annunci del venditore.
- Il servizio di annunci del venditore restituisce il risultato vincente criptato e, facoltativamente, un risultato contestuale all'SDK on-device.
- Sul dispositivo, i venditori recuperano l'annuncio vincente utilizzando l'API
processAdSelectionResult
, che decripta la risposta dal servizio pubblicitario del venditore.
Una descrizione dettagliata di ogni passaggio e di come vengono criptati i dati è disponibile su GitHub. Il codice per questi componenti sarà reso disponibile tramite open source. Il codice fornito gestirà la federazione delle richieste dal servizio SellerFrontEnd ai servizi BuyersFrontEnd.
Deployment Cloud
Gli ad tech eseguono il deployment di servizi B&A su una piattaforma cloud pubblica supportata. Questi deployment devono essere gestiti da ad tech, che saranno responsabili della definizione di un obiettivo del livello di servizio di disponibilità.
Esecuzione di un'asta
Il primo passaggio per eseguire un'asta B&A consiste nel raccogliere i dati dai segmenti di pubblico personalizzati on-device e criptarli per essere inviati alle aste lato server. A questo scopo, utilizza l'API getAdSelectionData
:
AdSelectionData getAdSelectionData(AdTechIdentifier seller)
Il metodo getAdSelectionData
genera l'input richiesto per i componenti B&A,
come BuyerInput
e
ProtectedAudienceInput
, e cripta i dati prima di renderli
disponibili al chiamante. Per evitare fughe di dati tra le app, questi dati contengono informazioni di tutti gli acquirenti presenti sul dispositivo. Per ulteriori informazioni su questa decisione, consulta la sezione Considerazioni sulla privacy.
Questa API restituisce un oggetto AdSelectionData
:
class AdSelectionData {
long adSelectionId // Unique identifier for the auction.
byte[] data // Encrypted bytes containing data sourced from
// on device custom audiences; will
// be used as the payload to B&A.
}
Con questo AdSelectionData
, l'SDK on-device può inviare una richiesta al servizio di annunci del venditore includendo i dati in una richiesta POST o PUT:
fetch('https://www.example-ssp.com/auction', {
method: "PUT",
body: data,
…
})
L'SDK on-device è responsabile della codifica di questi dati. Ti consigliamo di
utilizzare una soluzione efficiente in termini di spazio, come inviare la richiesta al servizio di annunci del venditore come
multipart/form-data
.
Una volta avviata la richiesta, il servizio di annunci del venditore inoltra la richiesta al servizio SellerFrontEnd eseguito in un TEE. Quando configuri un servizio SellerFrontEnd, i venditori forniranno un elenco di indirizzi di dominio corrispondenti ai servizi BuyersFrontEnd gestiti dagli acquirenti con cui il venditore è partner. Le richieste saranno federate ai vari servizi BuyersFrontEnd forniti dal venditore, in modo che gli acquirenti possano generare offerte per i candidati degli annunci selezionati. Per un acquirente specifico, B&A invia solo informazioni sui segmenti di pubblico personalizzati di proprietà dell'acquirente, in modo che non avvengano cross-leaking di dati tra gli acquirenti. Dopo aver generato le offerte, l'elenco degli annunci dei candidati torna al servizio SellerFrontEnd, dove viene selezionato un vincitore. Infine, il servizio SellerFrontEnd restituisce l'annuncio vincente criptato al dispositivo.
Con la risposta della richiesta al servizio di annunci del venditore sul dispositivo, la piattaforma offre una seconda nuova API per decriptare il risultato e fornire un AdSelectionOutcome
, lo stesso oggetto che viene restituito oggi da un'asta on-device.
PersistAdSelectionResultRequest {
AdSelectionId id // Same ID returned from initial getAdSelectionData call.
AdTechIdentifier seller // Used for enrollment checks.
byte[] adSelectionionResult // The result of the network call to Seller Ad
// service/B&A.
}
persistAdSelectionResult(persistAdSelectionResultRequest);
Report
Gli URL dei report verranno generati nei servizi B&A. I ping a questi URL per generare report sulle impressioni e sulle interazioni per le aste dovranno comunque essere attivati sul dispositivo. L'SDK on-device dovrà comunque richiamare le API
reportImpression()
e reportInteraction()
utilizzando
AdSelectionId
generati durante il flusso B&A. I beacon generati per i report sulle interazioni e gli URL corrispondenti sono contenuti nella risposta criptata, quindi durante la decrittografia della risposta gli eventi e le mappature degli URL vengono archiviati sul dispositivo.
Considerazioni sulla privacy
La proposta di Offerte del browser e API dell'asta su GitHub descrive come sono state prese in considerazione le considerazioni sulla privacy. Questa proposta utilizza la nomenclatura di Chrome, ma gli stessi principi si applicano ad Android.
adSelectionData
è criptato per garantire che i dati in transito siano accessibili solo
alla PPAPI e ai server attendibili. Per ridurre il rischio di fuga di dati dovuta alle
modifiche alle dimensioni di adSelectionData
, prevediamo di generare lo stesso adSelectionData
per tutte le chiamate all'API getAdSelectionData
. Ciò significa che tutti gli CustomAudience
sul dispositivo vengono utilizzati per creare adSelectionData
. Prevediamo inoltre di limitare l'influenza dei parametri di input GetAdSelectionData
sui adSelectionData
generati.
La generazione dello stesso adSelectionData
per tutte le tecnologie pubblicitarie utilizzando tutti i dati delle aste on-device comporta un payload più elevato che deve essere trasferito in ogni chiamata al server di tecnologia pubblicitaria, aprendo potenzialmente l'ecosistema all'utilizzo illecito di entità dannose. Questi problemi vengono affrontati nelle sezioni Considerazioni sulle
dimensioni e Considerazioni anti-abuso di seguito.
Considerazioni sulle dimensioni
L'SDK del client ad tech dovrebbe pacchettizzare i byte criptati di adSelectionData
in una chiamata per annunci contestuali indirizzati al server del venditore.
Per prestazioni ottimali, è importante ottimizzare le dimensioni di
adSelectionData
senza compromettere la funzionalità. Prevediamo di introdurre le ottimizzazioni come menzionato nel spiegatore dell'ottimizzazione del payload per ridurre le dimensioni di adSelectionData
. Queste ottimizzazioni
includeranno:
- Aggiunta di
ad_render_id
inCustomAudience
in modo che venga inviato utilizzandoadSelectionData
anziché l'URI e i metadati del rendering dell'annuncio. Gli ad tech possono ottimizzare ulteriormente questo aspetto non inviando dati pubblicitari inadSelectionData
. Questa opzione sarà supportata inCustomAudience API
nelle release future. - Assicurati che non vengano inviati
user_bidding_signals
inadSelectionData
. Le tecnologie pubblicitarie possono invece recuperareuser_bidding_signals
dal proprio server chiave/valore. - Consenti agli acquirenti di assegnare la priorità a
CustomAudience
. - Consenti all'acquirente di specificare la priorità del venditore.
- Genera
adSelectionData
in pochi bucket fissi per limitare la perdita di bit, riducendo al contempo le dimensioni del payload.
Le ottimizzazioni delle dimensioni verranno ottimizzate nel rispetto delle preoccupazioni sollevate in relazione alla privacy.
Considerazioni anti-abuso
Come menzionato nelle considerazioni sulla privacy, il valore adSelectionData
viene generato utilizzando
tutti i dati dell'acquirente sul dispositivo.
Questo apre l'ecosistema a potenziali entità dannose che potrebbero aggiungere dati fraudolenti sull'acquirente che potrebbero ridurre le prestazioni, gonfiare i payload per aumentare i costi e così via.
Per contrastare l'abuso di adSelectionData
, introdurremo le seguenti misure
- Consenti a
CustomAudience
di specificare esplicitamente i venditori approvati e la priorità dei venditori - Consentire alle SSP di specificare esplicitamente la quota per acquirente, priorità acquirente e per acquirente nel payload generato
- Fornire un meccanismo per le SSP di definire un numero massimo di acquirenti per chiamata o la dimensione massima per acquirente.
Queste misure sono progettate per consentire agli ad tech di definire con quali altre tecnologie pubblicitarie collaborare e di impostare limiti accettabili sul payload di adSelectionData
da elaborare. Proponiamo di consentire al venditore di specificare
l'elenco acquirenti e la priorità in una chiamata separata. Questa specifica sarà
costante per un determinato intervallo di tempo per evitare di esporre dati aggiuntivi
sull'utente tramite chiamate ripetute.
Le misure di mitigazione menzionate sopra sono in fase di discussione e soggette a evoluzione nel tempo. Come accennato in precedenza, tutte le misure di mitigazione introdotte per le restrizioni contro i comportamenti illeciti e le dimensioni devono rispettare le considerazioni sulla privacy.