Migliora la latenza dell'asta dell'API Protected Audience

È nel migliore 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 con l'API Protected Audience in modo efficiente per non utilizzare eccessivamente le risorse limitate del dispositivo, 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 reattiva. Anche i publisher vogliono una pubblicità efficace per massimizzare le loro entrate.
• Gli inserzionisti e le tecnologie pubblicitarie vogliono che i loro annunci vengano visualizzati rapidamente per fornire la massima utilità.

Questo documento descrive alcune best practice per l'implementazione dell'API Protected Audience, per garantire che il tuo sito funzioni alla massima efficienza.

Best practice per gli acquirenti (offerenti)

Per assicurarti di ottimizzare l'efficienza dell'asta dell'API Protected Audience, segui queste best practice.

Meno proprietari di gruppi basati sugli interessi

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 dei gruppi basati sugli interessi.

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 vari sottodomini. Ad esempio, se adtech.example aveva gruppi di interesse di proprietà di cats.adtech.example e dogs.adtech.example, il browser probabilmente utilizzerebbe due processi separati per eseguire gli script di offerta.

Meno gruppi basati sugli interessi che fanno offerte

Il browser deve eseguire una configurazione e una preparazione significative prima di richiamare uno script generateBid() di un acquirente, ad esempio impostando un nuovo ambiente di esecuzione JavaScript pulito e analizzando e caricando il codice generateBid().

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

Filtra i gruppi di interesse dalle offerte nel tuo servizio coppie chiave-valore

Se un acquirente può determinare nel proprio server di indicatori di offerta attendibili in tempo reale che determinati gruppi di interesse non devono fare offerte (ad es. la campagna è disattivata, in pausa o ha esaurito il budget oppure non deve fare offerte per questo particolare publisher), può indicarlo al browser con la risposta priorityVector al recupero degli indicatori di offerta attendibili. Se il prodotto scalare sparso risultante di priorityVector e prioritySignals è negativo, il browser non richiamerà generateBid() per questo gruppo di interesse. Puoi scoprire di più su questo meccanismo nella sezione"Filtro e assegnazione della priorità ai gruppi basati sugli interessi" della spiegazione.

Riutilizzare 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, pari al tempo necessario per l'esecuzione di un generateBid() minimo. Questo tempo può essere risparmiato utilizzando le modalità di esecuzione group-by-origin o frozen-context.

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

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 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 periodo di offerta (per generateBid()) e anche durante il periodo di generazione dei report (per reportWin()). Se le intestazioni di controllo della cache non sono impostate, il browser recupererà lo stesso script due volte, una volta per ogni periodo di tempo.

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

Riutilizza trustedBiddingSignalsUrls

La latenza di rete e l'utilizzo delle risorse possono essere molto significativi. Un minor numero di recuperi degli indicatori di offerta attendibili in tempo reale può contribuire a ridurre questa latenza.

I recuperi dell'indicatore di offerta attendibile 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 garantire 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 negli spazi pubblicitari quando le dimensioni degli spazi differiscono perché l'URL richiesto sarà diverso.

Recuperi più piccoli degli indicatori di offerta affidabili in tempo reale

La latenza di rete può essere molto significativa e dipende direttamente dalla quantità di dati trasferiti durante i recuperi dei segnali di offerta attendibili in tempo reale.

Preferisci archiviare i dati specifici degli annunci o dei gruppi di interesse nel gruppo di interesse, anziché nel servizio di indicatori di offerta attendibili in tempo reale. Riserva i dati degli indicatori di offerta attendibili in tempo reale solo per gli indicatori veramente in tempo reale, come il budget della campagna o i kill switch.

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

Non restituire indicatori di offerta attendibili per i gruppi di interesse filtrati come descritto nella sezione "Filtrare i gruppi di interesse dalle offerte nel servizio Key/Value".

Dare la priorità ai gruppi basati sugli interessi

I venditori utilizzeranno i timeout per limitare l'utilizzo delle risorse del browser nelle pagine dei publisher. Quando i 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 gruppi di interesse in modo che vengano eseguiti per primi quelli con maggiori probabilità di vincere l'asta. Ad esempio, se perBuyerCumulativeTimeouts è impostato su 100 ms e il recupero dei segnali di offerta attendibili di un offerente richiede 50 ms e ogni chiamata di generateBid() richiede 10 ms e sul dispositivo sono presenti 10 gruppi di interesse, solo la metà dei gruppi di interesse avrà la possibilità di calcolare le offerte. L'acquirente in questo esempio deve dare la priorità ai gruppi di interesse in ordine di probabilità di vincita, dal più probabile al meno probabile.

I gruppi basati sugli interessi possono contenere priorità statiche definite con il campo priority. I gruppi di interesse possono anche utilizzare priorità dinamiche che possono essere calcolate sul 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, questi possono essere intervallati da gruppi di interesse di origini di unione diverse, il che potrebbe vanificare l'ottimizzazione di group-by-origin.

Best practice per i venditori

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

Parallelizzare le aste

Le moderne connessioni di rete e i processori multi-core svolgono un ottimo lavoro eseguendo più attività contemporaneamente. Il browser può eseguire un'asta Protected Audience in parallelo con altre attività. Il modo migliore per farlo è chiamare runAdAuction() il prima possibile. Riconoscendo che alcuni input di runAdAuction() potrebbero non essere disponibili all'inizio, ad esempio quelli che vengono inviati di nuovo 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 dell'asta più bassa possibile, runAdAuction() deve essere chiamato quando è noto l'input interestGroupBuyers. Ciò consente di avviare immediatamente molte parti dell'asta, incluso il recupero degli indicatori di offerta in tempo reale dell'offerente.

Monitorare le aste

Raccogli metriche sulle tue aste. Il browser può generare report per-buyersulle metriche di latenza per i venditori, fornendo molte informazioni su come viene utilizzato il tempo 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 nel modo più efficace. I venditori possono condividere le metriche di latenza di un acquirente specifico con l'acquirente per aiutarlo a ottimizzare ulteriormente.

Gli offerenti potrebbero avere informazioni sul rendimento delle offerte dei propri gruppi basati sugli interessi, ma potrebbero non essere in grado di confrontarlo con quello di altri offerenti. Il confronto tra i tassi di vittoria relativi e i 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 perché sono state effettuate offerte eccessive con creatività non approvate.

Proteggiti dagli script di offerta lenti

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

I venditori devono utilizzare perBuyerCumulativeTimeouts per evitare aste lente e accettare comunque 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 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 e l'esecuzione di scoreAd() dell'indicatore di punteggio attendibile 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.