Protected Audience: guida all'integrazione

Le implementazioni Android di Protected Audience (precedentemente nota come FLEDGE) prevedono l'integrazione tra app dell'inserzionista, app dei publisher, venditori e acquirenti. Questa guida è rivolta ai partner che hanno intenzione di gestire segmenti di pubblico personalizzati ed eseguire aste, incluse le reti di tecnologia pubblicitaria che operano sia come acquirenti che come venditori. Campagne pubblicitarie diverse possono avere obiettivi diversi e non tutte le funzionalità di Protected Audience vengono utilizzate per tutti i casi d'uso. Questa guida tenta di indicare i passaggi necessari per supportare i casi più specializzati, ove possibile.

Per prepararsi al deployment in produzione su larga scala di Protected Audience, i partner possono iniziare a eseguire test simulando i punti di integrazione con altre parti. Per aiutarti nella pianificazione dell'integrazione, questa guida fornisce una visione completa di come integrare Protected Audience con le tue app Android. Potrebbero essere incluse funzionalità non ancora implementate nella fase attuale di Privacy Sandbox nell'Anteprima per gli sviluppatori Android. In questi casi vengono fornite indicazioni sulle tempistiche.

Il flusso di lavoro dell'integrazione di Protected Audience prevede quattro passaggi chiave basati su diversi tipi di partner di tecnologia pubblicitaria:

1. L'acquirente crea segmenti di pubblico personalizzati.
2. Il processo di selezione degli annunci sceglie un annuncio vincente.
   1. L'app del venditore avvia la selezione degli annunci.
   2. I servizi pubblicitari eseguono filtri per gli acquirenti e codice di offerta.
   3. I servizi pubblicitari eseguono il codice decisionale lato vendite.
3. L'annuncio vincente viene visualizzato nell'app del venditore.
4. I report sulle impressioni degli annunci vengono resi disponibili sia per l'acquirente che per il venditore.

Il seguente diagramma illustra questi passaggi:

Flusso di lavoro per la gestione e la selezione degli annunci di Protected Audience.

Terminologia

• Inserzionista: un'azienda che coinvolge gli utenti mediante l'acquisto di inventario pubblicitario.
• Publisher: un'azienda che vende un inventario pubblicitario disponibile insieme ai suoi contenuti.
• Acquirente: un'azienda di ad tech che facilita agli inserzionisti l'acquisto di inventario pubblicitario.
• Venditore: un'azienda di tecnologia pubblicitaria che aiuta i publisher a vendere l'inventario pubblicitario.
• Rete: un'azienda di tecnologia pubblicitaria che agisce sia come acquirente sia come venditore.
• Di proprietà e gestito: un'azienda che agisce in qualità di publisher, venditore e acquirente.
• Partner di integrazione: tutte le aziende con cui devi collaborare per integrare correttamente con Protected Audience.

Prerequisiti, coinvolgimento dei partner di integrazione e configurazione

Questa sezione illustra una serie di attività iniziali per aiutarti a capire come funziona Protected Audience, come iniziare a utilizzare l'integrazione di Protected Audience e come interagire con i tuoi partner di integrazione in un'implementazione di Protected Audience. Queste attività possono svolgersi in parallelo.

Guida all'implementazione delle funzionalità di Protected Audience.

Acquisisci familiarità con Protected Audience

Il primo passaggio consiste nell'acquisire familiarità con le API e i servizi Protected Audience.

1. Inizia a leggere la proposta di progettazione per acquisire familiarità con l'API Protected Audience e le sue funzionalità.
2. Leggi la guida per gli sviluppatori per scoprire come incorporare il codice e le chiamate API necessarie per i tuoi casi d'uso e i servizi necessari per l'integrazione con Protected Audience.
3. Invia un feedback relativo alla progettazione e all'implementazione delle API, dei servizi e della documentazione di Protected Audience.
4. Iscriviti per ricevere aggiornamenti sulle ultime funzionalità di Privacy Sandbox.

Configurare e testare app di esempio

Una volta acquisite le nozioni di base di Protected Audience, come descritto in precedenza, devi configurare e testare le app di esempio.

1. Quando è tutto pronto per iniziare l'integrazione, configura il tuo ambiente di sviluppo con la più recente anteprima per gli sviluppatori di Privacy Sandbox.
2. Configura gli endpoint del server richiesti. Utilizza gli esempi di simulazioni con la soluzione di test delle API che preferisci per eseguire il bootstrap di questo processo.
3. Crea un fork ed esegui il codice nella nostra app di esempio per acquisire familiarità con la gestione dei segmenti di pubblico personalizzati, il flusso di lavoro per la selezione degli annunci e i report sulle impressioni.

Coinvolgimento del partner di integrazione

Programma discussioni con i tuoi partner di integrazione per discutere dei test e dell'adozione di Protected Audience su Android, inclusa la forma degli indicatori trasmessi tra le parti. Per gli acquirenti, le discussioni devono includere strategie per creare e partecipare a segmenti di pubblico personalizzati, che potrebbero includere discussioni su come vengono definiti i segmenti di pubblico. Collabora con i tuoi partner di integrazione per definire le tempistiche per l'integrazione, dal test iniziale all'adozione, e le aree di responsabilità di ogni parte nella progettazione.

Configurazione beta (disponibile nel quarto trimestre)

Registra la tua organizzazione a Privacy Sandbox su Android. La registrazione è necessaria per garantire che gli sviluppatori di ad tech operino rispettando i criteri di Privacy Sandbox e consentono agli sviluppatori di ad tech di definire la propria identità in più SDK e domini.

Considerazioni sull'architettura

Sia per gli acquirenti che per i venditori, Protected Audience introduce la possibilità di eseguire aste dell'annuncio sul dispositivo. Tu e i tuoi partner di integrazione dovrete tenere conto di diversi aspetti critici nella vostra progettazione:

I segmenti di pubblico e gli annunci di remarketing vengono memorizzati sul dispositivo

Diversamente dall'archiviazione attuale degli annunci sui server, le informazioni sul pubblico e gli annunci di remarketing vengono memorizzati sul dispositivo. Gli annunci contestuali che non si basano sui dati nel dispositivo per il targeting continueranno a rimanere sui server. Le piattaforme di tecnologia pubblicitaria devono espandersi per tenere conto della domanda di annunci distribuita tra server e dispositivi.

Le procedure di asta e offerta avvengono sul dispositivo

Oltre a eseguire aste sui server, le piattaforme di tecnologia pubblicitaria ora hanno l'opportunità di determinare il prezzo e il ranking della domanda di annunci memorizzata sul dispositivo.

Un approccio comune è che le tecnologie pubblicitarie eseguono aste per gli annunci contestuali come fanno attualmente. Dopo aver completato l'asta, il venditore può scegliere di eseguire un'asta sul dispositivo per valutare la domanda di remarketing memorizzata sul dispositivo. Dato che questi processi ora vengono eseguiti sul dispositivo, è importante ricordare i limiti esistenti per garantire che l'asta venga eseguita end-to-end come previsto dai diversi partner di integrazione, in una serie di casi d'uso di remarketing.

Strategia di dati

Le piattaforme di ad tech devono prendere in considerazione i tipi di dati utilizzati nelle aste. Oggi queste informazioni vengono raccolte da varie origini e poi centralizzate su un server. Le aste di Protected Audience offrono diversi percorsi per trasmettere i dati. Ad esempio, gli indicatori in tempo reale come il budget residuo provengono da un servizio chiave-valore come indicatori attendibili, mentre gli indicatori di contesto come l'ora del giorno vengono inviati dai venditori durante l'esecuzione di un'asta. Questi indicatori sono spiegati più in dettaglio nelle sezioni pertinenti di questa guida.

Crea la tua soluzione

Per eseguire un'asta con Protected Audience sono previste diverse fasi fondamentali. Gli acquirenti devono creare il pubblico, fornire dati sulle offerte, scegliere i segmenti di pubblico come target degli annunci e configurare le offerte. Il venditore deve configurare e attivare l'asta, assegnare un punteggio agli annunci dei candidati e selezionare un vincitore. Alcune di queste fasi richiedono la collaborazione tra le due parti per garantire la corretta esecuzione dell'asta. Le seguenti sezioni descrivono in dettaglio ogni fase e indicano esplicitamente la parte responsabile dell'implementazione.

Acquirenti: creazione di un segmento di pubblico

In genere, gli acquirenti gestiscono segmenti di pubblico personalizzati. Poiché i segmenti di pubblico personalizzati sono gestiti on-device, l'API per gestire i segmenti di pubblico personalizzati è progettata per essere richiamata sul dispositivo.

Se nell'app degli inserzionisti è presente un SDK personalizzato, puoi implementare questo codice direttamente tramite joinCustomAudience().

Se non disponi di un codice SDK sui dispositivi, puoi valutare la possibilità di collaborare con un partner di integrazione esistente che sia anche un provider di SDK. Identifica e collabora con questo partner per definire un contratto e un flusso per la definizione e la gestione dei segmenti di pubblico personalizzati. Questa guida utilizza il termine "acquirente" a prescindere dall'approccio utilizzato. Alcuni approcci di esempio includono:

• Come acquirente, fai in modo che sia l'inserzionista a definire il segmento di pubblico. L'SDK di un partner di integrazione sul dispositivo può inviare eventi app all'acquirente. Quando vengono soddisfatti i criteri predefiniti, l'acquirente invia un messaggio all'SDK per unirsi al segmento di pubblico personalizzato per il cliente per conto dell'acquirente.
• L'SDK può possedere direttamente il pubblico. Gli inserzionisti collaborano con un provider di SDK per definire il pubblico. L'SDK monitora gli eventi dell'app e si unisce al segmento di pubblico al momento opportuno; inoltre, comunica all'acquirente che un utente è entrato a far parte del segmento di pubblico.

Prototipare la campagna di remarketing: progettare un segmento di pubblico personalizzato

Un segmento di pubblico personalizzato è un gruppo di utenti con interessi simili ai quali possono essere pubblicati annunci personalizzati. Gli acquirenti possono aiutare gli inserzionisti a creare nelle loro app segmenti di pubblico personalizzati in base all'attività utente.

Protected Audience stabilisce un container per il segmento di pubblico personalizzato che viene mappato a un particolare coinvolgimento degli utenti personalizzato come definito dall'inserzionista. tra cui una raccolta di annunci candidati che possono essere mostrati a quel segmento di pubblico, nonché una raccolta di dati e logica di offerte personalizzate che possono essere utilizzati durante un'asta per filtrare e determinare il prezzo degli annunci.

Configurazione e prototipazione

• Utilizza l'API Custom Audience per creare e archiviare sul dispositivo un segmento di pubblico che può essere utilizzato in un secondo momento in un'asta.
• Consulta la guida per gli sviluppatori per informazioni dettagliate sull'implementazione e sull'utilizzo dell'API.

Note sul layout

Gli acquirenti possono supportare una varietà di casi d'uso configurando i segmenti di pubblico personalizzati. Ciò include la definizione della logica di offerta per il tipo di annuncio o campagna a cui è indirizzato il segmento di pubblico, la definizione dell'elenco di annunci candidati e considerazioni simili. Questa sezione include considerazioni sulla progettazione per il completamento e l'utilizzo di alcuni campi chiave in un segmento di pubblico personalizzato.

URL logica di offerta

Poiché le aste vengono eseguite sul dispositivo, gli acquirenti devono implementare un endpoint in grado di restituire la logica di offerta come JavaScript. La nostra guida per gli sviluppatori descrive le firme del metodo richieste. La logica di offerta ha accesso a determinati indicatori sull'utente durante l'asta, come descritto nelle sezioni successive. La configurazione della logica di offerta e degli indicatori utente viene spiegata più avanti in questo articolo.

Indicatori di offerta utente

Gli acquirenti possono utilizzare UserBiddingSignals per trasmettere la conoscenza dell'inserzionista o dell'acquirente stesso alle aste future sul dispositivo. Queste informazioni possono includere:

• Altri segmenti di pubblico a cui è stato aggiunto l'utente.
• Informazioni proprietarie dell'inserzionista sull'utente.

Poiché questi indicatori sono disponibili durante l'asta, durante l'asta gli acquirenti possono eseguire operazioni di offerte personalizzate, tra cui:

• Aumenta o diminuisci l'offerta in base agli indicatori di offerta.
• Escludere annunci specifici dall'asta.

Dati sulle offerte attendibili

Nell'ambito dell'implementazione Protected Audience, gli acquirenti possono accedere alle informazioni in tempo reale durante l'asta da un servizio chiave-valore. Come meccanismo temporaneo, l'acquirente e il venditore possono recuperare questi indicatori di offerta da qualsiasi servizio, incluso quello che gestisce autonomamente. L'esempio più comune è quello di controllare il budget rimanente per gli annunci. Durante lo sviluppo, è possibile simulare il servizio e sviluppare in base a questo endpoint fittizio. Consulta la directory FledgeServerSpec nel nostro repository dell'app di esempio su GitHub per le istruzioni di configurazione.

Il campo TrustedBiddingData è composto da un URL e da un insieme di chiavi. Ecco alcune considerazioni da fare durante la progettazione del tipo di struttura chiave da utilizzare:

• Un approccio semplice consiste nell'includere una chiave che mappa 1:1 al segmento di pubblico che viene creato. Il servizio chiave-valore può quindi contenere tutte le informazioni pertinenti associate al segmento di pubblico.
• Il budget e lo stato degli annunci sono aspetti importanti da considerare in tempo reale.
• Importo dell'offerta massima o altri indicatori utilizzabili per determinare il prezzo di un annuncio in un'asta. È possibile includere queste informazioni nell'annuncio in un elenco AdData, ma memorizzarle in un servizio chiave-valore ne facilita l'aggiornamento in base alle esigenze.

Elenco AdData

Durante la creazione di una campagna di remarketing, gli inserzionisti di solito prendono in considerazione molti tipi diversi di annunci da mostrare a un utente in un segmento di pubblico, ad esempio sconti diversi in base alla precedente interazione dell'utente con l'app. Un segmento di pubblico personalizzato include un elenco AdData contenente gli annunci candidati.

La quantità di informazioni da includere per ciascun annuncio spetta agli acquirenti. Alcuni aspetti da considerare:

• L'elenco AdData può essere aggiornato in due modi:
  • Se l'app ha un'attività visibile in primo piano, può avviare l'elenco quando un utente viene unito a un segmento di pubblico personalizzato.
  • Durante un aggiornamento giornaliero, il recupero viene avviato in background. Il dispositivo invia una richiesta al daily_update_url incluso nella chiamata joinCustomAudience e si aspetta una risposta che includa un elenco AdData aggiornato.
• È possibile richiedere ulteriori informazioni sugli annunci al momento dell'asta. Prima dell'asta, il dispositivo invia una richiesta al servizio chiave-valore dell'acquirente fornito nel campo trustedBiddingData di joinCustomAudience. Il servizio chiave-valore è un nuovo servizio che fa parte dell'implementazione di Protected Audience da parte degli acquirenti. Ulteriori dettagli su questo servizio sono spiegati più avanti in questo documento.
• L'inclusione di un ID creatività per il tuo annuncio può aiutarti a eseguire determinate azioni su creatività specifiche. Ad esempio, gli inserzionisti potrebbero mettere in pausa creatività specifiche e vuoi recuperare gli ID creatività dal servizio chiave-valore in tempo reale per confrontarli con gli annunci nell'elenco AdData.

AdData deve includere un render_url. L'URL di rendering dell'annuncio di remarketing vincente viene utilizzato per la visualizzazione dell'annuncio. Alcune considerazioni includono:

• L'URL di rendering ha una soglia di k-anonymity, quindi non includere parametri ristretti. Ulteriori informazioni relative a questa soglia di k-anonymity verranno pubblicate in un secondo momento.
• Questo URL deve contenere tutte le informazioni necessarie per la visualizzazione dell'annuncio. Ad esempio, se vuoi mostrare prodotti specifici, incorpora gli ID prodotto come parametri nell'URL.

In fase di prototipazione, l'unico campo obbligatorio è renderUri, che rimanda agli asset di rendering dell'annuncio. Il campo dei metadati in AdData può essere ignorato durante la creazione della soluzione. Quando passi la tua soluzione alla produzione, devi considerare quali metadati sono pertinenti per te, in quanto possono essere utilizzati durante la generazione delle offerte per modificare il prezzo dell'offerta.

Ora di attivazione e data di scadenza

Puoi utilizzare i campi di attivazione e scadenza per supportare casi d'uso in cui un segmento di pubblico personalizzato deve essere idoneo per le aste solo entro un periodo di tempo predefinito. Tieni presente che esistono alcune limitazioni relative al tempo di ritardo di un'attivazione e il delta tra l'attivazione e la scadenza. Ecco alcuni casi d'uso di esempio:

• Utente non più attivo (ad es. un utente che non ha interagito con l'app dell'inserzionista negli ultimi 7 giorni)
  • Ogni volta che l'utente apre l'app, l'acquirente può chiamare joinCustomAudience e configurare activation_time in modo che sia un timestamp di 7 giorni nel futuro.
  • Il segmento di pubblico è idoneo per le offerte se sono trascorsi 7 giorni dall'ultima apertura dell'app da parte dell'utente.
• Segmento di pubblico stagionale (un segmento di pubblico valido solo durante un periodo di tempo specifico nel prossimo futuro)
  • Un acquirente può iniziare a definire in anticipo segmenti di pubblico personalizzati che dovrebbero essere idonei per le offerte solo durante un periodo prestabilito nel (vicino) futuro.
  • Ad esempio, se un inserzionista ha una campagna di fine estate negli Stati Uniti nel 2022, l'acquirente può chiamare joinCustomAudience e configurare activation_time in modo che sia sabato 20 agosto 2022. Se la campagna viene pubblicata solo per una settimana, l'acquirente può impostare la data di scadenza al 27 agosto 2022. Trascorso questo periodo, il segmento di pubblico personalizzato viene filtrato ed escluso dalla piattaforma durante la selezione degli annunci.

Acquirenti e venditori: selezione degli annunci

La selezione degli annunci richiede la collaborazione tra acquirenti e venditori. Questo processo può essere in quattro fasi:

1. I venditori definiscono una strategia di mediazione.
2. I venditori configurano l'asta e avviano la selezione degli annunci.
3. Gli acquirenti sono invitati a partecipare all'asta tramite la configurazione definita dal venditore. La logica di offerta dell'acquirente viene eseguita per selezionare un annuncio candidato e un'offerta.
4. La logica decisionale del venditore viene eseguita per assegnare un punteggio ai candidati e selezionare un annuncio vincente.

Per facilitare lo sviluppo, è possibile simulare le risposte dei servizi per acquirenti e venditori, il che include la logica di offerta e punteggio, in modo che tu possa concentrarti sullo sviluppo di ciò che è pertinente per il tuo caso d'uso. Consulta la directory FledgeServerSpec su GitHub per istruzioni sulla configurazione di endpoint fittizi o la guida per gli sviluppatori per istruzioni su come ignorare la necessità del recupero di JavaScript remoto.

Venditori: definire una strategia di mediazione

Protected Audience mira a supportare la mediazione a cascata. L'area è in fase di sviluppo. Forniremo ulteriori informazioni non appena saranno disponibili. Per il momento, consulta la proposta di progettazione per la mediazione a cascata in Protected Audience.

Venditori: configurare l'asta

I venditori sono responsabili della configurazione dell'asta, fornendo informazioni sul processo di selezione degli annunci. I venditori possono scegliere di rendere le informazioni disponibili solo per determinate parti o solo per determinate parti. Ciò può includere informazioni in tuo possesso o informazioni che includi per conto degli acquirenti.

Configurazione e prototipazione

• Un venditore può configurare e avviare un'asta impostando un oggetto AdSelectionConfig e utilizzando l'API AdSelection. Attiva l'asta richiamando selectAds().
• Consulta la guida per gli sviluppatori per informazioni dettagliate sull'implementazione e sull'utilizzo dell'API.

Note sul layout

Questa sezione include considerazioni sulla progettazione per il completamento e l'utilizzo dei campi chiave in una configurazione di selezione degli annunci.

• L'ambiente di esecuzione privato include solo annunci dei segmenti di pubblico personalizzati sul dispositivo, quindi l'invio di una richiesta di annuncio contestuale prima consente di considerare una domanda aggiuntiva.

• Prima di iniziare il flusso di lavoro per la selezione degli annunci, esegui una richiesta di annuncio per raccogliere informazioni dagli acquirenti. Poi, utilizza queste informazioni per configurare la selezione dell'annuncio.

• Poiché molti acquirenti potrebbero aver creato segmenti di pubblico personalizzati sul dispositivo, i venditori devono utilizzare il campo Acquirenti dei segmenti di pubblico personalizzati per indicare gli acquirenti specifici da includere nella procedura. Questo elenco può essere costruito in molti modi. Ecco alcuni esempi:

  • Un elenco statico di acquirenti che il venditore vuole sempre includere nella procedura.
  • Un elenco di acquirenti che indicano che vogliono partecipare alla loro risposta all'annuncio. Questa opzione è utile se il venditore collabora con piattaforme di scambio pubblicitario e potrebbe non conoscere appieno tutti gli acquirenti.

• Il venditore può trasferire le informazioni nella procedura in diversi modi:

  • Il campo degli indicatori di selezione degli annunci è disponibile per tutti gli acquirenti e i venditori che partecipano all'asta nel runtime privato. Utilizzalo per fornire informazioni sull'opportunità pubblicitaria, ad esempio dimensioni e formato dell'annuncio.
  • Il campo indicatori per acquirente viene inoltrato a un acquirente specifico per utilizzarlo nel processo di offerta. Queste informazioni sono fornite dall'acquirente e tu, in qualità di venditore, devi valutare come riceverle sul dispositivo per utilizzarle durante la selezione degli annunci.
  • Il campo Indicatori del venditore è l'ultimo modo con cui il venditore può passare le informazioni al processo. In qualità di venditore, utilizzi questi indicatori quando assegni un punteggio agli annunci e li filtri, ad esempio attivi un controllo di sicurezza del brand.

Acquirenti: offerte per un'area annuncio

Configurazione e prototipazione

• Un acquirente può aggiungere la propria logica di offerta alla funzione JavaScript generateBid() pubblicata dal parametro biddingLogicUrl impostato durante la creazione di un CustomAudience. Puoi configurare un servizio fittizio utilizzando la specifica fornita oppure implementare questo endpoint su un server reale.
• Consulta la guida per gli sviluppatori per informazioni dettagliate sull'implementazione e sull'utilizzo dell'API.

Note sul layout

• La logica di offerta viene eseguita sul dispositivo e su alcuni indicatori utilizzati nell'asta viene eseguita una query in tempo reale. Fai riferimento all'elenco delle limitazioni per i vincoli.
• Per alcuni casi d'uso degli annunci, è importante collaborare con il venditore per assicurarti di avere più annunci candidati e le relative offerte da considerare sul dispositivo.

Progetta la logica di offerta

La logica di offerta dell'acquirente deve essere implementata tramite JavaScript e sul dispositivo. La guida per gli sviluppatori contiene informazioni sulla firma richiesta e dettagli sui vari parametri trasmessi durante l'asta. La logica di offerta sul dispositivo ha accesso a informazioni aggiuntive, trasmesse come parametri alla funzione generateBid().

Fornisci i dati sulle offerte

Indicatori delle offerte in tempo reale con servizi chiave-valore

In qualità di acquirente, puoi recuperare indicatori in tempo reale durante un'asta da un servizio chiave-valore di tua proprietà. Puoi trovare un'implementazione iniziale di questo servizio nel repository di Privacy Sandbox pubblico oppure puoi creare un servizio tutto tuo. L'URL per questo servizio è specificato come trustedBiddingUrl in un segmento di pubblico personalizzato e la piattaforma tenta di recuperare i dati e renderli disponibili per la funzione generateBid con trusted_bidding_signals parameter. Devi definire una struttura di chiavi personalizzata.

Indicatori contestuali e degli utenti

La funzione generateBid ha accesso a indicatori utente aggiuntivi quando viene eseguita l'asta sul dispositivo. Questi indicatori vengono passati con i campi contextual_signals e per_buyer_signals. Questi campi sono tutti oggetti JSON il cui formato deve essere definito da acquirenti e venditori.

Il campo contextual_signals include informazioni che potrebbero essere pertinenti sull'utente. L'oggetto che contiene questi indicatori viene creato da Protected Audience e trasmesso alla logica di offerta. Attualmente, questo viene passato come oggetto vuoto. Se ritieni che un indicatore contestuale sull'utente possa essere pertinente per il tuo caso d'uso, invia un feedback affinché venga preso in considerazione.

Il campo per_buyer_signals viene reso disponibile alla logica di offerta. Un venditore imposta questi valori durante la creazione della configurazione dell'asta. Acquirenti e venditori devono collaborare per garantire che questi dati siano sul dispositivo e trasmessi alla logica di offerta. Ecco alcuni esempi di utilizzo di questo campo:

• Filtri per la sicurezza del brand. Il venditore può comunicare agli acquirenti alcune informazioni di classificazione relative all'app che richiede un annuncio e l'acquirente può utilizzare queste informazioni per filtrare determinati annunci.
• Invio di un incorporamento per un modello ML che consideri le informazioni contestuali.

Venditori: assegna un punteggio e seleziona l'annuncio vincente

Configurazione e prototipazione

• Un venditore può aggiungere la propria logica di punteggio alla funzione JavaScript scoreAd() pubblicata dal parametro scoringLogicUrl impostato durante la creazione di AdSelectionConfig. Puoi configurare un servizio fittizio utilizzando la specifica fornita oppure implementare questo endpoint su un server reale.
• Consulta la guida per gli sviluppatori per informazioni dettagliate sull'implementazione e sull'utilizzo dell'API.

Progetta la logica di punteggio

I venditori implementano la logica di punteggio in JavaScript, che viene eseguita sul dispositivo. La guida per gli sviluppatori contiene informazioni sulla firma richiesta e dettagli sui vari parametri trasmessi durante l'asta. Inoltre, la logica di punteggio sul dispositivo ha accesso a informazioni aggiuntive trasmesse come parametri alla funzione scoreAd.

Fornisci dati sui punteggi

Indicatori di punteggio in tempo reale con servizi chiave-valore

In qualità di venditore, puoi recuperare indicatori in tempo reale durante un'asta da un servizio chiave-valore di tua proprietà. Puoi trovare un'implementazione iniziale di questo servizio nel repository pubblico di Privacy Sandbox. L'URL per questo servizio è specificato come trustedScoringUri nella configurazione dell'asta e la piattaforma tenta di recuperare i dati e renderli disponibili alla tua funzione scoreAd tramite il parametro trusted_scoring_signals. Dovresti stabilire la tua struttura chiave.

Indicatori contestuali e degli utenti

La funzione scoreAd ha accesso a indicatori utente aggiuntivi quando viene eseguita l'asta sul dispositivo. Questi indicatori vengono passati alla funzione di punteggio tramite il campo contextual_signal. Questo campo contiene un oggetto JSON il cui formato è definito da acquirenti e venditori.

Il campo contextual_signal include informazioni contestuali che potrebbero essere pertinenti per l'utente. L'oggetto che contiene questi indicatori viene creato da Protected Audience stesso e trasmesso alla logica di punteggio. Questo viene passato come un oggetto vuoto. Se ritieni che un indicatore sull'utente possa essere pertinente per il tuo caso d'uso, invia un feedback affinché venga preso in considerazione.

Venditori: rendering di un annuncio

I venditori devono visualizzare l'annuncio vincente. Fai riferimento alla proposta di progettazione per ulteriori dettagli su come viene eseguito il rendering degli annunci vincenti. Questa area è ancora in fase di progettazione.

Segnala i risultati delle impressioni

Configurazione e prototipazione

• Gli acquirenti e i venditori possono aggiungere una logica di report alla funzione JavaScript reportWin() pubblicata rispettivamente dal parametro biddingLogicUrl o scoringLogicUrl. Puoi configurare un servizio fittizio utilizzando la specifica fornita oppure implementare questo endpoint su un server reale.
• Consulta la guida per gli sviluppatori per informazioni dettagliate sull'implementazione e sull'utilizzo dell'API.

Note sul layout

Gli acquirenti e i venditori devono implementare una funzione reportWin nel codice JavaScript restituito dai loro endpoint configurati. Questo metodo ti consente di inviare i dati ai tuoi server.

Privacy Sandbox fornisce anche un'API Attribution Reporting per gestire report aggregati e a livello di evento. Per ulteriori dettagli, consulta la guida all'integrazione.