È 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àuserBiddingSignalsdi 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.
后续操作
我们希望与您交流，确保我们构建适合所有人的 API。
讨论 API
与其他 Privacy Sandbox API 一样，此 API 也会记录在案并公开讨论。
使用 API 进行实验
您可以进行实验并参与有关 Protected Audience API 的对话。