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

Inviare feedback

Aggiornamenti recenti

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 a venditore singolo 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 esatte di rilascio varieranno a seconda della funzionalità e questa tabella verrà aggiornata con i link alla documentazione non appena disponibili.

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

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 ancora 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. Utilizzando queste informazioni, gli inserzionisti possono selezionare annunci pertinenti sui loro server.

L'API Protected Audience su Android (precedentemente nota come FLEDGE) comprende le seguenti API per le piattaforme ad tech e gli inserzionisti per supportare casi d'uso comuni basati sull'interazione in modi che limitano la condivisione sia degli identificatori tra le app sia delle 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 pubblico designato dall'inserzionista con intenzioni comuni. Le informazioni sul pubblico vengono memorizzate sul dispositivo e possono essere associate ad annunci candidati pertinenti per il segmento di pubblico e a metadati arbitrari, come gli indicatori delle offerte. Queste informazioni possono essere utilizzate 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 sul dispositivo per determinare un annuncio "vincente " prendendo in considerazione gli annunci candidati memorizzati localmente ed eseguire un'ulteriore elaborazione sugli annunci candidati che una piattaforma di tecnologia pubblicitaria restituisce al dispositivo.
Figura 1. Diagramma di flusso che mostra il flusso di lavoro personalizzato per la gestione dei segmenti di pubblico e la selezione degli annunci in Privacy Sandbox su Android.

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 archivia 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 resi disponibili nel flusso di lavoro di selezione degli annunci affinché vengano presi in considerazione. La piattaforma può essere configurata per recuperare periodicamente gli annunci basati sul pubblico aggiornati in background. Ciò consente di mantenere aggiornato e non correlato alle richieste inviate agli 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. Questo può essere ottenuto FrisbeeGame (con un SDK per gli annunci integrato) richiamando 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 ad tech e dall'SDK degli annunci con una logica di offerta e punteggio personalizzata per raggiungere obiettivi pubblicitari appropriati. Questo approccio consente ai dati sull'interesse dell'utente o sulle interazioni con le app di prendere decisioni sulla 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 ad tech esegue il rendering dell'annuncio selezionato.

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

Accedere a Protected Audience sulle API Android

Le piattaforme ad tech devono registrarsi per accedere all'API Protected Audience. Per ulteriori informazioni, consulta Registrare un account Privacy Sandbox.

Gestione dei segmenti di pubblico personalizzati

Segmento di pubblico personalizzato

Un segmento di pubblico personalizzato rappresenta un gruppo di utenti secondo quanto 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 archivia le informazioni sul pubblico localmente sul dispositivo e non mostra 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ò contribuisce a limitare la condivisione delle informazioni degli utenti.

L'app di un inserzionista o l'SDK integrato può unirsi o abbandonare 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: il nome del pacchetto dell'app del proprietario, impostato implicitamente 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 dell'annuncio. L'acquirente viene specificato secondo il formato eTLD+1.
  • Nome: un nome o identificatore arbitrario per il segmento di pubblico personalizzato, ad esempio un utente con "utenti che hanno abbandonato il carrello degli acquisti". Questo attributo potrebbe 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 scadenza: questi campi definiscono la finestra temporale in cui il segmento di pubblico personalizzato verrà applicato. La piattaforma utilizza queste informazioni per revocare l'appartenenza a un segmento di pubblico personalizzato. La scadenza non può superare una finestra di durata massima per limitare la durata di un segmento di pubblico personalizzato.
  • URL di 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 gli annunci candidati per i segmenti di pubblico personalizzati.
  • Indicatori di offerta dell'utente: indicatori specifici della piattaforma di tecnologia pubblicitaria per qualsiasi offerta degli annunci di remarketing. Esempi di indicatori includono: posizione approssimativa dell'utente, le impostazioni internazionali preferite e così via.
  • Dati di offerte attendibili: le piattaforme di tecnologia pubblicitaria si basano su dati in tempo reale per il recupero degli annunci e l'assegnazione del punteggio. Ad esempio, il budget potrebbe essere esaurito e la pubblicazione di un annuncio 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 eseguire la ricerca in tempo reale. Il server che gestisce questa richiesta sarà un server attendibile gestito dalla piattaforma ad tech.
  • URL logica di offerta: l'URL utilizzato dalla piattaforma per recuperare il codice delle offerte dalla Demand-Side Platform. La piattaforma esegue questo passaggio quando viene avviata un'asta dell'annuncio.
  • Annunci: un elenco di annunci candidati per il segmento di pubblico personalizzato. Sono inclusi i metadati degli annunci specifici per la piattaforma di tecnologia pubblicitaria e un URL per visualizzare l'annuncio. Quando viene avviata un'asta per il segmento di pubblico personalizzato, questo elenco di metadati degli annunci verrà preso in considerazione. Questo elenco di annunci verrà aggiornato utilizzando l'endpoint dell'URL di aggiornamento giornaliero, se possibile. A causa di 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 di segmenti di pubblico personalizzati si basano solitamente su tecnologie e integrazioni 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 a far parte di un segmento di pubblico personalizzato, le tecnologie pubblicitarie degli acquirenti che non hanno una presenza con SDK nelle app devono collaborare con le tecnologie pubblicitarie che hanno una presenza on-device, ad esempio 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:

Entrare a far parte di un segmento di pubblico personalizzato

Puoi unirti a un segmento di pubblico personalizzato 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 unirsi 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 inoltre che anche l'URL di aggiornamento giornaliero corrisponda al dominio 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 dal TLD+1 di fetchUri. L'identità dell'acquirente CustomAudience viene utilizzata per eseguire gli stessi controlli di registrazione e autorizzazione delle 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 oltre al controllo eTLD+1 e, in particolare, non esiste alcun controllo k-anon. L'API fetchAndJoinCustomAudience() invia una richiesta HTTP GET a fetchUri e prevede un oggetto JSON che rappresenti il segmento di pubblico personalizzato. Alla risposta vengono applicati gli stessi limiti obbligatori e facoltativi e gli stessi valori predefiniti dei campi dell'oggetto pubblico personalizzato. Scopri di più sui requisiti e sulle limitazioni attuali nella nostra Guida per gli sviluppatori.

Qualsiasi risposta di errore HTTP dell'acquirente determina l'errore di 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 ha esito negativo anche se la risposta dell'acquirente non è valida. Gli errori vengono segnalati al chiamante dell'API responsabile di un nuovo tentativo dovuto a errori temporanei (ad esempio il server non risponde) o della gestione di errori persistenti (come errori di convalida dei dati o altri errori non transitori nella 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 precedente. 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 dell'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 la dimensione viene superata, 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 di abilitare la condivisione delle informazioni tra l'acquirente e l'SDK. Per facilitare la verifica del pubblico personalizzato, l'acquirente può fornire un token di verifica. L'SDK on-device deve includere questo token in fetchUri in modo che 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 abbia avuto origine da un partner on-device attendibile. Per condividere le informazioni, l'acquirente può concordare con il chiamante sul dispositivo che alcune delle informazioni da utilizzare per creare il segmento di pubblico personalizzato verranno aggiunte come parametri di ricerca 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 del token di verifica

  • Il token di verifica non viene utilizzato per alcuno scopo dall'API Protected Audience ed è facoltativo.

    • Il token di verifica può essere utilizzato dall'acquirente per verificare che i segmenti di pubblico in fase di creazione 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 potrebbe 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 abbandonare la chiamata chiamando leaveCustomAudience(), come mostrato nello snippet di codice illustrativo riportato di seguito:

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

Per preservare l'utilizzo dello spazio di archiviazione e di altre risorse del dispositivo, i segmenti di pubblico personalizzati scadono e vengono rimossi dall'archivio 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 offrire 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 aggiunti 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 Privacy Sandbox su Android, che include l'API Protected Audience. Se l'utente ha disattivato Privacy Sandbox, l'API Protected Audience non funziona e non vengono visualizzati.

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

Autorizzazioni e controllo delle app

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

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

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

Controllo della piattaforma ad tech

Questa proposta delinea i modi in cui le tecnologie pubblicitarie 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 tutti i segmenti di pubblico personalizzati di chiamata. 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 basate sulla tecnologia pubblicitaria.

Annunci dei candidati e risposta ai metadati

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

  • Metadati: metadati degli annunci specifici per la tecnologia pubblicitaria per gli acquirenti. Ad esempio, potrebbero essere incluse 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 per gli acquirenti.

Flusso di lavoro per la selezione degli annunci

L'obiettivo di questa proposta è 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 selezioni di annunci esclusivamente sui loro server. Con questa proposta, i segmenti di pubblico personalizzati e altri indicatori sensibili degli utenti, 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 della logica attuale di asta e selezione degli annunci sul dispositivo. Le piattaforme ad tech potrebbero prendere in considerazione le seguenti modifiche al flusso di lavoro di selezione degli annunci:

  • Se le informazioni sui pacchetti installati non sono disponibili sul server, le piattaforme di ad tech potrebbero decidere di inviare più annunci contestuali al dispositivo e richiamare il flusso di lavoro di selezione degli annunci per attivare i filtri basati sull'installazione delle app al fine di massimizzare le possibilità di mostrare un annuncio pertinente.
  • Poiché gli annunci di remarketing vengono recuperati dal limite, potrebbe essere necessario aggiornare i modelli di offerta attuali. Le piattaforme di ad tech potrebbero voler creare modelli secondari di offerta (l'implementazione può basarsi su un modello chiamato modello a due torri) che può lavorare separatamente sulle funzionalità pubblicitarie 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 delle interazioni con l'app dell'utente di influenzare la selezione degli annunci, limitando al contempo la condivisione di questi dati con terze parti.

Figura 2. Diagramma 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 acquisti
  3. Esecuzione della logica decisionale lato vendite

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

La progettazione delle selezioni di annunci che non prevedono segmenti di pubblico personalizzati è in fase di progettazione attiva.

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 online con domanda basata sul pubblico personalizzata per questa asta, nel formato eTLD+1.
  • Indicatori per la selezione degli annunci: informazioni sull'asta (dimensioni dell'annuncio, formato dell'annuncio e così via).
  • Indicatori del venditore: indicatori specifici della Supply-Side Platform.
  • URL indicatori di punteggio attendibili: endpoint URL dell'indicatore attendibile lato vendite 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 l'SDK di una piattaforma di tecnologia pubblicitaria che avvia il flusso di lavoro di selezione degli annunci definendo prima l'elemento AdSelectionConfig e poi attivando 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 acquirente

La logica di offerta è in genere fornita dalle piattaforme lato acquisti. Lo scopo del codice è determinare le offerte per gli annunci candidati. Può applicare 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 calcolato dell'offerta. La piattaforma attiverà 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 della 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 attendibili: le piattaforme di tecnologia pubblicitaria si basano su dati in tempo reale per fornire informazioni sul recupero e sull'assegnazione del punteggio degli annunci. 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 è necessario eseguire la ricerca in tempo reale. Il server gestito della piattaforma ad tech che gestisce questa richiesta sarà un server attendibile gestito dalla piattaforma ad tech.
  • Indicatori di contesto: possono includere timestamp approssimativi o informazioni sulla posizione approssimative oppure il costo per clic sull'annuncio.
  • Indicatori utente: potrebbero includere informazioni disponibili, tra cui le 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(). Ecco alcuni esempi:

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 storico a 8 bit per la privacy. Il valore arrotondato di adCost viene quindi trasmesso al parametro contextual_signals in reportWin durante i report sulle impressioni.

Logica di filtro lato acquisti

Le piattaforme lato acquisti saranno in grado di 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 ci sono più provider di filtri, il sistema non garantisce la sequenza di esecuzione tra i provider.

La logica di filtro per gli acquirenti può essere implementata come parte della logica di offerta restituendo un valore dell'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 on-device aggiuntivi disponibili per Protected Audience e che non lasceranno il dispositivo. Man mano che solidificiamo i progetti di una logica di filtro aggiuntiva, le piattaforme lato acquisti seguiranno questa stessa struttura per indicare che l'applicazione di filtri dovrebbe essere eseguita.

Logica di punteggio lato vendite

La logica di 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 logica di business aggiuntiva per determinare il risultato. Se ci sono 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 riportata 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: output dell'importo dell'offerta 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 determinare il punteggio e i filtri degli annunci. Ad esempio, un publisher di app potrebbe impedire a una campagna pubblicitaria di mostrare 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 di contesto: può includere timestamp approssimati o informazioni sulla posizione approssimative.
  • Indicatore utente: potrebbe includere informazioni quali lo store che ha avviato l'installazione dell'app.
  • Indicatore sul segmento di pubblico personalizzato: se l'annuncio a cui viene assegnato un punteggio proviene da un segmento di pubblico personalizzato on-device, 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 limite verranno condivisi in un aggiornamento successivo.
  • Il codice deve essere autonomo e non deve avere dipendenze esterne.

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

Linguaggio di programmazione

Il codice dell'asta fornito dalla piattaforma di tecnologia pubblicitaria deve essere scritto in JavaScript. Ciò consentirebbe alle piattaforme ad tech di condividere, ad esempio, il codice di offerta tra più 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 trasmesso all'SDK per il rendering.

Il piano è 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 informazioni sull'annuncio vincente (simili alla proposta di frame protetti di Chrome).

Report su impressioni ed eventi

Dopo il rendering dell'annuncio, l'impressione vincente può essere riportata alle piattaforme lato acquisti e lato vendite partecipanti. Ciò consente ad acquirenti e venditori di includere informazioni derivanti dall'asta, ad esempio 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. In questo modo è possibile includere informazioni sull'asta (offerta, nome del segmento di pubblico personalizzato e così via) con clic, visualizzazioni e altri eventi relativi agli annunci. La piattaforma richiama la logica di reporting in questo ordine:

  1. Report lato vendite.
  2. Report per gli acquirenti.

Questo consente alle piattaforme lato acquisti e lato vendite di inviare ai server informazioni importanti sul dispositivo per attivare funzionalità come la definizione del budget in tempo reale, gli aggiornamenti dei modelli di offerta e l'accuratezza dei flussi di lavoro di fatturazione. L'assistenza per la generazione di 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 venditore è 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, registrando i 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 acquirente possono chiamare il metodo registerAdBeacon() dalla funzione JavaScript reportWin().

registerAdBeacon(beacons)

Ingresso:

  • event_key: una stringa che indica il tipo di interazione per la registrazione. Questa è utilizzata come chiave per cercare il punto finale inviato dalla piattaforma quando genera report sui risultati dell'asta.
  • reporting_url: l'URL di proprietà della piattaforma ad tech per la gestione dell'evento.

Le chiavi di evento sono identificatori di stringa di proprietà dell'SDK lato vendite responsabile della generazione di report sui risultati dell'asta. Per eseguire un callback, le tecnologie pubblicitarie registrano i beacon con chiavi corrispondenti a quelle utilizzate dal lato vendite durante la segnalazione degli eventi. Non è necessario che siano k-anonymity, anche se sono previsti 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 lato acquisti vincente è idonea a ricevere questi report.

Report lato vendite

La piattaforma richiama la funzione JavaScript reportResult() nel codice fornito dal lato dell'offerta 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 per operazione riuscita, qualsiasi altro valore per errore.
  • URL del report: 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 gli indicatori pertinenti nell'URL del report per aiutarlo a ottenere ulteriori informazioni sull'asta e sull'annuncio vincente. Ad esempio, potrebbero 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 quello della domanda, la piattaforma trasmette questo valore restituito come parametro di input al codice del report lato domanda.

Report lato acquirenti

La piattaforma richiama la funzione JavaScript reportWin() nel codice fornito dal lato della domanda scaricato dai metadati URL logica delle offerte 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 sono stati recuperati da AuctionConfig. Qualsiasi informazione che la piattaforma di acquisto deve trasmettere all'URL del report può derivare 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 Buy-Side Platform 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.

Uscita:

  • Stato: 0 per operazione riuscita, qualsiasi altro valore per errore.
  • URL del report: la piattaforma richiama questo URL restituito dalla funzione.

Report sugli eventi

La generazione di report sugli eventi è possibile solo dopo il completamento dei report sulle impressioni per l'asta. L'SDK per i venditori è responsabile della segnalazione di eventuali eventi. La piattaforma mostra un'API che prende un ReportEventRequest che specifica l'asta eseguita di recente, la chiave 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 relativi agli annunci. Il client definisce la chiave evento e la raccolta di dati da segnalare.

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 vendita che descrive l'evento di interazione.
  • event_data è una stringa che rappresenta i dati associati a event_key
  • reporting_destinations è un insieme di maschere di bit che utilizza i flag forniti dalla piattaforma. Può essere FLAG_REPORTING_DESTINATION_SELLER o FLAG_REPORTING_DESTINATION_BUYER oppure entrambi.
  • (Facoltativo) input_event 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 associare event_key alle chiavi registrate da acquirenti e 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, con il corpo dell'elemento event_data. Questa richiesta viene effettuata secondo il criterio del "best effort" e non viene eseguita in background in caso di errore di rete, 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 ai tecnici pubblicitari di valutare il rendimento dell'attribuzione in varie 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 chiave-valore degli URI da utilizzare per 1) i report sulle interazioni con gli annunci e 2) la registrazione delle origini.
  • Includi i dati dell'asta dell'asta di 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 queste interazioni di 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 potrebbe scegliere di trasmettere CustomAudience (o altre informazioni contestuali pertinenti sull'annuncio, ad esempio il posizionamento dell'annuncio o la durata di visualizzazione) utilizzando quell'URL in modo che i metadati possano essere propagati nei report di riepilogo quando la tecnologia pubblicitaria esamina il rendimento aggregato della campagna.

Abilitazione della registrazione dell'origine

reportEvent() accetterà un nuovo parametro facoltativo InputEvent. Gli acquirenti vincenti che registrano beacon degli 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 report sugli eventi inviate da reportEvent(). Tutte le risposte con intestazioni ARA appropriate verranno analizzate come qualsiasi altra normale risposta di registrazione dell'origine ARA. Consulta il testo esplicativo dell'API Attribution Reporting per informazioni su come registrare un URL di origine.

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

Tieni presente che l'elemento eventData post-asta potrebbe contenere informazioni sensibili, pertanto la piattaforma rimuove eventData nelle richieste di registrazione dell'origine reindirizzate.

Esempio di report sul coinvolgimento e sulle conversioni

In questo esempio, esamineremo l'acquirente dal punto di vista dell'acquirente 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 nell'asta. Durante l'asta, l'acquirente invia questo ID univoco con i dati dell'asta. Durante il tempo di rendering e di conversione, anche i dati dell'annuncio mostrato vengono inviati con lo stesso ID univoco. Successivamente, potrai 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 sua risposta all'offerta in tempo reale ("RTB") di pubblicità programmatica. L'ID può essere impostato come variabile, ad esempio auctionId. L'ID viene trasmesso come perBuyerSignals nel auctionConfig e diventa disponibile nella logica di offerta dell'acquirente.

  1. Durante l'esecuzione di reportWin, l'acquirente può registrare un beacon degli annunci da attivare durante il tempo di rendering dell'annuncio e per eventi di interazione specifici (registerAdBeacon()). Per associare gli indicatori dell'asta per un evento dell'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 dati a livello di evento. Il venditore deve attivare reportEvent() e trasmettere i dati a livello di evento. La piattaforma invia 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 beaconing 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 registrazione dell'origine.

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 associare l'uno all'altro.

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

Server affidabile gestito dalla piattaforma ad tech

La logica di selezione degli annunci oggi richiede informazioni in tempo reale come lo stato di esaurimento del budget per determinare se i candidati degli annunci devono essere selezionati per l'asta. Sia le piattaforme lato acquisti che quelle lato vendita saranno in grado di ottenere queste informazioni dai server che gestiscono. Per ridurre al minimo la fuga di informazioni sensibili tramite questi server, la proposta richiede le seguenti limitazioni:

  • I comportamenti di questi server, descritti più avanti in questa sezione, non rendono pubbliche le informazioni degli utenti.
  • I server non creerebbero profili con pseudonimi in base ai dati che vedono, quindi dovranno 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 di 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, il lato acquisti può 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, in base ai metadati dell'indicatore di offerta attendibile dal segmento di pubblico personalizzato:

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

La risposta del server dovrebbe 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 vendita: analogamente al flusso lato acquisto descritto sopra, il lato vendite potrebbe voler recuperare informazioni sulle creatività considerate nell'asta. Ad esempio, un publisher potrebbe voler imporre che determinate creatività non vengano mostrate nella sua app sulla base di problemi di sicurezza del brand. Queste informazioni possono essere recuperate e rese disponibili per la logica dell'asta lato vendite. Analogamente alla ricerca server attendibile lato acquisto, anche la ricerca 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 è necessario recuperare 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 URL di rendering inviati nella richiesta.

Questi server funzionerebbero in modo affidabile per offrire diversi vantaggi in termini di sicurezza e privacy:

  • Si può considerare attendibile il valore restituito dal server per ogni chiave in modo che sia basato solo su quella chiave.
  • Il server non esegue la registrazione 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 gestiscono autonomamente. Tuttavia, nella versione di rilascio, la richiesta verrà inviata solo a un server di tipo chiave-valore attendibile.

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