Servizi di aste e aste

Nella proposta iniziale di Protected Audience, offerte e asta per la domanda di annunci di remarketing viene eseguita localmente sul dispositivo. Questo requisito può richiedere requisiti di calcolo che potrebbero non essere pratici da eseguire su dispositivi potenza di elaborazione limitata o potrebbe essere troppo lenta per selezionare e visualizzare gli annunci a causa di latenza di rete.

La proposta relativa ai servizi di offerte e aste delinea un modo per consentire il calcolo di Protected Audience da eseguire sui server cloud in un ambiente dell'ambiente di esecuzione (TEE), anziché eseguire localmente sul dispositivo di un utente. La La proposta di B&A mira a supportare un flusso unificato per prendere in considerazione domanda di annunci di remarketing. Spostare il calcolo sui server può aiutare a ottimizzare Protected Audience liberando cicli di calcolo e reti per un dispositivo.

Google fornirà i componenti del B&A, che saranno resi disponibili come open source. I tecnici pubblicitari interessati possono ospitare le proprie istanze con strumenti con i provider cloud pubblici. Puoi leggere ulteriori informazioni sulla proposta B&A su GitHub. Tieni presente che le date presentate in questo documento riflettono implementazione per Chrome e pubblicheremo maggiori informazioni su con Android in futuro. Il presente documento funge da introduzione a B&A e le nuove API fornite da Android per interagire con B&A. Pubblicheremo informazioni più tecniche sull'utilizzo di queste nuove API negli aggiornamenti futuri.

Dove si trovano i servizi B&A

B&A offre un'opzione aggiuntiva per eseguire un'asta all'interno di una tecnologia pubblicitaria server attendibili che eseguono un programma binario open source fornito da Google. Dati utente è ancora presente sul dispositivo e Google fornirà le API per al TEE. Scopri di più sulla nostra strategia di crittografia di seguito.

Ciò significa che alcune parti della procedura di asta avvengono sul dispositivo, mentre altre nel cloud. Dal punto di vista della DSP, i segmenti di pubblico personalizzati (inclusi annunci candidati) per le campagne di remarketing) siano comunque gestite sul dispositivo con lo stesso le API di gestione dei segmenti di pubblico come quando l'asta viene eseguita sul dispositivo. Da un 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 segnalazione il risultato di un'asta inizia comunque dal dispositivo al termine della chiamata B&A.

La differenza principale risiede nel punto in cui l'URL per offerte, punteggi e report viene eseguita una logica di generazione. Invece di eseguire offerte, aste e report logica sul dispositivo, generateBid(), scoreAd(), reportResult() e La logica reportWin() viene eseguita nel TEE. La logica di offerta di un acquirente e la viene eseguita all'interno del proprio ambiente B&A, nel mezzo Flusso dell'asta Protected Audience:

Crittografia dei dati

Con B&A, le informazioni su Protected Audience, come segmenti di pubblico personalizzati e offerte gli importi fluiscono dal dispositivo, tramite i server ad tech del venditore, alla tecnologia pubblicitaria dell'acquirente tra i server web, per poi tornare al dispositivo. Per questo motivo, la piattaforma cripta inviati ai servizi Protected Audience e possono essere decriptati solo e i servizi che sono stati attestati. Scopri di più sulle strategie di crittografia su GitHub.

Architettura e flusso delle aste

Questa proposta prevede la necessità di diversi nuovi componenti descritti in dettaglio 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 la sezione API getAdSelectionData.
2. L'SDK on-device invia una richiesta all'annuncio venditore Google Cloud. Questa richiesta include payload contestuale ProtectedAudienceInput criptato.
3. Il servizio di annunci del venditore invia una richiesta all'acquirente offerte in tempo reale (RTB) in esecuzione al di fuori di un TEE per ottenere annunci contestuali candidati, quindi e selezionare un annuncio contestuale vincente.
4. Il servizio annunci del venditore invia una richiesta al proprio SellerFrontEnd in esecuzione in un TEE.
5. Il servizio SellerFrontEnd invia richieste con dati specifici dell'acquirente a Servizi di buyerFrontEnd.
6. Gli acquirenti utilizzano il proprio servizio chiave/valore e offerte , che genera offerte per i candidati di annunci provenienti da il dispositivo per tutti i segmenti di pubblico personalizzati presi in considerazione per il remarketing.
7. Il servizio SellerFrontEnd legge il proprio codice/valore Google Cloud e assegna un punteggio agli annunci candidati. Il risultato è criptato e tornare al servizio Annunci del venditore.
8. Il servizio di annunci del venditore restituisce il risultato criptato vincente e, facoltativamente, un risultato contestuale all'SDK on-device.
9. Sul dispositivo, i venditori recuperano l'annuncio vincente utilizzando API processAdSelectionResult, che decripta la risposta dall'annuncio del venditore completamente gestito di Google Cloud.

Una descrizione dettagliata di ogni passaggio e della modalità di crittografia dei dati 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 BuyerFrontEnd.

Deployment Cloud

Il team ad tech eseguirà il deployment dei servizi B&A su un cloud pubblico supportato completamente gestita. Questi deployment devono essere gestiti da tecnici pubblicitari che sarà responsabile della definizione di un obiettivo del livello del servizio di disponibilità.

Eseguire un'asta

Il primo passaggio per eseguire l'asta B&A è raccogliere i dati dal dispositivo segmenti di pubblico personalizzati e criptarli per essere inviati alle aste lato server. Da fare 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 effettuare il risultato disponibile per il chiamante. Per evitare fughe di dati tra le app, 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.
}

Con questo AdSelectionData, l'SDK on-device può inviare una richiesta al suo 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. È consigliabile Utilizzare una soluzione efficiente nello spazio, ad esempio inviare la richiesta all'annuncio del venditore servizio come multipart/form-data.

Una volta avviata la richiesta, il servizio di annunci del venditore inoltra la richiesta al Servizio SellerFrontEnd in esecuzione in un TEE. Quando configuri un SellerFrontEnd servizio, i venditori forniranno un elenco di indirizzi di dominio che corrispondono ai servizi BuyerFrontEnd gestiti dagli acquirenti che il venditore con cui collabora. Le richieste saranno federate con i vari buyerFrontEnd, forniti dal venditore, per consentire agli acquirenti di generare offerte per i candidati selezionati. Per uno specifico acquirente, B&A invia solo informazioni sui segmenti di pubblico personalizzati di proprietà dell'acquirente, in modo che fuga di dati incrociata tra acquirenti. Dopo aver generato le offerte, l'elenco gli annunci candidati tornano al servizio SellerFrontEnd dove un vincitore selezionato. Infine, il servizio SellerFrontEnd restituisce l'annuncio vincente criptato al dispositivo.

Una volta ricevuta sul dispositivo la risposta alla richiesta al servizio di annunci del venditore, la piattaforma offre una seconda nuova API per decriptare il risultato e fornire AdSelectionOutcome, lo stesso oggetto restituito da un'asta on-device oggi stesso.

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. Invia ping a questi URL per le impressioni dei report e le interazioni per le aste devono essere attivata sul dispositivo. L'SDK on-device dovrà comunque richiamare API di reportImpression() e reportInteraction() utilizzando AdSelectionId generati durante il flusso B&A. Beacon generati per report sulle interazioni e i corrispondenti URL sono contenuti nel risposta criptata. In questo modo, durante la decrittografia della risposta gli eventi e l'URL vengono memorizzate sul dispositivo.

Considerazioni sulla privacy

Le offerte per il browser e La proposta dell'API Asta su GitHub descrive il modo in cui sono state considerate le considerazioni sulla privacy. Questa proposta utilizza la ma gli stessi principi valgono per 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 dovuta a: adSelectionData modifiche alle dimensioni, prevediamo di generare lo stesso adSelectionData per tutte le chiamate all'API getAdSelectionData. Ciò implica che tutte le CustomAudience sul dispositivo vengono utilizzati per creare adSelectionData. Abbiamo anche intendiamo limitare l'influenza di GetAdSelectionData parametri di input Generazione di adSelectionData completata.

Generazione dello stesso adSelectionData per tutte le tecnologie pubblicitarie utilizzando tutte le tecnologie on-device delle aste porta a un carico utile maggiore che deve essere trasferito chiamata al server ad tech, aprendo potenzialmente l'ecosistema a comportamenti illeciti da entità dannose. Questi problemi vengono risolti nella sezione Considerazioni contro i comportamenti illeciti e Considerazioni anti-abuso di seguito.

Considerazioni sulle dimensioni

L'SDK del client ad tech dovrebbe pacchettizzare i byte criptati dei adSelectionData in una chiamata per annunci contestuali effettuata al server del venditore. Per ottenere prestazioni ottimali, è importante ottimizzare le dimensioni adSelectionData senza compromettere la funzionalità. Prevediamo di introdurre ottimizzazioni come indicato nella sezione Ottimizzazione del payload esplicativo per ridurre le dimensioni di adSelectionData. Queste ottimizzazioni includerà:

1. Aggiunta di ad_render_id in CustomAudience in modo che venga inviato tramite adSelectionData anziché utilizzare l'URI e i metadati di rendering dell'annuncio. Gli ad tech possono ottimizza ulteriormente questo criterio non inviando dati pubblicitari in adSelectionData. Questa opzione sarà supportato nella versione CustomAudience API nelle release future.
2. Assicurati che user_bidding_signals non vengano inviati in adSelectionData. Invece, I tecnici 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 durante riducendo la dimensione del payload.

Le ottimizzazioni delle dimensioni verranno apportate nel rispetto delle preoccupazioni sollevate in materia di privacy diverse considerazioni.

Considerazioni contro i comportamenti illeciti

Come menzionato nella sezione Considerazioni sulla privacy, il valore adSelectionData viene generato utilizzando tutti i dati dell'acquirente sul dispositivo.

Ciò apre l’ecosistema a potenziali entità dannose che potrebbero aggiungere dati fraudolenti sugli acquirenti che potrebbero peggiorare le prestazioni, gonfiare i payload per aumentare costi ecc.

Per contrastare l'abuso di adSelectionData, introdurremo le seguenti misure

• Consenti a CustomAudience di specificare esplicitamente venditori e venditori approvati priorità
• Consenti alle SSP di specificare esplicitamente acquirente, priorità acquirente e quota per acquirente nel payload generato
• Offrire alle SSP un meccanismo di definire un numero massimo di acquirenti per chiamata o la dimensione massima per acquirente.

Queste misure sono pensate per consentire ai tecnici pubblicitari di definire con cui collaborano e di impostare limiti accettabili su adSelectionData payload che dovranno elaborare. Consigliamo al venditore di specificare l'elenco di acquirenti e la priorità in una chiamata separata. Questa specifica sarà costante per un certo intervallo di tempo per evitare di esporre dati aggiuntivi sull'utente tramite chiamate ripetute.

Le mitigazioni sopra menzionate sono in fase di discussione e sono soggette a nel tempo. Come accennato in precedenza, tutte le mitigazioni introdotte per contrastare i comportamenti illeciti e le dimensioni devono rispettare le norme sulla privacy.