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:
- Sul dispositivo, i venditori raccolgono informazioni da Protected Audience utilizzando la sezione
API
getAdSelectionData
. - L'SDK on-device invia una richiesta all'annuncio venditore
Google Cloud. Questa richiesta include payload contestuale
ProtectedAudienceInput
criptato. - 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.
- Il servizio annunci del venditore invia una richiesta al proprio SellerFrontEnd in esecuzione in un TEE.
- Il servizio SellerFrontEnd invia richieste con dati specifici dell'acquirente a Servizi di buyerFrontEnd.
- 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.
- 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.
- Il servizio di annunci del venditore restituisce il risultato criptato vincente e, facoltativamente, un risultato contestuale all'SDK on-device.
- 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à:
- Aggiunta di
ad_render_id
inCustomAudience
in modo che venga inviato tramiteadSelectionData
anziché utilizzare l'URI e i metadati di rendering dell'annuncio. Gli ad tech possono ottimizza ulteriormente questo criterio non inviando dati pubblicitari inadSelectionData
. Questa opzione sarà supportato nella versioneCustomAudience API
nelle release future. - Assicurati che
user_bidding_signals
non vengano inviati inadSelectionData
. Invece, I tecnici possono recuperareuser_bidding_signals
dal proprio server chiave/valore. - Consenti agli acquirenti di dare la priorità a
CustomAudience
. - Consenti all'acquirente di specificare la priorità del venditore.
- 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.