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

Inviare feedback

Aggiornamenti recenti

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

Con Protected Audience puoi:

  • Gestisci i segmenti di pubblico personalizzati in base alle azioni precedenti degli utenti.
  • Avvia aste on-device con il supporto della mediazione a cascata o singolo venditore.
  • Esercitati con i report sulle impressioni dopo la selezione degli annunci.

Per iniziare, leggi la guida per gli sviluppatori di Protected Audience. Il tuo feedback è importante per noi durante lo sviluppo di Protected Audience.

Sequenza temporale

Nei prossimi mesi lanceremo nuove funzionalità. Le date di uscita esatte variano a seconda della funzionalità e questa tabella verrà aggiornata con i link alla documentazione non appena disponibile.

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

Panoramica

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

Oggi, questi casi d'uso in genere vengono 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 annunci pertinenti sui propri server.

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

  1. API Custom Audience: si concentra 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 segmento di pubblico e a metadati arbitrali, come gli indicatori di offerta. Queste informazioni possono essere utilizzate per definire le offerte degli inserzionisti, i filtri degli annunci e il rendering.
  2. API Ad Selection: fornisce un framework che orchestra i flussi di lavoro delle piattaforme di tecnologia pubblicitaria che sfruttano gli indicatori sul dispositivo per determinare un annuncio "vincente" considerando gli annunci candidati archiviati localmente ed eseguendo ulteriori elaborazioni sugli annunci candidati che una piattaforma di tecnologia pubblicitaria restituisce al dispositivo.
Grafico di flusso che mostra il flusso di lavoro personalizzato per la gestione dei segmenti di pubblico e la selezione degli annunci in Privacy Sandbox su Android.

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

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

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

  3. L'SDK dell'app di pubblicazione degli annunci o della piattaforma di tecnologia pubblicitaria mostra l'annuncio selezionato.

  4. La piattaforma semplifica 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 ad tech possono personalizzare in base alle esigenze di reporting.

Ottenere l'accesso a Protected Audience sulle API Android

Le piattaforme di ad tech devono registrarsi per accedere all'API Protected Audience. Per ulteriori informazioni, consulta la pagina Registrazione 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 determinato segmento, ad esempio qualcuno che ha "lasciato articoli nel carrello" o "ha completato i livelli per principianti" di un gioco. La piattaforma gestisce e archivia le informazioni sul pubblico localmente sul dispositivo e non mostra a quali segmenti di pubblico personalizzati si trova l'utente. I segmenti di pubblico personalizzati sono distinti dai gruppi di interesse di Protected Audience di Chrome e non possono essere condivisi tra web e app. Ciò consente di limitare la condivisione delle informazioni degli utenti.

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

Metadati dei segmenti di pubblico personalizzati

Ogni segmento di pubblico personalizzato contiene i seguenti metadati:

  • Proprietario: nome del pacchetto dell'app del proprietario. È impostato implicitamente sul nome del pacchetto dell'app del chiamante.
  • Acquirente: rete pubblicitaria dell'acquirente che gestisce gli annunci per questo segmento di pubblico personalizzato. L'acquirente rappresenta anche la parte che può accedere al segmento di pubblico personalizzato e recuperare le informazioni pertinenti sull'annuncio. L'acquirente viene specificato in base al formato eTLD+1.
  • Nome: un nome o un identificatore arbitrario per il segmento di pubblico personalizzato, ad esempio un utente con "utenti che hanno abbandonato il carrello degli acquisti". Questo attributo può essere utilizzato, ad esempio, come uno dei criteri di targeting nelle campagne pubblicitarie dell'inserzionista o come stringa di query nell'URL per recuperare il codice di offerta.
  • Ora di attivazione e ora di scadenza: questi campi definiscono l'intervallo temporale in cui entrerà in vigore il segmento di pubblico personalizzato. La piattaforma utilizza queste informazioni per ritirare l'appartenenza a un pubblico personalizzato. La scadenza non può superare una finestra di durata massima per limitare la durata di un segmento di pubblico personalizzato.
  • URL di aggiornamento giornaliero: l'URL utilizzato dalla piattaforma per recuperare annunci candidati e altri metadati definiti nei campi "Indicatori offerte per l'utente" e "Indicatori di offerta attendibili" su base ricorrente. Per ulteriori dettagli, consulta la sezione su come recuperare annunci candidati per segmenti di pubblico personalizzati.
  • Indicatori di offerta per l'utente: indicatori specifici della piattaforma per la tecnologia pubblicitaria per qualsiasi offerta di annunci di remarketing. Esempi di indicatori includono: la posizione approssimativa dell'utente, le impostazioni internazionali preferite e così via.
  • Dati sulle offerte attendibili: le piattaforme di ad tech si basano su dati in tempo reale per raccogliere e valutare gli annunci. Ad esempio, un annuncio potrebbe esaurire il budget e la pubblicazione deve essere interrotta immediatamente. Un ad-tech 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 che gestisce questa richiesta sarà un server attendibile gestito dalla piattaforma ad tech.
  • URL logica di offerta: l'URL utilizzato dalla piattaforma per recuperare il codice di offerta dalla Demand-Side Platform. La piattaforma esegue questo passaggio quando viene avviata un'asta dell'annuncio.
  • Annunci:un elenco di annunci candidati per il segmento di pubblico personalizzato. Sono inclusi metadati degli annunci specifici della piattaforma di tecnologia pubblicitaria e un URL per eseguire il rendering dell'annuncio. Quando viene avviata un'asta per il segmento di pubblico personalizzato, viene preso in considerazione questo elenco di metadati dell'annuncio. Se possibile, questo elenco di annunci verrà aggiornato utilizzando l'endpoint URL di aggiornamento giornaliero. A causa della carenza di risorse sui dispositivi mobili, esiste un limite al numero di annunci che possono essere archiviati in un segmento di pubblico personalizzato.

Delega segmenti di pubblico personalizzati

La definizione e la configurazione dei segmenti di pubblico personalizzati tradizionali in genere si basano su tecnologie lato server e integrazioni basate su tecnologie pubblicitarie 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, i tecnici pubblicitari degli acquirenti che non hanno una presenza SDK nelle app devono collaborare con quelli 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. Questa procedura è chiamata delega dei segmenti di pubblico personalizzati. Per configurare la delega per i segmenti di pubblico personalizzati:

Entrare a far parte di un segmento di pubblico personalizzato

Puoi entrare in un segmento di pubblico personalizzato in due modi:

joinCustomAudience()

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

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

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

fetchAndJoinCustomAudience()

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

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

fetchAndJoinCustomAudience(fetchRequest);

L'endpoint URL, di proprietà dell'acquirente, risponde con un oggetto JSON CustomAudience nel corpo della risposta. I campi dell'acquirente e del 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 dell'app effettuati da joinCustomAudience() e non può essere modificata dalla risposta di recupero. Il proprietario CustomAudience è il nome del pacchetto dell'applicazione chiamante. Non esiste nessun'altra convalida di fetchUri oltre al controllo eTLD+1 e, in particolare, non esiste un controllo k-anon. L'API fetchAndJoinCustomAudience() invia una richiesta GET HTTP a fetchUri e prevede un oggetto JSON che rappresenti il segmento di pubblico personalizzato. Alla risposta vengono applicati gli stessi vincoli obbligatori e facoltativi e gli stessi valori predefiniti per i campi degli oggetti pubblico personalizzati. Scopri di più sui requisiti e sulle limitazioni attuali nella nostra Guida per gli sviluppatori.

Qualsiasi risposta di errore HTTP da parte dell'acquirente provoca un errore di fetchAndJoinCustomAudience. In particolare, una risposta dello 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 dell'API responsabile di riprovare 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 di transito 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 in alto. Se impostati nella richiesta, questi valori non possono essere sovrascritti dalla risposta dell'acquirente ricevuta dalla piattaforma; l'API Protected Audience ignora i campi nella risposta. Se non sono impostati nella richiesta, devono essere impostati nella risposta, poiché questi campi sono obbligatori per creare un segmento di pubblico personalizzato. Una rappresentazione JSON dei contenuti di CustomAudience, parzialmente definita dal chiamante dell'API, è inclusa nella richiesta GET a fetchUri in un'intestazione speciale X-CUSTOM-AUDIENCE-DATA. La dimensione del formato serializzato dei dati specificati per il segmento di pubblico personalizzato è limitata a 8 kB. Se la dimensione viene superata, la chiamata API fetchAndJoinCustomAudience non va a buon fine.

In assenza di un controllo k-anon, puoi utilizzare fetchUri per la verifica dell'acquirente e per attivare la condivisione delle informazioni tra acquirente e SDK. Per facilitare la verifica dei segmenti di pubblico personalizzati, l'acquirente può fornire un token di verifica. L'SDK sul dispositivo deve includere questo token in fetchUri affinché l'endpoint ospitato dall'acquirente possa recuperare i contenuti del segmento di pubblico personalizzato e utilizzare il token di verifica per verificare che l'operazione fetchAndJoinCustomAudience() corrisponda all'acquirente e provenga da un partner sul dispositivo 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.

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 creati vengono eseguiti per suo conto.
    • La proposta dell'API Protected Audience non specifica né un formato per il token di verifica né il modo in cui l'acquirente trasferisce il token 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 illustrato nello snippet di codice illustrativo riportato di seguito:

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

Per contribuire a preservare 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. Devi determinare il valore predefinito. Il proprietario può sostituire questo valore predefinito.

Controllo utenti

  • La proposta intende dare agli utenti visibilità sull'elenco delle app installate che hanno creato almeno un segmento di pubblico personalizzato
  • Gli utenti possono rimuovere app da questo elenco. La rimozione cancella tutti i segmenti di pubblico personalizzati associati alle app e impedisce che queste si uniscano a nuovi segmenti di pubblico personalizzati.
  • Gli utenti hanno la possibilità di reimpostare completamente l'API Protected Audience. In questo caso, 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 va a buon fine.

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

Aggiornamenti programmati

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

Per facilitare questa operazione, il team ad tech può chiamare l'API scheduleCustomAudienceUpdate(). Questa API consente al chiamante di specificare un ritardo nel momento in cui deve essere effettuata la chiamata API, fornendo quindi tempo aggiuntivo affinché la tecnologia pubblicitaria che risponda 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 delayedCustomUpdates List of Delayed Update events that trigger a
* call to DSP endpoint provided inside the DelayedCustomUpdate object
*/

public void scheduleCustomAudienceUpdates(
    @NonNull DelayedCustomUpdate delayedCustomAudienceUpdate,
    @NonNull @CallBackExecutor Executor executor,
    @NonNull AdServicesOutcomeReceiver<Object, Exception> receiver)

DelayedCustomAudienceUpdate

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

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

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

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

  • UpdateUri: endpoint URI a cui verrebbe inviata una chiamata GET per recuperare l'aggiornamento. L'identità dell'acquirente viene dedotta intrinsecamente dall'eTLD+1, 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 dall'esecuzione della chiamata API scheduleCustomAudienceUpdate() per pianificare l'aggiornamento.

  • PartialCustomAudience: l'API consente inoltre all'SDK sul dispositivo di inviare un elenco di segmenti di pubblico personalizzati parzialmente creati. Ciò consente agli SDK in-app di svolgere il duplice ruolo, dal controllo completo al controllo parziale sulla gestione dei segmenti di pubblico personalizzati in base alla loro partnership con le DSP.

    • Inoltre, l'API è compatibile con l'API fetchAndJoinCustomAudience(), che consente la condivisione di informazioni simili.

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à è ancora in fase di sviluppo e i dettagli verranno inclusi in un aggiornamento successivo.

Controllo della piattaforma ad tech

Questa proposta descrive i modi in cui i tecnici pubblicitari possono controllare i propri segmenti di pubblico personalizzati:

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

Annunci candidati e risposta dei metadati

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

  • Metadati: metadati degli annunci lato acquisti, specifici per la tecnologia pubblicitaria. Potrebbero essere incluse, ad esempio, informazioni sulla campagna pubblicitaria e criteri di targeting come località e lingua.
  • URL di rendering: endpoint per il rendering della creatività dell'annuncio.
  • Filtro:informazioni facoltative necessarie all'API Protected Audience per filtrare gli annunci in base ai dati sul dispositivo. Per ulteriori dettagli, leggi la sezione sulla logica di filtro lato acquisti.

Flusso di lavoro per la selezione degli annunci

Questa proposta mira a migliorare la privacy introducendo l'API di selezione degli annunci, che orchestra l'esecuzione dell'asta per le piattaforme di tecnologia pubblicitaria.

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

  • Senza le informazioni sui pacchetti installati disponibili 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 basato sull'installazione di app al fine di massimizzare le probabilità di mostrare un annuncio pertinente.
  • Poiché gli annunci di remarketing vengono recuperati fuori banda, potrebbe essere necessario aggiornare i modelli di offerta correnti. Le piattaforme ad tech potrebbero voler creare sottomodelli di offerta (l'implementazione potrebbe essere basata su un pattern chiamato modello a due torri) in grado di lavorare separatamente sulle funzionalità pubblicitarie e sugli indicatori di contesto e combinare gli output del modello secondario sul dispositivo per prevedere le offerte. Questo può trarre vantaggio sia dalle aste lato server sia dalle aste per ogni opportunità pubblicitaria.

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

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

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

  1. Esecuzione della logica delle offerte lato acquisti
  2. Filtro ed elaborazione degli annunci lato acquisti
  3. Esecuzione della logica decisionale lato vendite

Per la selezione di annunci che prevede segmenti di pubblico personalizzati, la piattaforma recupererà il codice JavaScript fornito dal lato acquisto in base all'endpoint dell'URL pubblico definito dai metadati "URL logica di offerta" del segmento di pubblico personalizzato. L'endpoint URL per il codice decisionale lato vendite verrà inoltre trasmesso come input per avviare il flusso di lavoro di selezione degli annunci.

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

Avvia flusso di lavoro di selezione degli annunci

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

  • Venditore: identificatore della piattaforma pubblicitaria lato vendite, secondo il formato eTLD+1
  • URL logica decisionale: quando viene avviata un'asta dell'annuncio, la piattaforma utilizza questo URL per recuperare il codice JavaScript dalla Sell-Side Platform ed assegnare un punteggio a un annuncio vincente.
  • Acquirenti di segmenti di pubblico personalizzati: un elenco di piattaforme lato acquisti con domanda personalizzata basata sul pubblico 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: fornisci indicatori specifici della piattaforma laterale.
  • URL indicatori di punteggio attendibili: endpoint URL dell'indicatore attendibile lato vendite da cui è possibile recuperare informazioni in tempo reale specifiche della creatività.
  • Indicatori per acquirente: le parti della domanda partecipanti possono utilizzare questo parametro per fornire input per l'asta. Ad esempio, questo parametro può includere informazioni contestuali complete utili per determinare le offerte.

Il seguente snippet di codice illustrativo mostra l'SDK di una piattaforma di tecnologia pubblicitaria che avvia il flusso di lavoro di selezione degli annunci definendo innanzitutto 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

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

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

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

Il metodo generateBid() restituisce l'importo 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 provider.

La funzione prevede i seguenti parametri:

  • Annuncio: l'annuncio considerato dal codice delle offerte lato acquisti. Sarà un annuncio di un segmento di pubblico personalizzato idoneo
  • Indicatori d'asta: indicatori lato vendite e specifici per piattaforma.
  • Indicatori per acquirente: le parti della domanda partecipanti possono utilizzare questo parametro per fornire input per l'asta. Ad esempio, questo parametro può includere informazioni contestuali complete utili per determinare le offerte.
  • Indicatori di offerte affidabili: le piattaforme di ad tech si basano su dati in tempo reale per informare il recupero e il punteggio degli annunci. Ad esempio, una campagna pubblicitaria potrebbe esaurire il budget e deve essere interrotta immediatamente. Un Ad-Tech può definire un endpoint URL da cui è possibile 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 ad tech che soddisfa questa richiesta sarà un server affidabile gestito dalla piattaforma ad tech.
  • Indicatori di contesto: possono includere timestamp approssimativi o informazioni sulla posizione approssimative oppure il costo per clic sull'annuncio.
  • Indicatori utente: potrebbero includere informazioni quali le informazioni disponibili sui pacchetti installati.

Costo dell'annuncio

Oltre all'offerta, le piattaforme lato acquisti hanno la possibilità di restituire il costo per clic come parte 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 si aggiudica l'asta, adCost viene arrotondato stocasticamente a 8 bit per motivi di privacy. Il valore arrotondato di adCost viene quindi trasmesso al parametro contextual_signals in reportWin durante i report sulle impressioni.

Logica di filtro lato acquisti

Le piattaforme lato acquisti potranno filtrare gli annunci in base a ulteriori indicatori on-device disponibili durante la fase di selezione degli annunci. Ad esempio, qui le piattaforme di tecnologie possono implementare la quota limite. Se sono presenti più provider di filtro, il sistema non garantisce la sequenza di esecuzione tra i provider.

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

Inoltre, le piattaforme lato acquisti potranno segnalare che un determinato annuncio deve essere filtrato in base a ulteriori indicatori sul dispositivo disponibili per Protected Audience e che non escono dal dispositivo. Man mano che consolidiamo i progetti di una logica di filtro aggiuntiva, le piattaforme lato acquisti seguiranno questa stessa struttura per segnalare che il filtro dovrebbe avvenire.

Logica di punteggio lato vendite

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

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

La funzione prevede i seguenti parametri:

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

Tempo di esecuzione del codice di selezione degli annunci

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

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

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

Linguaggio di programmazione

Il codice asta fornito dalla piattaforma per la tecnologia pubblicitaria deve essere scritto in JavaScript. Ciò consentirebbe alle piattaforme delle tecnologie pubblicitarie, ad esempio, di condividere il codice di offerta tra le piattaforme che supportano Privacy Sandbox.

Rendering dell'annuncio vincente

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

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

Report sulle impressioni e sugli eventi

Una volta visualizzato l'annuncio, l'impressione vincente può essere riportata alle piattaforme lato acquisti e lato vendite partecipanti. In questo modo acquirenti e venditori possono includere informazioni provenienti dall'asta, come il nome dell'offerta o del segmento di pubblico personalizzato, nel report sulle impressioni vincenti. Inoltre, la Sell-Side Platform e gli acquirenti vincenti 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 relativi agli annunci. La piattaforma richiama la logica di reporting in questo ordine:

  1. Report lato vendite.
  2. Report lato acquisti.

In questo modo, le piattaforme lato acquisti e lato vendite possono inviare importanti informazioni sul dispositivo ai server per abilitare funzionalità come la definizione del budget 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.

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

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

registerAdBeacon(beacons)

Input:

  • event_key: una stringa che indica il tipo di interazione da utilizzare. Viene utilizzato come chiave per cercare il punto finale segnalato dalla piattaforma durante i report sui risultati dell'asta.
  • reporting_url: l'URL di proprietà della piattaforma ad tech per la gestione dell'evento.

Le chiavi evento sono identificatori di stringa di proprietà dell'SDK lato vendite responsabile della generazione di report sui risultati dell'asta. Affinché venga eseguito il callback, il team ad tech registra i beacon con chiavi corrispondenti a quelle utilizzate dal lato vendite quando segnalano gli eventi. Non è necessario che siano k-anonymous, anche se esistono dei limiti alla quantità e alla lunghezza delle chiavi che è possibile registrare per un determinato segmento di pubblico personalizzato. Se viene chiamata reportEvent(), le piattaforme lato vendite che eseguono l'asta sono sempre idonee a ricevere questi report sugli eventi. Solo la piattaforma lato acquisti vincente è idonea a ricevere questi report.

Report lato vendite

La piattaforma richiama la funzione JavaScript reportResult() nel codice fornito lato fornitura 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 l'operazione riuscita, qualsiasi altro valore per l'errore.
  • URL di reporting: la piattaforma richiama questo URL restituito dalla funzione.
  • Indicatori per l'acquirente: un oggetto JSON da passare alla funzione reportWin dell'acquirente.

Il lato offerta potrebbe 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 offerta vincente
  • Nome dell'app
  • Identificatori di query
  • Indicatori per l'acquirente: per supportare la condivisione dei dati tra il lato offerta e la domanda, la piattaforma trasmette questo valore restituito come parametro di input per il codice dei report sul lato domanda.

Report lato acquisti

La piattaforma richiama la funzione JavaScript reportWin() nel codice fornito 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 recuperati da AuctionConfig. Tutte le informazioni che la piattaforma lato acquisti deve trasmettere all'URL dei report possono provenire da questo dato.
  • signals_for_buyer è l'output del reportResult lato vendite. Ciò offre alla Sell-Side Platform l'opportunità di condividere i dati con la Piattaforma lato acquirente per la generazione di report.
  • contextual_signals contiene informazioni come il nome dell'app e custom_audience_signals contiene informazioni sul segmento di pubblico personalizzato. In futuro potrebbero essere aggiunte altre informazioni.

Output:

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

Eventi dei report

Gli eventi di generazione dei report sono possibili solo dopo che il report sulle impressioni per l'asta è completato. L'SDK lato vendite è responsabile della generazione di report su tutti gli eventi. La piattaforma espone un'API che utilizza un ReportEventRequest che specifica l'asta eseguita di recente, la chiave evento segnalata, i dati associati alla chiave, se il report deve essere inviato all'acquirente o al venditore (o entrambi) e un evento di input facoltativo per gli eventi annuncio. Il client definisce la chiave evento e la raccolta di dati da segnalare.

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

reportEvent(request)

Input:

  • ad_selection_id deve essere un AdSelectionId di un'asta eseguita di recente recuperata 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 all'elemento event_key
  • reporting_destinations è una maschera di bit impostata utilizzando i flag forniti dalla piattaforma. Può essere uno di FLAG_REPORTING_DESTINATION_SELLER, 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 nullo (per un evento di visualizzazione). Per ulteriori dettagli su questo parametro, consulta Integrazione dell'API Attribution Reporting.

Dopo che l'SDK lato vendite richiama reportEvent e, a seconda del flag reporting_destinations, la piattaforma tenta di abbinare event_key alle chiavi registrate da acquirenti e venditori nelle loro funzioni JavaScript reportWin e reportResult. Se viene trovata una corrispondenza, la piattaforma PUBBLICA event_data nell'elemento reporting_url associato. Il tipo di contenuti della richiesta è in testo normale, con il corpo event_data. Questa richiesta viene effettuata secondo il criterio del "best effort" e non va a buon fine in caso di errore di rete, risposta a un 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, stiamo fornendo funzionalità cross-API nell'API Protected Audience e Attribution Reporting (ARA). Questa funzionalità consente ai tecnici pubblicitari di valutare il rendimento dell'attribuzione attraverso diverse tattiche di remarketing, in modo da poter capire quali tipi di segmenti di pubblico generano il ROI più elevato.

Grazie a questa integrazione tra API, i tecnici pubblicitari possono:

  • Crea una mappa chiave-valore degli URI da utilizzare sia per i report sull'interazione con gli annunci sia per la registrazione dell'origine.
  • Includi i dati dell'asta dell'asta Protected Audience nella mappatura delle chiavi lato origine per i report di riepilogo aggregati (utilizzando l'API Attribution Reporting). Per saperne di più, consulta la proposta di progettazione ARA.

Quando un utente visualizza o fa clic su un annuncio:

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

Abilitazione della registrazione di origine

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

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

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

Esempio di report sul coinvolgimento e sulle conversioni

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

In questo flusso di lavoro, l'acquirente si coordina con il venditore per inviare un ID univoco nell'asta. Durante l'asta, l'acquirente invia questo ID univoco con i dati dell'asta. Durante il tempo di rendering e di conversione, anche i dati dell'annuncio 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 come parte della risposta all'offerta programmatica per le offerte in tempo reale ("RTB"). L'ID può essere impostato come una variabile come auctionId. L'ID viene trasmesso come perBuyerSignals nell'elemento auctionConfig e diventa disponibile nella logica di offerta dell'acquirente.

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

Al termine della procedura descritta sopra, l'acquirente dispone di un report sulle aste, sulle interazioni e sulle conversioni, che possono essere correlati tramite l'ID univoco che può essere utilizzato per essere associati 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 affidabile gestito dalla piattaforma ad tech

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

  • I comportamenti di questi server, descritti più avanti in questa sezione, non divulgano le informazioni degli utenti.
  • I server non creerebbero profili con pseudonimi in base ai dati che vede, ovvero dovranno essere "attendibili".

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

Di seguito è riportato un URL di esempio per recuperare i dati di Trusted Bidding in base ai metadati degli indicatori di Trusted Bidding provenienti dal segmento di pubblico personalizzato:

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

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

Lato vendita: in modo analogo al flusso lato acquisti riportato sopra, il lato vendite potrebbe voler recuperare informazioni sulle creatività considerate nell'asta. Ad esempio, un publisher potrebbe voler richiedere che determinate creatività non vengano mostrate nella sua app in base a problemi di sicurezza del brand. Queste informazioni possono essere recuperate e messe a disposizione della logica dell'asta lato vendite. Analogamente alla ricerca server attendibili lato acquisti, anche la ricerca server attendibili lato vendite avviene tramite un recupero HTTP. L'URL è composto aggiungendo l'URL Indicatori di punteggio attendibili con gli URL di rendering delle creatività per le quali devono essere recuperati i dati.

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

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

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

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

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

Come meccanismo temporaneo, l'acquirente e il venditore possono recuperare questi indicatori di offerta da qualsiasi server, incluso uno che operano in modo autonomo. Tuttavia, nella versione di release, la richiesta verrà inviata solo a un server di tipo chiave-valore attendibile.

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