Protected Audience: guida all'integrazione

Le implementazioni di Protected Audience (precedentemente nota come FLEDGE) su Android in genere prevedono l'integrazione tra app dell'inserzionista, app del publisher, venditori e acquirenti. Questa guida è destinata ai partner che prevedono 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 casi più specializzati, ove possibile.

Per prepararsi all'implementazione della produzione su larga scala di Protected Audience, i partner possono iniziare a testare 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. Ciò può includere funzionalità non ancora implementate nella fase attuale dell'anteprima per sviluppatori di Privacy Sandbox su Android. 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 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 il codice di filtro e offerta lato acquisti.
   3. I servizi pubblicitari eseguono il codice di decisione lato venditore.
3. Viene eseguito il rendering dell'annuncio vincente nell'app del venditore.
4. I report sulle impressioni degli annunci vengono resi disponibili sia all'acquirente che al venditore.

Il seguente diagramma illustra questi passaggi:

Terminologia

• Inserzionista: una società che coinvolge gli utenti acquistando inventario pubblicitario.
• Publisher: un'azienda che vende l'inventario pubblicitario disponibile insieme ai suoi contenuti.
• Acquirente: una società di tecnologia pubblicitaria che aiuta gli inserzionisti ad acquistare inventario pubblicitario.
• Venditore: un'azienda di tecnologia pubblicitaria che aiuta i publisher a vendere l'inventario pubblicitario.
• Rete: una società di tecnologia pubblicitaria che funge sia da acquirente che da venditore.
• Di proprietà e gestito: una società che funge da editore, venditore e acquirente.
• Partner di integrazione: tutte le aziende con cui devi collaborare per integrare correttamente Protected Audience.

Prerequisiti, coinvolgimento del partner di integrazione e configurazione

Questa sezione descrive 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 partner di integrazione per l'implementazione di Protected Audience. Queste attività possono essere eseguite in parallelo.

Familiarizzare con Protected Audience

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

1. Inizia leggendo la proposta di progettazione 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 necessari per i tuoi casi d'uso e i servizi necessari per l'integrazione con Protected Audience.
3. Invia feedback in merito alla progettazione e all'implementazione di API, servizi e documentazione Protected Audience.
4. Registrati per ricevere aggiornamenti per rimanere al corrente sulle ultime funzionalità di Privacy Sandbox.

Configurare e testare le app di esempio

Una volta acquisita 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 l'ambiente di sviluppo con l'ultima anteprima per gli sviluppatori di Privacy Sandbox.
2. Configura gli endpoint server richiesti. Utilizza i mock di esempio con la soluzione di test delle API che preferisci per avviare questo processo.
3. Forca ed esegui il codice nella nostra app di esempio per acquisire familiarità con la gestione dei segmenti di pubblico personalizzati, il flusso di lavoro di selezione degli annunci e il reporting delle 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 unirsi a segmenti di pubblico personalizzati, che possono includere discussioni su come vengono definiti i segmenti di pubblico. Collabora con i partner di integrazione per definire le tempistiche di integrazione, dai test iniziali all'adozione, e le aree di responsabilità di ciascuna parte nella progettazione.

Configurazione della versione beta (disponibile nel quarto trimestre)

Registra la tua organizzazione a Privacy Sandbox su Android. La registrazione è necessaria per garantire che gli sviluppatori di tecnologie pubblicitarie operino nel rispetto delle norme di Privacy Sandbox e consente loro di definire la propria identità in più SDK e domini.

Considerazioni architettoniche

Per acquirenti e venditori, Protected Audience introduce la possibilità di eseguire aste di annunci sul dispositivo. Tu e i tuoi partner di integrazione dovete tenere conto di diverse considerazioni critiche nei vostri progetti:

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

A differenza di oggi, in cui gli annunci vengono memorizzati interamente sui server, le informazioni sul pubblico e gli annunci di remarketing vengono memorizzati sul dispositivo. Gli annunci contestuali che non si basano sui dati sul dispositivo per il targeting continuano a rimanere sui server. Le piattaforme di tecnologia pubblicitaria devono essere ampliate per considerare la domanda di annunci distribuita tra server e dispositivi.

I processi di offerta e asta 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 eseguano aste per gli annunci contestuali come fanno oggi. Dopo aver completato l'asta, un venditore può scegliere di eseguire un'asta sul dispositivo per valutare la domanda di remarketing memorizzata sul dispositivo. Poiché questi processi vengono ora eseguiti sul dispositivo, è importante ricordare i limiti esistenti per verificare che l'asta venga eseguita end-to-end come progettato dai diversi partner di integrazione, in una serie di casi d'uso del remarketing.

Strategia dei dati

Le piattaforme di tecnologia pubblicitaria devono prendere in considerazione i tipi di dati utilizzati nelle aste. Oggi, 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 chiave-valore come indicatori attendibili, mentre gli indicatori contestuali come l'ora del giorno vengono inviati dai venditori durante l'esecuzione di un'asta. Questi indicatori sono spiegati in modo più approfondito nelle sezioni pertinenti di questa guida.

Crea la tua soluzione

L'esecuzione di un'asta con Protected Audience prevede diverse fasi chiave. Gli acquirenti devono creare il segmento di pubblico, fornire i dati sulle offerte, scegliere come target degli annunci 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 di entrambe le parti per garantire la corretta esecuzione 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 richiamata sul dispositivo.

Se hai il tuo SDK presente nell'app degli inserzionisti, puoi implementare questo codice direttamente utilizzando joinCustomAudience().

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

• In qualità di acquirente, chiedi all'inserzionista di definire il segmento di pubblico. L'SDK di un partner di integrazione sul dispositivo può inviare eventi relativi alle app all'acquirente. Quando vengono soddisfatti i criteri predefiniti, l'acquirente invia un messaggio all'SDK per entrare a far parte del segmento di pubblico personalizzato sul client per conto dell'acquirente.
• L'SDK può essere proprietario del pubblico direttamente. Gli inserzionisti collaborano con un fornitore di SDK per definire il segmento di pubblico. L'SDK monitora gli eventi dell'app e unisce l'utente al segmento di pubblico al momento opportuno e comunica all'acquirente che un utente è stato aggiunto al segmento di pubblico.

Campagna di remarketing prototipo: progetta un segmento di pubblico personalizzato

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

Protected Audience crea un contenitore per il segmento di pubblico personalizzato che corrisponde a un determinato coinvolgimento degli utenti personalizzato definito dall'inserzionista. Ciò include una raccolta di annunci candidati che possono essere mostrati a quel segmento di pubblico e una raccolta di dati e logica di offerta personalizzati che possono essere utilizzati durante un'asta per filtrare e prezzare gli annunci.

Configurazione e prototipo

• Utilizza l'API per i segmenti di pubblico personalizzati per creare e archiviare un segmento di pubblico sul dispositivo 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

Gli acquirenti 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 a cui è destinato questo segmento di pubblico, la definizione dell'elenco degli annunci candidati e considerazioni simili. Questa sezione include considerazioni sulla 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 dei segnali utente sono spiegate più avanti in questo articolo.

Indicatori di offerta degli utenti

Gli acquirenti possono utilizzare UserBiddingSignals per trasmettere le informazioni che l'inserzionista o l'acquirente stesso ha sull'utente nelle aste future sul dispositivo. Queste possono includere informazioni quali:

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

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

• Aumentare o diminuire l'offerta in base agli indicatori di offerta.
• Filtra annunci specifici dall'asta.

Dati delle offerte attendibili

Nell'ambito dell'implementazione di Protected Audience, gli acquirenti possono accedere a 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 uno gestito direttamente. L'esempio più comune è quello di controllare il budget residuo per gli annunci. Durante lo sviluppo, è possibile simulare questo servizio e puoi sviluppare in base a questo endpoint simulato. Consulta la directory FledgeServerSpec nel nostro repository di app di esempio su GitHub per le istruzioni di configurazione.

Il campo TrustedBiddingData è composto da un URL e da un insieme di chiavi. Ecco alcuni aspetti da considerare quando progetti il tipo di struttura delle chiavi da utilizzare:

• Un approccio consiste nell'includere una chiave che esegue il mapping 1:1 al pubblico che viene creato. Il servizio chiave-valore può quindi contenere tutte le informazioni pertinenti associate al 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 determinare il prezzo di un annuncio in un'asta. È possibile includere queste informazioni con l'annuncio in un elenco AdData, ma memorizzarle in un servizio chiave-valore consente di aggiornarle in base alle esigenze.

Elenco AdData

Quando creano una campagna di remarketing, gli inserzionisti in genere prendono in considerazione molti tipi diversi di annunci da mostrare a un utente in un segmento di pubblico, ad esempio pubblicità con sconti diversi in base al precedente coinvolgimento dell'utente con l'app. Un segmento di pubblico personalizzato include un elenco AdData che contiene gli annunci candidati.

Spetta agli acquirenti decidere la quantità di informazioni da includere per ogni annuncio. 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 unisce un utente a un segmento di pubblico personalizzato.
  • Durante un aggiornamento giornaliero, il recupero viene avviato in background. Il dispositivo invia una richiesta a daily_update_url incluso nella chiamata joinCustomAudience e si aspetta una risposta che includa un elenco AdData aggiornato.
• Al momento dell'asta possono essere richieste ulteriori informazioni sugli annunci. Prima dell'asta, il dispositivo invia una richiesta al servizio chiave-valore degli acquirenti 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 intraprendere determinate azioni su creatività specifiche. Ad esempio, gli inserzionisti potrebbero mettere in pausa creatività specifiche e tu vuoi estrarre gli ID creatività dal servizio di coppie chiave-valore in tempo reale e poi 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 eseguire il rendering dell'annuncio. Alcune considerazioni includono:

• L'URL di rendering ha una soglia di k-anonimato, quindi evita di includere parametri ristretti. Ulteriori informazioni su questa soglia di k-anonymity 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 prototipazione, l'unico campo obbligatorio è renderUri, che punta 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 relativi all'ora di attivazione e scadenza per supportare i 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 alcuni limiti per il tempo di ritardo di un'attivazione e per la differenza tra l'ora di attivazione e quella di scadenza. 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 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 devono essere idonei per le offerte solo durante un periodo di tempo predeterminato nel futuro (prossimo).
  • Ad esempio, se un inserzionista ha una campagna di fine estate negli Stati Uniti nel 2022, il suo 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, dopodiché il segmento di pubblico personalizzato viene filtrato dalla piattaforma durante la selezione degli annunci e infine raccolto come spazzatura.

Acquirenti e venditori: selezione degli annunci

La selezione degli annunci richiede la collaborazione tra acquirenti e venditori. Questo può essere considerato un processo 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 vengono invitati a partecipare all'asta utilizzando 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 gli acquirenti e per i venditori, inclusa la logica di offerta e assegnazione del punteggio, consentendoti di concentrarti sullo sviluppo di ciò che è pertinente al tuo caso d'uso. Per istruzioni sulla configurazione degli endpoint di simulazione, consulta la directory FledgeServerSpec su GitHub oppure la guida per gli sviluppatori per istruzioni su come ignorare la necessità di recuperare JavaScript da remoto.

Venditori: definire la strategia di mediazione

Protected Audience mira a supportare la mediazione con struttura a cascata. Questa sezione è in fase di sviluppo e verranno fornite ulteriori informazioni quando saranno disponibili. Per il momento, fai riferimento alla proposta di progettazione per la mediazione con struttura a cascata in Protected Audience.

Venditori: configura l'asta

I venditori sono responsabili della configurazione dell'asta e della fornitura di informazioni al processo di selezione degli annunci. I venditori possono scegliere di rendere disponibili le informazioni a tutti o solo a parti selezionate. Ciò può includere informazioni che hai 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 richiamando 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 il popolamento e l'utilizzo dei campi chiave in una configurazione di selezione degli annunci.

• L'ambiente di esecuzione privato include solo annunci per segmenti di pubblico personalizzati sul dispositivo, pertanto l'invio di una richiesta di annuncio contestuale in precedenza consente di prendere in considerazione una 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 creare 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 le piattaforme di scambio di annunci e potrebbe non conoscere tutti gli acquirenti.

• Il venditore può trasmettere informazioni alla procedura 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 procedura di offerta. Queste informazioni vengono fornite dall'acquirente e tu, in qualità di venditore, devi valutare come inserirle sul dispositivo per utilizzarle durante la selezione degli annunci.
  • Il campo Segnali del venditore è l'ultimo modo per il venditore di trasmettere informazioni alla procedura. In qualità di venditore, utilizzi questi indicatori quando valuti e filtri gli annunci, ad esempio quando attivi un controllo di sicurezza del brand.

Acquirenti: offerta per uno spazio pubblicitario

Configurazione e prototipo

• Un acquirente può aggiungere la propria logica di offerta alla funzione JavaScript generateBid() fornita dal parametro biddingLogicUrl impostato durante la creazione di 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 alcune indicazioni utilizzate nell'asta vengono richieste in tempo reale. Consulta l'elenco delle limitazioni per i vincoli.
• Per alcuni casi d'uso degli annunci, è importante collaborare con il venditore per verificare di disporre di più candidati annuncio e delle relative offerte da prendere in considerazione sul dispositivo.

Progettare la logica di offerta

La logica di offerta degli acquirenti deve essere implementata utilizzando JavaScript ed è eseguita sul dispositivo. La guida per 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().

Dati delle offerte di fornitura

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 chiave-valore 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 alla tua funzione generateBid con trusted_bidding_signals parameter. Devi stabilire la tua struttura delle chiavi.

Indicatori contestuali e degli utenti

La funzione generateBid ha accesso a indicatori utente aggiuntivi quando esegue l'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 sull'utente. L'oggetto che contiene questi indicatori viene creato da Protected Audience e trasmesso alla tua logica di offerta. Viene passato come oggetto vuoto. Se ritieni che un segnale contestuale sull'utente possa essere pertinente al tuo caso d'uso, invia un feedback per la valutazione.

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. Acquirenti e venditori devono collaborare per verificare che questi dati siano sul dispositivo e vengano trasmessi alla logica di offerta. Alcuni esempi di utilizzo di questo campo includono:

• Filtro per la sicurezza del brand. Il venditore può comunicare agli acquirenti alcune informazioni di classificazione sull'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 prende in considerazione informazioni contestuali.

Venditori: assegnare un punteggio e selezionare l'annuncio vincente

Configurazione e prototipo

• Un venditore può aggiungere la propria logica di assegnazione del punteggio alla funzione JavaScript scoreAd() che viene pubblicata dal parametro scoringLogicUrl impostato durante la creazione di 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 assegnazione del punteggio

I venditori implementano la logica di assegnazione del 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.

Dati di valutazione dell'offerta

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 di questo servizio è specificato come trustedScoringUri nella configurazione dell'asta e la piattaforma tenta di recuperare i dati e renderli disponibili alla tua funzione scoreAd utilizzando il parametro trusted_scoring_signals. Devi stabilire la tua struttura delle chiavi.

Indicatori contestuali e degli utenti

La funzione scoreAd ha accesso a indicatori utente aggiuntivi quando esegue l'asta sul dispositivo. Questi indicatori vengono passati alla funzione di assegnazione del punteggio utilizzando 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 assegnazione del punteggio. Questo viene trasmesso come oggetto vuoto. Se ritieni che un segnale relativo all'utente possa essere pertinente al tuo caso d'uso, invia un feedback per la valutazione.

Venditori: visualizzare un annuncio

I venditori devono eseguire il rendering dell'annuncio vincente. Consulta la proposta di progettazione per ulteriori dettagli su come vengono visualizzati gli annunci vincenti. Questa area è ancora in fase di progettazione.

Risultati delle impressioni del report

Configurazione e prototipo

• Acquirenti e venditori possono aggiungere la logica di generazione dei report alla funzione JavaScript reportWin() pubblicata 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

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

Privacy Sandbox fornisce anche un'API Attribution Reporting per la gestione di report a livello di evento e aggregati. Per ulteriori dettagli, leggi 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 Protected Audience