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

Aggiornamenti recenti

• Sono state aggiunte informazioni sulla pianificazione degli aggiornamenti dei segmenti di pubblico personalizzati
• È stata aggiunta l'integrazione di Attribution Reporting con Protected Audience
• È stata pubblicata una cronologia delle funzionalità di Protected Audience.
• FLEDGE è stata rinominata API Protected Audience.
• È stata aggiunta una proposta per la delegazione dei segmenti di pubblico personalizzati.
• È stato rimosso il requisito di k-anonimità per l'URL di aggiornamento giornaliero.

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

Con Protected Audience puoi:

• Gestisci i segmenti di pubblico personalizzati in base alle azioni precedenti degli utenti.
• Avvia aste on-device con l'assistenza della mediazione a cascata o con un singolo venditore.
• Genera report sulle impressioni degli esercizi dopo la selezione degli annunci.

Per iniziare, leggi la guida per gli sviluppatori di Protected Audience. Il tuo feedback è molto apprezzato perché ci consente di continuare a sviluppare Protected Audience.

Cronologia

Nei prossimi mesi lanceremo nuove funzionalità. Le date di rilascio esatta variano a seconda della funzionalità e questa tabella verrà aggiornata con i link alla documentazione man mano che diventano disponibili.

Panoramica

Nella pubblicità mobile, gli inserzionisti devono in genere pubblicare annunci per gli 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à agli utenti che hanno articoli nel carrello degli acquisti, mostrando annunci per ricordare loro di completare l'acquisto. Nel settore, questa idea generale viene comunemente descritta con termini come "remarketing" e "targeting per pubblico personalizzato".

Attualmente, questi casi d'uso vengono in genere implementati condividendo informazioni contestuali sulla modalità di visualizzazione dell'annuncio (ad es. il nome dell'app) e informazioni private come gli elenchi dei segmenti di pubblico con le piattaforme di tecnologia pubblicitaria. Utilizzando queste informazioni, gli inserzionisti possono selezionare annunci pertinenti sui propri server.

L'API Protected Audience su Android (precedentemente nota come FLEDGE) include le seguenti API per consentire alle piattaforme ad tech e agli inserzionisti di supportare i casi d'uso comuni basati sulle interazioni in modo da limitare la condivisione sia degli identificatori tra le app sia delle informazioni sulle interazioni dell'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 vengono memorizzate sul dispositivo e possono essere associate ad annunci candidati pertinenti per il pubblico e metadati arbitrari, come gli indicatori per le offerte. Le informazioni possono essere utilizzate per fornire informazioni su offerte, filtro degli annunci e rendering degli inserzionisti.
2. API Ad Selection: fornisce un framework che orchestra i flussi di lavoro delle piattaforme di tecnologia pubblicitaria che utilizzano indicatori sul dispositivo per determinare un annuncio "vincente " tenendo conto degli annunci candidati archiviati localmente ed eseguendo un'ulteriore elaborazione degli annunci candidati che una piattaforma di tecnologia pubblicitaria restituisce al dispositivo.

A livello generale, l'integrazione funziona nel seguente modo:

1. SportingGoodsApp vuole ricordare ai propri utenti di acquistare gli articoli rimasti 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 di tecnologia pubblicitaria per mostrare i suoi annunci agli utenti nel suo elenco del segmento di pubblico. La piattaforma di tecnologia pubblicitaria gestisce i metadati per gli elenchi di segmenti di pubblico e fornisce annunci candidati, che vengono messi a disposizione del flusso di lavoro di selezione degli annunci per la considerazione. La piattaforma può essere configurata per recuperare periodicamente gli annunci basati sui segmenti di pubblico aggiornati in background. In questo modo, l'elenco degli annunci candidati basati sui segmenti di pubblico rimane aggiornato e non correlato alle richieste inviate agli ad server di terze parti durante l'opportunità pubblicitaria (ovvero la richiesta di annunci contestuali).

2. Quando l'utente gioca a FrisbeeGame sullo stesso dispositivo, potrebbe vedere un annuncio che gli ricorda di completare l'acquisto degli articoli rimasti nel carrello acquisti di SportingGoodsApp. Questo risultato può essere ottenuto da FrisbeeGame (con un SDK annunci integrato) che richiama l'API di selezione degli annunci per selezionare un annuncio vincente per l'utente in base a qualsiasi elenco del segmento di pubblico di cui fa parte (in questo esempio, il segmento di pubblico personalizzato "Prodotti nel carrello" creato da SportingGoodsApp). Il flusso di lavoro di 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 sul dispositivo associati ai segmenti di pubblico personalizzati e ad altri indicatori sul dispositivo. Il flusso di lavoro può essere anche personalizzato dalla piattaforma ad tech e dall'SDK per gli annunci con logiche di offerta e di punteggio personalizzate per raggiungere obiettivi pubblicitari appropriati. Questo approccio consente di utilizzare i dati sugli interessi o sulle interazioni con le app dell'utente per determinare la selezione degli annunci, limitando al contempo la condivisione di questi dati con terze parti.

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

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

Accedere a Protected Audience sulle API Android

Le piattaforme di ad tech devono registrarsi per accedere all'API Protected Audience. Per saperne di più, consulta Registrarsi per un account Privacy Sandbox.

Gestione dei segmenti di pubblico personalizzati

Segmento di pubblico personalizzato

Un segmento di pubblico personalizzato rappresenta un gruppo di utenti, come stabilito dall'inserzionista, con intenzioni o interessi comuni. Un'app o un SDK potrebbe utilizzare un segmento di pubblico personalizzato per indicare un pubblico specifico, ad esempio un utente che ha "lasciato articoli nel carrello degli acquisti" o "ha completato i livelli per principianti" di un gioco. La piattaforma gestisce e archivia le informazioni sui segmenti di pubblico localmente sul dispositivo e non rivela i segmenti di pubblico personalizzati a cui appartiene l'utente. I segmenti di pubblico personalizzati sono diversi dai gruppi di interesse di Protected Audience di Chrome e non possono essere condivisi sul web e nelle app. In questo modo, puoi limitare la condivisione delle informazioni degli utenti.

Un'app dell'inserzionista o l'SDK integrato può unirsi o uscire da un segmento di pubblico personalizzato in base, ad esempio, al coinvolgimento dell'utente in un'app.

Metadati dei segmenti di pubblico personalizzati

Ogni segmento di pubblico personalizzato contiene i seguenti metadati:

• Proprietario:nome del pacchetto dell'app proprietaria. Viene impostato implicitamente sul nome del pacchetto dell'app chiamante.
• Acquirente: la 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 informazioni pertinenti sugli annunci. L'acquirente viene specificato nel formato eTLD+1.
• Nome: un nome o un identificatore arbitrario per il pubblico personalizzato, ad esempio un utente che ha "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 stringa di query nell'URL per il recupero del codice di offerta.
• Ora di attivazione e ora di scadenza:questi campi definiscono l'intervallo di tempo in cui sarà efficace questo segmento di pubblico personalizzato. La piattaforma utilizza queste informazioni per recedere dall'iscrizione a un segmento di pubblico personalizzato. La data e l'ora di scadenza non possono superare un periodo di durata massima per limitare la vita 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 per le offerte per gli utenti" e "Indicatori per le offerte attendibili" su base ricorrente. Per maggiori dettagli, consulta la sezione su come recuperare gli annunci candidati per i segmenti di pubblico personalizzati.
• Indicatori per le offerte per gli utenti:indicatori specifici della piattaforma AdTech per qualsiasi offerta di annunci di remarketing. Alcuni esempi di indicatori sono: la posizione approssimativa dell'utente, le impostazioni internazionali preferite e così via.
• Dati di offerta attendibili: le piattaforme di tecnologia pubblicitaria si basano su dati in tempo reale per fornire informazioni sul recupero e sul punteggio degli annunci. Ad esempio, un annuncio potrebbe esaurire il budget e la sua pubblicazione deve essere interrotta immediatamente. Una tecnologia pubblicitaria può definire un endpoint URL da cui è possibile recuperare questi dati in tempo reale e l'insieme di chiavi per le quali deve essere eseguita la ricerca in tempo reale. Il server che gestisce questa richiesta sarà un server attendibile gestito dalla piattaforma ad tech.
• URL della logica di offerta: l'URL utilizzato dalla piattaforma per recuperare il codice di offerta dalla piattaforma di scambio pubblicitario. La piattaforma esegue questo passaggio quando viene avviata un'asta di annunci.
• Annunci:un elenco di annunci candidati per il segmento di pubblico personalizzato. Sono inclusi i metadati degli annunci specifici della piattaforma ad tech e un URL per il rendering dell'annuncio. Quando viene avviata un'asta per il segmento di pubblico personalizzato, questo elenco di metadati dell'annuncio verrà preso in considerazione. Questo elenco di annunci verrà aggiornato utilizzando l'endpoint URL di aggiornamento giornaliero, se possibile. A causa delle limitazioni delle risorse sui dispositivi mobili, è previsto 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 dei segmenti di pubblico personalizzati tradizionali si basano in genere su tecnologie e integrazioni lato server sviluppate da ad tech in partnership con clienti e partner di agenzie e inserzionisti. L'API Protected Audience consente di definire e configurare i segmenti di pubblico personalizzati, tutelando al contempo la privacy degli utenti. Per integrare un segmento di pubblico personalizzato, le tecnologie pubblicitarie per gli acquirenti che non hanno un SDK nelle app devono collaborare con quelle che hanno una presenza on-device, come i partner di misurazione mobile (MMP) e le Supply-Side Platform (SSP). L'obiettivo dell'API Protected Audience è supportare questi SDK fornendo soluzioni flessibili per la gestione dei segmenti di pubblico personalizzati, consentendo agli utenti che chiamano il dispositivo di invocare la creazione di segmenti di pubblico personalizzati per conto degli acquirenti. Questa procedura è chiamata delega dei segmenti di pubblico personalizzati. Per configurare la delega dei segmenti di pubblico personalizzati, segui questi passaggi:

Partecipare a un segmento di pubblico personalizzato

Puoi partecipare 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 l'oggetto CustomAudience con i parametri previsti. Ecco un esempio di snippet di codice:

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 compilati automaticamente dall'API). L'API impone inoltre 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 delle app eseguiti da joinCustomAudience() e non può essere modificata dalla risposta del recupero. Il proprietario CustomAudience è il nome del pacchetto dell'applicazione chiamante. Non esiste un'altra convalida di fetchUri oltre al 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 dell'oggetto segmento di pubblico personalizzato. Scopri i requisiti e le limitazioni attuali nella nostra guida per gli sviluppatori.

Qualsiasi risposta di errore HTTP da parte dell'acquirente causa il fallimento di fetchAndJoinCustomAudience. In particolare, una risposta di stato HTTP 429 (Troppe richieste) blocca le richieste provenienti dall'applicazione corrente per un periodo da definire. La chiamata dell'API non va a buon fine anche se la risposta dell'acquirente ha un formato non valido. Gli errori vengono segnalati al chiamante dell'API responsabile del nuovo tentativo a causa di errori temporanei (ad esempio il server non risponde) o della gestione di errori persistenti (ad esempio errori di convalida dei dati o altri errori non transitori con la comunicazione al server).

L'oggetto CustomAudienceFetchRequest consente all'autore della chiamata 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, in quanto questi campi sono obbligatori per creare un segmento di pubblico personalizzato. Una rappresentazione JSON dei contenuti di CustomAudience come parzialmente definito dall'autore della chiamata dell'API è inclusa nella richiesta GET a fetchUri in un'intestazione speciale X-CUSTOM-AUDIENCE-DATA. La dimensione della forma serializzata degli annunci pubblicitari personalizzati è limitata a 8 KB. Se le dimensioni superano il limite, la chiamata all'API fetchAndJoinCustomAudience non va a buon fine.

La mancanza di un controllo k-anon ti 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 del segmento di 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() sia associata all'acquirente e che abbia avuto origine da un partner on-device attendibile. Per condividere le informazioni, l'acquirente può concordare con l'utente che chiama sul dispositivo che alcune delle informazioni da utilizzare per creare il segmento di pubblico personalizzato verranno aggiunte come parametri di query a fetchUri. In questo modo, l'acquirente può verificare le chiamate e rilevare se un token di convalida è stato utilizzato da una tecnologia pubblicitaria dannosa per creare diversi segmenti di pubblico personalizzati.

Una nota sulla definizione e sull'archiviazione dei 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 creati per suo conto.
  • La proposta dell'API Protected Audience non specifica né un formato per il token di verifica né la modalità di trasferimento del token di verifica all'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.

Lasciare un segmento di pubblico personalizzato

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

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

Per contribuire a ridurre l'utilizzo dello spazio di archiviazione e di altre risorse del dispositivo, i segmenti di pubblico personalizzati scadono e vengono rimossi dallo spazio di archiviazione sul dispositivo dopo un periodo di tempo predeterminato. Il valore predefinito deve essere determinato. Il proprietario può ignorare questo valore predefinito.

Controllo utente

• La proposta intende dare agli utenti la visibilità dell'elenco delle app installate che hanno creato almeno un segmento di pubblico personalizzato
• Gli utenti possono rimuovere le app da questo elenco. La rimozione cancella tutti i segmenti di pubblico personalizzato associati alle app e impedisce alle app di aggiungerne di nuovi.
• 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 hanno la possibilità di disattivare completamente Privacy Sandbox su Android, inclusa l'API Protected Audience. Se l'utente ha disattivato Privacy Sandbox, l'API Protected Audience non genera alcun errore.

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

Aggiornamenti pianificati

Le soluzioni descritte in precedenza richiedono che l'SDK dell'app o della tecnologia pubblicitaria richiami le API mentre l'app è in primo piano e fornisca le proprietà complete del segmento di pubblico personalizzato, direttamente o tramite delega. Tuttavia, non è sempre possibile per gli inserzionisti e i fornitori di tecnologia pubblicitaria definire in tempo reale a quali segmenti di pubblico appartiene un utente mentre utilizza l'app.

Per semplificare questa procedura, è possibile che la tecnologia pubblicitaria chiami l'scheduleCustomAudienceUpdate() API. Questa API consente al chiamante di specificare un ritardo per l'invio della chiamata API, fornendo così tempo aggiuntivo alla tecnologia pubblicitaria che risponde per elaborare gli eventi a livello di app e determinare a quali segmenti di pubblico protetti l'utente deve partecipare o da cui deve essere rimosso.

/**
* API To schedule delayed update events for Custom Audience
*
* @param request Criteria that determine when and where to trigger a call to a
* DSP endpoint to update one or more Custom Audiences
*/

public void scheduleCustomAudienceUpdate(
    @NonNull ScheduleCustomAudienceUpdateRequest request,
    @NonNull @CallBackExecutor Executor executor,
    @NonNull AdServicesOutcomeReceiver<Object, Exception> receiver)

ScheduleCustomAudienceUpdateRequest

public final class ScheduleCustomAudienceUpdateRequest {
  // Required Field
  @NonNull public Uri getUpdateUri() {
    return mUpdateUri;
  }

  // Required Field
  @NonNull public Duration getMinDelay() {
    return mMinDelay;
  }

  //  Required Field
  @NonNull public List<PartialCustomAudience> getPartialCustomAudienceList() {
    return mPartialCustomAudiences;
  }

  //  Optional Field (default false)
  public boolean shouldReplacePendingUpdates () {
    return mShouldReplacePendingUpdates;
  }
}

ScheduleCustomAudienceUpdateRequest contiene le informazioni necessarie per registrare un job in ritardo da eseguire con la piattaforma. Dopo il ritardo specificato, un job in background verrà eseguito periodicamente e invierà le richieste. ScheduleCustomAudienceUpdateRequest può contenere le seguenti informazioni:

• UpdateUri: endpoint URI a cui verrà inviata una chiamata GET per recuperare l'aggiornamento. L'identità dell'acquirente viene dedotta intrinsecamente dall'eTLD+1 e non deve essere fornita esplicitamente e non può essere modificata dalla risposta all'aggiornamento. La richiesta GET si aspetta un oggetto JSON contenente un elenco di oggetti customAudience come risposta.
• DelayTime: l'ora che indica il ritardo dal momento dell'esecuzione della chiamata all'API scheduleCustomAudienceUpdate() per pianificare l'aggiornamento.

• PartialCustomAudience: l'API consente inoltre all'SDK on-device di inviare un elenco di segmenti di pubblico personalizzato parzialmente costruiti. In questo modo, gli SDK in-app possono svolgere il doppio ruolo, dal controllo completo a quello parziale sulla gestione dei segmenti di pubblico personalizzati, in base alla partnership con le DSP.

  • In questo modo, l'API rimane compatibile con l'fetchAndJoinCustomAudience() API che consente la condivisione di informazioni simili.

• ShouldReplacePendingUpdates: valore booleano che determina se gli aggiornamenti pianificati in attesa devono essere annullati e sostituiti con l'aggiornamento descritto nell'ScheduleCustomAudienceUpdateRequest corrente. Se questo valore è impostato su false e esistono aggiornamenti precedentemente richiesti ancora in attesa per lo stesso acquirente nella stessa app, una chiamata a scheduleCustomAudienceUpdate con questo valore ScheduleCustomAudienceUpdateRequest non andrà a buon fine. Il valore predefinito è false.

Autorizzazioni e controllo delle app

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

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

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

Controllo della piattaforma ad tech

Questa proposta illustra i modi in cui le tecnologie pubblicitarie possono controllare i propri segmenti di pubblico personalizzati:

• Le tecnologie pubblicitarie si registrano in Privacy Sandbox e forniscono un dominio eTLD+1 che corrisponde a tutti gli URL per un segmento di pubblico personalizzato.
• Le tecnologie pubblicitarie possono collaborare con app o SDK per fornire token di verifica utilizzati per verificare la creazione di un segmento di pubblico personalizzato. Quando questa procedura viene delegata a un partner, la creazione di segmenti di pubblico personalizzati può essere configurata in modo da richiedere il riconoscimento da parte della tecnologia pubblicitaria.
• Un fornitore di tecnologia pubblicitaria può scegliere di disattivare le chiamate joinCustomAudience per suo conto e consentire solo all'API fetchAndJoinCustomAudience di attivare tutti i segmenti di pubblico personalizzati delle chiamate. 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 su ogni tecnologia pubblicitaria.

Annunci candidati e risposta dei metadati

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

• Metadati:metadati degli annunci lato acquirente specifici per la tecnologia pubblicitaria. Ad esempio, possono 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 per consentire all'API Protected Audience di filtrare gli annunci in base ai dati sul dispositivo. Per maggiori dettagli, leggi la sezione sulla logica di filtraggio lato acquirente.

Flusso di lavoro di selezione degli annunci

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

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

• Se non sono disponibili informazioni sui pacchetti installati sul server, le piattaforme di ad tech potrebbero voler inviare più annunci contestuali al dispositivo e richiamare il flusso di lavoro di selezione degli annunci per attivare il filtro in base alle installazioni di app al fine di massimizzare le probabilità di mostrare un annuncio pertinente.
• Poiché gli annunci di remarketing vengono recuperati al di fuori del normale flusso, potrebbe essere necessario aggiornare i modelli di offerta attuali. Le piattaforme di tecnologia pubblicitaria potrebbero voler creare sottomodelli di asta (l'implementazione potrebbe essere basata su un pattern chiamato modello a due torri) che possono lavorare separatamente sulle funzionalità degli annunci e sugli indicatori di contesto e combinare le uscite del sottomodello sul dispositivo per prevedere le offerte. Ciò può trarre vantaggio sia dalle aste lato server sia dalle aste per una determinata opportunità pubblicitaria.

Questo approccio consente di utilizzare i dati sulle interazioni con le app dell'utente per la selezione degli annunci, limitando al contempo la condivisione di questi dati con terze parti.

Questo flusso di lavoro di selezione degli annunci orchestra l'esecuzione on-device del codice JavaScript fornito dall'ad tech in base alla seguente sequenza:

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

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

Il design delle selezioni di annunci che non coinvolgono i segmenti di pubblico personalizzati è in fase di progettazione attiva.

Avvia il flusso di lavoro di selezione degli annunci

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

• Venditore: identificatore della piattaforma pubblicitaria sell-side, nel formato eTLD+1
• URL della logica decisionale: quando viene avviata un'asta di annunci, la piattaforma utilizzerà questo URL per recuperare il codice JavaScript dalla piattaforma di vendita al fine di assegnare un punteggio all'annuncio vincente.
• Acquirenti di segmenti di pubblico personalizzati: un elenco di piattaforme di acquisto con domanda basata su segmenti di pubblico personalizzati per questa asta, nel formato eTLD+1.
• Indicatori di selezione degli annunci: informazioni sull'asta (dimensioni dell'annuncio, formato dell'annuncio e così via).
• Indicatori del venditore: indicatori specifici della piattaforma di scambio pubblicitario.
• URL indicatori di punteggio attendibili: endpoint URL dell'indicatore attendibile sell-side da cui è possibile recuperare informazioni in tempo reale specifiche per la creatività.
• Indicatori per acquirente: i lati 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 ad tech che avvia il flusso di lavoro di selezione degli annunci definendo prima AdSelectionConfig e poi invocando 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 acquisti

La logica di offerta viene in genere fornita dalle piattaforme di acquisto. 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 deve 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 invoca questa funzione in sequenza per tutti gli annunci (contestuali o di remarketing). Se esistono più fornitori di logica di offerta, il sistema non garantisce la sequenza di esecuzione tra i fornitori.

La funzione prevede i seguenti parametri:

• Annuncio: l'annuncio preso in considerazione dal codice di offerta lato acquirente. Si tratta di un annuncio di un segmento di pubblico personalizzato idoneo
• Indicatori asta: indicatori sell-side specifici della piattaforma.
• Indicatori per acquirente: i lati 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 informare il recupero e il calcolo del punteggio degli annunci. Ad esempio, una campagna pubblicitaria potrebbe esaurire il budget e la sua pubblicazione deve essere interrotta immediatamente. Una tecnologia pubblicitaria può definire un endpoint URL da cui è possibile recuperare questi dati in tempo reale e l'insieme di chiavi per le quali è 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 approssimativo o informazioni sulla posizione approssimative o il costo per clic sull'annuncio.
• Indicatori utente: potrebbero essere incluse informazioni come i dati dei pacchetti installati disponibili.

Costo dell'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 stocastico a 8 bit per motivi di privacy. Il valore arrotondato di adCost viene poi passato al parametro contextual_signals in reportWin durante la generazione di report sulle impressioni.

Logica di filtro lato acquisti

Le piattaforme di acquisto potranno filtrare gli annunci in base a ulteriori indicatori sul dispositivo disponibili durante la fase di selezione degli annunci. Ad esempio, le piattaforme di ad tech possono implementare qui le funzionalità di quota limite. Se sono presenti più fornitori di filtri, il sistema non garantisce la sequenza di esecuzione tra i fornitori.

La logica di filtro lato acquirenti può essere implementata nell'ambito della logica di offerta restituendo un valore di offerta pari a 0 per un determinato annuncio.

Inoltre, le piattaforme di acquisto potranno segnalare che un determinato annuncio deve essere filtrato in base a ulteriori indicatori on-device disponibili per Protected Audience e che non usciranno dal dispositivo. Man mano che perfezioniamo la progettazione di una logica di filtro aggiuntiva, le piattaforme di acquisto seguiranno la stessa struttura per segnalare che il filtro deve essere eseguito.

Logica di punteggio lato vendite

La logica di punteggio viene in genere fornita dalla piattaforma lato vendite. Lo scopo del codice è determinare un annuncio vincente in base agli output della logica di offerta. Potrebbe essere applicata una logica di business aggiuntiva per determinare il risultato. Se sono presenti più fornitori di logica decisionale, il sistema non garantisce la sequenza di esecuzione tra i fornitori. La piattaforma utilizzerà il parametro di input "URL logica decisionale" dell'API selectAds() per recuperare il codice JavaScript che deve 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 in fase di valutazione; l'output della funzione generateBid().
• Offerta: l'importo dell'offerta generato dalla funzione generateBid().
• Auction config: parametro di input per il metodo selectAds().
• Indicatori di punteggio attendibili: le piattaforme di tecnologia pubblicitaria si basano su dati in tempo reale per informare il filtraggio e il punteggio degli annunci. Ad esempio, un publisher di app può 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 attendibile gestito dalla tecnologia pubblicitaria.
• Indicatore contestuale: può includere informazioni approssimative sulla posizione o il timestamp approssimativo.
• Indicatore utente: possono essere incluse informazioni come lo store che ha avviato l'installazione dell'app.
• Indicatore relativo ai segmenti di pubblico personalizzati: se l'annuncio a cui viene assegnato un punteggio proviene da un segmento di pubblico personalizzato sul dispositivo, questo indicatore conterrà informazioni come il lettore e il nome del segmento di pubblico personalizzato.

Esecuzione del codice di selezione degli annunci

Nella proposta, il sistema recupererà il codice dell'asta fornito dalla piattaforma ad tech da endpoint URL configurabili ed eseguirà l'operazione sul dispositivo. Dati i vincoli di risorse sui dispositivi mobili, il codice dell'asta deve rispettare le seguenti linee guida:

• L'esecuzione del codice dovrebbe terminare in un periodo di tempo predefinito. Questo limite si applicherà 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 avere dipendenze esterne.

Poiché il codice dell'asta, ad esempio la logica di offerta, potrebbe richiedere l'accesso ai dati privati degli utenti, come le origini di installazione delle app, il runtime non fornirà accesso alla rete o allo stoccaggio.

Linguaggio di programmazione

Il codice dell'asta fornito dalla piattaforma di tecnologia pubblicitaria deve essere scritto in JavaScript. In questo modo, le piattaforme di tecnologia pubblicitaria potrebbero, ad esempio, condividere il codice di offerta tra le piattaforme che supportano Privacy Sandbox.

Visualizzazione dell'annuncio vincente

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

Il piano è far evolvere la soluzione per garantire che le informazioni sull'appartenenza a un segmento di pubblico personalizzato o sulla cronologia del coinvolgimento con l'app di un utente non possano essere determinate dall'app o dall'SDK tramite le informazioni sull'annuncio vincente (in modo simile alla proposta di frame delimitati di Chrome).

Report sulle impressioni e sugli eventi

Una volta visualizzato l'annuncio, l'impressione vincente può essere registrata nuovamente sulle piattaforme lato acquisti e lato vendite partecipanti. In questo modo, acquirenti e venditori possono includere le informazioni dell'asta, ad esempio l'offerta o il nome del segmento di pubblico personalizzato, nel report sulle impressioni vincenti. Inoltre, la piattaforma lato vendite e la piattaforma lato acquisti vincente sono idonee a ricevere report aggiuntivi a livello di evento sull'annuncio vincente. In questo modo, puoi includere informazioni sull'asta (offerta, nome del segmento di pubblico personalizzato e così via) con clic, visualizzazioni e altri eventi correlati agli annunci. La piattaforma richiama la logica di generazione dei report in questo ordine:

1. Report sell-side.
2. Report lato acquirente.

In questo modo, le piattaforme buy-side e sell-side hanno un modo per inviare nuovamente ai server informazioni importanti sul dispositivo per attivare funzionalità come il budgeting in tempo reale, gli aggiornamenti dei modelli di offerta e flussi di lavoro di fatturazione accurati. Questo supporto per i report sulle impressioni è complementare all'API Attribution Reporting.

Per supportare i report sugli eventi sono necessari due passaggi: il lato sell-side e il lato buy-side. JavaScript deve registrare l'evento per cui deve ricevere i report sugli eventi e il lato sell-side è responsabile della generazione di report a livello di evento.

Protected Audience fornisce un meccanismo per iscriversi a eventi futuri correlati a un'asta vincente registrando i beacon. Nella funzione JavaScript reportResult() di un venditore, le piattaforme di scambio pubblicitario possono registrare i beacon utilizzando la funzione registerAdBeacon() della piattaforma. Analogamente, le piattaforme di acquisto possono chiamare la funzione registerAdBeacon() dalla funzione JavaScript reportWin().

registerAdBeacon(beacons)

Input:

• event_key: una stringa che indica il tipo di interazione per cui registrarsi. Viene utilizzato come chiave per cercare l'endpoint a cui la piattaforma invia ping durante la generazione dei report sui risultati dell'asta.
• reporting_url: l'URL di proprietà della piattaforma di ad tech per la gestione dell'evento.

Le chiavi evento sono identificatori di stringa di proprietà dell'SDK sell-side responsabile della generazione di report sui risultati dell'asta. Affinché venga eseguito un callback, le tecnologie pubblicitarie registrano i beacon con chiavi corrispondenti a quelle utilizzate dal sell-side quando vengono registrati gli eventi. Non è necessario che siano anonimi k, 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 piattaforme di scambio pubblicitario che hanno eseguito l'asta sono sempre idonee a ricevere questi report sugli eventi. Solo la piattaforma di acquisto vincente è idonea a ricevere questi report.

Report sell-side

La piattaforma invoca la funzione JavaScript reportResult() nel codice fornito dal lato dell'offerta scaricato dal parametro URL logica decisionale 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 esito positivo, qualsiasi altro valore per esito negativo.
• URL report: la piattaforma richiama questo URL restituito dalla funzione.
• Indicatori per l'acquirente: un oggetto JSON da passare alla funzione reportWin dell'acquirente.

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

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

Report lato acquirente

La piattaforma richiama la funzione JavaScript reportWin() nel codice fornito dal lato domanda scaricato dai metadati dell'URL della 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}};
}

Input:

• auction_signals e per_buyer_signals vengono recuperati da AuctionConfig. Qualsiasi informazione che la piattaforma di acquisto deve trasmettere all'URL report può provenire da questo dato.
• signals_for_buyer è l'output di reportResult lato venditore. In questo modo, la piattaforma lato vendite ha la possibilità di condividere i dati con la piattaforma lato acquisti per la generazione di report.
• contextual_signals contiene informazioni come il nome dell'app e custom_audience_signals contiene le informazioni sul segmento di pubblico personalizzato. In futuro è possibile che vengano aggiunte altre informazioni.

Output:

• Stato: 0 per esito positivo, qualsiasi altro valore per esito negativo.
• URL report: la piattaforma richiama questo URL restituito dalla funzione.

Eventi di segnalazione

La generazione di report sugli eventi è possibile solo al termine della generazione dei report sulle impressioni per l'asta. L'SDK sell-side è responsabile della generazione di report su eventuali eventi. La piattaforma espone un'API che accetta un ReportEventRequest che specifica la asta eseguita di recente, la chiave dell'evento registrata, i dati associati a quella chiave, se il report deve essere inviato all'acquirente o al venditore (o entrambi) e un evento di input facoltativo per gli eventi correlati agli annunci. Il client definisce la chiave dell'evento e la raccolta dei 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)

Input:

• ad_selection_id deve essere un AdSelectionId di un'asta eseguita di recente recuperata dal AdSelectionOutcome.
• event_key è una stringa definita dal lato vendita che descrive l'evento di interazione.
• event_data è una stringa che rappresenta i dati associati al event_key
• reporting_destinations è una maschera di bit impostata utilizzando i flag forniti dalla piattaforma. Può essere FLAG_REPORTING_DESTINATION_SELLER o FLAG_REPORTING_DESTINATION_BUYER oppure 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 la sezione Integrazione dell'API Attribution Reporting.

Dopo che l'SDK sell-side ha invocato reportEvent e, a seconda del flag reporting_destinations, la piattaforma tenta di abbinare event_key alle chiavi registrate da acquirenti e venditori nelle funzioni JavaScript reportWin e reportResult. Se esiste una corrispondenza, la piattaforma esegue il POST del event_data al reporting_url associato. Il tipo di contenuto della richiesta è testo normale con il corpo event_data. Questa richiesta viene effettuata secondo il criterio del "best effort" e non genera alcun messaggio in caso di errore di rete, risposta di errore del server o se non vengono trovate chiavi corrispondenti.

Integrazione dell'API Attribution Reporting

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

Grazie a questa integrazione cross-API, le adtech possono:

• Crea una mappa chiave-valore degli URI da utilizzare sia per 1) i report sulle interazioni con gli annunci sia per 2) la registrazione delle origini.
• Includi i dati dell'asta Protected Audience nella mappatura delle chiavi lato sorgente per i report di riepilogo aggregati (utilizzando l'API Attribution Reporting). Per ulteriori informazioni, consulta la proposta di progettazione ARA.

Quando un utente visualizza o fa clic su un annuncio:

• L'URL utilizzato per registrare le interazioni con gli eventi utilizzando Protected Audience fornirà all'acquirente i dati necessari per registrare una visualizzazione 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 della visualizzazione) utilizzando questo URL, in modo che questi metadati possano essere propagati ai report di riepilogo quando la tecnologia pubblicitaria esamina il rendimento aggregato delle campagne.

Attivazione della registrazione delle sorgenti

reportEvent() accetterà un nuovo parametro facoltativo InputEvent. Gli acquirenti vincitori che registrano gli ad beacon possono scegliere quali report reportEvent vengono registrati con le API Attribution Reporting come origine registrata. L'intestazione della richiesta Attribution-Reporting-Eligible verrà aggiunta a tutte le richieste di generazione di report sugli eventi inviate da reportEvent(). Eventuali risposte con intestazioni ARA appropriate verranno analizzate nello stesso modo in cui verrebbe analizzata qualsiasi altra risposta di registrazione della fonte ARA normale. Consulta la spiegazione dell'API Attribution Reporting per scoprire come registrare un URL di origine.

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

Tieni presente che il valore eventData post-asta potrebbe contenere informazioni sensibili, pertanto la piattaforma elimina il valore eventData nelle richieste di registrazione delle origini reindirizzate.

Esempio di report sul coinvolgimento e sulle conversioni

In questo esempio, lo esamineremo dal punto di vista dell'acquirente interessato a 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 il rendering e il momento della conversione, anche i dati dell'annuncio visualizzato vengono inviati con lo stesso ID univoco. In seguito, l'ID univoco può essere utilizzato per associare questi report.

Flusso di lavoro: prima dell'inizio dell'asta, l'acquirente invia un ID univoco al venditore nell'ambito della sua risposta all'offerta in tempo reale ("RTB") programmatica. L'ID può essere impostato come variabile, ad esempio auctionId. L'ID viene passato 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 annuncio da attivare al momento del rendering dell'annuncio e per eventi di interazione specifici (registerAdBeacon()). Per associare gli indicatori dell'asta a un evento annuncio, imposta auctionId come parametro di query dell'URL del beacon.
2. Durante il rendering dell'annuncio, i beacon registrati durante l'asta possono essere attivati o migliorati con dati a livello di evento. Il venditore deve attivare reportEvent() e passare i dati a livello di evento. La piattaforma invia un ping all'URL del beacon annuncio registrato dell'acquirente correlato al reportEvent() 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 delle aste per un evento di conversione, imposta auctionId nell'URL di origine della registrazione.

Al termine della procedura descritta sopra, l'acquirente avrà 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 associarli tra loro.

Un flusso di lavoro simile si applica a un venditore se ha bisogno di 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 che al venditore.

Server attendibile gestito dalla piattaforma ad tech

Attualmente, 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 di scambio pubblicitario sia quelle di scambio pubblicitario potranno ottenere queste informazioni dai server che gestiscono. Per ridurre al minimo la fuga di informazioni sensibili tramite questi server, la proposta prevede le seguenti limitazioni:

• Il comportamento di questi server, descritto più avanti in questa sezione, non causerebbe la fuga di informazioni degli utenti.
• I server non creano profili pseudonimi in base ai dati che vedono, ovvero devono essere "attendibili".

Lato acquirente: una volta che il lato acquirente avvia la logica di offerta lato acquirente, la piattaforma esegue un recupero HTTP dei dati di offerta attendibili dal server attendibile. L'URL viene composto aggiungendo l'URL e le chiavi presenti nei metadati di Trusted Bidding Signals del segmento di pubblico personalizzato in lavorazione. Questo recupero viene eseguito solo durante l'elaborazione degli annunci provenienti dai segmenti di pubblico personalizzati sul dispositivo. In questa fase, il lato acquirente può applicare i budget, controllare lo stato di messa in pausa / riattivata della campagna, eseguire il targeting e così via.

Di seguito è riportato un URL di esempio per recuperare i dati delle offerte affidabili, in base ai metadati degli indicatori delle offerte affidabili del segmento di pubblico personalizzato:

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

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

Sell side: come per il flusso di acquisto sopra riportato, il sell side potrebbe voler recuperare informazioni sulle creatività prese in considerazione nell'asta. Ad esempio, un publisher potrebbe voler imporre che determinate creatività non vengano mostrate nella sua app in base a motivi di sicurezza del brand. Queste informazioni possono essere recuperate e rese disponibili per la logica dell'asta sul lato vendite. Analogamente alla ricerca del server attendibile lato acquirente, anche la ricerca del server attendibile lato venditore avviene utilizzando un recupero HTTP. L'URL è composto dall'aggiunta dell'URL degli indicatori di punteggio attendibili agli URL di rendering delle creatività per le quali devono essere recuperati i dati.

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

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

La risposta del server deve essere un oggetto JSON le cui chiavi sono gli URL di rendering inviati nella richiesta.

Questi server opereranno in modo attendibile per offrire diversi vantaggi in termini di sicurezza e privacy:

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

Come meccanismo temporaneo, l'acquirente e il venditore possono recuperare questi indicatori per le offerte da qualsiasi server, incluso uno di loro. Tuttavia, nella versione di release, la richiesta verrà inviata solo a un server di tipo chiave-valore attendibile.

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