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 essere impraticabili da eseguire 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 relativa ai servizi di offerte e aste (B&A) illustra un modo per consentire l'esecuzione del calcolo di Protected Audience su server cloud in un Trusted Execution Environment (TEE), anziché localmente sul dispositivo di un utente. La proposta B&A mira a supportare un flusso unificato per prendere in considerazione 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 larghezza di banda di rete per un dispositivo.

Google fornirà i componenti di B&A, che saranno disponibili come open source. Le tecnologie pubblicitarie interessate possono ospitare le proprie istanze con i fornitori di cloud pubblico supportati. Puoi leggere di più sulla proposta di B&A su GitHub. Tieni presente che le date indicate in questo documento riflettono l'implementazione per Chrome e in futuro pubblicheremo ulteriori informazioni sull'integrazione con Android. Questo documento funge da introduzione a B&A e alle nuove API che Android fornirà per interagire con B&A. Pubblicheremo ulteriori informazioni tecniche su come utilizzare queste nuove API nei futuri aggiornamenti.

Il ruolo dei servizi di pubblicità e analisi

B&A offre un'opzione aggiuntiva per eseguire un'asta all'interno di server di tecnologia pubblicitaria di proprietà affidabili che eseguono un binario open source fornito da Google. I dati utente rimangono sul dispositivo e Google fornirà API per spostarli in modo sicuro nel TEE. Di seguito trovi maggiori informazioni sulla nostra strategia di crittografia.

Ciò significa che alcune parti della procedura di asta vengono eseguite sul dispositivo, mentre 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 ancora gestiti sul dispositivo utilizzando le stesse API di gestione dei segmenti di pubblico personalizzati di quando l'asta viene eseguita sul dispositivo. Dal punto di vista di una SSP, le richieste vengono comunque attivate sul dispositivo e questo documento descrive le nuove API che verranno utilizzate. Per tutte le parti, la segnalazione del risultato di un'asta inizia comunque dal dispositivo, dopo il completamento della chiamata B&A.

La differenza principale riguarda il punto in cui viene eseguita la logica di generazione dell'URL di offerta, punteggio e report. Invece di eseguire la logica di offerta, asta e report sul dispositivo, la logica di generateBid(), scoreAd(), reportResult() e reportWin() viene eseguita nell'ambiente di esecuzione attendibile. La logica di offerta di un acquirente e la logica di assegnazione del punteggio di un venditore vengono eseguite nel proprio ambiente B&A, al centro 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, vengono trasferite dal dispositivo ai server ad tech del venditore, ai server ad tech 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 in dettaglio 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 informazioni da Protected Audience utilizzando l'API getAdSelectionData.
2. L'SDK sul dispositivo invia una richiesta al proprio servizio annunci del venditore. Questa richiesta include il payload contestuale e ProtectedAudienceInput criptato.
3. Il servizio Annuncio 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 Annuncio 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 servizio di offerta, che genera offerte per i candidati annuncio provenienti dal dispositivo per tutti i segmenti di pubblico personalizzati presi in considerazione per il remarketing.
7. Il servizio SellerFrontEnd legge dal servizio Key/Value e assegna un punteggio agli annunci candidati. Il risultato viene criptato e restituito al servizio Annunci del venditore.
8. Il servizio Annuncio del venditore restituisce il risultato vincente criptato e, facoltativamente, un risultato contestuale all'SDK sul dispositivo.
9. Sul dispositivo, i venditori recuperano l'annuncio vincente utilizzando l'API processAdSelectionResult, che decripta la risposta del servizio Annunci del venditore.

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

Deployment cloud

Le tecnologie pubblicitarie implementeranno i servizi B&A in una piattaforma cloud pubblico supportata. Questi deployment devono essere gestiti da ad tech che saranno responsabili della definizione di un obiettivo di livello di servizio di disponibilità.

Eseguire un'asta

Il primo passaggio per eseguire l'asta B&A consiste nel raccogliere i dati dai 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 B&A, come BuyerInput e ProtectedAudienceInput, e cripta i dati prima di rendere disponibile il risultato al chiamante. Per evitare la perdita 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 Seller Ads 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, ad esempio inviando la richiesta al servizio Seller Ads come multipart/form-data.

Una volta avviata la richiesta, il servizio Seller Ad 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 stretto una partnership. Le richieste verranno federate ai vari servizi BuyerFrontEnd forniti dal venditore, in modo che gli acquirenti possano generare offerte per i candidati annuncio selezionati. Per un acquirente specifico, B&A invierà solo informazioni sui segmenti di pubblico personalizzati di proprietà dell'acquirente, in modo da evitare la fuoriuscita di dati tra gli acquirenti. Dopo aver generato le offerte, l'elenco degli annunci 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 Annunci del venditore 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 registrare impressioni e interazioni per le aste dovranno comunque essere attivati sul dispositivo. L'SDK on-device dovrà comunque richiamare le API reportImpression() e reportInteraction() utilizzando AdSelectionId generato durante il flusso di verifica e autenticazione. I beacon generati per la reportistica sulle interazioni e gli URL corrispondenti sono contenuti nella risposta criptata, quindi durante la decriptazione della risposta gli eventi e i mapping degli URL vengono memorizzati sul dispositivo.

Considerazioni sulla privacy

La proposta di API per le aste e le offerte del browser su GitHub descrive in che modo sono state prese in considerazione le questioni relative alla 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 a PPAPI e ai server attendibili. Per ridurre il rischio di fuga di dati a causa di modifiche alle dimensioni di 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. Prevediamo inoltre di limitare l'influenza dei parametri di input GetAdSelectionData sui adSelectionData generati.

La generazione dello stesso adSelectionData per tutte le tecnologie pubblicitarie che utilizzano tutti i dati dell'asta sul dispositivo comporta un payload più elevato che deve essere trasferito in ogni chiamata al server della tecnologia pubblicitaria, aprendo potenzialmente l'ecosistema ad abusi da parte di entità malintenzionate. Queste preoccupazioni sono affrontate nelle sezioni Considerazioni sulle dimensioni e Considerazioni sull'anti-abuso.

Considerazioni sulle dimensioni

L'SDK client di tecnologia pubblicitaria dovrebbe includere 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 di adSelectionData senza compromettere la funzionalità. Prevediamo di introdurre ottimizzazioni come indicato nella spiegazione 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 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 versioni future.
2. Assicurati che user_bidding_signals non vengano inviati in adSelectionData. Invece, le tecnologie pubblicitarie possono recuperare user_bidding_signals dal proprio server chiave/valore.
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 le dimensioni del payload.

Le ottimizzazioni delle dimensioni verranno apportate rispettando i problemi 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.

In questo modo, l'ecosistema si apre a potenziali entità dannose che potrebbero aggiungere dati fraudolenti degli acquirenti che potrebbero compromettere il rendimento, 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à del venditore
• Consenti alle SSP di specificare esplicitamente l'acquirente, la priorità dell'acquirente e la quota per acquirente nel payload generato
• Fornisci un meccanismo per consentire alle SSP di definire un numero massimo di acquirenti per chiamata o una 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 payload adSelectionData che devono elaborare. Proponiamo di consentire al venditore di specificare questo elenco di acquirenti e la priorità in una chiamata separata. Questa specifica rimarrà costante per un determinato periodo di tempo per evitare di esporre dati aggiuntivi sull'utente tramite chiamate ripetute.

Queste misure di mitigazione sono in fase di discussione e sono soggette a evoluzione nel tempo. Come accennato in precedenza, tutte le misure di mitigazione introdotte per le limitazioni relative ad abusi e dimensioni devono rispettare le considerazioni sulla privacy.