Servizi di aste e aste

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:

Illustrazione che mostra il flusso dell'asta di Protected Audience e dove si adattano le offerte e l'asta.
Flusso di aste 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.

Illustrazione che mostra il flusso unificato di asta per segmento di pubblico contestuale e protetto, descritto di seguito.
Flusso di asta unificato contestuale e protetto, con servizi per offerte e aste.

A livello generale, il flusso di dati è descritto come segue:

  1. Sul dispositivo, i venditori raccolgono informazioni da Protected Audience utilizzando l'API getAdSelectionData.
  2. L'SDK on-device invia una richiesta al servizio pubblicitario del venditore. Questa richiesta include payload contestuale e ProtectedAudienceInput criptato.
  3. 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.
  4. Il servizio di annunci del venditore invia una richiesta al servizio SellerFrontEnd in esecuzione in un TEE.
  5. Il servizio SellerFrontEnd invia richieste con dati specifici dell'acquirente ai servizi BuyersFrontEnd.
  6. 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.
  7. 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.
  8. Il servizio di annunci del venditore restituisce il risultato vincente criptato e, facoltativamente, un risultato contestuale all'SDK on-device.
  9. 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:

  1. Aggiunta di ad_render_id in CustomAudience in modo che venga inviato utilizzando adSelectionData anziché l'URI e i metadati del rendering dell'annuncio. Gli ad tech possono ottimizzare ulteriormente questo aspetto non inviando dati pubblicitari in adSelectionData. Questa opzione sarà supportata in CustomAudience API nelle release future.
  2. Assicurati che non vengano inviati user_bidding_signals in adSelectionData. Le tecnologie pubblicitarie possono invece recuperare user_bidding_signals dal proprio server chiave/valore.
  3. Consenti agli acquirenti di assegnare la priorità a CustomAudience.
  4. Consenti all'acquirente di specificare la priorità del venditore.
  5. 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.