Integrazione e ottimizzazione dei servizi di asta e aste

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:

1. Raccogliere e criptare i dati per l'asta del server
2. Invia una richiesta a un servizio venditore non attendibile
3. Ricevere una risposta da un servizio di venditore non attendibile
4. 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:

1. 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.
2. 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:

1. 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.
2. Invia richiesta al servizio di venditori non attendibili: una richiesta HTTP POST o PUT contenente il payload criptato generato dall'API getAdSelectionData al servizio di venditori non attendibili e i dati richiesti dal servizio di venditori non attendibili per generare risultati contestuali.
3. 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.
4. 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 da persistAdSelectionResult 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:

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

1. Il chiamante deve impostare il campo seller nella richiesta, in quanto viene utilizzato per eseguire i controlli di registrazione prima di elaborare la richiesta.
2. Il campo coordinatorOriginUri è facoltativo.
   1. 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.
   2. 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

   3. Se non viene fornita alcuna origine del coordinatore, viene utilizzato il coordinatore predefinito.
   4. 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:

1. adSelectionId: un numero intero opaco per identificare questa invocazione di getAdSelectionData. Il client di tecnologia pubblicitaria deve conservare questo valore adSelectionId perché funge da puntatore alla chiamata getAdSelectionData. Questo identificatore è richiesto dall'API persistAdSelectionResult per decriptare il risultato dell'asta dal server di offerte e aste ed è richiesto anche dalle API reportImpression e reportEvent.
2. adSelectionData: si tratta dei dati dell'asta criptati necessari al server di Bidding and Auction per eseguire le aste. Questo metodo contiene:
   1. 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.
   2. 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:

1. Se getAdSelectionData viene avviato con argomenti non validi, AdServicesException indica un'eccezione IllegalArgumentException come causa.
2. Tutti gli altri errori ricevono un AdServicesException con un IllegalStateException 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);
}

1. adSelectionId: l'identificatore opaco generato dalla chiamata getAdSelectionData il cui risultato il chiamante vuole decriptare.
2. seller: l'identificatore della tecnologia pubblicitaria del venditore deve essere impostato nella richiesta di esecuzione dei controlli di registrazione prima di elaborare la richiesta.
3. 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: il adSelectionId 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:

1. Se getAdSelectionData viene avviato con argomenti non validi, AdServicesException indica un 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 perdita di dati può verificarsi a causa delle dimensioni di adSelectionData. Le dimensioni adSelectionData possono variare a causa di:

1. Modifiche ai dati di CustomAudience presenti sul dispositivo.
2. Modifiche alla logica di filtraggio di CustomAudience.
3. 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:

1. 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.

2. 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 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 nell'allowlist. Recupereremo 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 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.

3. 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 richiesta getAdSelectionData.

   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:

   1. 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.
   2. 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.
   3. 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.
   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 dimensione massima rispetterebbe i bucket di dimensioni fisse impostati dall'API Protected Audience.

4. Modifiche ai segmenti di pubblico personalizzati

   1. 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 su 0.0 per impostazione predefinita.

5. Modifiche ai dati di payload

   1. 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:
      1. Il cliente invia gli ID rendering annuncio (anziché gli oggetti annuncio) nel payload.
      2. Il client non invia dati pubblicitari nel payload.
      3. Non inviare indicatori di offerta dell'utente nel payload client.

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:

1. 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

   1. Attivazione da parte del venditore della pre-generazione dei dati Protected Audience.
   2. Gli acquirenti idonei a partecipare a un'asta avviata da un determinato venditore.
   3. Identificazione dei segmenti di pubblico personalizzati per acquirente che faranno 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à del segmento di pubblico personalizzato definita nella configurazione dell'acquirente.

2. 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 chiamata getAdSelectionData 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 di getAdSelectionData per il riscaldamento dell'asta.

3. 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 di adSelectionData.

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.