Migliora la latenza dell'asta dell'API Protected Audience

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

• Gli utenti che navigano sul web vogliono che i siti si carichino rapidamente. Ciò significa che gli sviluppatori devono creare in modo efficiente con l'API Protected Audience per non utilizzare in modo eccessivo le risorse limitate dei dispositivi, come le risorse di calcolo o di rete, necessarie per caricare i siti e i relativi annunci incorporati.
• I publisher vogliono che i loro siti vengano caricati rapidamente, offrendo agli utenti un'esperienza efficiente e adattabile. Anche i publisher vogliono pubblicità efficace per massimizzare le proprie entrate.
• Gli inserzionisti e le ad tech vogliono che i loro annunci vengano visualizzati rapidamente per offrire la massima utilità.

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

Best practice per gli acquirenti (offerente)

Per assicurarti di eseguire l'ottimizzazione in base all'efficienza delle aste dell'API Protected Audience, segui queste best practice.

Meno proprietari di gruppi di interesse

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

Per ridurre al minimo la spesa di queste risorse molto costose, è fondamentale avere il numero minimo di proprietari di gruppi di interesse. Evita di avere gruppi di interesse diversi di proprietà di vari sottodomini. Ad esempio, se adtech.example ha gruppi di interesse di proprietà di cats.adtech.example e dogs.adtech.example, il browser probabilmente utilizzerà due procedure distinte per eseguire i propri script di offerta.

Meno gruppi di interesse che fanno offerte

Il browser deve eseguire una configurazione e una preparazione significative prima di invocare lo script generateBid() di un acquirente, ad esempio impostare un nuovo ambiente di esecuzione JavaScript pulito e analizzare e caricare il codice generateBid().

• I gruppi di interesse che rappresentano gli utenti che non sono attualmente il target di una campagna pubblicitaria attiva devono avere elenchi di creatività degli annunci vuoti. In questo modo, l'API Protected Audience non eseguirà generateBid() per i gruppi di interesse senza annunci pertinenti.
• La combinazione di gruppi di interesse simili riduce il numero di volte generateBid() deve essere eseguito. La proprietà userBiddingSignals di un gruppo di interessi può essere utilizzata per archiviare metadati aggiuntivi sull'utente, pertanto un numero inferiore di gruppi di interessi non deve necessariamente comportare un targeting meno efficace.
• L'API Protected Audience supporta limiti specificati dal venditore al numero di gruppi di interesse e un'API che consente agli acquirenti di specificare la priorità relativa dei propri gruppi di interesse. Questi limiti possono essere utilizzati per ridurre notevolmente il numero di script di offerta da eseguire.

Escludere i gruppi di interesse dalle offerte nel servizio Key/Value

Se un acquirente può determinare nel proprio server di indicatori delle offerte attendibili in tempo reale che determinati gruppi di interesse non devono fare offerte (ad es. la campagna è disattivata, in pausa o fuori budget oppure non deve fare offerte per questo publisher specifico), può indicarlo al browser con la risposta priorityVector al recupero degli indicatori delle offerte attendibili. Se il prodotto scalare sparso risultante di priorityVector e prioritySignals è negativo, il browser salta l'invocazione di generateBid() per questo gruppo di interesse. Puoi scoprire di più su questo meccanismo nella sezione"Filtro e definizione della priorità dei gruppi di interesse" della spiegazione.

Riutilizzare l'ambiente di esecuzione di JavaScript

Prima che il browser possa eseguire generateBid(), deve inizializzare un nuovo ambiente di esecuzione JavaScript. L'operazione può richiedere molto tempo, in linea con il tempo necessario per l'esecuzione di un generateBid() minimo. Questo tempo può essere risparmiato utilizzando le modalità di esecuzione Gruppo per origine o Contesto congelato.

La modalità group-by-origin può riutilizzare gli ambienti di esecuzione nei casi in cui i gruppi di interesse vengono uniti nella stessa origine e probabilmente non richiederà modifiche allo script di offerta. Per saperne di più, consulta la descrizione di group-by-origin nell'articolo esplicativo. La modalità di contesto congelato 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 nell'articolo esplicativo.

Riutilizzare 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 sui gruppi di interesse (ad es. name o userBiddingSignals) utilizzando lo stesso script.

Senza le intestazioni HTTP di controllo cache, lo script di offerta non viene memorizzato nella cache. Specifica le intestazioni appropriate per assicurarti che lo script non venga recuperato inutilmente. Se nella pagina sono in esecuzione più aste in parallelo, lo script di offerta dello stesso offerente verrà riutilizzato se è già in memoria, ignorando la semantica della memorizzazione nella cache. Se le aste vengono eseguite in sequenza, il browser rispetterà il meccanismo di memorizzazione nella cache HTTP.

Tieni presente che il browser carica lo script di offerta durante il momento dell'offerta (per generateBid()) e anche durante il momento della generazione dei report (per reportWin()). Se le intestazioni di controllo della cache non sono impostate, il browser recupererà lo stesso script due volte, una per ogni periodo di tempo.

Pertanto, ti consigliamo di impostare le intestazioni di controllo della cache su tutti gli script.

Riutilizzo trustedBiddingSignalsUrls

La latenza della rete e l'utilizzo delle risorse possono essere molto significativi. Ridurre il numero di recupero di indicatori di offerta affidabili in tempo reale può contribuire a ridurre questa latenza.

I recuperi degli indicatori per le offerte attendibili possono essere combinati quando trustedBiddingSignalsUrl viene riutilizzato in 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 assicurarti che i recuperi degli indicatori di offerta attendibili vengano memorizzati nella cache negli spazi pubblicitari di una determinata pagina web. Evita di impostare trustedBiddingSignalsSlotSizeMode su slot-size, in quanto ciò impedirà la memorizzazione nella cache tra gli spazi pubblicitari quando le dimensioni degli spazi sono diverse perché l'URL richiesto sarà diverso.

Recupero di indicatori di offerte affidabili in tempo reale più piccoli

La latenza della rete può essere molto significativa e questo è influenzato direttamente dalla quantità di dati trasferiti durante i recuperi dell'indicatore delle offerte attendibili in tempo reale.

Preferisci memorizzare i dati specifici per gli annunci o per i gruppi di interesse nel gruppo di interesse anziché nel servizio di indicatori di aste attendibili in tempo reale. Riserva i dati degli indicatori di offerta attendibili in tempo reale solo per gli indicatori in tempo reale, come il budget della campagna 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 esclusi come descritto nella sezione "Escludere i gruppi di interesse dalle offerte nel servizio Key/Value".

Dare la priorità ai gruppi di interesse

I venditori utilizzeranno i timeout per limitare l'utilizzo delle risorse del browser sulle pagine del publisher. Quando perBuyerCumulativeTimeouts vengono utilizzati per limitare il tempo necessario agli acquirenti per recuperare gli indicatori di offerta attendibili ed eseguire gli script di offerta, è fondamentale che gli acquirenti diano la priorità ai gruppi di interesse in modo che quelli con maggiori probabilità di vincere l'asta vengano eseguiti per primi. Ad esempio, se perBuyerCumulativeTimeouts è impostato su 100 ms, l'acquisizione degli indicatori di offerte attendibili di un offerente richiede 50 ms, ogni chiamata a perBuyerCumulativeTimeouts richiede 10 ms e sono presenti 10 gruppi di interesse su un dispositivo, solo la metà dei gruppi di interesse avrà la possibilità di calcolare le offerte.generateBid() L'acquirente in questo esempio deve dare la priorità ai gruppi di interessi in ordine dal più probabile al meno probabile.

I gruppi di interesse possono contenere priorità statiche definite con il relativo campo priority. I gruppi di interesse possono anche utilizzare priorità dinamiche che possono essere calcolate nel loro servizio di 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 i gruppi di interesse dalla priorità più alta a quella più bassa, potrebbero essere intermezzati gruppi di interesse di origini di unione diverse, il che potrebbe annullare l'ottimizzazione group-by-origin.

Best practice per i venditori

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

Eseguire in parallelo le aste

Le connessioni di rete moderne e i processori multi-core sono molto efficaci nell'eseguire più attività contemporaneamente. Il browser può eseguire un'asta Protected Audience in parallelo con altre attività. Per facilitare questa operazione, chiama runAdAuction() il prima possibile. Poiché alcuni input di runAdAuction() potrebbero non essere disponibili all'inizio, ad esempio quelli 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 le promesse JavaScript. Per ottenere la latenza di asta più bassa possibile, runAdAuction() deve essere chiamato quando è noto l'input interestGroupBuyers. In questo modo è possibile iniziare immediatamente molte parti dell'asta, incluso il recupero degli indicatori delle offerte in tempo reale dell'offerente.

Monitorare le aste

Raccogli le metriche sulle tue aste. Il browser può generare report sulle per-buyermetriche di latenza per i venditori che forniscono molti approfondimenti su come viene speso il tempo nelle aste di un venditore. I venditori possono utilizzare queste metriche per cercare modi per ottimizzare le aste, ad esempio per sapere come impostare i timeout in modo più efficace. I venditori possono condividere con un acquirente specifico le metriche relative alla latenza di un acquirente specifico per aiutarlo a ottimizzare ulteriormente.

Gli offerenti potrebbero avere informazioni sul rendimento delle offerte dei propri gruppi di interesse, ma potrebbero non essere in grado di confrontarlo con quello di altri offerenti. Confrontare i tassi di aggiudicazione e di rifiuto delle offerte relativi di diversi offerenti può essere utile per identificare i casi in cui le risorse di calcolo delle offerte sono state sprecate a causa di gruppi di interesse che non hanno mai prodotto offerte valide o offerte eccessive con creatività non approvate.

Proteggere dagli script di offerta lenti

Gli script di offerta che richiedono troppo tempo possono rallentare l'asta dell'API Protected Audience per tutti gli utenti coinvolti. L'utilizzo dei timeout può impedire le aste lente, recuperando al contempo le entrate quando l'asta è lenta.

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

L'utilizzo del campo signal di configurazione dell'asta per implementare un timeout complessivo dell'asta è una buona idea anche per evitare aste eccessivamente lunghe nei casi in cui i recuperi dell'indicatore di punteggio attendibile e l'esecuzione di scoreAd() richiedano troppo tempo.

Importante: una nota sui tempi dell'asta: spesso le persone si chiedono "quanto tempo richiede un'asta Protected Audience?" "A quale valore deve impostare il venditore i timeout?" o "Per quale latenza deve essere ottimizzata la richiesta di un acquirente?". La risposta a queste domande dipende da quale risultato dell'asta viene ottimizzato dai partecipanti. I venditori potrebbero voler massimizzare le entrate pubblicitarie del sito web, in questo caso devono fare esperimenti con diversi timeout per trovare l'impostazione che massimizza le entrate. Potrebbe essere utile avere timeout diversi per computer e dispositivi mobili. L'utilizzo di Protected Audience può cambiare nel tempo con l'aumento dell'adozione, l'ottimizzazione della logica da parte dei partecipanti all'asta o l'evoluzione dei computer, pertanto la sperimentazione continua può essere utile. Se gli acquirenti eseguono l'ottimizzazione per vincere il maggior numero di aste, devono monitorare e ottimizzare la latenza degli indicatori di offerta attendibili e la latenza generateBid() e prendere in considerazione la possibilità di dare la priorità ai gruppi di interesse in modo che, quando i venditori impostano timeout rigorosi, generino prima le offerte migliori.

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.