La proposta di progettazione dei servizi di offerte e aste per Android descrive in dettaglio l'esecuzione e il flusso di dati delle aste su Android utilizzando il server di offerte e aste attendibili. Per assicurarsi che i dati in transito vengano gestiti solo da API che preservano la privacy e da server attendibili, i dati vengono criptati tra il client e il server utilizzando la crittografia ibrida bidirezionale con chiave pubblica.
Per eseguire l'asta come descritto in precedenza, la tecnologia pubblicitaria del venditore sul dispositivo deve eseguire i seguenti passaggi:
- Raccogliere e criptare i dati per l'asta del server
- Invia una richiesta a un servizio venditore non attendibile
- Ricevere una risposta da un servizio di venditore non attendibile
- Decripta la risposta all'asta Protected Audience e ottieni il risultato dell'asta
Protected Audience introduce due nuove API per supportare l'esecuzione di aste sul server:
- L'API
getAdSelectionData
raccoglie i dati per l'asta del server e genera un payload criptato contenente i dati dell'asta. Il server di aste e offerte utilizza questo payload per eseguire un'asta, generare il risultato dell'asta e restituirlo. - I client di tecnologia pubblicitaria sul dispositivo possono chiamare l'API
persistAdSelectionResult
per decriptare il risultato generato dall'asta del server e ottenere l'URL di rendering dell'annuncio vincente.
La tecnologia pubblicitaria del venditore sul dispositivo deve integrare e creare quanto segue per eseguire un'asta:
- Raccogliere e criptare i dati per il venditore dell'asta del server: la tecnologia pubblicitaria deve
chiamare l'API
getAdSelectionData
per ottenere il payload criptato. - Invia richiesta al servizio di venditori non attendibili: una richiesta
HTTP POST
oPUT
contenente il payload criptato generato dall'APIgetAdSelectionData
al servizio di venditori non attendibili e i dati richiesti dal servizio di venditori non attendibili per generare risultati contestuali. - Ricevere la risposta dal servizio venditori non attendibili: la risposta dal servizio venditori non attendibili conterrà il risultato dell'asta Protected Audience criptato e il risultato dell'asta contestuale.
- Decripta la risposta all'asta Protected Audience e ottieni il risultato dell'asta:Per decriptare il risultato dell'asta Protected Audience, la tecnologia pubblicitaria del venditore deve chiamare
l'API
persistAdSelectionResult
. Il risultato generato dapersistAdSelectionResult
aiuterà le tecnologie pubblicitarie a determinare se l'annuncio contestuale o l'annuncio Protected Audience ha vinto l'asta e l'URI dell'annuncio Protected Audience vincente, se applicabile.
Funzionalità supportate per l'asta lato server
Il nostro obiettivo è supportare tutte le funzionalità disponibili per l'asta sul dispositivo. La tempistica per il supporto di queste funzionalità nell'asta del server è la seguente:
Asta sul dispositivo |
Asta lato server |
|||
Anteprima per gli sviluppatori |
Beta |
Anteprima per gli sviluppatori |
Beta |
|
Report sulle vittorie a livello di evento |
T1 2023 |
T3 2023 |
N/D |
T4 2023 |
T1 2023 |
T4 2023 |
N/D |
Q1 24 |
|
T2 2023 |
T3 2023 |
N/D |
T4 2023 |
|
Trasferire gli annunci contestuali al flusso di lavoro di selezione degli annunci per il filtraggio |
T2 2023 |
Q1 2024 |
N/D |
N/D |
T2 2023 |
T3 2023 |
N/D |
T4 2023 |
|
Partecipare alla delega dei segmenti di pubblico personalizzati |
T3 2023 |
T4 2023 |
N/D |
T4 2023 |
fatturazione non basata su CPM |
T3 2023 |
T4 2023 |
||
Report |
T3 2023 |
T4 2023 |
T3 2023 |
T4 2023 |
Mediazione Open Bidding |
N/D |
N/D |
N/D |
Q1 2024 |
T2 2023 |
Q1 2024 |
N/D |
Q1 2024 |
|
Gestione delle valute |
N/D |
N/D |
N/D |
Q1 2024 |
Integrazione di K-anon |
N/D |
Q1 2024 |
N/D |
Q1 2024 |
Integrazione di Private Aggregation |
N/D |
N/D |
N/D |
Q3 '24 |
Esegui aste lato server utilizzando le API Protected Audience
Nel canale Anteprima per gli sviluppatori, AdSelectionManager espone due nuove API:
getAdSelectionData
e persistAdSelectionResult
. Queste API consentono agli SDK
di tecnologia pubblicitaria di integrarsi con i server di offerte e aste.
Raccogliere e criptare i dati per un'asta del server
L'API getAdSelectionData
genera l'input richiesto per i componenti Offerte e
Asta, ad esempio BuyerInput
e
ProtectedAudienceInput
, e cripta i dati prima di rendere
il risultato disponibile 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 e sulle strategie per
ottimizzarla nella sezione Considerazioni sulle dimensioni.
Per accedere all'API, deve essere abilitato l'accesso all'API Protected Audience e l'autorizzazione
ACCESS_ADSERVICES_CUSTOM_AUDIENCE
deve essere definita nel
manifest dell'applicazione chiamante.
public class AdSelectionManager {
public void getAdSelectionData(
GetAdSelectionDataRequest getAdSelectionDataRequest,
Executor executor,
OutcomeReceiver<GetAdSelectionDataOutcome, Exception> receiver) {}
}
GetAdSelectionDataRequest
- Il chiamante deve impostare il campo
seller
nella richiesta, in quanto viene utilizzato per eseguire i controlli di registrazione prima di elaborare la richiesta. - Il campo
coordinatorOriginUri
è facoltativo.- Se impostato, questo valore deve corrispondere allo schema, al nome host e alla porta dell'URL del coordinatore configurato durante il deployment del server B&A del venditore.
- Il coordinatore deve appartenere all'elenco dei coordinatori approvati:
Provider URI Origine URI Predefinito Google Cloud https://publickeyservice.pa.gcp.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys https://publickeyservice.pa.gcp.privacysandboxservices.com Sì Amazon Web Services https://publickeyservice.pa.aws.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys https://publickeyservice.pa.aws.privacysandboxservices.com No - Se non viene fornita alcuna origine del coordinatore, viene utilizzato il coordinatore predefinito.
- Sebbene sia molto improbabile che l'URL del coordinatore cambi, è vivamente consigliabile implementare un meccanismo per la gestione dinamica di questo URL. In questo modo, eventuali modifiche future all'URL possono essere apportate senza richiedere una nuova release dell'SDK.
public class GetAdSelectionDataRequest {
public setSeller(AdTechIdentifier seller);
public setCoordinatorOriginUri(Uri coordinatorOriginUri)
}
Una volta convalidata la richiesta, i dati dell'acquirente sul dispositivo vengono composti in
BuyerInput
e ProtectedAudienceInput
. L'oggetto payload finale viene poi
criptato utilizzando la crittografia ibrida bidirezionale con chiave pubblica.
GetAdSelectionDataOutcome
GetAdSelectionDataOutcome
viene generato come risultato dell'API getAdSelectionData
. Contiene quanto segue:
adSelectionId
: un numero intero opaco per identificare questa invocazione digetAdSelectionData
. Il client di tecnologia pubblicitaria deve conservare questo valoreadSelectionId
perché funge da puntatore alla chiamatagetAdSelectionData
. Questo identificatore è richiesto dall'APIpersistAdSelectionResult
per decriptare il risultato dell'asta dal server di offerte e aste ed è richiesto anche dalle APIreportImpression
ereportEvent
.adSelectionData
: si tratta dei dati dell'asta criptati necessari al server di Bidding and Auction per eseguire le aste. Questo metodo contiene:- Dati dei segmenti di pubblico personalizzati filtrati in base alla quota limite, ai filtri di installazione delle app e ai requisiti dell'asta del server per i segmenti di pubblico personalizzati.
- In una versione futura, conterrà i dati di installazione delle app.
public class GetAdSelectionDataOutcome {
Public getAdSelectionId(long adSelectionId);
public byte[] getAdSelectionData();
}
Gestione di errori, eccezioni e guasti
Se la generazione dei dati di selezione degli annunci non può essere completata correttamente a causa di
motivi quali argomenti non validi, timeout o consumo eccessivo di risorse,
il callback OutcomeReceiver.onError()
fornisce un AdServicesException
con
i seguenti comportamenti:
- Se
getAdSelectionData
viene avviato con argomenti non validi,AdServicesException
indica un'eccezione IllegalArgumentException come causa. - Tutti gli altri errori ricevono un
AdServicesException
con unIllegalStateException
come causa.
Inviare una richiesta a un servizio venditore non attendibile
Utilizzando AdSelectionData
, l'SDK sul dispositivo può inviare una richiesta al servizio pubblicitario 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, ad esempio inviando la richiesta al servizio di pubblicazione di annunci del venditore come multipart/form-data.
Ricevere una risposta da un servizio venditore non attendibile
Come descritto nella spiegazione del server di offerte e aste, quando il servizio del venditore non attendibile riceve la richiesta, effettua chiamate agli acquirenti partner per gli annunci contestuali.
Il servizio del venditore non attendibile inoltra adSelectionData
e
AuctionConfig
criptati al servizio SellerFrontEnd del server di offerte e aste
in esecuzione in un TEE.
Al termine dell'asta Protected Audience, il servizio SellerFrontEnd cripta il risultato dell'asta e lo restituisce come risposta al servizio del venditore non attendibile.
Il servizio venditore non attendibile invia una risposta al dispositivo contenente l'annuncio contestuale e / o il risultato dell'asta Protected Audience criptato.
Al ricevimento della risposta, il codice della tecnologia pubblicitaria del venditore sul dispositivo potrebbe scegliere di
utilizzare solo l'annuncio contestuale nella risposta oppure, se ritiene che ci sia
un valore incrementale nell'ottenere il risultato Protected Audience, può scegliere di
decriptare il risultato Protected Audience chiamando l'API PersistAdSelectionResult
.
API PersistAdSelectionResult
Per decriptare il risultato di Protected Audience, la tecnologia pubblicitaria del venditore può chiamare la seconda
API Protected Audience persistAdSelectionResult
. L'API decripta il risultato
e restituisce un AdSelectionOutcome
, lo stesso oggetto restituito da un'asta
on-device oggi.
Per accedere all'API, il chiamante deve abilitare l'accesso all'API Protected Audience e
definire l'autorizzazione ACCESS_ADSERVICES_CUSTOM_AUDIENCE
nel manifest.
public void persistAdSelectionResult(
PersistAdSelectionResultRequest persistAdSelectionResultRequest,
Executor executor,
OutcomeReceiver<AdSelectionOutcome, Exception> receiver) {}
PersistAdSelectionResultRequest
Il richiedente deve impostare quanto segue nella richiesta:
public final class PersistAdSelectionResultRequest {
Public setAdSelectionId(long adSelectionId);
public setSeller(AdTechIdentifier seller);
public setAdSelectionResult(byte[] adSelectionResult);
}
adSelectionId
: l'identificatore opaco generato dalla chiamatagetAdSelectionData
il cui risultato il chiamante vuole decriptare.seller
: l'identificatore della tecnologia pubblicitaria del venditore deve essere impostato nella richiesta di esecuzione dei controlli di registrazione prima di elaborare la richiesta.adSelectionResult
: Il risultato dell'asta criptato generato dal server di offerte e aste che il chiamante vuole decriptare.
Risposta AdSelectionOutcome
Se è presente un vincitore di Protected Audience, AdSelectionOutcome
restituisce l'URI di rendering dell'annuncio vincente.Una volta decrittografato adSelectionResult
, i dati dei report vengono archiviati internamente. Il callback OutcomeReceiver.onResult()
restituisce
un AdSelectionOutcome
che contiene:
URI
: se è presente un annuncio Protected Audience vincente, viene restituito un URL di rendering dell'annuncio vincente. Se non viene selezionato alcun vincitore di Protected Audience, viene restituito `Uri.EMPTY.adSelectionId
: iladSelectionId
associato a questa esecuzione dell'asta del server.
Gestione di errori, eccezioni e guasti
Se la generazione dei dati di selezione degli annunci non può essere completata correttamente a causa di
motivi quali argomenti non validi, timeout o consumo eccessivo di risorse,
il callback OutcomeReceiver.onError()
fornisce un AdServicesException
con
i seguenti comportamenti:
- Se
getAdSelectionData
viene avviato con argomenti non validi,AdServicesException
indica unIllegalArgumentException
come causa. - Tutti gli altri errori ricevono un
AdServicesException
con unIllegalStateException
come causa.
Considerazioni sulla privacy
adSelectionData
è criptato per garantire che i dati in transito siano accessibili solo
a PPAPI e ai server attendibili.
Nonostante la crittografia, la perdita di dati può verificarsi a causa delle dimensioni di adSelectionData
. Le dimensioni
adSelectionData
possono variare a causa di:
- Modifiche ai dati di
CustomAudience
presenti sul dispositivo. - Modifiche alla logica di filtraggio di
CustomAudience
. - Modifiche all'input per la chiamata a
getAdSelectionData
.
La modifica delle dimensioni di adSelectionData
può essere utilizzata per generare un identificatore cross-app come indicato nella discussione sulla perdita di 1 bit. Molte
mitigazioni applicabili alla perdita di 1 bit sono applicabili anche qui.
Per gestire queste perdite, prevediamo di generare lo stesso adSelectionData
per tutte le chiamate all'API getAdSelectionData
. Nelle versioni iniziali, tutti i
CustomAudiences
sul dispositivo vengono utilizzati per creare adSelectionData
e il
payload criptato verrà riempito per mascherare le variazioni di dimensione. Limiteremo inoltre
l'influenza dei parametri di input GetAdSelectionData
sul adSelectionData
generato.
Tuttavia, la generazione dello stesso adSelectionData
per tutte le tecnologie pubblicitarie che utilizzano tutti i
dati dell'asta sul dispositivo crea un payload di grandi dimensioni che ora deve essere trasferito
in ogni chiamata al server della tecnologia pubblicitaria. L'utilizzo di tutti i segmenti di pubblico personalizzati sul dispositivo per
generare il payload dell'asta espone anche l'ecosistema ad abusi da parte di entità
malicious. Abbiamo trattato questi problemi nelle sezioni Ottimizzazioni delle dimensioni e
Mitigazioni degli abusi.
Ottimizzazioni delle dimensioni
L'SDK client di tecnologia pubblicitaria deve includere i byte criptati di
adSelectionData
nella chiamata contestuale HTTP PUT/POST
effettuata al server di tecnologia pubblicitaria. Per ridurre la latenza e i costi del tempo di andata e ritorno, è necessario ridurre
le dimensioni di adSelectionData
il più possibile senza influire sull'utilità.
Prevediamo di esplorare e potenzialmente introdurre le seguenti ottimizzazioni nelle
prossime release per ridurre le dimensioni di adSelectionData
:
Payload generato in un insieme fisso di dimensioni dei bucket con padding: per ridurre al minimo la perdita dovuta alle variazioni di dimensioni, consentendo al contempo payload più piccoli, ti consigliamo di utilizzare il bucketing a dimensioni fisse per il payload generato. Se il numero di bucket è basso, ad esempio 7, l'entropia trapelata per chiamata a
getAdSelectionData
sarà inferiore a 3 bit.Se i dati sul dispositivo superano le dimensioni massime del bucket, vengono utilizzate strategie come i valori di priorità per decidere quali dati vengono eliminati.
Configurazione dell'acquirente: stiamo valutando la fattibilità di consentire agli acquirenti di configurare un payload per acquirente. Questa configurazione sarebbe utile per identificare le aste a cui un acquirente è interessato a partecipare. Se fattibile, durante la registrazione, una tecnologia pubblicitaria dell'acquirente potrebbe registrare un endpoint da cui Protected Audience recupererebbe la configurazione del payload a una cadenza regolare giornaliera. In alternativa, le API che tutelano la privacy esporrebbero un'API per consentire alle tecnologie pubblicitarie degli acquirenti di registrare questo endpoint.
Questa configurazione verrà quindi utilizzata per valutare il contributo di un acquirente ai
adSelectionData
generati per ogni richiestagetAdSelectionData
.La configurazione del payload dell'acquirente consentirebbe agli acquirenti di specificare:
- Elenco dei venditori consentiti: i segmenti di pubblico personalizzati dell'acquirente verranno aggiunti al payload solo se la chiamata
getAdSelectionData
viene avviata da un venditore nell'allowlist. Recupereremo la configurazione del payload con una cadenza giornaliera per mantenere aggiornata la lista consentita. - Limite di dimensioni per venditore: l'acquirente può specificare un limite di dimensioni per venditore per determinare le dimensioni dei dati da inviare nel payload quando un'asta viene avviata da un determinato venditore. Questa opzione è utile se un acquirente vuole dedicare più risorse all'elaborazione dei dati delle aste di determinati venditori. SellerFrontendService inoltra solo i dati specifici dell'acquirente a ogni BuyerFrontendService. Pertanto, definendo un limite di dimensioni per venditore, un acquirente potrebbe controllare esplicitamente la quantità di dati inseriti ed elaborati da BuyerFrontendService del server di offerta e asta per le aste gestite da un venditore.
- Elenco dei venditori consentiti: i segmenti di pubblico personalizzati dell'acquirente verranno aggiunti al payload solo se la chiamata
Configurazione del venditore: stiamo valutando la fattibilità di una configurazione dell'asta per venditore che consenta ai venditori di definire i parametri dell'asta per controllare le dimensioni del payload e i partecipanti all'asta. Se possibile, durante la registrazione, la tecnologia pubblicitaria del venditore potrebbe specificare l'endpoint da cui Protected Audience potrebbe recuperare la configurazione dell'asta per venditore a una cadenza regolare. Questa configurazione verrà quindi utilizzata per determinare la composizione e i limiti di
adSelectionData
generati per ogni richiestagetAdSelectionData
.Analogamente alla configurazione dell'acquirente, una configurazione per venditore consentirebbe ai venditori di specificare quale insieme di acquirenti si aspettano di vedere in un'asta e di specificare limiti al contributo per acquirente alle dimensioni del payload.
La configurazione dell'asta del venditore consentirebbe ai venditori di specificare:
- Elenco degli acquirenti consentiti: per le aste avviate dal venditore specificato, solo gli acquirenti inclusi nella lista consentita potranno contribuire con CustomAudiences per l'asta. La configurazione dell'asta deve essere aggiornata quotidianamente per mantenere la lista consentita aggiornata con la lista consentita degli acquirenti lato server.
- Limite di dimensioni per acquirente: i venditori possono specificare un limite per acquirente per regolare le dimensioni dei dati caricati da ciascun acquirente nel payload inviato a SellerFrontendService. Se l'acquirente supera il limite di dimensioni per acquirente, verrà utilizzata la priorità CustomAudience impostata nella configurazione del payload dell'acquirente per ottenere i dati nei limiti previsti.
- Priorità per acquirente: consente ai venditori di impostare la priorità per acquirente. La priorità dell'acquirente verrà utilizzata per identificare quali dati dell'acquirente devono essere mantenuti nel payload se le dimensioni del payload superano il limite.
- Limite di dimensione massima per il payload: venditori diversi potrebbero avere un'allocazione delle risorse diversa e potrebbero voler impostare un limite di dimensione massima per il payload dell'asta per richiesta. Il limite di dimensione massima rispetterebbe i bucket di dimensioni fisse impostati dall'API Protected Audience.
Modifiche ai segmenti di pubblico personalizzati
- Specifica la priorità del segmento di pubblico personalizzato: consente agli acquirenti di specificare un valore di priorità in un segmento di pubblico personalizzato. Il campo
priority
viene utilizzato per identificare i segmenti di pubblico personalizzati da includere in un'asta se l'insieme dei segmenti di pubblico personalizzati dell'acquirente supera i limiti di dimensioni per venditore o per acquirente. Un valore di priorità non specificato in un segmento di pubblico personalizzato verrà impostato su0.0
per impostazione predefinita.
- Specifica la priorità del segmento di pubblico personalizzato: consente agli acquirenti di specificare un valore di priorità in un segmento di pubblico personalizzato. Il campo
Modifiche ai dati di payload
- Ridurre i dati inviati nel payload: come descritto in Ottimizzazione del payload dei servizi di offerte e asta, un payload più elevato è determinato dai dati dei segmenti di pubblico personalizzati
ads
, dai segnali di offerta degli utenti e dai segnali Android. I payload più grandi possono essere ridotti:- Il cliente invia gli ID rendering annuncio (anziché gli oggetti annuncio) nel payload.
- Il client non invia dati pubblicitari nel payload.
- Non inviare indicatori di offerta dell'utente nel payload client.
- Ridurre i dati inviati nel payload: come descritto in Ottimizzazione del payload dei servizi di offerte e asta, un payload più elevato è determinato dai dati dei segmenti di pubblico personalizzati
Sebbene queste strategie consentano alle tecnologie pubblicitarie di definire configurazioni per gestire la composizione e i limiti del payload adSelectionData
, potrebbero anche diventare un fattore per modulare le dimensioni di adSelectionData
modificando i parametri di configurazione. Per evitare questo problema, la configurazione viene recuperata quotidianamente da Protected
Audience dall'endpoint configurato.
Ottimizzazione della latenza
Affinché le aste lato server abbiano un livello di utilità auspicabile, dobbiamo assicurarci che l'API getAdSelectionData
e l'API persistAdSelectionResult
abbiano una bassa latenza per chiamata. Sebbene il nostro obiettivo sia fornire il supporto delle funzionalità per le API nel 2023, la release successiva si concentrerà sui benchmark di latenza e sulle ottimizzazioni per le API.
Stiamo esplorando le seguenti strategie per mantenere la latenza entro limiti accettabili:
Pre-generazione dei dati Protected Audience per venditore: poiché la configurazione dell'asta del venditore e la configurazione del payload dell'acquirente saranno stabili per un periodo di tempo considerevole (giornaliero), la piattaforma potrebbe precalcolare e memorizzare i dati Protected Audience idonei.
Ciò richiederebbe alla piattaforma di creare un meccanismo per monitorare gli aggiornamenti dei segmenti di pubblico personalizzati e modificare i dati Protected Audience pregenerati in base agli aggiornamenti. La piattaforma dovrebbe anche dichiarare gli SLO relativi al ritardo che la tecnologia pubblicitaria potrebbe aspettarsi tra gli aggiornamenti dei segmenti di pubblico personalizzati e la visualizzazione della modifica del
adSelectionData
generato per l'asta del server.Poiché un dispositivo fornisce un modello di calcolo delle risorse limitato con priorità di elaborazione variabili, riconosciamo che la fornitura di questa funzionalità di pre-generazione deve essere accompagnata da garanzie di alta affidabilità e SLO.
La pre-generazione dei dati Protected Audience si baserebbe quindi su
- Attivazione da parte del venditore della pre-generazione dei dati Protected Audience.
- Gli acquirenti idonei a partecipare a un'asta avviata da un determinato venditore.
- Identificazione dei segmenti di pubblico personalizzati per acquirente che faranno parte del
payload in base a:
- Limiti di dimensioni per acquirente, priorità per acquirente e limiti di dimensioni massime definiti nella configurazione del venditore.
- Limite di dimensioni per venditore, priorità del segmento di pubblico personalizzato definita nella configurazione dell'acquirente.
Applicazione anticipata del filtro negativo: se preferito da un venditore, la piattaforma potrebbe precalcolare
adSelectionData
pregenerando i dati Protected Audience e applicando il filtro negativo al di fuori della chiamatagetAdSelectionData
critica. In questo modo, i venditori possono bilanciare la riduzione della latenza accettando l'obsolescenza nel filtro negativo.La piattaforma potrebbe fornire questo supporto offrendo un'opzione predefinita nella configurazione del venditore con un limite di obsolescenza e un'opzione di override in
getAdSelectionData
per consentire il calcolo più recente, se necessario. In alternativa, la piattaforma potrebbe fornire un'API di inizializzazione aggiuntiva da chiamare prima digetAdSelectionData
per il riscaldamento dell'asta.Calcolo del payload per più aste: in alcuni scenari, potrebbe essere preferibile disporre di un'API con prestazioni di latenza a scapito di un aumento dell'obsolescenza dei dati. Per fornire questo, la piattaforma potrebbe introdurre un'API di inizializzazione per calcolare l'intero payload e fornire un riferimento al payload calcolato al chiamante.
Per le chiamate successive a
getAdSelectionData
, il chiamante potrebbe fornire un riferimento al payload precalcolato da utilizzare per la generazione diadSelectionData
.
Queste tre strategie si trovano nella fase di esplorazione iniziale e hanno lo scopo di descrivere la direzione che la piattaforma potrebbe intraprendere per ottimizzare la latenza. Man mano che esploriamo profili di latenza più dettagliati dell'API e requisiti di tecnologia pubblicitaria, continueremo a proporre strategie aggiuntive.
Mitigazione e identificazione di comportamenti illeciti
Come indicato in Considerazioni sulla privacy, adSelectionData
viene generato utilizzando
tutti i dati dell'acquirente sul dispositivo.
Tuttavia, se tutti i dati dell'acquirente sul dispositivo vengono utilizzati per generare l'output adSelectionData
, un'entità dannosa potrebbe spacciarsi per un acquirente e creare dati fraudolenti per peggiorare le prestazioni di Android, gonfiare il payload per aumentare i costi di un'ad tech per eseguire aste o offerte e così via.
Attenuazione
Alcune misure menzionate nella sezione Considerazioni sulle dimensioni, come la configurazione del payload dell'acquirente contenente venditori autorizzati e la configurazione dell'asta del venditore contenente acquirenti autorizzati, contribuirebbero a escludere dati imprevisti nel payload.
Anche altre misure di considerazione delle dimensioni, come consentire alle SSP di specificare la priorità dell'acquirente, inserire la quota per acquirente nel payload generato e impostare una dimensione massima per payload dell'asta, possono contribuire a mitigare l'impatto dell'aumento delle dimensioni del payload dannoso. Queste misure hanno lo scopo di consentire alle tecnologie pubblicitarie di definire con quali tecnologie pubblicitarie collaborano e di impostare limiti accettabili per il payload che devono elaborare.
Come accennato in precedenza, tutte le misure di mitigazione introdotte per l'anti-abuso e le limitazioni di dimensioni devono rispettare le considerazioni sulla privacy.
Identificazione di entità dannose
Sebbene queste misure di mitigazione proteggano la generazione di adSelectionData
per le aste del server, non aiutano a identificare entità malintenzionate o a proteggere la piattaforma da abusi come la creazione di un numero senza precedenti di segmenti di pubblico personalizzati da parte di un acquirente.
Per verificare la stabilità e l'integrità della piattaforma, dobbiamo trovare un meccanismo per identificare le entità dannose, i vettori di abuso e la motivazione degli attacchi specifici. Nelle versioni successive, introdurremo spiegazioni che descrivono in dettaglio i potenziali vettori di abuso e le protezioni in atto per contrastarli.