Supportare il targeting per pubblico personalizzato con l'API Protected Audience

Nota: questo articolo riflette le attuali proposte di design di Privacy Sandbox su Android ed è soggetto a ulteriori modifiche. Incoraggiamo il tuo feedback e i tuoi commenti per contribuire a queste iniziative.

Inviare feedback

Aggiornamenti recenti

• Aggiunta l'integrazione dei report sull'attribuzione con i segmenti di pubblico protetti
• È stata pubblicata una sequenza temporale delle funzionalità di Protected Audience.
• FLEDGE è stata rinominata API Protected Audience.
• È stata aggiunta una proposta per la delega di segmenti di pubblico personalizzati.
• È stato rimosso il requisito di k-anonymity per l'URL di aggiornamento giornaliero.

Protected Audience è in versione beta ed è disponibile per i test su dispositivi pubblici.

Con Protected Audience puoi:

• Gestisci i segmenti di pubblico personalizzati in base alle azioni precedenti degli utenti.
• Avvio di aste on-device con il supporto della mediazione per singolo venditore o a cascata.
• Report sulle impressioni dell'esercizio dopo la selezione degli annunci.

Per iniziare, leggi la guida per gli sviluppatori di Protected Audience. Apprezziamo il tuo feedback perché continuiamo a sviluppare Protected Audience.

Sequenza

Nei prossimi mesi rilasceremo nuove funzionalità. Le date di rilascio esatte varieranno a seconda della funzionalità e questa tabella verrà aggiornata con i link alla documentazione non appena sarà disponibile.

Funzionalità	Disponibile in Anteprima per sviluppatori	Disponibile in versione beta
Report a livello di evento	T1 2023	T3 '23
Mediazione a cascata	T1 2023	T4 '23
Filtro degli annunci per l'installazione di app	T2 '23	T3 '23
Filtro per quota limite	T2 '23	T3 '23
Trasmettere gli annunci contestuali al flusso di lavoro per la selezione degli annunci per l'applicazione di filtri	T2 '23	T3 '23
Report sulle interazioni	T2 '23	T3 '23
Partecipare alla delega dei segmenti di pubblico personalizzati	T3 '23	T4 '23
fatturazione non CPM	T3 '23	T4 '23
Integrazione dei servizi di asta e aste	T3 '23	T4 '23
Report di debug	T3 '23	T4 '23
Integrazione dei report sull'attribuzione	N/A	T4 '23
Mediazione Open Bidding	T4 '23	T4 '23
Gestione della valuta	T1 2024	T2 '24
Integrazione K-anon	N/A	T2 '24
Integrazione dei report aggregati	T3 2024	T4 '24

Panoramica

Nella pubblicità per il mobile, gli inserzionisti di solito devono pubblicare annunci per utenti potenzialmente interessati in base al modo in cui hanno interagito in precedenza con l'app dell'inserzionista. Ad esempio, lo sviluppatore di SportingGoodsApp potrebbe voler fare pubblicità per gli utenti che hanno lasciato gli articoli nel carrello degli acquisti, mostrando annunci per ricordare agli utenti di completare l'acquisto. Il settore descrive comunemente questa idea generale con termini quali "remarketing" e "targeting per pubblico personalizzato".

Oggi questi casi d'uso vengono in genere implementati condividendo informazioni contestuali su come viene mostrato l'annuncio (ad esempio il nome dell'app) e informazioni private come gli elenchi dei segmenti di pubblico con piattaforme di tecnologia pubblicitaria. Grazie a queste informazioni, gli inserzionisti possono selezionare annunci pertinenti sui propri server.

L'API Protected Audience su Android (precedentemente nota come FLEDGE) comprende le seguenti API per piattaforme di tecnologia pubblicitaria e inserzionisti al fine di supportare casi d'uso comuni basati sull'interazione in modi che limitano la condivisione di entrambi gli identificatori tra le app e le informazioni sulle interazioni delle app di un utente con terze parti:

1. API Custom Audience: è incentrata sull'astrazione "segmento di pubblico personalizzato", che rappresenta un segmento di pubblico designato dall'inserzionista con intenzioni comuni. Le informazioni sul pubblico sono memorizzate sul dispositivo e possono essere associate ad annunci candidati pertinenti per il segmento di pubblico e a metadati arbitrari, come gli indicatori di offerta. Queste informazioni possono essere usate per definire le offerte degli inserzionisti, i filtri degli annunci e il rendering.
2. API Ad Selection: fornisce un framework che orchestra i flussi di lavoro delle piattaforme di tecnologia pubblicitaria che sfruttano gli indicatori on-device per determinare un annuncio "vincente" prendendo in considerazione gli annunci candidati memorizzati localmente ed eseguendo ulteriori elaborazioni sugli annunci candidati che una piattaforma di tecnologia pubblicitaria restituisce al dispositivo.

Grafico di flusso che mostra il flusso di lavoro per la gestione e la selezione degli annunci personalizzati in Privacy Sandbox su Android.

Nota: questa proposta di progettazione si concentra sui casi d'uso della pubblicità basata sull'interazione tra utenti dall'app e l'app, in cui un'app può registrare segmenti di pubblico personalizzati che possono essere presi in considerazione per la pubblicazione di annunci in altre app. Per il futuro verranno presi in considerazione ulteriori dettagli su altri casi d'uso, ad esempio quando l'utente interagisce in un'app web con WebView e il browser.

A livello generale, l'integrazione funziona come segue:

1. SportingGoodsApp vuole ricordare ai suoi utenti di acquistare gli articoli di merchandising lasciati nel carrello se non hanno completato l'acquisto entro 2 giorni. SportingGoodsApp utilizza l'API Custom Audience per aggiungere l'utente all'elenco del segmento di pubblico "Prodotti nel carrello". La piattaforma gestisce e memorizza questo elenco del segmento di pubblico sul dispositivo, limitando la condivisione con terze parti. SportingGoodsApp collabora con una piattaforma ad tech per mostrare i suoi annunci agli utenti nel suo elenco del segmento di pubblico. La piattaforma ad tech gestisce i metadati per gli elenchi dei segmenti di pubblico e fornisce annunci candidati, che vengono messi a disposizione del flusso di lavoro di selezione degli annunci affinché vengano presi in considerazione. La piattaforma può essere configurata per recuperare periodicamente in background gli annunci basati sui segmenti di pubblico aggiornati. Ciò consente di mantenere l'elenco di annunci candidati basati sul pubblico aggiornato e non correlato alle richieste inviate a ad server di terze parti durante l'opportunità di annuncio (ovvero, la richiesta di annuncio contestuale).

2. Quando l'utente gioca a FrisbeeGame sullo stesso dispositivo, può visualizzare un annuncio che gli ricorda di completare l'acquisto degli articoli rimasti nel carrello di SportingGoodsApp. Per ottenere questo risultato, FrisbeeGame (con un SDK per gli annunci integrato) richiama l'API Ad Selection per selezionare un annuncio vincente per l'utente in base a qualsiasi elenco del segmento di pubblico di cui potrebbe far parte (in questo esempio, il segmento di pubblico personalizzato "prodotti nel carrello" creato da SportingGoodsApp). Il flusso di lavoro per la selezione degli annunci può essere configurato in modo da prendere in considerazione gli annunci recuperati dai server delle piattaforme di tecnologia pubblicitaria, oltre agli annunci on-device associati ai segmenti di pubblico personalizzati e ad altri indicatori on-device. Il flusso di lavoro può anche essere personalizzato dalla piattaforma di ad tech e dall'SDK per gli annunci con offerte personalizzate e logica di punteggio per raggiungere obiettivi pubblicitari appropriati. Questo approccio consente ai dati sugli interessi dell'utente o sulle interazioni con l'app di influenzare la selezione degli annunci, limitando al contempo la condivisione di questi dati con terze parti.

3. L'SDK dell'app per la pubblicazione di annunci o della piattaforma di tecnologia pubblicitaria esegue il rendering dell'annuncio selezionato.

4. La piattaforma facilita la generazione di report sulle impressioni e sui risultati di selezione degli annunci. Questa funzionalità di reporting è complementare con l'API Attribution Reporting. Le piattaforme di tecnologia pubblicitaria possono essere personalizzate in base alle proprie esigenze di generazione di report.

Accedere a Protected Audience sulle API Android

Le piattaforme di tecnologia pubblicitaria devono registrarsi per accedere all'API Protected Audience. Per ulteriori informazioni, consulta Creare un account Privacy Sandbox.

Gestione dei segmenti di pubblico personalizzati

Segmento di pubblico personalizzato

Un segmento di pubblico personalizzato rappresenta un gruppo di utenti stabilito dall'inserzionista con intenzioni o interessi comuni. Un'app o un SDK può utilizzare un segmento di pubblico personalizzato per indicare un determinato segmento di pubblico, ad esempio un utente che ha "lasciato articoli nel carrello degli acquisti" o "ha completato i livelli principiante" di un gioco. La piattaforma gestisce e memorizza le informazioni sul pubblico localmente sul dispositivo e non espone i segmenti di pubblico personalizzati in cui si trova l'utente. I segmenti di pubblico personalizzati sono distinti dai gruppi di interesse Protected Audience di Chrome e non possono essere condivisi tra web e app. Ciò consente di limitare la condivisione delle informazioni degli utenti.

Un'app dell'inserzionista o l'SDK integrato può join o lasciare un segmento di pubblico personalizzato in base, ad esempio, al coinvolgimento degli utenti in un'app.

Metadati dei segmenti di pubblico personalizzati

Ogni segmento di pubblico personalizzato contiene i seguenti metadati:

• Proprietario: nome del pacchetto dell'app proprietario. È implicitamente impostato sul nome del pacchetto dell'app del chiamante.
• Acquirente: rete pubblicitaria dell'acquirente che gestisce gli annunci per questo segmento di pubblico personalizzato. L'acquirente rappresenta anche la parte che può accedere al segmento di pubblico personalizzato e recuperare le informazioni pertinenti sull'annuncio. L'acquirente viene specificato seguendo il formato eTLD+1.
• Nome: un nome o identificatore arbitrario per il segmento di pubblico personalizzato, ad esempio un utente che ha "utenti che hanno abbandonato il carrello degli acquisti". Questo attributo può essere utilizzato, ad esempio, come uno dei criteri di targeting nelle campagne pubblicitarie dell'inserzionista o come una stringa di query nell'URL per recuperare il codice di offerta.
• Ora di attivazione e ora di scadenza: questi campi definiscono la finestra temporale in cui verrà applicato il segmento di pubblico personalizzato. La piattaforma utilizza queste informazioni per recedere da un segmento di pubblico personalizzato. La data di scadenza non può superare una finestra di durata massima per limitare la durata di un segmento di pubblico personalizzato.
• URL aggiornamento giornaliero: l'URL utilizzato dalla piattaforma per recuperare gli annunci candidati e altri metadati definiti nei campi "Indicatori di offerta dell'utente" e "Indicatori di offerta attendibili" su base ricorrente. Per ulteriori dettagli, consulta la sezione su come recuperare annunci candidati per segmenti di pubblico personalizzati.
• Indicatori delle offerte utente: indicatori specifici della piattaforma di tecnologia pubblicitaria per tutte le offerte per gli annunci di remarketing. Esempi di indicatori includono: posizione approssimativa dell'utente, impostazioni internazionali preferite e così via.
• Dati sulle offerte affidabili: le piattaforme di tecnologia pubblicitaria si basano su dati in tempo reale per il recupero e il punteggio degli annunci. Ad esempio, il budget di un annuncio potrebbe essere esaurito e la pubblicazione deve essere interrotta immediatamente. Una tecnologia pubblicitaria può definire un endpoint URL da cui è possibile recuperare questi dati in tempo reale e il set di chiavi per cui deve essere eseguita la ricerca in tempo reale. Il server che gestisce questa richiesta sarà un server attendibile gestito dalla piattaforma di tecnologia pubblicitaria.
• URL logica dell'offerta:l'URL utilizzato dalla piattaforma per recuperare il codice delle offerte dalla Demand-Side Platform. La piattaforma esegue questo passaggio all'avvio di un'asta dell'annuncio.
• Annunci: un elenco di annunci candidati per il segmento di pubblico personalizzato. Sono inclusi i metadati dell'annuncio specifici della piattaforma di tecnologia pubblicitaria e un URL per visualizzare l'annuncio. Quando viene avviata un'asta per il segmento di pubblico personalizzato, viene preso in considerazione questo elenco di metadati degli annunci. Questo elenco di annunci verrà aggiornato utilizzando l'endpoint URL di aggiornamento giornaliero, se possibile. A causa dei limiti di risorse sui dispositivi mobili, esiste un limite al numero di annunci che possono essere archiviati in un segmento di pubblico personalizzato.

Delega dei segmenti di pubblico personalizzati

La definizione e la configurazione tradizionali dei segmenti di pubblico personalizzati si basano solitamente su integrazioni e tecnologie lato server basate su tecnologie pubblicitarie in collaborazione con clienti e partner di agenzie e inserzionisti. L'API Protected Audience consente la definizione e la configurazione dei segmenti di pubblico personalizzati, proteggendo al contempo la privacy degli utenti. Per entrare in un segmento di pubblico personalizzato, i tecnici pubblicitari degli acquirenti che non hanno una presenza di SDK nelle app devono collaborare con i tecnici pubblicitari che hanno una presenza on-device, come i partner di misurazione mobile (MMP) e Supply-Side Platform (SSP). L'API Protected Audience mira a supportare questi SDK fornendo soluzioni flessibili per la gestione dei segmenti di pubblico personalizzati, consentendo ai chiamanti sul dispositivo di richiamare la creazione di segmenti di pubblico personalizzati per conto degli acquirenti. Questa procedura è chiamata delega dei segmenti di pubblico personalizzati. Per configurare la delega di segmenti di pubblico personalizzati:

Entra in un segmento di pubblico personalizzato

L'aggiunta di un segmento di pubblico personalizzato può essere eseguita in due modi:

joinCustomAudience()

Un'app o un SDK può richiedere di partecipare a un segmento di pubblico personalizzato chiamando joinCustomAudience() dopo aver creato un'istanza dell'oggetto CustomAudience con i parametri previsti. Ecco un esempio di snippet di codice illustrativo:

CustomAudience audience = new CustomAudience(
    Buyer = "example-dsp.com",
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    DailyUpdateURL = Uri.parse("https://..."),
    UserBiddingSignals = new JSONObject("{...}"),
    TrustedBiddingURL = Uri.parse("https://..."),
    TrustedBiddingKeys = {'key1","key2", ...,"key n"},
    BiddingLogicURL =  Uri.parse("https://..."),
    Ads = [new AdData(renderUrl = Uri.parse("https://..."),
           metadata = new JSONObject("{...}"), ...];

// Invoke ad services API to join a custom audience.
joinCustomAudience(audience);

fetchAndJoinCustomAudience()

Un'app o un SDK può richiedere di partecipare a un segmento di pubblico personalizzato per conto di una tecnologia pubblicitaria che non ha una presenza sul dispositivo chiamando fetchAndJoinCustomAudience() con i parametri previsti, come nell'esempio seguente:

FetchAndJoinCustomAudienceRequest fetchRequest = new FetchAndJoinCustomAudienceRequest(
    // Example: Optional verification token passed inside the fetch URL
    FetchURI = Uri.parse("https://example-dsp.com/...?mytoken=arbitrary1234"),
    // All the following parameters are optional
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    UserBiddingSignals = new JSONObject("{...}")
);

fetchAndJoinCustomAudience(fetchRequest);

L'endpoint URL di proprietà dell'acquirente risponde con un oggetto JSON CustomAudience nel corpo della risposta. I campi Acquirente e Proprietario del segmento di pubblico personalizzato vengono ignorati (e vengono compilati automaticamente dall'API). L'API impone anche che l'URL di aggiornamento giornaliero corrisponda anche all'eTLD+1 dell'acquirente.

{
 "name": "running-shoes",
 "activation_time": 1680603133000,
 "expiration_time": 1680803133000,
 "user_bidding_signals" : {"signal1": "value"},
 "trusted_bidding_data": {
    "trusted_bidding_uri": "https://example-dsp.com/.."
    "trusted_bidding_keys": ["k1", "k2"],
 },
 "bidding_logic_uri": "https://example-dsp.com/...",
 "daily_update_uri": "https://example-dsp.com/...",
 "ads": [
   {
     "render_uri": "https://example-dsp.com/...",
     "metadata": {},
     "ad_filters": {
       "frequency_cap": {
         "win": [
           {
             "ad_counter_key": 1,
             "max_count": 2,
             "interval_in_seconds": 60
           },
         ],
         "view": [
           {
             "ad_counter_key": 2,
             "max_count": 10,
             "interval_in_seconds": 3600
           },
         ]
       },
       "app_install": {
         "package_names": [
           "package.name.one",
           "package.name.two", ...
         ]
       }
     }
   },
   ...
 ]
}

L'API fetchAndJoinCustomAudience() determina l'identità dell'acquirente dall'eTLD+1 di fetchUri. L'identità dell'acquirente CustomAudience viene utilizzata per eseguire gli stessi controlli di registrazione e autorizzazione dell'app effettuati da joinCustomAudience() e non può essere modificata dalla risposta di recupero. Il proprietario CustomAudience è il nome del pacchetto dell'applicazione di chiamata. Non esiste un'altra convalida di fetchUri a parte il controllo eTLD+1 e, in particolare, non esiste un controllo k-anon. L'API fetchAndJoinCustomAudience() invia una richiesta HTTP GET a fetchUri e si aspetta un oggetto JSON che rappresenti il segmento di pubblico personalizzato. Alla risposta vengono applicati gli stessi vincoli obbligatori e facoltativi e gli stessi valori predefiniti per i campi degli oggetti dei segmenti di pubblico personalizzati. Scopri di più sui requisiti e sulle limitazioni attuali nella nostra Guida per gli sviluppatori.

Qualsiasi risposta a un errore HTTP dell'acquirente determina l'errore fetchAndJoinCustomAudience. In particolare, una risposta dello stato HTTP di 429 (Troppe richieste) blocca le richieste dell'applicazione corrente per un periodo da definire. La chiamata API non va a buon fine anche se la risposta dell'acquirente non è nel formato corretto. Gli errori vengono segnalati al chiamante dell'API responsabile di riprovare a causa di errori temporanei (come il server non risponde) o della gestione di errori persistenti (come errori di convalida dei dati o altri errori non transitori di comunicazione al server).

L'oggetto CustomAudienceFetchRequest consente al chiamante dell'API di definire alcune informazioni per il segmento di pubblico personalizzato utilizzando le proprietà facoltative mostrate nell'esempio sopra. Se impostati nella richiesta, questi valori non possono essere sovrascritti dalla risposta dell'acquirente ricevuta dalla piattaforma; l'API Protected Audience ignora i campi nella risposta. Se non sono impostati nella richiesta, devono essere impostati nella risposta poiché questi campi sono obbligatori per creare un segmento di pubblico personalizzato. Una rappresentazione JSON del contenuto di CustomAudience come parzialmente definito dal chiamante API è inclusa nella richiesta GET a fetchUri in un'intestazione speciale X-CUSTOM-AUDIENCE-DATA. Le dimensioni della forma serializzata dei dati specificati per il segmento di pubblico personalizzato sono limitate a 8 kB. Se le dimensioni vengono superate, la chiamata API fetchAndJoinCustomAudience non va a buon fine.

La mancanza di un controllo k-anon consente di utilizzare fetchUri per la verifica dell'acquirente e per attivare la condivisione delle informazioni tra l'acquirente e l'SDK. Per facilitare la verifica dei segmenti di pubblico personalizzati, l'acquirente può fornire un token di verifica. L'SDK on-device deve includere questo token in fetchUri affinché l'endpoint ospitato dall'acquirente possa recuperare i contenuti del segmento di pubblico personalizzato e utilizzare il token di verifica per verificare che l'operazione fetchAndJoinCustomAudience() corrisponda all'acquirente e provenga da un partner on-device attendibile. Per condividere informazioni, l'acquirente può concordare con il chiamante sul dispositivo che alcune delle informazioni da utilizzare per creare il segmento di pubblico personalizzato vengano aggiunti come parametri di query a fetchUri. Ciò consente all'acquirente di controllare le chiamate e rilevare se un token di convalida è stato utilizzato da una tecnologia pubblicitaria dannosa per creare diversi segmenti di pubblico personalizzati.

Nota sulla definizione e sull'archiviazione dei token di verifica

• Il token di verifica non viene utilizzato per alcuna finalità dall'API Protected Audience ed è facoltativo.

  • Il token di verifica può essere utilizzato dall'acquirente per verificare che i segmenti di pubblico creati vengano eseguiti per suo conto.
  • La proposta dell'API Protected Audience non specifica né un formato per il token di verifica, né il modo in cui l'acquirente trasferisce il token al chiamante. Ad esempio, il token di verifica potrebbe essere precaricato nell'SDK o nel backend del proprietario oppure può essere recuperato in tempo reale dall'SDK del proprietario dal server dell'acquirente.

Esci da un segmento di pubblico personalizzato

Il proprietario di un segmento di pubblico personalizzato può scegliere di abbandonarlo chiamando leaveCustomAudience(), come mostrato nello snippet di codice illustrativo riportato di seguito:

// Invoke ad services API to leave a custom audience.
leaveCustomAudience(buyer, name);

Nota: questa API non ha un valore restituito per impedire alle app di utilizzare questo metodo per dedurre l'appartenenza al segmento di pubblico personalizzato di un utente.

Per risparmiare l'utilizzo dello spazio di archiviazione e di altre risorse del dispositivo, i segmenti di pubblico personalizzati scadono e vengono rimossi dallo store sul dispositivo dopo un periodo di tempo prestabilito. Il valore predefinito è da stabilire. Il proprietario può sostituire questo valore predefinito.

Controllo utente

• La proposta intende fornire agli utenti visibilità sull'elenco delle app installate che hanno creato almeno un segmento di pubblico personalizzato
• Gli utenti possono rimuovere app da questo elenco. La rimozione cancella tutti i segmenti di pubblico personalizzati associati alle app e impedisce che queste vengano aggiunte a nuovi segmenti di pubblico personalizzati.
• Gli utenti hanno la possibilità di reimpostare completamente l'API Protected Audience. In questo caso, tutti i segmenti di pubblico personalizzati esistenti sul dispositivo vengono cancellati.
• Gli utenti possono disattivare completamente la funzionalità Privacy Sandbox su Android, che include l'API Protected Audience. Se l'utente ha disattivato Privacy Sandbox, l'API Protected Audience non funziona correttamente.

La progettazione di questa funzionalità è ancora in fase di sviluppo e i dettagli saranno inclusi in un aggiornamento successivo.

Autorizzazioni e controllo delle app

La proposta intende fornire alle app il controllo sui segmenti di pubblico personalizzati:

• Un'app può gestire le sue associazioni con i segmenti di pubblico personalizzati.
• Un'app può concedere alle piattaforme di tecnologia pubblicitaria di terze parti le autorizzazioni necessarie per gestire i segmenti di pubblico personalizzati per suo conto.

La progettazione di questa funzionalità è ancora in fase di sviluppo e i dettagli saranno inclusi in un aggiornamento successivo.

Controllo della piattaforma di tecnologia pubblicitaria

Questa proposta descrive i modi in cui gli ad tech possono controllare i loro segmenti di pubblico personalizzati:

• Gli ad tech si registrano a Privacy Sandbox e forniscono un dominio eTLD+1 che corrisponde a tutti gli URL per un segmento di pubblico personalizzato.
• Gli ad tech possono collaborare con app o SDK per fornire token di verifica che vengono utilizzati per verificare la creazione di segmenti di pubblico personalizzati. Quando questo processo viene delegato a un partner, la creazione di segmenti di pubblico personalizzati può essere configurata in modo da richiedere l'accettazione da parte della tecnologia pubblicitaria.
• Un ad tech può scegliere di disattivare le chiamate joinCustomAudience per suo conto e consentire solo all'API fetchAndJoinCustomAudience di abilitare tutte le chiamate ai segmenti di pubblico personalizzati. Il controllo può essere aggiornato durante la registrazione a Privacy Sandbox. Tieni presente che il controllo consente tutte le tecnologie pubblicitarie o nessuna. A causa delle limitazioni della piattaforma, le autorizzazioni di delega non possono essere applicate a livello di ad tech.

Annunci candidati e risposta ai metadati

Gli annunci candidati e i metadati restituiti da una piattaforma lato acquisti devono includere i seguenti campi:

• Metadati: metadati degli annunci specifici per le tecnologie pubblicitarie per gli acquirenti. Ad esempio, potrebbero includere informazioni sulla campagna pubblicitaria e criteri di targeting come località e lingua.
• URL di rendering: endpoint per il rendering della creatività dell'annuncio.
• Filtro:informazioni facoltative necessarie all'API Protected Audience per filtrare gli annunci in base ai dati sul dispositivo. Per ulteriori dettagli, consulta la sezione sulla logica di filtro lato acquisto.

Flusso di lavoro per la selezione degli annunci

Questa proposta mira a migliorare la privacy introducendo l'API Ad Selection, che orchestra l'esecuzione dell'asta per le piattaforme ad tech.

Oggi le piattaforme ad tech eseguono in genere offerte e selezione degli annunci esclusivamente sui propri server. Con questa proposta, i segmenti di pubblico personalizzati e altri indicatori utente sensibili, come le informazioni disponibili sui pacchetti installati, saranno accessibili solo tramite l'API Ad Selection. Inoltre, per il caso d'uso del remarketing, gli annunci candidati verranno recuperati fuori banda (ovvero non nel contesto in cui verranno mostrati gli annunci). Le piattaforme di ad tech dovranno prepararsi per il deployment e l'esecuzione di alcune parti dell'asta attuale e della logica di selezione degli annunci sul dispositivo. Le piattaforme di ad tech possono prendere in considerazione le seguenti modifiche al flusso di lavoro per la selezione degli annunci:

• Se le informazioni sui pacchetti installati non sono disponibili sul server, le piattaforme di tecnologia pubblicitaria potrebbero decidere di inviare più annunci contestuali al dispositivo e richiamare il flusso di lavoro di selezione degli annunci per attivare i filtri basati sulle installazioni di app al fine di massimizzare le probabilità di mostrare un annuncio pertinente.
• Poiché gli annunci di remarketing vengono recuperati fuori banda, i modelli di offerta attuali potrebbero dover essere aggiornati. Le piattaforme di tecnologia pubblicitaria potrebbero voler creare modelli secondari per le offerte (l'implementazione può basarsi su un modello chiamato modello a due torri) che possono lavorare separatamente sulle funzionalità degli annunci e sugli indicatori di contesto e combinare gli output del sottomodello sul dispositivo per prevedere le offerte. Ciò può trarre vantaggio sia dalle aste lato server sia dalle aste per ogni opportunità pubblicitaria.

Questo approccio consente ai dati sulle interazioni con l'app dell'utente di influenzare la selezione degli annunci, limitando al contempo la condivisione di questi dati con terze parti.

Grafico di flusso che mostra l'avvio del flusso di lavoro di selezione degli annunci.

Questo flusso di lavoro per la selezione degli annunci orchestra l'esecuzione sul dispositivo del codice JavaScript fornito dalla tecnologia pubblicitaria in base alla seguente sequenza:

1. Esecuzione della logica di offerta lato acquisti
2. Filtro ed elaborazione degli annunci lato acquisto
3. Esecuzione della logica decisionale lato vendite

Per le selezioni di annunci che prevedono segmenti di pubblico personalizzati, la piattaforma recupererà il codice JavaScript fornito dall'acquisto in base all'endpoint dell'URL pubblico definito dai metadati "URL logica di offerta" del segmento di pubblico personalizzato. L'endpoint URL per il codice di decisione lato vendite verrà passato anche come input per avviare il flusso di lavoro di selezione degli annunci.

La struttura delle selezioni di annunci che non prevede segmenti di pubblico personalizzati è in fase di progettazione.

Avvia flusso di lavoro per la selezione degli annunci

Quando un'app deve mostrare un annuncio, l'SDK della piattaforma ad tech può avviare il flusso di lavoro di selezione degli annunci chiamando il metodo selectAds() dopo aver creato un'istanza dell'oggetto AdSelectionConfig con i parametri previsti:

• Venditore: identificatore della piattaforma pubblicitaria lato vendite, secondo il formato eTLD+1.
• URL logica decisionale: quando viene avviata un'asta dell'annuncio, la piattaforma utilizza questo URL per recuperare il codice JavaScript dalla Sell-Side Platform e assegnare un punteggio a un annuncio vincente.
• Acquirenti di segmenti di pubblico personalizzati: un elenco di acquirenti di piattaforme lato pubblico con domanda basata sul pubblico personalizzata per questa asta, secondo il formato eTLD+1.
• Indicatori per la selezione degli annunci: informazioni sull'asta (dimensioni dell'annuncio, formato dell'annuncio e così via).
• Indicatori del venditore: fornisci indicatori specifici per le piattaforme lato piattaforma.
• URL indicatori di punteggio attendibili: endpoint URL dell'indicatore attendibile lato vendita da cui è possibile recuperare le informazioni in tempo reale specifiche della creatività.
• Indicatori per acquirente: le parti della domanda partecipanti possono utilizzare questo parametro per fornire input per l'asta. Ad esempio, questo parametro può includere informazioni contestuali complete utili per determinare le offerte.

Il seguente snippet di codice illustrativo mostra un SDK di una piattaforma di tecnologia pubblicitaria che avvia il flusso di lavoro di selezione degli annunci definendo prima l'AdSelectionConfig e poi richiamando selectAds per ottenere l'annuncio vincente:

AdSelectionConfig myAdSelectionConfig = new AdSelectionConfig {
    Seller = "example-ssp1.com",
    DecisionLogicURL = Uri.parse("https://..."),
    CustomAudienceBuyerList = Arrays.asList("example-dsp1.com","bexample-dsp2.com"),
    AdSelectionSignals = "{"min_price": 10,"auction_attempts": 3}"
    SellerSignals = "{"seller_type": "news", "content_category": "sports","mature_ads_accepted" :"false"}"
    PerBuyerSignals = " {"buyer1Name": {"key1" : "value1"},
                         "buyer2Name": {"key1" : "value1", "key2" : "value2" }"
};

// Invoke ad services API to initiate ad selection workflow.
Ad winningAd = selectAds(myAdSelectionConfig);

Logica di offerta lato acquisto

La logica di offerta in genere è fornita dalle piattaforme lato acquisti. Lo scopo del codice è determinare le offerte per gli annunci candidati. Potrebbe applicare una logica di business aggiuntiva per determinare il risultato.

La piattaforma utilizzerà i metadati "URL logica di offerta" del segmento di pubblico personalizzato per recuperare il codice JavaScript che dovrebbe includere la firma della funzione riportata di seguito:

generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return {'bid': ...};
}

Il metodo generateBid() restituisce l'importo dell'offerta calcolato. La piattaforma rivocherà questa funzione per tutti gli annunci (contestuali o di remarketing) in sequenza. Se esistono più provider di logica di offerta, il sistema non garantisce la sequenza di esecuzione tra i provider.

La funzione prevede i seguenti parametri:

• Annuncio: l'annuncio preso in considerazione dal codice di offerta per acquirenti. Questo sarà un annuncio di un segmento di pubblico personalizzato idoneo
• Indicatori delle aste: indicatori specifici per la piattaforma lato vendite.
• Indicatori per acquirente: le parti della domanda partecipanti possono utilizzare questo parametro per fornire input per l'asta. Ad esempio, questo parametro può includere informazioni contestuali complete utili per determinare le offerte.
• Indicatori di offerta affidabili: le piattaforme di tecnologia pubblicitaria si basano su dati in tempo reale per informare il recupero degli annunci e il punteggio. Ad esempio, il budget di una campagna pubblicitaria potrebbe essere esaurito e la pubblicazione deve essere interrotta immediatamente. Una tecnologia pubblicitaria può definire un endpoint URL da cui è possibile recuperare i dati in tempo reale e il set di chiavi per cui deve essere eseguita la ricerca in tempo reale. Il server gestito dalla piattaforma ad tech che gestisce questa richiesta sarà un server affidabile gestito dalla piattaforma ad tech.
• Indicatori contestuali: possono includere timestamp approssimati, informazioni sulla posizione approssimativa o costo per clic sull'annuncio.
• Indicatori utente: potrebbero includere informazioni disponibili sui pacchetti installati.

Costo annuncio

Oltre all'offerta, le piattaforme lato acquisti hanno la possibilità di restituire il costo per clic nell'ambito di generateBid(). Ad esempio:

generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return {'bid': ..., 'adCost': ...,};
}

Se questo annuncio è il vincitore, adCost viene arrotondato in modo statico a 8 bit per privacy. Il valore arrotondato di adCost viene quindi trasmesso al parametro contextual_signals in reportWin durante i report sulle impressioni.

Logica di filtro lato acquisto

Le piattaforme lato acquisti potranno filtrare gli annunci in base ad altri indicatori on-device disponibili durante la fase di selezione degli annunci. Ad esempio, le piattaforme ad tech possono implementare le funzionalità di quota limite. Se esistono più provider di filtri, il sistema non garantisce la sequenza di esecuzione tra i provider.

La logica di filtro lato acquisto può essere implementata come parte della logica di offerta restituendo un valore di offerta pari a 0 per un determinato annuncio.

Inoltre, le piattaforme lato acquisti saranno in grado di segnalare che un determinato annuncio deve essere filtrato in base agli indicatori aggiuntivi on-device disponibili per Protected Audience, che non lasceranno il dispositivo. Man mano che solidifichiamo i progetti di una logica di filtro aggiuntiva, le piattaforme lato acquisti seguiranno questa stessa struttura per segnalare che l'applicazione dei filtri dovrebbe avvenire.

Logica di punteggio lato vendite

La logica del punteggio è in genere fornita dalla Sell-Side Platform. Lo scopo del codice è determinare un annuncio vincente in base agli output della logica di offerta. Potrebbe applicare una logica di business aggiuntiva per determinare il risultato. Se esistono più provider di logica decisionale, il sistema non garantisce la sequenza di esecuzione tra i provider. La piattaforma utilizzerà il parametro di input "URL logica di decisione" dell'API selectAds() per recuperare il codice JavaScript che dovrebbe includere la firma della funzione di seguito:

scoreAd(ad, bid, auction_config, trusted_scoring_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return score_for_this_ad;
}

La funzione prevede i seguenti parametri:

• Annuncio: l'annuncio valutato; output dalla funzione generateBid().
• Offerta: l'importo dell'offerta generato dalla funzione generateBid().
• Configurazione asta: inserisci il parametro nel metodo selectAds().
• Indicatori di punteggio attendibili: le piattaforme di tecnologia pubblicitaria si basano su dati in tempo reale per stabilire il punteggio e il filtro degli annunci. Ad esempio, un publisher di app potrebbe impedire a una campagna pubblicitaria di pubblicare annunci nell'app. Questi dati vengono recuperati dal parametro URL degli indicatori di punteggio attendibili della configurazione dell'asta. Il server che gestisce questa richiesta deve essere un server affidabile gestito dalla tecnologia pubblicitaria.
• Indicatore contestuale: può includere timestamp approssimativi o informazioni sulla posizione approssimativa.
• Indicatore utente: potrebbe includere informazioni quali lo store che ha avviato l'installazione dell'app.
• Indicatore del segmento di pubblico personalizzato: se l'annuncio a cui viene assegnato un punteggio proviene da un segmento di pubblico personalizzato sul dispositivo, questo conterrà informazioni quali il lettore e il nome del segmento di pubblico personalizzato.

Tempo di esecuzione del codice per la selezione degli annunci

Nella proposta, il sistema recupererà il codice dell'asta fornito dalla piattaforma di tecnologia pubblicitaria dagli endpoint dell'URL configurabili ed verrà eseguito sul dispositivo. Dati i vincoli delle risorse sui dispositivi mobili, il codice dell'asta deve rispettare le seguenti linee guida:

• L'esecuzione del codice dovrebbe terminare entro un periodo di tempo predefinito. Questo vincolo verrà applicato in modo uniforme a tutte le reti pubblicitarie degli acquirenti. I dettagli di questo vincolo verranno condivisi in un aggiornamento successivo.
• Il codice deve essere indipendente e non deve avere dipendenze esterne.

Poiché il codice dell'asta, come la logica di offerta, potrebbe richiedere l'accesso a dati utente privati come le origini di installazione delle app, il runtime non fornirà accesso alla rete o allo spazio di archiviazione.

Linguaggio di programmazione

Il codice dell'asta fornito dalla piattaforma ad tech deve essere scritto in JavaScript. Ciò consentirebbe alle piattaforme di ad tech, ad esempio, di condividere il codice di offerta tra piattaforme che supportano Privacy Sandbox.

Rendering dell'annuncio vincente

L'annuncio con il punteggio più alto viene considerato il vincitore dell'asta. In questa proposta iniziale, l'annuncio vincente viene inviato all'SDK per il rendering.

Il piano prevede di sviluppare la soluzione per garantire che le informazioni sull'iscrizione al segmento di pubblico personalizzato di un utente o sulla cronologia del coinvolgimento in-app non possano essere determinate dall'app o dall'SDK tramite le informazioni sull'annuncio vincente (simili alla proposta di frame recintati di Chrome).

Report sulle impressioni e sugli eventi

Nota: esistono lievi differenze nell'API di reporting JS tra aste on-device e aste eseguite utilizzando i servizi di offerta e aste. Per maggiori dettagli sui report B&A, consulta la documentazione relativa a B&A.

Una volta visualizzato l'annuncio, l'impressione vincente può essere riportata alle piattaforme lato acquisti e Sell-Side Platform partecipanti. Ciò consente ad acquirenti e venditori di includere informazioni sull'asta, come il nome dell'offerta o del segmento di pubblico personalizzato, nel report sulle impressioni vincenti. Inoltre, la Sell-Side Platform e la Buy-Side Platform vincente sono idonee a ricevere ulteriori report a livello di evento sull'annuncio vincente. Ciò consente di includere informazioni sull'asta (offerta, nome del segmento di pubblico personalizzato e così via) con clic, visualizzazioni e altri eventi relativi all'annuncio. La piattaforma richiama la logica di reporting in questo ordine:

1. Report lato vendite.
2. Report lato acquirente.

Ciò offre alle piattaforme lato acquirente e Sell-Side Platform un modo per inviare ai server informazioni importanti sul dispositivo per attivare funzionalità come la definizione del budget in tempo reale, l'aggiornamento dei modelli di offerta e l'accuratezza dei flussi di lavoro di fatturazione. Questa assistenza per i report sulle impressioni è complementare all'API Attribution Reporting.

Per supportare i report sugli eventi sono necessari due passaggi: JavaScript lato vendite e lato acquirente deve registrare l'evento per cui deve ricevere i report sugli eventi, mentre il lato vendite è responsabile della generazione di report sulle informazioni a livello di evento.

Protected Audience offre un meccanismo per iscriversi a eventi futuri relativi a un'asta vincente grazie alla registrazione dei beacon. Nella funzione JavaScript reportResult() di un venditore, le Sell-Side Platform possono registrare i beacon utilizzando la funzione registerAdBeacon() della piattaforma. Analogamente, le piattaforme lato acquisti possono richiamare il metodo registerAdBeacon() dalla funzione JavaScript reportWin().

registerAdBeacon(beacons)

Ingresso:

• event_key: una stringa che indica il tipo di interazione da registrare. Questa è utilizzata come chiave per cercare il punto finale inviato dalla piattaforma per generare report sui risultati dell'asta.
• reporting_url: l'URL di proprietà della piattaforma di tecnologia pubblicitaria per la gestione dell'evento.

Le chiavi evento sono identificatori di stringhe di proprietà dell'SDK lato vendite responsabile della generazione di report sui risultati dell'asta. Affinché venga effettuato un callback, gli ad tech registrano i beacon con chiavi corrispondenti a quelle utilizzate dal lato vendite quando segnalano gli eventi. Questi non devono essere necessariamente k-anonym, anche se esistono limiti alla quantità e alla lunghezza delle chiavi che possono essere registrate per un determinato segmento di pubblico personalizzato. Se viene chiamato reportEvent(), le Sell-Side Platform che hanno eseguito l'asta sono sempre idonee a ricevere questi report sugli eventi. Solo la piattaforma acquirente vincente è idonea a ricevere questi report.

Nota: la proposta richiede l'esecuzione di report a livello di evento. In futuro, la progettazione si trasformerà in un meccanismo di generazione di report aggregati.

Report lato vendite

La piattaforma richiama la funzione JavaScript reportResult() nel codice fornito lato fornitura scaricato dal parametro URL logica di decisione del venditore per l'API selectAds():

reportResult(render_url, bid, auction_config, contextual_signals) {
    // ...
    beacons = {"click":clickUri}
    registerAdBeacon(beacons)
    return {
      "status": 0,
      "results": {"reporting_url": reporting_url,
                  "signals_for_buyer": signals_for_buyer}};
}

Output: un oggetto JSON contenente

• Stato: 0 in caso di esito positivo, qualsiasi altro valore in caso di errore.
• URL di reporting: la piattaforma richiama questo URL restituito dalla funzione.
• Indicatori per l'acquirente: un oggetto JSON da trasmettere alla funzione reportWin dell'acquirente.

Il lato offerta può codificare indicatori pertinenti nell'URL dei report per aiutarlo a ottenere ulteriori informazioni sull'asta e sull'annuncio vincente. Ad esempio, potrebbe includere gli indicatori riportati di seguito:

• URL di rendering dell'annuncio
• Importo offerta vincente
• Nome dell'app
• Identificatori di query
• Indicatori per l'acquirente: per supportare la condivisione dei dati tra il lato dell'offerta e il lato della domanda, la piattaforma trasmette questo valore restituito come parametro di input al codice del report lato domanda.

Report lato acquirente

La piattaforma richiama la funzione JavaScript reportWin() nel codice fornito dal lato della domanda scaricato dai metadati URL logica di offerta del segmento di pubblico personalizzato associato all'asta.

reportWin(render_url, bid, auction_signals, per_buyer_signals,
        signals_for_buyer, contextual_signals, custom_audience_signals) {
    // ...
    beacons = {"click":clickUri}
    registerAdBeacon(beacons)
    return {
      "status": 0,
      "results": {"reporting_uri": reporting_uri}};
}

Ingresso:

• auction_signals e per_buyer_signals vengono recuperati da AuctionConfig. Qualsiasi informazione che la piattaforma di acquisto deve trasmettere all'URL del report può provenire da questo dato.
• signals_for_buyer è l'output del reportResult lato vendite. In questo modo la Sell-Side Platform offre l'opportunità di condividere dati con la Piattaforma di Acquisto per la generazione di report.
• contextual_signals contiene informazioni come il nome dell'app e custom_audience_signals contiene informazioni sul segmento di pubblico personalizzato. In futuro potrebbero essere aggiunte altre informazioni.

Output:

• Stato: 0 in caso di esito positivo, qualsiasi altro valore in caso di errore.
• URL di reporting: la piattaforma richiama questo URL restituito dalla funzione.

Report sugli eventi

La generazione di report sugli eventi è possibile solo dopo che sono stati completati i report sulle impressioni per l'asta. L'SDK lato vendite è responsabile della segnalazione di eventuali eventi. La piattaforma espone un'API che prende un ReportEventRequest che specifica l'asta eseguita di recente, la chiave dell'evento segnalata, i dati associati alla chiave, se il report deve essere inviato all'acquirente o al venditore (o a entrambi) e un evento di input facoltativo per gli eventi annuncio. Il client definisce la chiave dell'evento e la raccolta di dati da includere nel report.

ReportEventRequest request = new ReportEventRequest(
  AdSelectionId = ad_selection_id,
  event_key = "view"
  event_data = "{ "viewTimeInSeconds" :1 }",
  reporting_destinations =
    FLAG_REPORTING_DESTINATION_SELLER |
      FLAG_REPORTING_DESTINATION_BUYER,
  input_event = clickInputEvent // or null for view
  )

reportEvent(request)

Ingresso:

• ad_selection_id deve essere un AdSelectionId di un'asta eseguita di recente recuperata da AdSelectionOutcome.
• event_key è una stringa definita lato vendite che descrive l'evento di interazione.
• event_data è una stringa che rappresenta i dati associati a event_key
• reporting_destinations è una maschera di bit impostata che utilizza i flag forniti dalla piattaforma. Può essere FLAG_REPORTING_DESTINATION_SELLER, FLAG_REPORTING_DESTINATION_BUYER o entrambi.
• input_event (facoltativo) viene utilizzato per l'integrazione con l'API Attribution Reporting. Può essere un oggetto InputEvent (per un evento di clic) o nullo (per un evento di visualizzazione). Per ulteriori dettagli su questo parametro, consulta Integrazione dell'API Attribution Reporting.

Dopo che l'SDK lato vendite richiama reportEvent e, a seconda del flag reporting_destinations, la piattaforma tenta di abbinare event_key alle chiavi registrate dagli acquirenti e dai venditori nelle loro funzioni JavaScript reportWin e reportResult. Se viene rilevata una corrispondenza, la piattaforma PUBBLICA il event_data nell'elemento reporting_url associato. Il tipo di contenuti della richiesta è in testo normale, il cui corpo è event_data. Questa richiesta viene eseguita secondo il criterio del massimo impegno e non viene eseguita correttamente se si verifica un errore di rete, una risposta di errore del server o se non è stata trovata alcuna chiave corrispondente.

Integrazione dell'API Attribution Reporting

Per supportare gli acquirenti che partecipano a un'asta Protected Audience, stiamo fornendo funzionalità cross-API nelle API Protected Audience e Attribution Reporting (ARA). Questa funzionalità consente agli ad tech di valutare il rendimento dell'attribuzione in diverse tattiche di remarketing, in modo da poter capire quali tipi di segmenti di pubblico generano il ROI più elevato.

Grazie a questa integrazione tra API, le tecnologie pubblicitarie possono:

• Crea una mappa degli URI da utilizzare per i report sulle interazioni con gli annunci e 2) la registrazione dell'origine.
• Includere i dati delle aste dell'asta Protected Audience nella mappatura delle chiavi lato origine per la generazione di report di riepilogo aggregati (utilizzando l'API Attribution Reporting). Per ulteriori informazioni, consulta la proposta di progettazione dell'ARA.

Quando un utente visualizza o fa clic su un annuncio:

• L'URL utilizzato per segnalare le interazioni di questi eventi tramite Protected Audience fornirà all'acquirente i dati necessari da utilizzare per registrare una vista o un clic come origine idonea con l'API Attribution Reporting.
• La tecnologia pubblicitaria può scegliere di trasmettere CustomAudience (o altre informazioni contestuali pertinenti sull'annuncio, come il posizionamento dell'annuncio o la durata di visualizzazione) utilizzando l'URL in modo che i metadati possano propagarsi ai report di riepilogo quando la tecnologia pubblicitaria esamina il rendimento aggregato della campagna.

Abilitazione della registrazione dell'origine in corso...

reportEvent() accetterà un nuovo parametro facoltativo InputEvent. Gli acquirenti vincitori che registrano beacon di annunci possono scegliere quali report ReportEvent devono essere registrati con le API Attribution Reporting come origine registrata. L'intestazione della richiesta Attribuzione-Reporting-Idoneo verrà aggiunta a tutte le richieste di generazione di report sugli eventi inviate da reportEvent(). Tutte le risposte con intestazioni ARA appropriate verranno analizzate come qualsiasi altra risposta regolare di registrazione di origine ARA. Consulta la spiegazione dell'API Attribution Reporting per scoprire come registrare un URL di origine.

Poiché l'ARA su Android supporta gli eventi di visualizzazione e clic, vengono utilizzati InputEvents per distinguere tra i due tipi. Proprio come per la registrazione delle origini ARA, l'API reportEvent() interpreterà un InputEvent verificato dalla piattaforma come un evento di clic. Se InputEvent non è presente, è nullo o non è valido, la registrazione dell'origine sarà considerata una visualizzazione.

Tieni presente che, dopo l'asta, eventData potrebbe contenere informazioni sensibili, quindi la piattaforma rimuove il eventData nelle richieste di registrazione dell'origine reindirizzata.

Esempio di report sul coinvolgimento e sulle conversioni

In questo esempio, lo esamineremo dal punto di vista dell'acquirente, che è interessato ad associare i dati dell'asta, dell'annuncio visualizzato e dell'app di conversione.

In questo flusso di lavoro, l'acquirente si coordina con il venditore per inviare un ID univoco all'asta. Durante l'asta, l'acquirente invia questo ID univoco con i dati dell'asta. Durante la fase di rendering e di conversione, anche i dati dell'annuncio visualizzato vengono inviati con lo stesso ID univoco. Successivamente, puoi usare l'ID univoco per associare questi report.

Flusso di lavoro: prima dell'inizio dell'asta, l'acquirente invia un ID univoco al venditore come parte della risposta all'offerta programmatica per le offerte in tempo reale ("RTB"). L'ID può essere impostato come variabile, ad esempio auctionId. L'ID viene trasmesso come perBuyerSignals in auctionConfig e diventa disponibile nella logica di offerta dell'acquirente.

1. Durante l'esecuzione di reportWin, l'acquirente può registrare un beacon dell'annuncio da attivare durante il tempo di rendering dell'annuncio e per specifici eventi di interazione (registerAdBeacon()). Per associare gli indicatori dell'asta per un evento di annuncio, imposta auctionId come parametro di query dell'URL di beacon.
2. Durante il rendering dell'annuncio, i beacon registrati al momento dell'asta possono essere attivati o migliorati con i dati a livello di evento. Il venditore deve attivare reportEvent() e trasmettere i dati a livello di evento. La piattaforma invierà un ping all'URL di beaconing dell'annuncio registrato dell'acquirente correlato all'elemento reportEvent() che è stato attivato.
3. L'acquirente registrerà l'annuncio con l'API Attribution Reporting rispondendo alle richieste di beacon degli annunci con l'intestazione Attribution-Reporting-Register-Source. Per associare gli indicatori dell'asta a un evento di conversione, imposta auctionId nell'URL di origine della registrazione.

Dopo la procedura descritta in precedenza, l'acquirente dispone di un report sull'asta, un report sulle interazioni e un report sulle conversioni che possono essere correlati utilizzando l'ID univoco che può essere utilizzato per l'associazione l'uno con l'altro.

Un flusso di lavoro simile viene applicato a un venditore che ha bisogno di accedere ai dati di attribuzione e può anche utilizzare un ID univoco per l'invio con registerAdBeacon(). La chiamata reportEvent() contiene una proprietà di destinazione che può essere utilizzata per inviare il report sia all'acquirente che al venditore.

Server attendibile gestito dalla piattaforma ad tech

Oggi la logica di selezione degli annunci richiede informazioni in tempo reale come lo stato di esaurimento del budget per determinare se gli annunci candidati devono essere selezionati per l'asta. Sia le piattaforme lato acquisti che le piattaforme lato vendite saranno in grado di ottenere queste informazioni dai server in cui operano. Per ridurre al minimo la fuga di informazioni sensibili attraverso questi server, la proposta richiede le seguenti restrizioni:

• Il comportamento di questi server, descritto più avanti in questa sezione, non fa trapelare le informazioni degli utenti.
• I server non creano profili con pseudonimi in base ai dati che vedono, pertanto devono essere "attendibili".

Lato acquisto: una volta che il lato acquisto avvia la logica di offerta lato acquisto, la piattaforma esegue un recupero HTTP dei dati delle offerte attendibili dal server attendibile. L'URL è composto dall'aggiunta dell'URL e delle chiavi presenti nei metadati degli indicatori delle offerte attendibili del segmento di pubblico personalizzato in fase di elaborazione. Questo recupero viene eseguito solo durante l'elaborazione degli annunci provenienti dai segmenti di pubblico personalizzati sul dispositivo. In questa fase, gli acquirenti possono applicare i budget, controllare lo stato di messa in pausa / riattivazione della campagna, eseguire il targeting e così via.

Di seguito è riportato un URL di esempio per recuperare dati sulle offerte attendibili, basati su metadati di indicatori di asta attendibili dal segmento di pubblico personalizzato:

https://www.kv-server.example/getvalues?keys=key1,key2

La risposta dal server deve essere un oggetto JSON le cui chiavi sono key1, key2 e così via e i cui valori saranno resi disponibili alle funzioni di offerta dell'acquirente.

Lato vendite: in modo analogo al flusso lato acquisto sopra indicato, il lato vendite potrebbe voler recuperare informazioni sulle creatività considerate nell'asta. Ad esempio, un publisher potrebbe voler fare in modo che determinate creatività non vengano visualizzate nella sua app in base a problemi di sicurezza del brand. Queste informazioni possono essere recuperate e rese disponibili per la logica dell'asta lato vendite. Analogamente alla ricerca del server attendibile lato acquisto, anche la ricerca del server attendibile lato vendita avviene tramite un recupero HTTP. L'URL è composto aggiungendo l'URL degli indicatori di punteggio attendibili con gli URL di rendering delle creatività per cui devono essere recuperati i dati.

Di seguito è riportato un URL di esempio per recuperare informazioni sulle creatività considerate nell'asta, in base agli URL di rendering delle creatività:

https://www.kv-server.example/getvalues?renderUrls=render_url1,render_url2

La risposta dal server deve essere un oggetto JSON le cui chiavi sono il rendering degli URL inviati nella richiesta.

Questi server funzionano in modo affidabile e offrono numerosi vantaggi in termini di sicurezza e privacy:

• Il valore restituito dal server per ogni chiave può essere considerato attendibile in modo che sia basato solo su quella chiave.
• Il server non esegue il logging a livello di evento.
• Il server non ha altri effetti collaterali basati su queste richieste.

Come meccanismo temporaneo, l'acquirente e il venditore possono recuperare questi indicatori di offerta da qualsiasi server, incluso quello che utilizzano autonomamente. Tuttavia, nella versione release, la richiesta verrà inviata soltanto a un server di tipo chiave-valore attendibile.

Acquirenti e venditori possono utilizzare un server tipo chiave-valore affidabile e comune per le piattaforme compatibili con Privacy Sandbox su Android e per il web.