Questa pagina è stata tradotta dall'API Cloud Translation.

Integrazione e ottimizzazione dei servizi di asta e aste

La proposta di progettazione dei servizi di offerte e aste per Android descrive nel dettaglio l'esecuzione e il flusso di dati dell'esecuzione di aste su Android utilizzando le offerte attendibili e il server delle aste. 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.

Illustrazione del flusso del pubblico protetto. Tre colonne rappresentano il modo in cui i dati vengono spostati tra i dispositivi, i servizi venditori non attendibili e un ambiente di esecuzione affidabile. — Flusso di aste di Protected Audience.

Per eseguire l'asta come descritto in precedenza, l'ad tech del venditore sul dispositivo deve eseguire i seguenti passaggi:

Raccogli e cripta i dati per l'asta sul server
Inviare una richiesta a un Servizio venditore non attendibile
Ricevere una risposta da un Servizio venditore non attendibile
Decripta la risposta all'asta Protected Audience e ricevi il risultato dell'asta

Protected Audience sta introducendo due nuove API per supportare l'esecuzione di aste del 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 offerte e il server di aste utilizza questo payload per eseguire un'asta, generare il risultato dell'asta e restituire il risultato dell'asta.
I client ad tech on-device possono chiamare l'API persistAdSelectionResult per decriptare il risultato generato dall'asta 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:

Raccogliere e criptare i dati per il venditore asta del server: l'ad tech deve chiamare l'API getAdSelectionData per ottenere il payload criptato.
Invia una richiesta al servizio di invio del servizio del venditore non attendibile: una richiesta HTTP POST o PUT contenente il payload criptato generato dall'API getAdSelectionData al suo servizio venditore non attendibile e i dati richiesti dal servizio venditore non attendibile per generare risultati contestuali.
Ricevi risposta dal servizio non attendibile del venditore: la risposta da un servizio venditore non attendibile conterrebbe il risultato dell'asta protetto criptato del pubblico e il risultato dell'asta contestuale.
Decriptare la risposta all'asta del segmento di pubblico protetto e ottenere il risultato dell'asta: per decriptare il risultato dell'asta del segmento di pubblico protetto, la tecnologia pubblicitaria del venditore deve chiamare l'API persistAdSelectionResult. Il risultato generato da persistAdSelectionResult aiuterà le tecnologie pubblicitarie a determinare se l'annuncio contestuale o l'annuncio con pubblico protetto ha vinto l'asta e l'URI dell'annuncio con pubblico protetto vincente, se applicabile.

Funzionalità supportate per l'asta server

Il nostro obiettivo è supportare tutte le funzioni attualmente disponibili per l'asta on-device. Le tempistiche per il supporto di queste funzionalità nell'asta 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 2023	T3 '23	N/A	T4 '23
Mediazione a cascata	T1 2023	T4 '23	N/A	T1 24
Filtro per quota limite	T2 '23	T3 '23	N/A	T4 '23
Trasmettere gli annunci contestuali al flusso di lavoro per la selezione degli annunci per l'applicazione di filtri	T2 '23	T1 2024	N/A	N/A
Report sulle interazioni	T2 '23	T3 '23	N/A	T4 '23
Partecipare alla delega dei segmenti di pubblico personalizzati	T3 '23	T4 '23	N/A	T4 '23
fatturazione non CPM	T3 '23	T4 '23
Report di debug	T3 '23	T4 '23	T3 '23	T4 '23
Mediazione Open Bidding	N/A	N/A	N/A	T1 2024
Filtro degli annunci per l'installazione di app	T2 '23	T1 2024	N/A	T1 2024
Gestione della valuta	N/A	N/A	N/A	T1 2024
Integrazione K-anon	N/A	T1 2024	N/A	T1 2024
Integrazione di aggregazione privata	N/A	N/A	N/A	T3 2024

Esegui aste server utilizzando le API Protected Audience

Nel canale Anteprima per sviluppatori, AdSelectionManager espone due nuove API: getAdSelectionData e persistAdSelectionResult. Queste API consentono l'integrazione degli SDK ad tech con i server di asta e di asta.

Raccogli e cripta i dati per un'asta sul server

L'API getAdSelectionData genera l'input richiesto per i componenti di asta e asta come BuyerInput e ProtectedAudienceInput e cripta i dati prima di renderli disponibili al 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 ottimizzarla 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 manifest del 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 perché viene utilizzato per eseguire i controlli di registrazione prima di gestire la richiesta.

public class GetAdSelectionDataRequest {
  Public setSeller(AdTechIdentifier seller);
}

Dopo la convalida della richiesta, i dati dell'acquirente sul dispositivo 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:

adSelectionId: un numero intero opaco per identificare questa chiamata di getAdSelectionData. Il client di ad tech deve 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 offerte e dal server delle aste, oltre che dalle API reportImpression e reportEvent.
adSelectionData: questi sono i dati criptati delle aste che sarebbero necessari per i server delle offerte e per le aste per poter eseguire le aste. Questo metodo contiene:
1. Dati sui segmenti di pubblico personalizzati filtrati in base a quota limite, filtri per l'installazione di app e 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 correttamente per motivi quali argomenti non validi, timeout o un 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 di tipo IllegalArgumentException.
Tutti gli altri errori ricevono un AdServicesException con IllegalStateException come causa.

Inviare una richiesta a un servizio di 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 in termini di spazio, come inviare la richiesta al servizio di annunci del venditore come multipart/form-data.

Ricevere una risposta da un servizio venditore non attendibile

Come descritto in dettaglio nel spiegamento esplicativo del server delle offerte e del 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 delle offerte e delle aste in esecuzione in un TEE.

Al termine dell'asta Protected Audience, il servizio SellerFrontEnd cripta il risultato dell'asta e lo restituisce in risposta al servizio 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.

Una volta ricevuta la risposta, il codice ad tech del venditore sul dispositivo potrebbe scegliere di utilizzare solo l'annuncio contestuale nella risposta oppure, se ritiene che ci sia un valore incrementale per ottenere il risultato di Protected Audience, può scegliere di decriptare il risultato di Protected Audience chiamando l'API PersistAdSelectionResult.

API PersistAdSelectionResult

Per decriptare il risultato di Protected Audience, l'ad tech del venditore può chiamare la seconda API Protected Audience persistAdSelectionResult. L'API decripta il risultato e restituisce un AdSelectionOutcome, lo stesso oggetto restituito oggi da un'asta on-device.

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 chiamante 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 chiamata getAdSelectionData di cui il chiamante vuole decriptare il risultato.
seller: per eseguire i controlli di registrazione prima di gestire la richiesta, è necessario impostare l'identificatore ad tech del venditore nella richiesta.
adSelectionResult: il risultato dell'asta criptato generato dal server di offerte e dall'asta che il chiamante vuole decriptare.

Risposta AdSelectionResult

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

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

Errori, eccezioni e gestione degli errori

Se getAdSelectionData viene avviato con argomenti non validi, AdServicesException indica IllegalArgumentException come causa.
Tutti gli altri errori ricevono un AdServicesException con IllegalStateException come causa.

Considerazioni sulla privacy

adSelectionData è criptato per garantire che i dati in transito siano accessibili solo alla PPAPI e ai server attendibili.

Nonostante la crittografia, potrebbe verificarsi una fuga di dati a causa della dimensione adSelectionData. La dimensione di adSelectionData può variare per i seguenti motivi:

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

È possibile utilizzare la modifica delle dimensioni di adSelectionData per generare un identificatore cross-app, come indicato nella disciplina delle fughe di dati a 1 bit. Molte mitigazioni applicabili alle fughe di dati 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 mascherare le variazioni di dimensioni. Limita anche l'influenza dei parametri di input GetAdSelectionData sui valori generati di adSelectionData.

Tuttavia, generare lo 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 di ad tech. L'utilizzo di tutti i segmenti di pubblico personalizzati on-device per generare payload per l'asta apre inoltre l'ecosistema all'abuso di entità dannose. Abbiamo affrontato questi problemi nelle sezioni Ottimizzazioni delle dimensioni e Mitigazioni degli abusi 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 all'ad tech server. Per ridurre al minimo la latenza e i costi di round trip, è necessario ridurre il più possibile le dimensioni di adSelectionData senza influire sull'utilità.

Abbiamo in programma di esplorare e introdurre potenzialmente le seguenti ottimizzazioni nelle prossime release per ridurre le dimensioni di adSelectionData:

Payload generato in un set fisso di dimensioni dei bucket con spaziatura interna: per ridurre al minimo la perdita dovuta alle variazioni di dimensioni, consentendo comunque carichi di payload inferiori, suggeriamo di utilizzare bucket di dimensioni fisse per il payload generato. Limitare il numero di bucket, ad esempio: sette porteranno a una perdita di entropia inferiore a 3 bit per chiamata a getAdSelectionData.

Se i dati sul dispositivo superano la dimensione massima del bucket, verranno utilizzate le strategie menzionate di seguito, come i valori di priorità, per decidere quali dati vengono eliminati.
Configurazione acquirente: stiamo valutando la fattibilità di consentire agli acquirenti di impostare una configurazione del payload per acquirente. Questa configurazione è utile per identificare le aste alle quali 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 espongono un'API per consentire ai tecnici pubblicitari degli acquirenti di registrare questo endpoint.

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

La configurazione del payload dell'acquirente consente 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 incluso nella lista consentita. Recuperiamo la configurazione del payload con una cadenza giornaliera per mantenere aggiornata la lista consentita.
2. Limite di dimensioni per venditore: l'acquirente può specificare un limite di dimensioni per venditore al fine di determinare la dimensione dei dati da inviare nel payload quando un'asta viene avviata da un determinato venditore. Questo è utile se un acquirente vuole destinare più risorse all'elaborazione dei dati delle aste di determinati venditori. SellerFrontendService inoltra solo dati specifici dell'acquirente a ogni BuyersFrontendService. Pertanto, definendo un limite di dimensioni per venditore, un acquirente potrebbe controllare in modo esplicito la quantità di dati importati ed elaborati dal servizio BuyersFrontendService del suo server di offerte e aste per le aste eseguite da un venditore.
Configurazione del venditore: stiamo valutando la fattibilità di una configurazione di asta per venditore che consentirebbe ai venditori di definire i parametri dell'asta per controllare le dimensioni del payload e i partecipanti all'asta. Se possibile, durante la registrazione l'ad tech del venditore potrebbe specificare l'endpoint da cui Protected Audience potrebbe recuperare la configurazione dell'asta per venditore a 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 l'insieme di acquirenti che si aspettano di vedere in un'asta e i limiti relativi al contributo per acquirente alle dimensioni del payload.

La configurazione dell'asta del venditore consente ai venditori di specificare:
1. Elenco di acquirenti consentiti: per le aste avviate dal venditore in questione, solo gli acquirenti nella lista consentita potranno contribuire con i segmenti di pubblico personalizzati per l'asta. La configurazione dell'asta deve essere aggiornata quotidianamente per mantenere la lista consentita al passo con la lista consentita degli acquirenti lato server.
2. Limite di dimensioni per acquirente: i venditori possono specificare un limite per acquirente al fine di 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.
3. Priorità per acquirente: consente ai venditori di impostare la priorità in base all'acquirente. La priorità dell'acquirente verrebbe utilizzata per identificare quali dati dell'acquirente devono essere conservati nel payload se la dimensione del payload supera il limite previsto.
4. 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 dimensioni massime rispetterebbe i bucket con dimensioni fisse impostati dall'API Protected Audience.
Modifiche ai segmenti di pubblico personalizzati
1. Specifica la priorità del segmento di pubblico personalizzato: consenti agli acquirenti di specificare un valore di priorità in un segmento di pubblico personalizzato. Il campo priority verrebbe utilizzato per identificare i segmenti di pubblico personalizzati che devono essere inclusi 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.
Modifiche ai dati del payload
1. Riduci i dati inviati nel payload: come descritto in Ottimizzazione del payload dei servizi per offerte e aste, un payload più elevato si basa sui dati dei segmenti di pubblico personalizzati ads, sugli indicatori delle offerte degli utenti e sugli indicatori di Android. Un payload maggiore potrebbe essere ridotto tramite:
  1. Fare in modo che il client invii gli ID di rendering dell'annuncio (anziché gli oggetti annuncio) nel payload.
  2. Fare in modo che il client non invii dati pubblicitari nel payload.
  3. Mancata invio degli indicatori di offerta dell'utente nel payload del client.

Sebbene le strategie menzionate sopra permettano alle tecnologie pubblicitarie di definire le configurazioni per gestire la composizione e i limiti del payload di adSelectionData, potrebbero anche diventare un fattore per la modulazione delle dimensioni di adSelectionData cambiando i parametri di configurazione. Per evitare che questo accada, la configurazione viene recuperata ogni giorno da Protected Audience dall'endpoint configurato.

Ottimizzazione della latenza

Affinché le aste server abbiano un livello di utilità desiderabile, 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 release successiva si concentrerà sui benchmark e sulle ottimizzazioni di latenza per le API.

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

Pregenerazione 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 Protected Audience pregenerati in base agli aggiornamenti. La piattaforma dovrà anche dichiarare gli SLO sulla gara che la tecnologia pubblicitaria con ritardo potrebbe prevedere tra gli aggiornamenti dei segmenti di pubblico personalizzati e il rilevamento della modifica nei adSelectionData" generati per l'asta del server.

Poiché un dispositivo fornisce un modello di calcolo delle risorse limitato con priorità di processo diverse, riconosciamo che per fornire questa struttura di pre-generazione è necessario garantire un'elevata affidabilità e garanzie di SLO.

La pregenerazione dei dati di Protected Audience sarebbe quindi basata su
1. Attiva la pregenerazione dei dati Protected Audience da parte del venditore.
2. Acquirenti idonei a partecipare a un'asta avviata da un determinato venditore.
3. Identificazione dei segmenti di pubblico personalizzati per acquirente che fa parte del payload in base a:
  1. Limiti di dimensioni per acquirente, priorità per acquirente e limiti di dimensioni massime definiti nella configurazione del venditore,
  2. Limite di dimensioni per venditore, priorità dei segmenti di pubblico personalizzati definita nella configurazione dell'acquirente.
Applicazione forzata di filtri negativi: se preferito da un venditore, la piattaforma potrebbe precalcolare adSelectionData pregenerando dati di Protected Audience e applicando un filtro negativo sulla chiamata getAdSelectionData critica. In questo modo, i venditori possono bilanciare la riduzione della latenza e il livello di obsolescenza nei filtri negativi.

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.
Calcolo del payload per più aste: in alcuni scenari, potrebbe essere preferibile avere un'API con prestazioni di latenza a costo 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 adSelectionData.

Tutte e tre le strategie menzionate sopra sono nella fase di esplorazione iniziale e hanno lo scopo di descrivere la direzione che la piattaforma potrebbe intraprendere per ottimizzare per la latenza. Man mano che esploreremo profili di latenza più dettagliati dei requisiti API e ad tech, continueremo a proporre strategie aggiuntive.

Mitigazione e identificazione degli abusi

Come menzionato nelle considerazioni sulla privacy, il valore 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 presentarsi come acquirente e creare dati fraudolenti per l'acquirente per ridurre il rendimento di Android, gonfiare il payload per aumentare il costo di una tecnologia pubblicitaria per le aste o l'esecuzione di offerte e così via.

Attenuazione

Alcune misure menzionate nella sezione relativa alle dimensioni, come la configurazione del payload dell'acquirente contenente venditori nella lista consentita e la configurazione delle aste dei venditori contenenti acquirenti nella lista consentita, potrebbero contribuire a escludere dati imprevisti nel payload.

Anche altre misure per la considerazione delle dimensioni, come consentire alle SSP di specificare la priorità dell'acquirente, l'inserimento della quota per acquirente nel payload generato e l'impostazione di una dimensione massima per payload di asta possono contribuire a mitigare l'impatto del gonfiore del payload dannoso. Queste misure hanno lo scopo di consentire ai tecnici pubblicitari di definire con quale tecnologia pubblicitaria collaborare e di impostare limiti accettabili per il payload che dovrebbero elaborare.

Come accennato in precedenza, tutte le misure di mitigazione introdotte per le restrizioni contro i comportamenti illeciti e le dimensioni devono rispettare le considerazioni sulla privacy.

Identificazione di entità dannose

Sebbene le mitigazioni menzionate sopra tutelino la generazione di adSelectionData per le aste dei server, non consentono di identificare entità dannose né di proteggere la piattaforma da abusi 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 abusi e identificare la motivazione degli attacchi specifici. Nelle versioni successive, introdurremo degli esplicativi che descrivono in dettaglio i potenziali vettori di abusi e le protezioni da adottare per contrastare questi comportamenti.