Integrazione e ottimizzazione dei servizi di asta e aste

La proposta di progettazione Offerte e servizi di aste per Android descrive in dettaglio l'esecuzione e il flusso di dati dell'esecuzione delle aste su Android utilizzando il server delle aste e Trusted Bidding. Per garantire che i dati in transito vengano gestiti solo da API che tutelano la privacy e server attendibili, i dati vengono criptati tra il client e il server tramite la crittografia a chiave pubblica ibrida bidirezionale.

Per eseguire l'asta come descritto in precedenza, la tecnologia pubblicitaria del venditore sul dispositivo deve eseguire i seguenti passaggi:

1. Raccogli e cripta i dati per l'asta del server
2. Inviare una richiesta a un servizio venditore non attendibile
3. Ricevere una risposta da un servizio venditore non attendibile
4. Decripta la risposta dell'asta Protected Audience e ottieni il risultato dell'asta

Protected Audience sta introducendo due nuove API per supportare le aste dei server in esecuzione:

1. L'API getAdSelectionData raccoglie i dati per l'asta del server e genera un payload criptato contenente i dati dell'asta. Il server per le offerte e le aste utilizza questo payload per eseguire un'asta, generare il risultato dell'asta e restituire il risultato dell'asta.
2. I clienti di tecnologia pubblicitaria on-device possono chiamare l'API persistAdSelectionResult per decriptare il risultato generato dall'asta del server e ottenere l'URL di rendering dell'annuncio vincente.

Per poter eseguire un'asta, la tecnologia pubblicitaria del venditore sul dispositivo deve integrare e creare i seguenti elementi:

1. Raccogli e cripta i dati per il venditore dell'asta del server: il tecnico pubblicitario deve chiamare l'API getAdSelectionData per ottenere il payload criptato.
2. Invia una richiesta all'invio di servizio per venditori non attendibili: una richiesta HTTP POST o PUT contenente il payload criptato generato dall'API getAdSelectionData al servizio venditore non attendibile e i dati richiesti dal servizio venditore non attendibile per generare risultati contestuali.
3. Ricevi risposta dal servizio venditore non attendibile: la risposta da un servizio venditore non attendibile contiene il risultato dell'asta basato su segmenti di pubblico protetti criptati e il risultato dell'asta contestuale.
4. Decriptare la risposta dell'asta con segmento di pubblico protetto e ottenere il risultato dell'asta: per decriptare il risultato dell'asta basato su pubblico protetto, la tecnologia pubblicitaria del venditore deve chiamare l'API persistAdSelectionResult. Il risultato generato da persistAdSelectionResult aiuterà i tecnici pubblicitari a determinare se l'annuncio contestuale o l'annuncio con segmento di pubblico protetto ha vinto l'asta e l'URI dell'annuncio con segmento di pubblico protetto vincente, se applicabile.

Funzionalità supportate per l'asta del server

Il nostro obiettivo è supportare tutte le funzionalità attualmente disponibili per l'asta on-device. Le tempistiche per il supporto di queste funzionalità nell'asta del server sono le seguenti:

	Asta on-device		Asta server
	Anteprima per gli sviluppatori	Beta	Anteprima per gli sviluppatori	Beta
Report sulle vincite a livello di evento	T1 '23	T3 '23	N/A	T4 2023
Mediazione con struttura a cascata	T1 '23	T4 2023	N/A	T1 24
Filtro della quota limite	T2 2023	T3 '23	N/A	T4 2023
Trasmettere gli annunci contestuali al flusso di lavoro di selezione degli annunci per l'applicazione di filtri	T2 2023	T1 24	N/A	N/A
Report sulle interazioni	T2 2023	T3 '23	N/A	T4 2023
Partecipare alla delega dei segmenti di pubblico personalizzati	T3 '23	T4 2023	N/A	T4 2023
fatturazione non CPM	T3 '23	T4 2023
Report di debug	T3 '23	T4 2023	T3 '23	T4 2023
Mediazione Open Bidding	N/A	N/A	N/A	T1 24
Filtro annunci per l'installazione di app	T2 2023	T1 24	N/A	T1 24
Gestione della valuta	N/A	N/A	N/A	T1 24
Integrazione K-anon	N/A	T1 24	N/A	T1 24
Integrazione dell'aggregazione privata	N/A	N/A	N/A	T3 2024

Eseguire aste del 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 ad tech di integrarsi con i server per le offerte e le aste.

Raccogli e cripta i dati per un'asta del server

L'API getAdSelectionData genera l'input richiesto per i componenti per Offerte e Asta come BuyerInput e ProtectedAudienceInput e cripta i dati prima di rendere il risultato disponibile per il chiamante. Per evitare fughe 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 ottimizzare questo aspetto nella sezione Considerazioni sulle dimensioni.

Per accedere all'API, è necessario abilitare l'accesso all'API Protected Audience e l'autorizzazione ACCESS_ADSERVICES_CUSTOM_AUDIENCE deve essere definita nel file manifest del chiamante.

public class AdSelectionManager {
    public void getAdSelectionData(
            GetAdSelectionDataRequest getAdSelectionDataRequest,
            Executor executor,
            OutcomeReceiver<GetAdSelectionDataOutcome, Exception> receiver) {}
}

GetAdSelectionDataRequest

1. Il chiamante deve impostare il campo seller nella richiesta, in quanto viene utilizzato per eseguire i controlli di registrazione prima di gestire la richiesta.
2. Il campo coordinatorOriginUri è facoltativo.
   1. Se impostato, deve corrispondere allo schema, al nome host e alla porta dell'URL del coordinatore configurato durante il deployment del server B&A del venditore.
   2. Il coordinatore deve appartenere all'elenco dei coordinatori approvati:

      Fornitore	URI	Origine URI	Predefinita
      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

   3. Se non viene fornita un'origine del coordinatore, viene utilizzato il coordinatore predefinito.
   4. Sebbene sia altamente improbabile che l'URL del coordinatore cambi, consigliamo vivamente di implementare un meccanismo per la gestione dinamica di questo URL. In questo modo, le eventuali modifiche future all'URL potranno essere apportate senza bisogno di una nuova release dell'SDK.

public class GetAdSelectionDataRequest {
  public setSeller(AdTechIdentifier seller);
  public setCoordinatorOriginUri(Uri coordinatorOriginUri)
}

Dopo la convalida della richiesta, i dati degli acquirenti on-device vengono composti in BuyerInput e ProtectedAudienceInput. L'oggetto payload finale viene quindi criptato tramite la crittografia a chiave pubblica ibrida bidirezionale.

GetAdSelectionDataOutcome

GetAdSelectionDataOutcome viene generato come risultato dell'API getAdSelectionData. Contiene quanto segue:

1. adSelectionId: un numero intero opaco per identificare questa chiamata di getAdSelectionData. Il client ad tech dovrebbe mantenere questo valore adSelectionId perché funge da puntatore alla chiamata getAdSelectionData. Questo identificatore è richiesto dall'API persistAdSelectionResult per decriptare il risultato dell'asta dal server delle aste e del server delle aste ed è richiesto anche dalle API reportImpression e reportEvent.
2. adSelectionData: si tratta dei dati criptati delle aste richiesti dal server di offerte e dal server delle aste per eseguire le aste. Questo metodo contiene:
   1. Dati sui segmenti di pubblico personalizzati filtrati in base alla quota limite, ai filtri per l'installazione di app e ai requisiti dell'asta del server per i segmenti di pubblico personalizzati.
   2. In una versione futura, conterrà i dati sulle installazioni di app.

public class GetAdSelectionDataOutcome {
  Public getAdSelectionId(long adSelectionId);
  public byte[] getAdSelectionData();
}

Errori, eccezioni e gestione degli errori

Se la generazione dei dati per la selezione degli annunci non può essere completata per motivi quali argomenti non validi, timeout o un consumo eccessivo di risorse, il callback OutcomeReceiver.onError() fornisce un valore AdServicesException con i seguenti comportamenti:

1. Se getAdSelectionData viene avviato con argomenti non validi, AdServicesException indica un'eccezione illegale come causa.
2. Tutti gli altri errori ricevono un AdServicesException con un IllegalStateException come causa.

Invia una richiesta a un servizio venditore non attendibile

Con AdSelectionData, l'SDK on-device 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. È consigliabile utilizzare una soluzione efficiente nello spazio, come l'invio della richiesta al servizio pubblicitario del venditore come multipart/form-data.

Ricevere una risposta da un servizio venditore non attendibile

Come descritto in dettaglio nel documento esplicativo sulle offerte e sul server delle aste, quando il servizio venditore non attendibile riceve la richiesta, effettua chiamate agli acquirenti partner per gli annunci contestuali.

Il servizio venditore non attendibile inoltra i 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 venditore non attendibile.

Il servizio venditore non attendibile invia una risposta al dispositivo contenente un annuncio contestuale e / o il risultato dell'asta Protected Audience criptato.

Dopo aver ricevuto la risposta, il codice della tecnologia pubblicitaria del venditore sul dispositivo potrebbe scegliere di usare solo l'annuncio contestuale nella risposta oppure, se ritiene che esista un valore incrementale per il recupero del risultato Protected Audience, può scegliere di decriptare il risultato di Protected Audience chiamando l'API PersistAdSelectionResult.

API PersistAdSelectionResult

Per decriptare il risultato 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 che viene 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 proprio file manifest.

    public void persistAdSelectionResult(
            PersistAdSelectionResultRequest persistAdSelectionResultRequest,
            Executor executor,
            OutcomeReceiver<AdSelectionOutcome, Exception> receiver) {}

PersistAdSelectionResultRequest

Il chiamante deve impostare quanto segue nella richiesta:

public final class PersistAdSelectionResultRequest {
  Public setAdSelectionId(long adSelectionId);
  public setSeller(AdTechIdentifier seller);
  public setAdSelectionResult(byte[] adSelectionResult);
}

1. adSelectionId: l'identificatore opaco generato dalla chiamata getAdSelectionData di cui il chiamante vuole decriptare.
2. seller: l'identificatore della tecnologia pubblicitaria del venditore deve essere impostato nella richiesta per eseguire i controlli di registrazione prima di gestire la richiesta.
3. adSelectionResult: il risultato dell'asta criptato generato dal server delle offerte e delle aste che il chiamante vuole decriptare.

Risposta AdSelectionRisultato

Se c'è un vincitore Protected Audience, AdSelectionOutcome restituisce l'URI di rendering dell'annuncio vincente.Una volta decriptato il adSelectionResult, i dati dei report vengono resi persistenti internamente. Il callback OutcomeReceiver.onResult() restituisce un AdSelectionOutcome che contiene:

• URI: se è presente un annuncio Protected Audience vincente, viene restituito un URL di rendering per l'annuncio vincente. Se non c'è un vincitore Protected Audience, viene restituito Uri.EMPTY.
• adSelectionId: il valore adSelectionId associato all'esecuzione dell'asta del server.

Errori, eccezioni e gestione degli errori

Se la generazione dei dati per la selezione degli annunci non può essere completata per motivi quali argomenti non validi, timeout o un consumo eccessivo di risorse, il callback OutcomeReceiver.onError() fornisce un valore AdServicesException con i seguenti comportamenti:

1. Se getAdSelectionData viene avviato con argomenti non validi, AdServicesException indica IllegalArgumentException come causa.
2. Tutti gli altri errori ricevono un AdServicesException con un IllegalStateException 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 fuga di dati può verificarsi a causa delle dimensioni di adSelectionData. La dimensione di adSelectionData può variare a causa di:

1. Modifiche ai dati di CustomAudience presenti sul dispositivo.
2. Modifiche alla logica di filtro di CustomAudience.
3. Modifiche all'input per la chiamata getAdSelectionData.

La modifica delle dimensioni di adSelectionData può essere utilizzata per generare un identificatore cross-app come menzionato nella discussione relativa alle fughe di dati a 1 bit. Molte mitigazioni applicabili alla fuga a 1 bit sono applicabili anche in questo caso.

Per gestire queste perdite, prevediamo di generare lo stesso adSelectionData per tutte le chiamate all'API getAdSelectionData. Nelle release iniziali, tutti i CustomAudiences sul dispositivo vengono utilizzati per creare adSelectionData e il payload criptato verrà riempito per variare le dimensioni della maschera. Limiteremo anche 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 delle aste on-device crea un grande payload che ora deve essere trasferito in ogni chiamata al server ad tech. L'utilizzo di tutti i segmenti di pubblico personalizzati on-device per generare il payload dell'asta apre inoltre l'ecosistema agli abusi da parte di entità dannose. Abbiamo trattato questi problemi nelle sezioni Ottimizzazioni delle dimensioni e Mitigazioni per comportamenti illeciti di seguito.

Ottimizzazioni delle dimensioni

L'SDK del client ad tech dovrebbe pacchettizzare i byte criptati di adSelectionData nella chiamata contestuale HTTP PUT/POST effettuata al server tecnico pubblicitario. Per ridurre il tempo di round trip e i costi, è necessario ridurre il più possibile le dimensioni di adSelectionData, senza influire sull'utilità.

Prevediamo di esplorare e introdurre potenzialmente le seguenti ottimizzazioni nelle prossime versioni per ridurre le dimensioni di adSelectionData:

1. Payload generato in un insieme fisso di dimensioni di bucket con spaziatura interna: per ridurre al minimo la perdita dovuta alle variazioni delle dimensioni, pur consentendo un carico di lavoro inferiore, ti consigliamo di utilizzare il bucketing a dimensione fissa per il payload generato. Se ad esempio il numero di bucket è ridotto, 7 porterà a meno di 3 bit di entropia divulgata per chiamata a getAdSelectionData.

   Se i dati sul dispositivo superano la dimensione massima del bucket, vengono utilizzate le strategie menzionate di seguito, ad esempio i valori di priorità, per decidere quali dati eliminare.

2. Configurazione acquirente: stiamo valutando se consentire agli acquirenti di configurare una configurazione del payload per acquirente. Questa configurazione è utile per identificare le aste a cui un acquirente è interessato. Se possibile, durante la registrazione, un acquirente ad tech potrebbe registrare un endpoint da cui Protected Audience recupera la configurazione del payload a una cadenza regolare giornaliera. In alternativa, le API incentrate sulla tutela della privacy esporranno un'API per consentire ai tecnici pubblicitari dell'acquirente di registrare questo endpoint.

   Questa configurazione verrà quindi utilizzata per valutare il contributo di un acquirente a adSelectionData generato per ogni richiesta getAdSelectionData.

   La configurazione del payload dell'acquirente consentirebbe agli acquirenti di specificare:

   1. 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 nella lista consentita. Recuperavamo la configurazione del payload giornaliera per mantenere aggiornata la lista consentita.
   2. Limite di dimensioni per venditore: l'acquirente può specificare un limite di dimensioni per venditore per determinare la dimensione dei dati da inviare nel payload quando un'asta viene avviata da un determinato venditore. Questo potrebbe essere utile se un acquirente vuole dedicare più risorse all'elaborazione dei dati delle aste di determinati venditori. SellerFrontendService inoltra solo dati specifici dell'acquirente a ogni buyerFrontendService. Pertanto, definendo un limite di dimensione per venditore, un acquirente potrebbe controllare in modo esplicito la quantità di dati importati ed elaborati dal BuyerFrontendService del proprio server di offerte e delle aste per le aste eseguite da un venditore.

3. Configurazione del venditore: stiamo valutando la fattibilità di una configurazione dell'asta per venditore che consentirebbe ai venditori di definire i parametri dell'asta per controllare la dimensione del payload e i partecipanti all'asta. Se possibile, durante la registrazione, il team AdTech del venditore sarebbe in grado di 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 richiesta getAdSelectionData.

   Analogamente alla configurazione dell'acquirente, una configurazione per venditore consente ai venditori di specificare quale insieme di acquirenti si aspettano di vedere in un'asta e di specificare i limiti per il contributo di ciascun acquirente alla dimensione del payload.

   La configurazione dell'asta del venditore consentirebbe ai venditori di specificare:

   1. Elenco degli acquirenti consentiti: per le aste avviate dal venditore in questione, solo gli acquirenti nella lista consentita possono contribuire con i segmenti di pubblico personalizzati per l'asta. La configurazione dell'asta deve essere aggiornata giornalmente per mantenere la lista consentita con la lista consentita dell'acquirente lato server.
   2. Limite di dimensioni per acquirente: i venditori possono specificare un limite per acquirente per regolare la dimensione dei dati caricati da ciascun acquirente nel payload inviato a SellerFrontendService. Se l'acquirente supera il limite di dimensioni per acquirente, viene utilizzata la priorità CustomAudience impostata nella configurazione del payload dell'acquirente per ottenere i dati entro i limiti previsti.
   3. Priorità per acquirente: consenti ai venditori di impostare la priorità in base all'acquirente. La priorità dell'acquirente viene utilizzata per identificare i dati dell'acquirente da conservare nel payload se la dimensione del payload supera il limite.
   4. Dimensioni massime del payload: venditori diversi potrebbero avere un'allocazione delle risorse diversa e potrebbero voler impostare un limite massimo per le dimensioni del payload dell'asta per richiesta. Le dimensioni massime consentite rispetterebbero i bucket di dimensioni fisse impostati dall'API Protected Audience.

4. Modifiche ai segmenti di pubblico personalizzati

   1. Specifica la priorità dei segmenti di pubblico personalizzati: consenti agli acquirenti di specificare un valore di priorità in un segmento di pubblico personalizzato. Il campo priority verrà utilizzato per identificare i segmenti di pubblico personalizzati da includere in un'asta se l'insieme di segmenti di pubblico personalizzati dell'acquirente supera i limiti di dimensioni per venditore o acquirente. Un valore di priorità non specificato in un segmento di pubblico personalizzato viene impostato su 0.0 per impostazione predefinita.

5. Modifiche ai dati del payload

   1. Riduci i dati inviati nel payload: come descritto in Ottimizzazione del payload dei servizi di offerte e aste, un payload più elevato è dovuto ai dati ads dei segmenti di pubblico personalizzati, agli indicatori delle offerte degli utenti e agli indicatori di Android. I payload più elevati potrebbero essere ridotti grazie a:
      1. Far inviare al cliente gli ID di rendering degli annunci (anziché gli oggetti degli annunci) nel payload.
      2. Fare in modo che il client non invii dati pubblicitari nel payload.
      3. Mancato invio degli indicatori di offerta dell'utente nel payload del client.

Sebbene le strategie menzionate sopra consentano ai tecnici pubblicitari di definire configurazioni per gestire la composizione e i limiti del payload di adSelectionData, potrebbero anche diventare un fattore per modulare le dimensioni di adSelectionData modificando i parametri di configurazione. Per evitare che questo accada, la configurazione veniva recuperata giornalmente da Protected Audience dall'endpoint configurato.

Ottimizzazione della latenza

Affinché le aste dei server abbiano un livello di utilità auspicabile, dobbiamo garantire che l'API getAdSelectionData e l'API persistAdSelectionResult abbiano una bassa latenza per chiamata. Anche se puntiamo a fornire il supporto delle funzionalità per le API nel 2023, la nostra prossima release si concentrerà sui benchmark di latenza e sulle ottimizzazioni per le API.

Stiamo esaminando le seguenti strategie per mantenere la latenza entro limiti accettabili:

1. Pre-generazione di dati Protected Audience per venditore: poiché la configurazione dell'asta del venditore e la configurazione del payload dell'acquirente rimarranno stabili per una durata considerevole (giornaliera), la piattaforma potrebbe precalcolare e archiviare i dati idonei di Protected Audience.

   Ciò richiederebbe alla piattaforma di creare un meccanismo per monitorare gli aggiornamenti dei segmenti di pubblico personalizzati e modificare i dati di Protected Audience pregenerati in base agli aggiornamenti. La piattaforma dovrebbe anche dichiarare gli SLO sul ritardo della tecnologia pubblicitaria che 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 di risorse limitate con diverse priorità di processo, riconosciamo che fornire questa struttura di pre-generazione deve offrire alta affidabilità e garanzie SLO.

   Quindi, la pregenerazione dei dati di Protected Audience si baserà su

   1. Attivazione della pregenerazione dei dati Protected Audience da parte del venditore.
   2. Gli acquirenti idonei a partecipare a un'asta avviata da un determinato venditore.
   3. Identificare segmenti di pubblico personalizzati per acquirente che farebbero parte del payload in base a:
      1. Limiti di dimensione per acquirente, priorità per acquirente e limiti di dimensione massimi definiti nella configurazione del venditore
      2. Limite di dimensioni per venditore, priorità del pubblico personalizzato definita nella configurazione dell'acquirente.

2. Applicazione del filtro negativo: se preferita da un venditore, la piattaforma potrebbe precalcolare adSelectionData pregenerando i dati Protected Audience e applicando un filtro negativo alla chiamata getAdSelectionData critica. In questo modo i venditori possono bilanciare la riduzione della latenza e accettare l'obsolescenza nel filtro negativo.

   La piattaforma potrebbe fornire questo supporto fornendo un'opzione predefinita nella configurazione del venditore con un limite di inattività e un'opzione di override in getAdSelectionData per consentire i calcoli più recenti, se necessario. In alternativa, la piattaforma potrebbe fornire un'API di inizializzazione aggiuntiva da chiamare prima del giorno getAdSelectionData per preparare l'asta.

3. Calcolo del payload per più aste: in alcuni scenari, potrebbe essere preferibile avere un'API con prestazioni elevate in termini di latenza, ma a scapito di una maggiore obsolescenza dei dati. A questo scopo, la piattaforma potrebbe introdurre un'API di inizializzazione per calcolare l'intero payload e fornire al chiamante un riferimento al payload calcolato.

   Per le chiamate successive a getAdSelectionData, il chiamante potrebbe fornire riferimento al payload precalcolato da utilizzare per la generazione di adSelectionData.

Tutte e tre le strategie sopra menzionate si trovano nella fase di esplorazione iniziale e hanno lo scopo di descrivere la direzione che la piattaforma potrebbe prendere per ottimizzare per la latenza. Man mano che esploriamo profili di latenza più dettagliati dei requisiti dell'API e della tecnologia pubblicitaria, continueremo a proporre strategie aggiuntive.

Mitigazione e identificazione degli abusi

Come menzionato nella sezione Considerazioni sulla privacy, il valore adSelectionData viene generato utilizzando tutti i dati degli acquirenti presenti sul dispositivo.

Tuttavia, se tutti i dati dell'acquirente sul dispositivo vengono utilizzati per generare l'output adSelectionData, un'entità dannosa potrebbe spacciarsi per acquirente e creare dati fraudolenti sull'acquirente per peggiorare le prestazioni di Android, generare payload eccessivo per aumentare il costo di una tecnologia pubblicitaria per l'esecuzione di aste o aste e così via.

Attenuazione

Alcune misure menzionate nella sezione delle considerazioni sulle dimensioni, ad esempio la configurazione del payload dell'acquirente contenente i venditori nella lista consentita e la configurazione dell'asta del venditore che contiene gli acquirenti nella lista consentita, aiuterebbero a escludere i dati imprevisti nel payload.

Anche altre misure di considerazione delle dimensioni, come consentire alle SSP di specificare la priorità dell'acquirente, posizionare la quota per acquirente nel payload generato e impostare una dimensione massima per payload dell'asta, possono contribuire a mitigare l'impatto del gonfiore di payload dannosi. Queste misure hanno lo scopo di consentire ai tecnici pubblicitari di definire le tecnologie pubblicitarie con cui collaborano e di impostare limiti accettabili per il payload che dovrebbero elaborare.

Come accennato in precedenza, tutte le mitigazioni introdotte per gli antiabuso e le limitazioni relative alle dimensioni devono ottemperare a considerazioni sulla privacy.

Identificazione di entità dannose

Sebbene le mitigazioni sopra menzionate proteggono la generazione adSelectionData per le aste server, non aiutano a identificare entità dannose o a proteggere la piattaforma da comportamenti illeciti, come la creazione di un numero senza precedenti di segmenti di pubblico personalizzati da parte di un acquirente.

Per garantire la stabilità e l'integrità della piattaforma, dobbiamo trovare un meccanismo per identificare le entità dannose, identificare i vettori di abuso e identificare la motivazione degli attacchi specifici. Nelle versioni successive introdurremo video esplicativi che illustrano in dettaglio i potenziali vettori e le protezioni per gli abusi in vigore per contrastarli.