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 delega del segmento di pubblico personalizzato.
• È stato rimosso il requisito di k-anonymity per l'URL di aggiornamento giornaliero.

Protected Audience è in versione beta ed è disponibile per lo sviluppo.

Con Protected Audience puoi:

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

Per iniziare, leggi la guida per gli sviluppatori di Protected Audience. Il tuo feedback è apprezzato mentre continuiamo a sviluppare Protected Audience.

Cronologia

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

Panoramica

Nella pubblicità mobile, gli inserzionisti hanno spesso bisogno di 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à agli utenti che hanno lasciato articoli nel carrello, mostrando annunci per ricordare loro di completare l'acquisto. Il settore descrive comunemente questa idea generale con termini come "remarketing" e "targeting per segmenti di pubblico personalizzati".

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 le piattaforme di tecnologia pubblicitaria. Utilizzando queste informazioni, gli inserzionisti possono selezionare gli annunci pertinenti sui propri server.

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

1. API Custom Audience: questa API è 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 a metadati arbitrari, come gli indicatori di offerta. Queste informazioni possono essere utilizzate per le offerte degli inserzionisti, il filtro degli annunci e il rendering.
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 " prendendo in considerazione gli 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 suoi 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 dei segmenti di pubblico "prodotti nel carrello". La piattaforma gestisce e memorizza questo elenco di segmenti 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 dei segmenti di pubblico. La piattaforma di tecnologia pubblicitaria gestisce i metadati per gli elenchi di segmenti di pubblico e fornisce gli annunci candidati, che vengono resi disponibili al flusso di lavoro di selezione degli annunci per la valutazione. La piattaforma può essere configurata per recuperare periodicamente in background gli annunci basati sul segmento di pubblico aggiornato. In questo modo, l'elenco degli annunci candidati basati sul pubblico rimane aggiornato e non correlato alle richieste inviate agli ad server di terze parti durante l'opportunità pubblicitaria (ovvero richiesta di annuncio contestuale).

2. Quando l'utente gioca a FrisbeeGame sullo stesso dispositivo, potrebbe visualizzare un annuncio che gli ricorda di completare l'acquisto degli articoli lasciati nel carrello acquisti di SportingGoodsApp. Ciò può essere ottenuto tramite FrisbeeGame (con un SDK per gli annunci integrato) che richiama l'API Ad Selection per selezionare un annuncio vincente per l'utente in base a qualsiasi elenco dei segmenti 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 di selezione degli annunci può essere configurato in modo da prendere in considerazione gli annunci recuperati dai server delle piattaforme ad tech, oltre agli annunci sul dispositivo associati ai segmenti di pubblico personalizzati e ad altri indicatori sul dispositivo. Il flusso di lavoro può anche essere personalizzato dalla piattaforma di tecnologia pubblicitaria e dall'SDK per gli annunci con logica di offerta e punteggio personalizzata per raggiungere gli obiettivi pubblicitari appropriati. Questo approccio consente di utilizzare i dati relativi agli interessi o alle interazioni con le app dell'utente per informare la selezione degli annunci, limitando al contempo la condivisione di questi dati con terze parti.

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

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

Accedere alle API Protected Audience su Android

Le piattaforme di tecnologia pubblicitaria 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 determinato dall'inserzionista con intenzioni o interessi comuni. Un'app o un SDK può utilizzare un segmento di pubblico personalizzato per indicare un segmento di pubblico particolare, ad esempio qualcuno che ha "lasciato articoli nel carrello" o "completato i livelli per principianti" di un gioco. La piattaforma mantiene e memorizza le informazioni sul pubblico localmente sul dispositivo e non mostra a quali segmenti di pubblico personalizzati appartiene l'utente. I segmenti di pubblico personalizzati sono diversi dai gruppi basati sugli interessi di Protected Audience di Chrome e non possono essere condivisi sul web e nelle app. In questo modo, la condivisione delle informazioni degli utenti viene limitata.

Un'app dell'inserzionista o l'SDK integrato può entrare a far parte o uscire da un segmento di pubblico personalizzato in base, ad esempio, al coinvolgimento degli utenti in un'app.

Metadati dei segmenti di pubblico personalizzati

Ogni segmento di pubblico personalizzato contiene i seguenti metadati:

• Proprietario:nome del pacchetto dell'app proprietaria. Questo valore 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 sugli annunci pertinenti. L'acquirente è specificato nel formato eTLD+1.
• Nome:un nome o un identificatore arbitrario per il segmento di pubblico personalizzato, ad esempio un utente che ha "abbandonato il carrello". 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 il recupero del codice di offerta.
• Ora di attivazione e ora di scadenza:questi campi definiscono la finestra temporale in cui questo segmento di pubblico personalizzato sarà efficace. La piattaforma utilizza queste informazioni per ritirare l'iscrizione a un segmento di pubblico personalizzato. Il tempo di scadenza non può superare una finestra di durata massima per limitare la durata di una custom audience.
• URL di aggiornamento giornaliero:l'URL che la piattaforma utilizza 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 di annunci di remarketing. Alcuni esempi di indicatori sono la posizione approssimativa o le impostazioni internazionali preferite dell'utente.
• Dati di offerta attendibili: le piattaforme di tecnologia pubblicitaria si basano su dati in tempo reale per informare il recupero e l'assegnazione del punteggio degli annunci. Ad esempio, un annuncio potrebbe esaurire il budget e deve essere interrotto immediatamente. Una tecnologia pubblicitaria può definire un endpoint URL da cui possono essere recuperati questi dati in tempo reale e l'insieme di chiavi per cui deve essere eseguita la ricerca in tempo reale. Il server che gestisce questa richiesta sarà un server attendibile gestito dalla piattaforma di tecnologia pubblicitaria.
• URL della logica di offerta: l'URL che la piattaforma utilizza per recuperare il codice di offerta dalla demand-side platform. 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 di tecnologia pubblicitaria e un URL per il rendering dell'annuncio. Quando viene avviata un'asta per il segmento di pubblico personalizzato, viene presa in considerazione questa lista di metadati degli annunci. Questo elenco di annunci verrà aggiornato utilizzando l'endpoint URL di aggiornamento giornaliero quando possibile. A causa dei limiti delle 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

L'approccio consolidato alla definizione e alla configurazione dei segmenti di pubblico personalizzati si basa in genere su tecnologie e integrazioni lato server gestite da ad tech in collaborazione con clienti e partner di agenzie e inserzionisti. L'API Protected Audience consente la definizione e la configurazione di 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 dell'acquirente che non hanno una presenza SDK nelle app devono collaborare con le tecnologie pubblicitarie che hanno una presenza sul dispositivo, come i partner di misurazione mobile (MMP) e le 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. Questo processo è chiamato delega del pubblico personalizzato. Configura la delega del segmento di pubblico personalizzato seguendo questi passaggi:

Unirsi a un segmento di pubblico personalizzato

L'iscrizione a un segmento di pubblico personalizzato può essere effettuata in due modi:

joinCustomAudience()

Un'app o un SDK può richiedere di entrare a far parte di un segmento di pubblico personalizzato chiamando joinCustomAudience() dopo aver creato un'istanza dell'oggetto CustomAudience con i parametri previsti. Ecco un esempio illustrativo 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 entrare a far parte di un segmento di pubblico personalizzato per conto di una tecnologia pubblicitaria che non è presente sul dispositivo chiamando fetchAndJoinCustomAudience() con i parametri previsti, come nel seguente esempio:

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 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 di recupero. Il proprietario di CustomAudience è il nome del pacchetto dell'applicazione chiamante. Non esiste 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 prevede un oggetto JSON che rappresenta 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 l'errore di fetchAndJoinCustomAudience. In particolare, una risposta di stato HTTP 429 (Troppe richieste) blocca le richieste dell'applicazione corrente per un periodo da definire. La chiamata API non va a buon fine anche se la risposta dell'acquirente non è valida. Gli errori vengono segnalati al chiamante API responsabile dei nuovi tentativi a causa di errori temporanei (ad esempio il server non risponde) o della gestione di errori permanenti (ad esempio errori di convalida dei dati o altri errori non temporanei di comunicazione con il 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. 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 necessari per creare un segmento di pubblico personalizzato. Una rappresentazione JSON dei contenuti di CustomAudience come parzialmente definita dal chiamante API è inclusa nella richiesta GET a fetchUri in un'intestazione speciale X-CUSTOM-AUDIENCE-DATA. La dimensione della forma serializzata dei dati specificati per il segmento di pubblico personalizzato è limitata a 8 kB. Se le dimensioni superano la chiamata API fetchAndJoinCustomAudience non va a buon fine.

L'assenza di un controllo k-anon ti consente di utilizzare fetchUri per la verifica dell'acquirente e per attivare la condivisione di 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 provenga 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 query a fetchUri. In questo modo, l'acquirente può controllare 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 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 che vengono creati siano creati per suo conto.
  • La proposta dell'API Protected Audience non specifica un formato per il token di verifica né come l'acquirente trasferisce il token di verifica 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.

Uscire da un segmento di pubblico personalizzato

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

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

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

Controllo utente

• La proposta intende dare agli utenti visibilità all'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 personalizzati associati alle app e impedisce alle app di entrare a far parte di nuovi segmenti di pubblico personalizzati.
• Gli utenti hanno la possibilità di reimpostare completamente l'API Protected Audience. Quando ciò accade, 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 funziona.

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

Aggiornamenti programmati

Le soluzioni descritte in precedenza richiedono che l'app o l'SDK di 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 facilitare questa operazione, le tecnologie pubblicitarie possono chiamare l'API scheduleCustomAudienceUpdate(). Questa API consente al chiamante di specificare un ritardo per l'esecuzione della chiamata API, fornendo così più tempo alla tecnologia pubblicitaria che risponde per elaborare gli eventi a livello di app e determinare a quali Protected Audience l'utente deve partecipare o da quali 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 posticipato da eseguire con la piattaforma. Dopo il ritardo specificato, un job in background verrà eseguito periodicamente e invierà le richieste. Il 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 di aggiornamento. La richiesta GET prevede la restituzione di un oggetto JSON contenente un elenco di oggetti customAudience.
• DelayTime: tempo che indica il ritardo tra il momento in cui viene effettuata la chiamata API scheduleCustomAudienceUpdate() e la pianificazione dell'aggiornamento.

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

  • In questo modo, l'API rimane compatibile con l'API fetchAndJoinCustomAudience() che consente una condivisione simile delle informazioni.

• ShouldReplacePendingUpdates: valore booleano che determina se gli aggiornamenti pianificati in attesa devono essere annullati e sostituiti con l'aggiornamento descritto nell'ScheduleCustomAudienceUpdateRequest corrente. Se questa opzione è impostata su false e nella stessa app sono ancora in attesa aggiornamenti richiesti in precedenza per lo stesso acquirente, una chiamata a scheduleCustomAudienceUpdate con questo 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 tecnologia pubblicitaria di terze parti le autorizzazioni 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 propri segmenti di pubblico personalizzati:

• Le tecnologie pubblicitarie si registrano a Privacy Sandbox e forniscono un dominio eTLD+1 che corrisponde a tutti gli URL di un segmento di pubblico personalizzato.
• Le tecnologie pubblicitarie possono collaborare con app o SDK per fornire token di verifica che vengono utilizzati per verificare la creazione di un segmento di pubblico personalizzato. Quando questo processo viene delegato a un partner, la creazione di segmenti di pubblico personalizzati può essere configurata in modo da richiedere la conferma da parte della tecnologia pubblicitaria.
• Una 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 per le 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 concesse in base alla tecnologia pubblicitaria.

Risposta di annunci e metadati candidati

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

• Metadati:metadati degli annunci specifici per la tecnologia pubblicitaria lato acquirente. Ad esempio, potrebbero essere incluse informazioni sulla campagna pubblicitaria e sui criteri di targeting, come località e lingua.
• URL di rendering:endpoint per il rendering della creatività dell'annuncio.
• Filtro:informazioni facoltative necessarie per l'API Protected Audience per filtrare gli annunci in base ai dati on-device. 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 coordina l'esecuzione dell'asta per le piattaforme di tecnologia pubblicitaria.

Oggi le piattaforme di tecnologie pubblicitarie in genere eseguono 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 lo scenario di utilizzo del remarketing, gli annunci candidati verranno recuperati fuori banda (ovvero non nel contesto in cui verranno mostrati gli annunci). Le piattaforme di tecnologia pubblicitaria dovranno prepararsi a implementare ed eseguire sul dispositivo alcune parti della logica attuale di asta e selezione degli annunci. Le piattaforme di tecnologia pubblicitaria possono prendere in considerazione le seguenti modifiche al flusso di lavoro di selezione degli annunci:

• Senza le informazioni sui pacchetti installati disponibili sul server, le piattaforme di tecnologia pubblicitaria potrebbero voler inviare più annunci contestuali al dispositivo e richiamare il flusso di lavoro di selezione degli annunci per attivare il filtro basato sull'installazione di app al fine di massimizzare le possibilità di mostrare un annuncio pertinente.
• Poiché gli annunci di remarketing vengono recuperati fuori banda, i modelli di offerta attuali potrebbero dover essere aggiornati. Le piattaforme di tecnologia pubblicitaria potrebbero voler creare sottomodelli di offerta (l'implementazione potrebbe basarsi su un pattern chiamato modello a due torri) che possono funzionare separatamente su funzionalità degli annunci e indicatori contestuali e combinare gli output dei sottomodelli sul dispositivo per prevedere le offerte. Può trarre vantaggio sia dalle aste lato server sia dalle aste per qualsiasi opportunità pubblicitaria.

Questo approccio consente di utilizzare i dati sulle interazioni con le app dell'utente per informare 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 sul dispositivo del codice JavaScript fornito dalla tecnologia pubblicitaria 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 acquisto in base all'endpoint URL pubblico definito dai metadati "URL logica di offerta" del segmento di pubblico personalizzato. L'endpoint URL per il codice di decisione lato vendite verrà passato anche come input per avviare il flusso di lavoro di selezione degli annunci.

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

Avviare il flusso di lavoro di selezione degli annunci

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

• Venditore: identificatore della piattaforma pubblicitaria lato vendita, nel formato eTLD+1
• URL della logica decisionale: quando viene avviata un'asta dell'annuncio, la piattaforma utilizza questo URL per recuperare il codice JavaScript dalla piattaforma lato vendite per 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 ecc.).
• Indicatori del venditore: indicatori specifici della Supply-Side Platform.
• URL indicatori di valutazione attendibili: URL endpoint dell'indicatore attendibile lato vendite da cui è possibile recuperare informazioni in tempo reale specifiche per la creatività.
• Indicatori per acquirente: le demand side 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 della piattaforma di tecnologia pubblicitaria che avvia il flusso di lavoro di selezione degli annunci definendo prima AdSelectionConfig e poi richiamando selectAds per ottenere l'annuncio vincente:

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

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

Logica di offerta lato acquisti

La logica di offerta viene in genere fornita dalle piattaforme lato acquirente. Lo scopo del codice è determinare le offerte per gli annunci candidati. Potrebbe applicare una logica aziendale 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 seguente firma della funzione:

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 richiamerà questa funzione per tutti gli annunci (contestuali o di remarketing) in sequenza. Se sono presenti 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. Questo sarà un annuncio di un segmento di pubblico personalizzato idoneo
• Indicatori asta: indicatori specifici della piattaforma lato vendita.
• Indicatori per acquirente: le demand side 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 ad tech si basano su dati in tempo reale per informare il recupero e l'assegnazione del punteggio degli annunci. Ad esempio, una campagna pubblicitaria potrebbe esaurire il budget e deve interrompere immediatamente la pubblicazione. Una tecnologia pubblicitaria può definire un endpoint URL da cui recuperare questi dati in tempo reale e l'insieme di chiavi per cui deve essere eseguita la ricerca in tempo reale. Il server gestito della piattaforma di tecnologia pubblicitaria che gestisce questa richiesta sarà un server attendibile gestito dalla piattaforma di tecnologia pubblicitaria.
• Segnali contestuali: possono includere timestamp approssimativi o informazioni sulla posizione approssimativa oppure il costo per clic sull'annuncio.
• Indicatori utente: potrebbero includere informazioni come i 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 stocasticamente a 8 bit per motivi di privacy. Il valore arrotondato di adCost viene quindi passato al parametro contextual_signals in reportWin durante la generazione di report sulle impressioni.

Logica di filtraggio lato acquisti

Le piattaforme buy-side potranno filtrare gli annunci in base a ulteriori indicatori sul dispositivo disponibili durante la fase di selezione degli annunci. Ad esempio, le piattaforme di tecnologia pubblicitaria 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 filtraggio lato acquisti può essere implementata come parte della logica di offerta restituendo un valore di offerta pari a 0 per un determinato annuncio.

Inoltre, le piattaforme buy-side potranno segnalare che un determinato annuncio deve essere filtrato in base a indicatori on-device aggiuntivi disponibili per Protected Audience e che non lasceranno il dispositivo. Man mano che consolidiamo i progetti di logica di filtraggio aggiuntiva, le piattaforme lato acquirente seguiranno la stessa struttura per segnalare che il filtraggio deve essere eseguito.

Logica di assegnazione del punteggio lato vendite

La logica di assegnazione del 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 applicare 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 seguente firma della funzione:

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; output della funzione generateBid().
• Offerta: l'importo dell'offerta restituito dalla funzione generateBid().
• Auction config (Configurazione asta): parametro di input per il metodo selectAds().
• Indicatori di punteggio attendibili: le piattaforme di ad tech si basano su dati in tempo reale per informare il filtro e l'assegnazione del punteggio degli annunci. Ad esempio, un editore di app può bloccare una campagna pubblicitaria in modo che non mostri annunci nell'app. Questi dati vengono recuperati dal parametro URL dei segnali di punteggio attendibili della configurazione dell'asta. Il server che gestisce questa richiesta deve essere un server attendibile gestito dalla tecnologia pubblicitaria.
• Segnale contestuale: può includere timestamp approssimativi o informazioni sulla posizione approssimative.
• Indicatore utente: può includere informazioni come lo store che ha avviato l'installazione dell'app.
• Indicatore del segmento di pubblico personalizzato: se l'annuncio a cui viene assegnato un punteggio proviene da un segmento di pubblico personalizzato sul dispositivo, questo conterrà informazioni come il lettore e il nome del segmento di pubblico personalizzato.

Runtime del codice di selezione degli annunci

Nella proposta, il sistema recupererà il codice dell'asta fornito dalla piattaforma di tecnologia pubblicitaria da endpoint URL configurabili e lo eseguirà sul dispositivo. Date le limitazioni delle risorse sui dispositivi mobili, il codice dell'asta deve rispettare le seguenti linee guida:

• L'esecuzione del codice deve terminare in un periodo di tempo predefinito. Questo limite verrà applicato uniformemente 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 dell'utente come le origini di installazione delle app, il runtime non fornirà l'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. 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 viene considerato il vincitore dell'asta. In questa proposta iniziale, l'annuncio vincente viene trasmesso all'SDK per il rendering.

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

Report su impressioni ed eventi

Una volta eseguito il rendering dell'annuncio, l'impressione vincente può essere segnalata alle piattaforme lato acquisti e lato vendite partecipanti. In questo modo, acquirenti e venditori possono includere informazioni dell'asta, come l'offerta o il nome del segmento di pubblico personalizzato, nel report sull'impressione vincente. Inoltre, la Sell-Side Platform e la piattaforma lato acquisti vincente sono idonee a ricevere report aggiuntivi a livello di evento sull'annuncio vincente. Ciò consente di includere informazioni sull'asta (offerta, nome del segmento di pubblico personalizzato e così via) con clic, visualizzazioni e altri eventi pubblicitari. La piattaforma richiama la logica di generazione dei report in questo ordine:

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

In questo modo, le piattaforme buy-side e sell-side possono inviare informazioni importanti sul dispositivo ai server per attivare funzionalità come il budget in tempo reale, gli aggiornamenti del modello di offerta e flussi di lavoro di fatturazione accurati. Questo supporto per la generazione di report sulle impressioni è complementare all'API Attribution Reporting.

Per supportare i report sugli eventi sono necessari due passaggi: il JavaScript lato venditore e lato acquirente deve registrare per quale evento deve ricevere i report sugli eventi e il lato venditore è responsabile della generazione di report sulle informazioni a livello di evento.

Protected Audience fornisce un meccanismo per abbonarsi a eventi futuri correlati a un'asta vincente registrando beacon. In una funzione JavaScript reportResult() di un venditore, le Sell-Side Platform possono registrare i beacon utilizzando la funzione registerAdBeacon() della piattaforma. Allo stesso modo, le piattaforme buy-side possono chiamare il metodo registerAdBeacon() dalla funzione JavaScript reportWin().

registerAdBeacon(beacons)

Input:

• event_key: una stringa che indica il tipo di interazione per cui registrarsi. Questo viene utilizzato come chiave per cercare l'endpoint che la piattaforma pinga durante la comunicazione dei risultati dell'asta.
• reporting_url: l'URL di proprietà della piattaforma di tecnologia pubblicitaria per la gestione dell'evento.

Le chiavi evento sono identificatori stringa di proprietà dell'SDK lato vendite responsabile della generazione di report sui risultati dell'asta. Per effettuare un callback, le tecnologie pubblicitarie registrano i beacon con chiavi che corrispondono a quelle utilizzate dal lato vendite quando vengono segnalati gli eventi. Questi non devono essere k-anonimi, 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 lato venditore 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 lato vendite

La piattaforma richiama la funzione JavaScript reportResult() nel codice fornito dal lato offerta scaricato dal parametro URL della 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 la riuscita, qualsiasi altro valore per l'errore.
• URL di reporting: la piattaforma richiama questo URL restituito dalla funzione.
• Signals for Buyer: un oggetto JSON da trasmettere alla funzione reportWin dell'acquirente.

Il lato dell'offerta può codificare indicatori pertinenti nell'URL di reporting per ottenere ulteriori informazioni sull'asta e sull'annuncio vincente. Ad esempio, può includere indicatori come questi:

• 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 la supply side e la demand side, la piattaforma trasmette questo valore restituito come parametro di input al codice di generazione dei report della demand side.

Report lato acquirente

La piattaforma richiama la funzione JavaScript reportWin() nel codice fornito dal lato della 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 lato acquisto deve trasmettere all'URL di reporting può provenire da questo dato.
• signals_for_buyer è l'output di reportResult lato vendite. In questo modo, la Sell-Side Platform ha l'opportunità di condividere i dati con la Buy-Side Platform a fini di reportistica.
• contextual_signals contiene informazioni come il nome dell'app e custom_audience_signals contiene le informazioni sul pubblico personalizzato. In futuro potrebbero essere aggiunte altre informazioni.

Output:

• Stato: 0 per la riuscita, qualsiasi altro valore per l'errore.
• URL di reporting: la piattaforma richiama questo URL restituito dalla funzione.

Segnalazione di eventi

La generazione di report sugli eventi è possibile solo dopo il completamento della generazione di report sulle impressioni per l'asta. L'SDK lato vendite è responsabile della generazione di report sugli eventi. La piattaforma espone un'API che accetta un ReportEventRequest che specifica l'asta eseguita di recente, la chiave evento segnalata, i dati associati a questa chiave, se il report deve essere inviato all'acquirente o al venditore (o a entrambi) e un evento di input facoltativo per gli eventi annuncio. Il client definisce la chiave dell'evento e la raccolta di dati da 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 recuperato da AdSelectionOutcome.
• event_key è una stringa definita dal lato vendite che descrive l'evento di interazione.
• event_data è una stringa che rappresenta i dati associati a event_key
• reporting_destinations è una maschera di bit impostata utilizzando i flag forniti dalla piattaforma. Può essere uno dei seguenti: FLAG_REPORTING_DESTINATION_SELLER o FLAG_REPORTING_DESTINATION_BUYER, o entrambi.
• input_event (facoltativo) viene utilizzato per l'integrazione con l'API Attribution Reporting. È un oggetto InputEvent (per un evento di clic) o null (per un evento di visualizzazione). Per ulteriori dettagli su questo parametro, consulta Integrazione dell'API Attribution Reporting.

Dopo che l'SDK lato venditore richiama 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 viene trovata una corrispondenza, la piattaforma invia event_data al reporting_url associato. L'content type della richiesta è testo normale con il corpo che è l'event_data. Questa richiesta viene effettuata nel miglior modo possibile e non va a buon fine in caso di errore di rete, risposta di errore del server o se non sono state trovate chiavi corrispondenti.

Integrazione dell'API Attribution Reporting

Per supportare gli acquirenti che partecipano a un'asta Protected Audience, forniamo funzionalità cross-API per le API Protected Audience e Attribution Reporting (ARA). Questa funzionalità consente alle tecnologie pubblicitarie 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 tra API, le ad tech possono:

• Crea una mappa chiave-valore degli URI da utilizzare per 1) la generazione di report sull'interazione con gli annunci e 2) la registrazione delle sorgenti.
• Includere i dati dell'asta Protected Audience nel mapping delle chiavi lato origine per i report di riepilogo aggregati (utilizzando l'API Attribution Reporting). Per ulteriori informazioni, consulta la proposta di progettazione di ARA.

Quando un utente visualizza o fa clic su un annuncio:

• L'URL utilizzato per segnalare le interazioni con questi eventi utilizzando Protected Audience fornirà i dati necessari all'acquirente da utilizzare 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 della campagna.

Attivazione della registrazione delle origini

reportEvent() accetterà un nuovo parametro facoltativo InputEvent. Gli acquirenti vincenti che registrano i beacon pubblicitari 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 reporting sugli eventi inviate da reportEvent(). Qualsiasi risposta con intestazioni ARA appropriate verrà analizzata nello stesso modo in cui verrebbe analizzata qualsiasi altra risposta di registrazione di un'origine ARA normale. Consulta la spiegazione dell'API Attribution Reporting per scoprire come registrare un URL di origine.

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

Tieni presente che il eventData post-asta potrebbe contenere informazioni sensibili, pertanto la piattaforma elimina il eventData nelle richieste di registrazione dell'origine reindirizzata.

Esempio di report sul coinvolgimento e sulle conversioni

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

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 tempo di conversione, i dati dell'annuncio sottoposto a rendering vengono inviati anche con lo stesso ID univoco. In un secondo momento, 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 risposta all'offerta di offerta in tempo reale (RTB) programmatica. L'ID può essere impostato come variabile, ad esempio auctionId. L'ID viene trasmesso come perBuyerSignals in auctionConfig e diventa disponibile nella logica di offerta dell'acquirente.

1. Durante l'esecuzione di reportWin, l'acquirente può registrare un beacon annuncio da attivare durante il tempo di 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 trasmettere i dati a livello di evento. La piattaforma eseguirà il ping dell'URL del beacon pubblicitario registrato dell'acquirente che corrisponde all'reportEvent() attivato.
3. L'acquirente registrerà l'annuncio con l'API Attribution Reporting API rispondendo alle richieste di beacon annuncio 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.

Al termine di questo processo, l'acquirente avrà un report asta, un report interazioni e un report 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 sia al venditore.

Server attendibile 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 all'annuncio devono essere selezionati per l'asta. Le piattaforme buy-side e sell-side potranno ottenere queste informazioni dai server che gestiscono. Per ridurre al minimo la divulgazione di informazioni sensibili utilizzando questi server, la proposta prevede le seguenti limitazioni:

• I comportamenti di questi server, descritti più avanti in questa sezione, non comportano la divulgazione di informazioni sugli utenti.
• I server non creerebbero profili pseudonimi in base ai dati visualizzati, ovvero dovrebbero essere "attendibili".

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

Questo è un URL di esempio per recuperare i dati di offerta attendibili, in base ai metadati del segnale di offerta attendibile 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, ecc. e i cui valori saranno resi disponibili alle funzioni di offerta dell'acquirente.

Lato vendite: in modo simile a questo flusso di acquisto, il lato vendite 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 preoccupazioni relative alla sicurezza del brand. Queste informazioni possono essere recuperate e rese disponibili alla logica dell'asta lato venditore. Analogamente alla ricerca del server attendibile lato acquisto, anche la ricerca del server attendibile lato vendita avviene tramite un recupero HTTP. L'URL è composto aggiungendo l'URL dei segnali di valutazione attendibili agli URL di rendering delle creatività per cui devono essere recuperati i dati.

Di seguito è riportato un URL di esempio per recuperare 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 funzionerebbero in modo affidabile per offrire diversi vantaggi in termini di sicurezza e privacy:

• Il valore restituito dal server per ogni chiave può essere considerato basato solo su quella chiave.
• Il server non esegue la registrazione 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 di offerta da qualsiasi server, incluso uno gestito in autonomia. Tuttavia, nella versione di rilascio, la richiesta verrà inviata solo a un server attendibile di tipo chiave-valore.

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