Servizi di aste e aste

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

Nella proposta iniziale di Protected Audience, le offerte e le aste per la domanda di annunci di remarketing vengono eseguite localmente sul dispositivo. Questo requisito può richiedere requisiti di calcolo che potrebbero non essere pratici da eseguire su dispositivi con potenza di elaborazione limitata o essere troppo lenti per selezionare e visualizzare gli annunci a causa della latenza della rete.

La proposta relativa ai servizi di offerte e aste (B&A) illustra un modo per consentire il calcolo di Protected Audience su server cloud in un ambiente di esecuzione attendibile (TEE), anziché eseguirlo localmente sul dispositivo di un utente. La proposta B&A ha lo scopo di supportare un flusso unificato per la considerazione della 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 larghezza di banda di rete per un dispositivo.

Google fornirà i componenti di B&A, che verranno resi disponibili come open source. Le aziende di tecnologia pubblicitaria interessate possono ospitare le proprie istanze con i fornitori di cloud pubblico supportati. Puoi scoprire di più sulla proposta B&A su GitHub. Tieni presente che le date riportate nel documento riflettono l'implementazione per Chrome e che in futuro pubblicheremo ulteriori informazioni sull'integrazione con Android. Questo documento è un'introduzione alle API di Business& Advertising e alle nuove API di Android che consentiranno di interagire con queste API. Pubblicheremo altre informazioni tecniche su come utilizzare queste nuove API in aggiornamenti futuri.

Il ruolo dei servizi B&A

B&A offre un'opzione aggiuntiva per l'esecuzione di un'asta all'interno di server di proprietà di ad tech di terze parti attendibili che eseguono un file binario open source fornito da Google. I dati utente rimangono sul dispositivo e Google fornirà API per spostarli in modo sicuro nel TEE. Scopri di più sulla nostra strategia di crittografia di seguito.

Ciò significa che alcune parti della procedura di asta vengono eseguite sul dispositivo e altre nel cloud. Dal punto di vista di una 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 quando l'asta viene eseguita sul dispositivo. Dal punto di vista degli SSP, le richieste vengono comunque attivate sul dispositivo e questo documento descrive le nuove API che verranno utilizzate. Per tutte le parti, la generazione del report sul risultato di un'asta inizia sempre dal dispositivo, al termine della chiamata B&A.

La differenza principale riguarda il punto in cui viene eseguita la logica di generazione di URL per offerte, punteggi e report. Invece di eseguire la logica di offerta, asta e generazione di report sul dispositivo, la logica di generateBid(), scoreAd(), reportResult() e reportWin() viene eseguita nel TEE. La logica di offerta di un acquirente e la logica di assegnazione del punteggio di un venditore vengono eseguite nel proprio ambiente B&A, nel mezzo del flusso dell'asta Protected Audience:

Crittografia dei dati

Con B&A, le informazioni di Protected Audience, come i segmenti di pubblico personalizzati e gli importi delle offerte, passano dal dispositivo ai server di tecnologia pubblicitaria del venditore, ai server di tecnologia pubblicitaria dell'acquirente e di nuovo al dispositivo. Per questo motivo, la piattaforma cripta i dati inviati ai servizi Protected Audience e può essere decriptata solo dai servizi che sono stati attestati. Scopri di più sulle strategie di crittografia su GitHub.

Architettura e flusso dell'asta

Questa proposta include la necessità di diversi nuovi componenti descritti su GitHub, incluso il flusso di dati dal dispositivo a B&A.

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

1. Sul dispositivo, i venditori raccolgono le informazioni da Protected Audience utilizzando l'getAdSelectionData API.
2. L'SDK on-device invia una richiesta al servizio pubblicitario del venditore. Questa richiesta include il payload contestuale eProtectedAudienceInput criptato.
3. Il servizio Annunci del venditore invia una richiesta al servizio di offerte in tempo reale (RTB) degli acquirenti in esecuzione al di fuori di un TEE per ottenere annunci contestuali candidati, quindi assegna un punteggio e seleziona un annuncio contestuale vincente.
4. Il servizio Annunci del venditore invia una richiesta al proprio servizio SellerFrontEnd in esecuzione in un TEE.
5. Il servizio SellerFrontEnd invia richieste con dati specifici dell'acquirente ai servizi BuyerFrontEnd.
6. Gli acquirenti utilizzano il proprio servizio Chiave/Valore e il proprio servizio di offerte, che generano offerte per gli annunci candidati provenienti dal dispositivo per tutti i segmenti di pubblico personalizzati presi in considerazione per il remarketing.
7. Il servizio SellerFrontEnd legge il servizio Key/Value e assegna un punteggio agli annunci candidati. Il risultato viene criptato e restituito al servizio Annunci del venditore.
8. Il servizio 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 del servizio annunci del venditore.

Su GitHub è disponibile una descrizione dettagliata di ogni passaggio e di come vengono criptati i dati. Il codice di questi componenti verrà reso disponibile tramite open source. Il codice fornito gestirà la federazione delle richieste dal servizio SellerFrontEnd ai servizi BuyerFrontEnd.

Deployment su cloud

Le tecnologie pubblicitarie implementeranno i servizi di B&A su una piattaforma cloud pubblico supportata. Questi implementazioni devono essere gestite da esperti di tecnologia pubblicitaria che saranno responsabili della definizione di un obiettivo di livello del servizio di disponibilità.

Eseguire un'asta

Il primo passaggio per eseguire l'asta B&A è raccogliere i dati dei segmenti di pubblico personalizzati on-device e criptarli per inviarli alle aste lato server. Per farlo, utilizza l'API getAdSelectionData:

AdSelectionData getAdSelectionData(AdTechIdentifier seller)

Il metodo getAdSelectionData genera l'input richiesto per i componenti di annunci adattabili, come BuyerInput e ProtectedAudienceInput, e cripta i dati prima di rendere il risultato disponibile per il chiamante. Per evitare la fuga di dati tra le app, questi dati contengono informazioni di tutti gli acquirenti presenti sul dispositivo. Scopri di più su questa decisione nella 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.
}

Utilizzando questo AdSelectionData, l'SDK on-device può inviare una richiesta al servizio 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 che consenta di risparmiare spazio, ad esempio inviando la richiesta al servizio annunci del venditore come multipart/form-data.

Una volta avviata la richiesta, il servizio Annunci del venditore la inoltra al servizio SellerFrontEnd in esecuzione in un TEE. Quando configurano un servizio SellerFrontEnd, i venditori forniscono un elenco di indirizzi di dominio che corrispondono ai servizi BuyerFrontEnd gestiti dagli acquirenti con cui il venditore ha stipulato un contratto di partnership. Le richieste verranno federate ai vari servizi BuyerFrontEnd forniti dal venditore, in modo che gli acquirenti possano generare offerte per gli annunci candidati selezionati. Per un acquirente specifico, B&A invierà solo informazioni sui segmenti di pubblico personalizzati di proprietà dell'acquirente, in modo che non si verifichino fughe di dati tra acquirenti. Dopo aver generato le offerte, l'elenco degli annunci candidati viene restituito 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 di nuovo sul dispositivo, la piattaforma offre una seconda nuova API per decriptare il risultato e fornire un AdSelectionOutcome, lo stesso oggetto restituito da un'asta on-device oggi.

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);

Rapporti

Gli URL dei report verranno generati nei servizi B&A. I ping a questi URL per la generazione di report sulle impressioni e sulle interazioni per le aste dovranno comunque essere attivati sul dispositivo. L'SDK on-device dovrà comunque invocare le API reportImpression() e reportInteraction() utilizzando AdSelectionId generato durante il flusso B&A. I beacon generati per la generazione di report sulle interazioni e gli URL corrispondenti sono contenuti nella risposta criptata, pertanto durante la decrittografia della risposta gli eventi e le mappature degli URL vengono memorizzati sul dispositivo.

Considerazioni sulla privacy

La proposta dell'API Browser Bidding & Auction 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 viene criptato per garantire che i dati in transito siano accessibili solo a PPAPI e ai server attendibili. Per ridurre il rischio di fuga di dati a causa delle modifiche delle dimensioni del adSelectionData, prevediamo di generare lo stesso adSelectionData per tutte le chiamate all'API getAdSelectionData. Ciò implica che tutti i CustomAudience sul dispositivo vengono utilizzati per creare adSelectionData. Inoltre, abbiamo intenzione di limitare l'influenza dei parametri di input GetAdSelectionData sul valore adSelectionData generato.

La generazione dello stesso adSelectionData per tutte le tecnologie pubblicitarie che utilizzano tutti i dati delle aste on-device comporta un payload più elevato da trasferire in ogni chiamata al server della tecnologia pubblicitaria, aprendo al contempo potenzialmente l'ecosistema a abusi da parte di entità dannose. Questi problemi sono affrontati nelle sezioni Considerazioni sul volume e Considerazioni anti-abuso di seguito.

Considerazioni sulle dimensioni

L'SDK client ad tech deve pacchettizzare i byte criptati di adSelectionData in una chiamata per gli annunci contestuali effettuata al server del venditore. Per un rendimento ottimale, è importante ottimizzare le dimensioni diadSelectionData senza comprometterne la funzionalità. Prevediamo di introdurre ottimizzazioni come indicato nell'articolo di approfondimento sull'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 di rendering dell'annuncio e i metadati. Le tecnologie pubblicitarie possono ottimizzare ulteriormente questo aspetto non inviando i dati degli annunci in adSelectionData. Questa opzione sarà supportata in CustomAudience API nelle release future.
2. Assicurati che i user_bidding_signals non vengano inviati in adSelectionData. I fornitori di tecnologia pubblicitaria possono invece recuperare user_bidding_signals dal proprio server Key/Value.
3. Consenti agli acquirenti di dare la priorità a CustomAudience.
4. Consenti all'acquirente di specificare la priorità del venditore.
5. Genera adSelectionData in alcuni bucket fissi per limitare la perdita di bit e ridurre al contempo le dimensioni del payload.

Le ottimizzazioni delle dimensioni verranno apportate nel rispetto dei dubbi sollevati nelle considerazioni sulla privacy.

Considerazioni anti-abuso

Come indicato in Considerazioni sulla privacy, adSelectionData viene generato utilizzando tutti i dati dell'acquirente sul dispositivo.

Ciò apre l'ecosistema a potenziali entità dannose che potrebbero aggiungere dati fraudolenti degli acquirenti che potrebbero peggiorare il rendimento, aumentare il volume dei payload per aumentare i costi e così via.

Per combattere gli abusi di adSelectionData, introdurremo le seguenti misure

• Consenti a CustomAudience di specificare esplicitamente i venditori approvati e la priorità del venditore
• Consentire alle SSP di specificare esplicitamente acquirente, priorità dell'acquirente e quota per acquirente nel payload generato
• Fornire un meccanismo per consentire alle SSP di definire un numero massimo di acquirenti per chiamata o la dimensione massima per acquirente.

Queste misure sono progettate per consentire alle tecnologie pubblicitarie di definire con quali altre tecnologie pubblicitarie collaborano e di impostare limiti accettabili per il adSelectionData payload da elaborare. Proponiamo di consentire al venditore di specificare questo elenco di acquirenti e la relativa 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 sopra menzionate sono in discussione e soggette a evolversi nel tempo. Come accennato in precedenza, tutte le misure di mitigazione introdotte per le limitazioni anti-abuso e di dimensione devono rispettare le considerazioni sulla privacy.