Integrazione e ottimizzazione dei servizi di asta e aste

bookmark_border Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

La proposta di progettazione dei servizi di offerte e aste per Android descrive in dettaglio l'esecuzione e il flusso di dati delle aste in esecuzione su Android utilizzando il server Trusted Bidding and Auction. Per garantire che i dati in transito vengano gestiti solo da API che rispettano la privacy e da server attendibili, i dati vengono criptati tra il client e il server utilizzando la crittografia con 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. Raccogliere e criptare i dati per l'asta del server
2. Inviare una richiesta a un servizio di 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 asta e offerte utilizza questo payload per eseguire un'asta, generare il risultato dell'asta e restituirlo.
2. I client 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.

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 del venditore non attendibile Invia: una richiesta HTTP POST o PUT contenente il payload criptato generato dall'API getAdSelectionData al servizio del venditore non attendibile e i dati richiesti dal servizio del venditore non attendibile per generare risultati contestuali.
3. Ricevere una risposta dal servizio del venditore non attendibile: la risposta del servizio del venditore non attendibile 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à gli esperti di tecnologia pubblicitaria a determinare se l'annuncio contestuale o l'annuncio per pubblico protetto ha vinto l'asta e l'URI dell'annuncio per 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. Ecco le tempistiche per il supporto di queste funzionalità nell'asta del server:

Eseguire aste 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 di asta e di offerta.

Raccogliere e criptare i dati per un'asta del server

L'API getAdSelectionData genera l'input richiesto per i componenti di offerte e aste, come BuyerInput e ProtectedAudienceInput, e cripta i dati prima di rendere disponibile il risultato per il chiamante. Per evitare la fuga 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, l'accesso all'API Protected Audience deve essere abilitato e l'autorizzazioneACCESS_ADSERVICES_CUSTOM_AUDIENCE deve essere definita nel manifest dell'autore dell'accesso.

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

GetAdSelectionDataRequest

1. L'utente che chiama deve impostare il campo seller nella richiesta perché viene utilizzato per eseguire controlli di registrazione prima di soddisfare 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:

      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 l'origine del coordinatore, viene utilizzato il coordinatore predefinito.
   4. Sebbene sia altamente improbabile che l'URL del coordinatore venga modificato, ti consigliamo vivamente di implementare un meccanismo per gestire questo URL in modo dinamico. 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 del payload finale viene quindi criptato utilizzando la crittografia con 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 deve mantenere costante questo valore adSelectionId perché funge da puntatore alla chiamata getAdSelectionData. Questo identificatore è richiesto dall'API persistAdSelectionResult per decriptare il risultato dell'asta dal server Bidding e Auction ed è richiesto anche dalle API reportImpression e reportEvent.
2. adSelectionData: si tratta dei dati dell'asta criptati che sarebbero richiesti dal server Bidding and Auction per eseguire le aste. Questo metodo contiene:
   1. Dati filtrati dei segmenti di pubblico personalizzati in base alla quota limite, ai filtri di installazione di app e ai requisiti per le aste di 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 di selezione degli annunci non può essere completata correttamente per 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.

Inviare una richiesta a un servizio di vendita non attendibile

Utilizzando 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. Ti consigliamo di utilizzare una soluzione che occupi poco spazio, ad esempio inviando la richiesta al servizio pubblicitario del venditore come multipart/form-data.

Ricevere una risposta da un servizio del venditore non attendibile

Come descritto nella spiegazione di aste e server di offerte, 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 aste e offerte 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 del venditore non attendibile invia al dispositivo una risposta contenente un annuncio contestuale e / o il risultato dell'asta Protected Audience criptato.

Una volta ricevuta la risposta, il codice ad tech del venditore sul dispositivo può scegliere di utilizzare solo l'annuncio contestuale nella risposta oppure, se ritiene che il risultato Protected Audience abbia un valore incrementale, 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 sul dispositivo oggi.

Per accedere all'API, l'utente che chiama deve attivare 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

L'utente che effettua la chiamata 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 per eseguire i controlli di registrazione prima di soddisfare la richiesta.
3. adSelectionResult: il risultato dell'asta criptato generato dal server Bidding e Auction che l'utente che chiama vuole decriptare.

Risposta AdSelectionOutcome

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

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

Errori, eccezioni e gestione degli errori

Se la generazione dei dati di selezione degli annunci non può essere completata correttamente per 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 viene criptato per garantire che i dati in transito siano accessibili solo a PPAPI e ai server attendibili.

Nonostante la crittografia, può verificarsi una fuga di dati a causa delle dimensioni di adSelectionData. Le dimensioni del adSelectionData possono variare a causa di:

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

La modifica delle dimensioni di adSelectionData può essere utilizzata per generare un identificatore tra app come indicato nella discussione sulla fuga di dati di 1 bit. Molte delle mitigazioni applicabili alla fuga di 1 bit sono applicabili anche in questo caso.

Per gestire queste fughe, prevediamo di generare lo stesso adSelectionData per tutte le chiamate all'API getAdSelectionData. Nelle release iniziali, tutte le CustomAudiences sul dispositivo vengono utilizzate per creare adSelectionData e il payload criptato verrà riempito per mascherare le variazioni di dimensioni. Inoltre, limiteremo l'influenza dei parametri di input GetAdSelectionData su adSelectionData generato.

Tuttavia, la generazione dello stesso adSelectionData per tutte le ad tech che utilizzano tutti i dati delle aste on-device crea un payload di grandi dimensioni 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 a possibili abusi da parte di enti malintenzionati. Abbiamo trattato questi problemi nelle sezioni Ottimizzazioni delle dimensioni e Mitigazioni degli abusi di seguito.

Ottimizzazioni delle dimensioni

L'SDK client ad tech deve pacchettizzare i byte criptati di adSelectionData nella chiamata contestuale HTTP PUT/POST effettuata al server ad tech. Per ridurre la latenza e il costo del tempo di percorrenza, è necessario ridurre il più possibile le dimensioni del adSelectionData senza influire sull'utilità.

Prevediamo di esplorare e potenzialmente introdurre le seguenti ottimizzazioni nelle release future per ridurre le dimensioni di adSelectionData:

1. Payload generato in un insieme fisso di dimensioni dei bucket con spaziatura: per minimizzare le perdite dovute alle variazioni di dimensione, consentendo al contempo payload inferiori, consigliamo di utilizzare il bucketing con dimensioni fisse per il payload generato. Mantenendo il numero di bucket ridotto, ad esempio 7, si avranno meno di 3 bit di entropia trapelata per chiamata a getAdSelectionData.

   Se i dati sul dispositivo superano le dimensioni massime del bucket, verranno utilizzate le strategie riportate di seguito, ad esempio i valori di priorità, per decidere quali dati eliminare.

2. Configurazione dell'acquirente: stiamo valutando la fattibilità di consentire agli acquirenti di configurare un payload per acquirente. Questa configurazione è utile per identificare le aste a cui un acquirente è interessato a partecipare. Se possibile, durante la registrazione, una tecnologia pubblicitaria per gli acquirenti potrebbe registrare un endpoint da cui Protected Audience recupererebbe la configurazione del payload con una cadenza regolare giornaliera. In alternativa, le API che tutelano la privacy esporrebbero un'API per consentire alle tecnologie pubblicitarie per gli acquirenti di registrare questo endpoint.

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

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

   1. Elenco di venditori consentiti: i segmenti di pubblico personalizzati dell'acquirente verranno aggiunti al payload solo se la chiamata getAdSelectionData viene avviata da un venditore presente nella lista consentita. 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 ciascun BuyerFrontendService. Pertanto, definendo un limite di dimensioni per venditore, un acquirente può controllare esplicitamente la quantità di dati importati ed elaborati da BuyerFrontendService del server di aste e offerte 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 con una cadenza regolare. Questa configurazione verrà poi utilizzata per determinare la composizione e i limiti di adSelectionData generato per ogni richiesta getAdSelectionData.

   Analogamente alla configurazione per acquirente, una configurazione per venditore consentirebbe ai venditori di specificare l'insieme di acquirenti che 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 consente ai venditori di specificare:

   1. Elenco di acquirenti consentiti: per le aste avviate dal venditore in questione, solo gli acquirenti nell'elenco consentiti potranno contribuire con segmenti di pubblico personalizzati per l'asta. La configurazione dell'asta deve essere aggiornata quotidianamente per mantenere aggiornata la lista consentita con la lista consentita dell'acquirente lato server.
   2. Limite di dimensione 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 dimensione per acquirente, verrà utilizzata la priorità del segmento di pubblico personalizzato 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 viene utilizzata per identificare i dati dell'acquirente da conservare nel payload se la dimensione del payload supera il limite.
   4. Limite di dimensione massima per il payload: venditori diversi potrebbero avere una diversa allocazione delle risorse e potrebbero voler impostare un limite di dimensione massima per il payload dell'asta per richiesta. Il limite di dimensione massima rispetterà 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 degli acquirenti supera i limiti di dimensione per venditore o per acquirente. Un valore di priorità non specificato in un segmento di pubblico personalizzato è 0.0 per impostazione predefinita.

5. Modifiche ai dati di payload

   1. Riduci i dati inviati nel payload: come descritto in Ottimizzazione del payload per i servizi di offerte e aste, un payload più elevato è generato da dati ads dei segmenti di pubblico personalizzati, indicatori di offerte per gli utenti e indicatori Android. I payload più elevati potrebbero essere ridotti:
      1. Il cliente deve inviare gli ID di rendering degli annunci (anziché gli oggetti annuncio) nel payload.
      2. Il client non invia dati dell'annuncio nel payload.
      3. Non vengono inviati indicatori per le offerte per gli utenti nel payload del client.

Sebbene le strategie sopra menzionate consentano agli esperti di tecnologia pubblicitaria di definire configurazioni per gestire la composizione e i limiti del payload adSelectionData, potrebbero anche diventare un fattore per modulare le dimensioni del adSelectionData modificando i parametri di configurazione. Per evitare ciò, la configurazione verrà recuperata quotidianamente da Protected Audience dall'endpoint configurato.

Ottimizzazione della latenza

Affinché le aste di server abbiano un livello di utilità auspicabile, dobbiamo assicurarci che le API getAdSelectionData e persistAdSelectionResult abbiano una latenza bassa per chiamata. Anche se il nostro obiettivo è fornire il supporto delle funzionalità per le API nel 2023, la nostra release successiva si concentrerà su benchmark e ottimizzazioni della latenza per le API.

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

1. Pregenerazione dei dati di Protected Audience per venditore: poiché la configurazione dell'asta del venditore e la configurazione del payload dell'acquirente saranno stabili per una durata considerevole (giornaliera), la piattaforma potrebbe precalcolare e memorizzare i dati di Protected Audience idonei.

   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 deve anche dichiarare gli SLO relativi al ritardo della gara che la tecnologia pubblicitaria potrebbe prevedere tra gli aggiornamenti dei segmenti di pubblico personalizzati e la visualizzazione della variazione in adSelectionData generata per l'asta del server.

   Poiché un dispositivo fornisce un modello di calcolo delle risorse limitato con priorità di processo diverse, siamo consapevoli che la fornitura di questa funzionalità di pre-generazione deve essere accompagnata da garanzie di elevata affidabilità e SLO.

   La pregenerazione dei dati del segmento di pubblico protetto si baserà quindi su

   1. Il venditore attiva la pregenerazione dei dati di Protected Audience.
   2. Acquirenti idonei a partecipare a un'asta avviata da un determinato venditore.
   3. Identificazione dei segmenti di pubblico personalizzati per acquirente che fanno 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 definito nella configurazione dell'acquirente.

2. Applicazione anticipata del filtro negativo: se un venditore preferisce, la piattaforma può precompilare il valore adSelectionData generando in anticipo i dati di Protected Audience e applicando il filtro negativo alla chiamata getAdSelectionData critica. In questo modo, i venditori potrebbero ridurre la latenza, accettando al contempo la mancata aggiornamento dei filtri esclusi.

   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 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 avere un'API con prestazioni in termini di latenza a costo di un aumento dell'obsolescenza dei dati. Per fornire questo servizio, la piattaforma potrebbe introdurre un'API di inizializzazione per calcolare l'intero payload e fornire un riferimento al chiamante per il payload calcolato.

   Per le chiamate successive a getAdSelectionData, l'utente che chiama potrebbe fornire il riferimento al payload precalcolato da utilizzare per la generazione di adSelectionData.

Tutte e tre le strategie sopra menzionate sono nella fase di esplorazione iniziale e hanno lo scopo di descrivere la direzione che la piattaforma potrebbe intraprendere per l'ottimizzazione in base alla 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 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'outputadSelectionData, un'entità malintenzionata potrebbe spacciarsi per un acquirente e creare dati dell'acquirente fraudolenti per degradare le prestazioni di Android, aumentare il payload per aumentare il costo per un'ad tech di gestire aste o offerte e così via.

Attenuazione

Alcune misure menzionate nella sezione Considerazioni sulle dimensioni, come la configurazione del payload dell'acquirente contenente venditori inclusi nella lista consentita e la configurazione dell'asta del venditore contenente acquirenti inclusi nella lista consentita, possono essere utili per escludere i dati imprevisti nel payload.

Anche altre misure relative alle 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 il payload dell'asta, possono contribuire ad attenuare l'impatto del bloating del payload dannoso. Queste misure hanno lo scopo di consentire alle tecnologie pubblicitarie di definire con quali altre tecnologie pubblicitarie collaborano e di impostare limiti accettabili per il payload da elaborare.

Come accennato in precedenza, tutte le misure di mitigazione introdotte per le limitazioni anti-abuso e di dimensione devono rispettare le considerazioni sulla privacy.

Identificazione di entità dannose

Sebbene le misure di mitigazione sopra menzionate proteggano la generazione di adSelectionData per le aste di server, non aiutano a identificare entità dannose 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 garantire 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 release successive, introdurremo video esplicativi che descrivono nel dettaglio i potenziali vettori di abuso e le protezioni messe in atto per contrastarli.