Protected Audience: guida all'integrazione

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Le implementazioni di Protected Audience (precedentemente noto come FLEDGE) su Android tipicamente prevedono l'integrazione tra app di inserzionisti, app di publisher, venditori e acquirenti. Questa guida è rivolta ai partner che intendono gestire segmenti di pubblico personalizzati e pubblicare aste, incluse le reti ad tech che operano sia come acquirenti sia 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 le richieste più specializzate, ove possibile.

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

Il flusso di lavoro di integrazione di Protected Audience è costituito da quattro passaggi chiave guidati da diversi tipi di partner di ad tech:

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 il codice di offerta e di filtro lato acquirente.
   3. I servizi pubblicitari eseguono il codice decisionale lato venditore.
3. L'annuncio vincente viene visualizzato nell'app del venditore.
4. I report sulle impressioni degli annunci sono resi disponibili sia per l'acquirente sia per il venditore.

Il seguente diagramma illustra questi passaggi:

Terminologia

• Inserzionista: una società che coinvolge gli utenti tramite l'acquisto di inventari pubblicitari.
• Publisher: un'azienda che vende inventario pubblicitario disponibile accanto ai suoi contenuti.
• Acquirente: una società di ad tech che aiuta gli inserzionisti ad acquistare inventario pubblicitario.
• Venditore: un'azienda di ad tech che aiuta i publisher a vendere l'inventario pubblicitario.
• Rete: una società di tecnologia pubblicitaria che agisce sia come acquirente sia come venditore.
• Di proprietà e gestita: una società che agisce come publisher, venditore e acquirente.
• Partner di integrazione: tutte le aziende con cui devi collaborare per eseguire correttamente l'integrazione con Protected Audience.

Prerequisiti, coinvolgimento del 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 per l'implementazione di Protected Audience. Queste attività possono avvenire in parallelo.

.

Familiarizzare con Protected Audience

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

1. Per iniziare, leggi la proposta di design per familiarizzare 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 di cui hai bisogno per i tuoi casi d'uso, nonché i servizi necessari per l'integrazione con Protected Audience.
3. Invia un feedback relativo alla progettazione e all'implementazione di API, servizi e documentazione di Protected Audience.
4. Registrati per ricevere aggiornamenti e non perderti le ultime funzionalità di Privacy Sandbox.

Configurare e testare app di esempio

Dopo aver acquisito familiarità con le nozioni di base di Protected Audience descritte 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 versione più recente dell'anteprima per gli sviluppatori di Privacy Sandbox.
2. Configura gli endpoint del server richiesti. Utilizza i mock di esempio con la tua soluzione di test API preferita per avviare questa procedura.
3. Esegui il fork e il codice nella nostra app di esempio per familiarizzare con la gestione dei segmenti di pubblico personalizzati, il flusso di lavoro di selezione degli annunci e i report sulle impressioni.

Coinvolgimento dei partner di integrazione

Pianifica 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 aggregare segmenti di pubblico personalizzati, che possono includere discussioni su come vengono definiti i segmenti di pubblico. Collabora con i tuoi partner di integrazione per definire le tempistiche per l'integrazione, dai test iniziali all'adozione, e le aree di responsabilità di ciascuna parte nel design.

Configurazione beta (disponibile nel quarto trimestre)

Registra la tua organizzazione con Privacy Sandbox su Android. La registrazione è obbligatoria per garantire che gli sviluppatori di tecnologia pubblicitaria rispettino le norme di Privacy Sandbox e consente loro di definire la propria identità su più SDK e domini.

Considerazioni sull'architettura

Sia per gli acquirenti sia per i venditori, Protected Audience introduce la possibilità di eseguire aste di annunci sul dispositivo. Tu e i tuoi partner di integrazione dovrete prendere in considerazione diverse considerazioni fondamentali nei vostri progetti:

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

A differenza di quanto accade oggi, quando gli annunci vengono archiviati interamente sui server, le informazioni sul pubblico e gli annunci di remarketing vengono archiviati sul dispositivo. Gli annunci contestuali che non si basano su dati in-device per il targeting continueranno a rimanere sui server. Le piattaforme di tecnologia pubblicitaria devono espandersi per prendere in considerazione la domanda di annunci distribuita tra server e dispositivi.

Le offerte e le aste avvengono sul dispositivo

Oltre a gestire le aste sui server, le piattaforme di ad tech ora hanno la possibilità di determinare il prezzo e classificare la domanda di annunci memorizzata sul dispositivo.

Un approccio comune è che le tecnologie pubblicitarie gestiscano le aste per gli annunci contestuali come fanno oggi. Dopo aver completato l'asta, un venditore può scegliere di eseguirne un'altra sul dispositivo per valutare la domanda di remarketing memorizzata sul dispositivo. Dato che ora queste procedure vengono eseguite sul dispositivo, è importante ricordare i limiti esistenti per garantire che l'asta venga eseguita dall'inizio alla fine come progettata dai diversi partner di integrazione, in una serie di casi d'uso di remarketing.

Strategia di dati

Le piattaforme di tecnologia pubblicitaria devono prendere in considerazione i tipi di dati utilizzati nelle aste. Attualmente, queste informazioni vengono raccolte da varie fonti e poi centralizzate su un server. Le aste Protected Audience offrono diversi percorsi per trasmettere questi dati. Ad esempio, gli indicatori in tempo reale come il budget rimanente provengono da un servizio di tipo chiave-valore come indicatori attendibili, mentre gli indicatori contestuali come l'ora del giorno vengono inviati dai venditori quando viene eseguita un'asta. Questi indicatori sono descritti in modo più approfondito nelle sezioni pertinenti di questa guida.

Crea la tua soluzione

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

Acquirenti: creare un segmento di pubblico

In genere, gli acquirenti gestiscono i segmenti di pubblico personalizzati. Poiché i segmenti di pubblico personalizzati vengono gestiti sul dispositivo, l'API per la gestione dei segmenti di pubblico personalizzati è progettata per essere invocata sul dispositivo.

Se hai il tuo SDK nell'app per gli inserzionisti, puoi implementare questo codice direttamente tramite joinCustomAudience().

Se non hai il tuo 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 definire e gestire i segmenti di pubblico personalizzati. In questa guida viene utilizzato il termine "acquirente" indipendentemente dall'approccio impiegato. Ecco alcuni esempi di approcci:

• In qualità di acquirente, chiedi all'inserzionista di definire il segmento di pubblico. Un SDK di un partner di integrazione sul dispositivo può inviare eventi relativi all'app all'acquirente. Quando vengono soddisfatti i criteri predefiniti, l'acquirente invia un messaggio all'SDK per partecipare al segmento di pubblico personalizzato sul client per conto dell'acquirente.
• L'SDK può possedere direttamente il segmento di pubblico. Gli inserzionisti collaborano con un fornitore di SDK per definire il segmento di pubblico. L'SDK monitora gli eventi dell'app e si unisce al segmento di pubblico al momento opportuno, nonché comunica all'acquirente che un utente si è unito al segmento di pubblico.

Prototipo di campagna di remarketing: progettare un segmento di pubblico personalizzato

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

Protected Audience crea un contenitore per il segmento di pubblico personalizzato che viene mappato a un determinato coinvolgimento degli utenti personalizzato, come definito dall'inserzionista. Sono inclusi una raccolta di annunci candidati che possono essere mostrati a quel segmento di pubblico e una raccolta di dati e logica di offerte personalizzate che possono essere utilizzati durante un'asta per filtrare e stabilire il prezzo degli annunci.

Configurazione e prototipo

• Utilizza l'API Segmenti di pubblico personalizzati per creare e memorizzare sul dispositivo un segmento di pubblico che può essere utilizzato in un secondo momento in un'asta.
• Per informazioni dettagliate sull'implementazione e sull'utilizzo dell'API, consulta la guida per gli sviluppatori.

Note sul layout

I buyer possono supportare una serie di casi d'uso configurando segmenti di pubblico personalizzati. Ciò include la definizione della logica di offerta per il tipo di annuncio o campagna scelto come target per questo segmento di pubblico, la definizione dell'elenco di annunci candidati e considerazioni simili. Questa sezione include considerazioni di progettazione per compilare e utilizzare alcuni campi chiave in un segmento di pubblico personalizzato.

URL della logica di offerta

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

Indicatori di offerta per gli utenti

Gli acquirenti possono utilizzare UserBiddingSignals per trasmettere le informazioni sull'utente in possesso dell'inserzionista o dell'acquirente stesso alle aste future sul dispositivo. ad esempio:

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

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

• Aumenta o riduci le offerte in base agli indicatori di offerta.
• Filtra annunci specifici dall'asta.

Dati di offerte attendibili

Nell'ambito dell'implementazione di Protected Audience, gli acquirenti possono accedere a informazioni in tempo reale durante l'asta da un servizio key-value. Come meccanismo temporaneo, l'acquirente e il venditore possono recuperare questi indicatori di offerta da qualsiasi servizio, incluso uno gestito da loro stessi. L'esempio più comune è controllare il budget residuo per gli annunci. Durante lo sviluppo, è possibile simulare questo servizio e puoi sviluppare in base a questo endpoint simulato. Per le istruzioni di configurazione, consulta la directory FledgeServerSpec nel nostro repository di app di esempio su GitHub.

Il campo TrustedBiddingData è composto da un URL e da un insieme di chiavi. Di seguito sono riportate alcune considerazioni per la progettazione del tipo di struttura della chiave da utilizzare:

• Un approccio semplice è includere una chiave che mappa 1:1 al segmento di pubblico in fase di creazione. Il servizio di coppie chiave-valore può quindi contenere tutte le informazioni pertinenti associate al segmento di pubblico.
• Il budget e lo stato dell'annuncio sono aspetti importanti da considerare in tempo reale.
• Importo massimo dell'offerta o altri indicatori che possono essere utilizzati per stabilire il prezzo di un annuncio in un'asta. È possibile includere queste informazioni nell'annuncio in un elencoAdData, ma la loro memorizzazione in un servizio chiave-valore consente di aggiornarle più facilmente in base alle esigenze.

Elenco AdData

Quando creano una campagna di remarketing, gli inserzionisti in genere prendono in considerazione molti tipi di annunci diversi da mostrare a un utente di un segmento di pubblico, ad esempio annunci con diversi sconti in base al coinvolgimento precedente 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 ogni annuncio è a discrezione degli acquirenti. Alcuni aspetti da considerare:

• L'elenco AdData può essere aggiornato in due modi:
  • Quando l'app ha un'attività visibile in primo piano, può avviare l'elenco quando aggiunge un utente a un segmento di pubblico personalizzato.
  • Durante un aggiornamento giornaliero, il recupero è stato 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 aggiornato di AdData.
• È possibile richiedere ulteriori informazioni sugli annunci al momento dell'asta. Prima dell'asta, il dispositivo invia una richiesta al servizio di coppia chiave-valore degli acquirenti fornito nel campo trustedBiddingData di joinCustomAudience. Il servizio key-value è 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 intraprendere determinate azioni su creatività specifiche. Ad esempio, gli inserzionisti possono mettere in pausa creatività specifiche e tu vuoi estrarre gli ID creatività dal servizio di coppia chiave-valore in tempo reale e poi abbinarli agli annunci nell'elenco AdData.

AdData deve includere un render_url. L'URL di rendering dell'annuncio di remarketing vincente viene utilizzato per eseguire il rendering dell'annuncio. Ecco alcune considerazioni:

• L'URL di rendering ha una soglia di k-anonimità, quindi evita di includere parametri limitati. Ulteriori informazioni su questa soglia di k-anonimità verranno pubblicate in un secondo momento.
• Questo URL deve contenere tutte le informazioni necessarie per il rendering dell'annuncio. Ad esempio, se vuoi mostrare prodotti specifici, incorpora gli ID prodotto come parametri nell'URL.

Durante la creazione della prototipazione, l'unico campo obbligatorio è renderUri, che rimanda alle risorse di rendering dell'annuncio. Il campo dei metadati in AdData può essere ignorato durante la creazione della soluzione. Man mano che la tua soluzione si avvicina 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 ora di scadenza

Puoi utilizzare i campi dell'ora di attivazione e di scadenza per supportare i casi d'uso in cui un segmento di pubblico personalizzato deve essere idoneo per le aste solo in un periodo di tempo predefinito. Tieni presente che esistono alcune limitazioni per quanto riguarda il ritardo di un orario di attivazione e il delta tra l'ora di attivazione e quella di scadenza. Ecco alcuni esempi di casi d'uso:

• 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 come timestamp da applicare 7 giorni dopo.
  • Il segmento di pubblico è idoneo per le offerte se sono trascorsi 7 giorni dall'ultima apertura dell'app da parte dell'utente.
• Pubblico stagionale (un segmento di pubblico valido solo per un determinato periodo di tempo nel prossimo futuro)
  • Un acquirente può iniziare a definire in anticipo segmenti di pubblico personalizzati che devono essere idonei per le offerte solo durante un periodo di tempo predeterminato nel futuro (immediato).
  • 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 come sabato 20 agosto 2022. Se la campagna viene pubblicata solo per una settimana, l'acquirente può impostare la data di scadenza su 27 agosto 2022, dopodiché il segmento di pubblico personalizzato viene filtrato dalla piattaforma durante la selezione degli annunci ed eventualmente viene eseguito il garbage collection.

Acquirenti e venditori: selezione degli annunci

La selezione degli annunci richiede la collaborazione tra acquirenti e venditori. Questa procedura può essere considerata come un processo in quattro passaggi:

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 e un'offerta candidati.
4. La logica decisionale dei venditori viene eseguita per assegnare un punteggio ai candidati e selezionare un annuncio vincente.

Per semplificare lo sviluppo, è possibile simulare le risposte del servizio per acquirenti e venditori, inclusa la logica di offerta e di punteggio, in modo da concentrarti sullo sviluppo di ciò che è pertinente per il tuo caso d'uso. Consulta la directory FledgeServerSpec su GitHub per istruzioni su come configurare endpoint simulati o la guida per gli sviluppatori per istruzioni su come ignorare la necessità di recupero di JavaScript remoto.

Venditori: definisci la strategia di mediazione

Protected Audience ha lo scopo di supportare la mediazione con struttura a cascata. Questa funzionalità è in fase di sviluppo e verranno fornite ulteriori informazioni quando saranno disponibili. Per il momento, consulta la proposta di design per la mediazione con struttura a cascata in Protected Audience.

Venditori: configura l'asta

I venditori sono responsabili della configurazione dell'asta e forniscono informazioni per la procedura di selezione degli annunci. I venditori possono scegliere di rendere disponibili le informazioni per tutte le parti o solo per alcune. Potrebbero essere incluse informazioni in tuo possesso o informazioni che includi per conto degli acquirenti.

Configurazione e prototipo

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

Note sul layout

Questa sezione include considerazioni di progettazione per compilare e utilizzare i campi chiave in una configurazione di selezione degli annunci.

• L'ambiente di esecuzione privato include solo gli annunci per pubblico personalizzati sul dispositivo, pertanto l'emissione di una richiesta di annuncio contestuale in precedenza ti consente di prendere in considerazione la domanda aggiuntiva.

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

• Poiché molti acquirenti potrebbero aver creato segmenti di pubblico personalizzati sul dispositivo, i venditori devono utilizzare il campo acquirenti di segmenti di pubblico personalizzati per indicare gli acquirenti specifici da includere nel processo. Esistono molti modi per compilare questo elenco. Ecco alcuni esempi:

  • Un elenco statico di acquirenti che il venditore vuole sempre includere nel processo.
  • Un elenco di acquirenti che indicano di voler partecipare alla risposta all'annuncio. Questa opzione è utile se il venditore collabora con piattaforme di scambio pubblicitario e potrebbe non avere una conoscenza completa di tutti gli acquirenti.

• Il venditore può trasmettere le informazioni al processo in diversi modi:

  • Il campo degli indicatori di selezione degli annunci è disponibile per tutti gli acquirenti e il venditore che partecipano all'asta nel runtime privato. Utilizzalo per fornire informazioni sull'opportunità pubblicitaria, ad esempio le dimensioni e il formato dell'annuncio.
  • Il campo Indicatori per acquirente viene inoltrato a un acquirente specifico per essere utilizzato nella sua procedura di offerta. Queste informazioni vengono fornite dall'acquirente e tu, in qualità di venditore, devi decidere come ottenerle sul dispositivo per utilizzarle durante la selezione degli annunci.
  • Il campo Indicatori del venditore è l'ultimo modo in cui il venditore può trasmettere informazioni alla procedura. In qualità di venditore, utilizzi questi indicatori per assegnare un punteggio agli annunci e filtrarli, ad esempio attivando un controllo di sicurezza del brand.

Acquirenti: offerte per un'area annuncio

Configurazione e prototipo

• Un acquirente può aggiungere la propria logica di offerta alla funzione JavaScript generateBid() pubblicata dal set di parametri biddingLogicUrl quando crea un CustomAudience. Puoi configurare un servizio simulato utilizzando la specifica fornita o implementare questo endpoint su un server reale.
• Per informazioni dettagliate sull'implementazione e sull'utilizzo dell'API, consulta la guida per gli sviluppatori.

Note sul layout

• La logica di offerta viene eseguita sul dispositivo e alcuni indicatori utilizzati nell'asta vengono sottoposti a query in tempo reale. Consulta l'elenco delle limitazioni per informazioni sui 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 prendere in considerazione sul dispositivo.

Progettare la logica di offerta

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

Dati sulle offerte di approvvigionamento

Indicatori per le offerte in tempo reale con servizi chiave-valore

In qualità di acquirente, puoi recuperare indicatori in tempo reale durante un'asta da un servizio di valore chiave di tua proprietà. Puoi trovare un'implementazione iniziale di questo servizio nel repository pubblico di Privacy Sandbox oppure puoi creare un servizio personalizzato. L'URL di 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 stabilire la tua struttura di chiavi.

Indicatori di contesto e utente

La funzione generateBid ha accesso a ulteriori indicatori utente durante l'esecuzione dell'asta sul dispositivo. Questi indicatori vengono trasmessi 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 per l'utente. L'oggetto che contiene questi indicatori viene creato da Protected Audience stesso e trasmesso alla logica di offerta. Al momento 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 per sottoporlo alla nostra attenzione.

Il campo per_buyer_signals viene reso disponibile per la logica di offerta. Un venditore imposta questi valori durante la creazione della configurazione dell'asta. Gli acquirenti e i 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 sulla classificazione dell'app che richiede un annuncio e l'acquirente può utilizzare queste informazioni per filtrare determinati annunci.
• Invio di un embedding per un modello ML che prende in considerazione informazioni contestuali.

Venditori: assegna un punteggio e seleziona l'annuncio vincente

Configurazione e prototipo

• Un venditore può aggiungere la propria logica di punteggio alla funzione JavaScript scoreAd() che viene pubblicata dal set di parametri scoringLogicUrl durante la creazione del AdSelectionConfig. Puoi configurare un servizio simulato utilizzando la specifica fornita o implementare questo endpoint su un server reale.
• Per informazioni dettagliate sull'implementazione e sull'utilizzo dell'API, consulta la guida per gli sviluppatori.

Progettare 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 passati durante l'asta. Inoltre, la logica di punteggio sul dispositivo ha accesso a informazioni aggiuntive passate come parametri alla funzione scoreAd.

Fornire i dati per il calcolo del punteggio

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 di valore chiave di tua proprietà. Puoi trovare un'implementazione iniziale di questo servizio nel repository pubblico di Privacy Sandbox. L'URL di questo servizio viene specificato come trustedScoringUri nella configurazione dell'asta e la piattaforma tenta di recuperare i dati e renderli disponibili per la funzione scoreAd tramite il parametro trusted_scoring_signals. Devi stabilire la tua struttura di chiavi.

Indicatori di contesto e utente

La funzione scoreAd ha accesso a ulteriori indicatori utente durante l'esecuzione dell'asta sul dispositivo. Questi indicatori vengono trasmessi alla funzione di punteggio tramite il campo contextual_signal. Questo campo contiene oggetti 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. Viene trasmesso come oggetto vuoto. Se ritieni che un indicatore relativo all'utente possa essere pertinente al tuo caso d'uso, invia un feedback per sottoporlo alla nostra attenzione.

Venditori: visualizzare un annuncio

I venditori devono eseguire il rendering dell'annuncio vincente. Consulta la proposta di design per approfondire la modalità di visualizzazione degli annunci vincenti. Questa area è ancora in fase di progettazione.

Report sui risultati delle impressioni

Configurazione e prototipo

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

Note sul layout

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

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

Consigliati per te

• Nota: il testo del link viene visualizzato quando JavaScript è disattivato
• Guida per gli sviluppatori sull'API Protected Audience su Android
• Supportare il targeting per pubblico personalizzato con l'API Protected Audience
• Quota limite per Protected Audience