Migliora la latenza dell'asta dell'API Protected Audience

È nell'interesse di tutti assicurarsi che l'API Protected Audience funzioni in modo efficiente:

  • Le persone che navigano sul web vogliono che i siti si carichino rapidamente. Ciò significa che gli sviluppatori dovrebbero creare con l'API Protected Audience in modo efficiente per non sovraccaricare le risorse del dispositivo limitate, come le risorse di calcolo o di rete, necessarie per caricare i siti e i relativi annunci incorporati.
  • Gli editori vogliono che i loro siti si carichino rapidamente, offrendo agli utenti un'esperienza efficiente e reattiva. Gli editori vogliono anche una pubblicità efficace per massimizzare le entrate.
  • Gli inserzionisti e gli esperti di tecnologia pubblicitaria vogliono che i loro annunci vengano visualizzati rapidamente per fornire la massima utilità.

Questo documento illustra alcune best practice per un'implementazione dell'API Protected Audience al fine di garantire la massima efficienza del tuo sito.

Best practice per l'acquirente (offerente)

Per ottimizzare l'efficienza delle aste dell'API Protected Audience, segui queste best practice.

Meno proprietari del gruppo di interesse

Per proteggere gli offerenti dell'API Protected Audience nello stesso modo in cui il browser protegge diverse origini sul web utilizzando l'isolamento dei siti, il browser utilizza risorse costose (come i processi del sistema operativo) per proteggere i singoli proprietari dei gruppi di interesse.

Per ridurre al minimo la spesa di queste risorse molto costose, è fondamentale avere il minor numero di proprietari di gruppi di interesse. Evita di avere gruppi di interesse diversi di proprietà di sottodomini diversi. Ad esempio, se adtech.example avesse gruppi di interesse di proprietà di cats.adtech.example e dogs.adtech.example, è probabile che il browser utilizzi due processi distinti per eseguire gli script di offerta.

Meno offerte per gruppi di interesse

Il browser deve eseguire una configurazione e una preparazione significative prima di richiamare lo script generateBid() di un acquirente, ad esempio deve configurare un nuovo ambiente di esecuzione JavaScript semplice e l'analisi e il caricamento del codice generateBid().

  • I gruppi di interesse che rappresentano utenti che non sono il target corrente di una campagna pubblicitaria attiva devono avere elenchi di creatività degli annunci vuoti. Ciò impedisce all'API Protected Audience di eseguire generateBid() per i gruppi di interesse senza annunci pertinenti.
  • La combinazione di gruppi di interesse simili diminuirà il numero di volte in cui generateBid() deve essere pubblicato. La proprietà userBiddingSignals di un gruppo di interesse può essere utilizzata per memorizzare metadati aggiuntivi sull'utente. In questo modo, un numero inferiore di gruppi di interesse non deve necessariamente indicare un targeting meno efficace.
  • L'API Protected Audience supporta i limiti specificati dal venditore per il numero di gruppi di interesse e un'API che consente agli acquirenti di specificare la priorità relativa dei loro gruppi di interesse. Questi limiti possono essere utilizzati per ridurre notevolmente il numero di script di offerta da eseguire.

Filtrare i gruppi di interesse dalle offerte nel servizio chiavi/valore

Se un acquirente è in grado di stabilire nel server degli indicatori di offerte attendibili in tempo reale che determinati gruppi di interesse non dovrebbero fare offerte (ad es. la campagna è disattivata, in pausa, fuori budget oppure non deve fare offerte per questo particolare publisher), può indicarlo al browser con la risposta priorityVector al recupero degli indicatori di offerte attendibili. Se il prodotto sparse dot risultante di priorityVector e prioritySignals è negativo, il browser ignorerà la richiesta di generateBid() per questo gruppo di interesse. Per ulteriori informazioni su questo meccanismo, consulta la sezione "Filtrare e assegnare la priorità ai gruppi di interesse" nel testo esplicativo.

Riutilizza l'ambiente di esecuzione JavaScript

Prima che il browser possa eseguire generateBid(), deve inizializzare un nuovo ambiente di esecuzione JavaScript. Questa operazione può richiedere molto tempo, in linea con il tempo necessario per l'esecuzione di almeno generateBid(). Questo periodo di tempo può essere salvato utilizzando le modalità di esecuzione raggruppamento per origine o contesto bloccato.

La modalità group-by-origin può riutilizzare gli ambienti di esecuzione nei casi in cui i gruppi di interesse sono uniti sulla stessa origine e probabilmente non richiederà modifiche allo script di offerta. Per saperne di più, consulta la descrizione di group-by-origin nel testo esplicativo. La modalità contesto bloccato può riutilizzare potenzialmente tutti gli ambienti di esecuzione, ma potrebbe richiedere modifiche allo script di offerta. Per saperne di più, consulta la descrizione di frozen-context nel messaggio esplicativo.

Riutilizza gli script di offerta

Se possibile, utilizza lo stesso script di offerta per i gruppi di interesse. In questo modo, il browser non deve scaricare, analizzare e compilare più script (il che comporta richieste di rete aggiuntive). Gli offerenti possono comunque differenziare le offerte in base alle informazioni sul gruppo di interesse (ad es. name o userBiddingSignals) utilizzando lo stesso script.

Riutilizza trustedBiddingSignalsUrls

La latenza di rete e l'utilizzo delle risorse possono essere molto significativi. Un numero minore di recuperi di indicatori di offerta attendibili in tempo reale contribuisce a ridurre questa latenza.

I recuperi degli indicatori di offerta attendibili possono essere combinati quando trustedBiddingSignalsUrl viene riutilizzato tra più gruppi di interesse. Se possibile, utilizza lo stesso trustedBiddingSignalsUrl per tutti i gruppi di interesse.

Specifica le intestazioni di controllo della cache HTTP appropriate per garantire che i recuperi degli indicatori di offerta affidabili vengano memorizzati nella cache nelle aree annuncio di una determinata pagina web. Evita di impostare trustedBiddingSignalsSlotSizeMode su slot-size poiché ciò impedirà la memorizzazione nella cache tra le aree annuncio quando le dimensioni di queste sono diverse, perché l'URL richiesto sarà diverso.

Recuperi di indicatori di offerte attendibili in tempo reale più piccoli

La latenza di rete può essere molto significativa e dipende direttamente dalla quantità di dati trasferiti durante il recupero degli indicatori di offerte attendibili in tempo reale.

Preferisci archiviare dati specifici per gli annunci o i gruppi di interesse nel gruppo di interesse anziché sul servizio di indicatore di offerte attendibili in tempo reale. Prenota i dati sugli indicatori di offerte attendibili in tempo reale solo per gli indicatori realmente in tempo reale, come il budget delle campagne o i kill-switch.

Qualsiasi indicatore che può essere aggiornato su base giornaliera o più lunga deve essere archiviato nel gruppo di interesse e aggiornato utilizzando gli aggiornamenti giornalieri.

Non restituire indicatori di offerta attendibili per i gruppi di interesse che vengono filtrati come descritto nella sezione "Escludere i gruppi di interesse dalle offerte nel servizio chiavi/valore".

Dai priorità ai gruppi di interesse

I venditori utilizzeranno i timeout per limitare il modo in cui le risorse del browser vengono utilizzate nelle pagine dei publisher. Quando gli perBuyerCumulativeTimeouts vengono utilizzati per limitare il tempo a disposizione degli acquirenti per recuperare gli indicatori di offerta attendibili ed eseguire gli script di offerta, è fondamentale che gli acquirenti si assicurino di dare la priorità ai propri gruppi di interesse, in modo che quelli con maggiori probabilità di vincere l'asta vengano eseguiti per primi. Ad esempio, se il valore di perBuyerCumulativeTimeouts è impostato su 100 ms e il recupero degli indicatori di offerta attendibili di un offerente richiede 50 ms e ogni chiamata di generateBid() richiede 10 ms e l'utente ha 10 gruppi di interesse presenti su un dispositivo, solo la metà dei suoi gruppi di interesse avrà la possibilità di calcolare le offerte. In questo esempio, l'acquirente deve dare la priorità ai gruppi di interesse in ordine decrescente.

I gruppi di interesse possono contenere priorità statiche definite nel relativo campo priority. I gruppi basati sugli interessi possono anche utilizzare le priorità dinamiche, che possono essere calcolate tramite il servizio degli indicatori di offerta attendibili e restituite al browser con la risposta priorityVector al recupero degli indicatori di offerta attendibili.

Tieni presente che quando il browser esegue gruppi di interesse dalla priorità più alta a quella più bassa, potrebbero alternare gruppi di interesse da origini di unione diverse, annullando l'ottimizzazione di group-by-origin.

Best practice per i venditori

Assicurati di monitorare e ottimizzare l'asta dell'API Protected Audience per l'efficienza delle aste.

Parallelizzare le aste

Connessioni di rete moderne e processori multi-core sono ideali per svolgere contemporaneamente più attività. Il browser può eseguire un'asta Protected Audience in parallelo con altre attività. Per farlo, è meglio chiamare runAdAuction() il prima possibile. Sapendo che alcuni input per runAdAuction() potrebbero non essere disponibili inizialmente, ad esempio quelli che vengono inviati al browser nella risposta contestuale, il browser consente di chiamare runAdAution() prima che siano disponibili e di fornire questi input in un secondo momento utilizzando Promise JavaScript. Per ottenere la latenza dell'asta più bassa possibile, è necessario chiamare runAdAuction() quando l'input interestGroupBuyers è noto. In questo modo, molte parti dell'asta possono iniziare immediatamente, compreso il recupero degli indicatori delle offerte in tempo reale dell'offerente.

Monitorare le aste

Raccogli le metriche sulle tue aste. Il browser può segnalare metriche di latenza per-buyer ai venditori che forniscono molte informazioni su come il tempo viene trascorso nelle aste di un venditore. I venditori possono utilizzare queste metriche per cercare modi per ottimizzare le aste, ad esempio per capire come impostare i timeout in modo più efficace. I venditori possono condividere con quest'ultimo le metriche di latenza di uno specifico acquirente per agevolare ulteriormente l'ottimizzazione.

Gli offerenti potrebbero avere informazioni sul rendimento delle offerte dei propri gruppi di interesse, ma non essere in grado di confrontarli con quelli di altri offerenti. Il confronto dei tassi di successo relativi e dei tassi di rifiuto delle offerte per diversi offerenti può aiutare a identificare i casi in cui le risorse di calcolo delle offerte sono state sprecate perché i gruppi di interesse non hanno mai prodotto offerte valide o offerte eccessive con creatività non approvate.

Blocca script di offerte lenti

Gli script di offerta che richiedono troppo tempo possono rallentare l'asta dell'API Protected Audience per tutte le persone coinvolte. L'utilizzo dei timeout può impedire aste lente e continuare a recuperare entrate quando l'asta è lenta.

I venditori devono utilizzare perBuyerCumulativeTimeouts per evitare aste lente e per continuare ad accettare offerte quando l'asta lenta e raggiunge il timeout. È preferibile utilizzare perBuyerCumulativeTimeouts anziché perBuyerTimeouts e perBuyerGroupLimits perché perBuyerCumulativeTimeouts non ha consigli sul numero di gruppi di interesse o sulla velocità di generateBid() (ad es. molti gruppi di interesse che fanno offerte rapide e pochi gruppi di interesse che fanno offerte lentamente possono essere completati prima del timeout).

Utilizzare il campo signal della configurazione dell'asta per implementare un timeout complessivo dell'asta è anche una buona idea per evitare aste troppo lunghe nei casi in cui il recupero dell'indicatore del punteggio attendibile e l'esecuzione di scoreAd() richiedono troppo tempo.

Passaggi successivi

Vogliamo interagire con te per assicurarci di creare un'API che funzioni per tutti.

Informazioni sull'API

Come altre API di Privacy Sandbox, questa API è documentata e spiegata pubblicamente.

Sperimenta con l'API

Puoi sperimentare e partecipare alla conversazione sull'API Protected Audience.