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
• Aggiunta l'integrazione di Attribution Reporting con Protected Audience.
• È stata pubblicata una cronologia delle funzionalità di Protected Audience.
• FLEDGE è stato rinominato API Protected Audience.
• È stata aggiunta una proposta per la delega dei segmenti di pubblico personalizzati.
• È stato rimosso il requisito di k-anonimità per l'URL dell'aggiornamento giornaliero.

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

Con Protected Audience puoi:

• Gestire 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 è molto apprezzato perché ci consente di continuare a sviluppare Protected Audience.

Cronologia

Nei prossimi mesi lanceremo nuove funzionalità. Le date di rilascio esatte varieranno in base alla funzionalità e questa tabella verrà aggiornata con i link alla documentazione non appena sarà disponibile.

Panoramica

Nella pubblicità per il mobile, gli inserzionisti di solito hanno bisogno di pubblicare gli utenti potenzialmente interessati in base a come hanno precedentemente interagito con i dell'inserzionista. Ad esempio, lo sviluppatore di SportingGoodsApp potrebbe volere mostrare annunci agli utenti che hanno lasciato degli articoli nel carrello, mostrando gli annunci a Ricordare agli utenti di completare l'acquisto. Nel settore, questa idea generale viene comunemente descritta con termini come "remarketing" e "targeting per pubblico personalizzato".

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

L'API Protected Audience su Android (precedentemente nota come FLEDGE) include le seguenti API per consentire alle piattaforme ad tech e agli inserzionisti di supportare i casi d'uso comuni basati sulle interazioni in modo da limitare la condivisione sia degli identificatori tra le app sia delle informazioni sulle interazioni dell'utente con terze parti:

1. API Custom Audience: incentrata sull'astrazione "segmento di pubblico personalizzato", che rappresenta un segmento di pubblico designato dall'inserzionista con intenzioni comuni. Le informazioni sul pubblico vengono memorizzate sul dispositivo e possono essere associate ad annunci candidati pertinenti per il pubblico e metadati arbitrari, come gli indicatori per le offerte. Le informazioni possono essere utilizzate per fornire informazioni su offerte, filtro degli annunci e rendering degli inserzionisti.
2. API Ad Selection: fornisce un framework che orchestra i flussi di lavoro delle piattaforme di tecnologia pubblicitaria che utilizzano indicatori sul dispositivo per determinare un annuncio "vincente" tenendo conto degli annunci candidati archiviati localmente ed eseguendo un'elaborazione aggiuntiva sugli annunci candidati che una piattaforma di tecnologia pubblicitaria restituisce al dispositivo.

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

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

2. Quando l'utente gioca a FrisbeeGame sullo stesso dispositivo, potrebbe vedere un annuncio che gli ricorda di completare l'acquisto degli articoli rimasti nel carrello acquisti di SportingGoodsApp. Questo obiettivo può essere ottenuto tramite FrisbeeGame (con annunci integrati SDK) richiamando l'API Ad Selection per la selezione di un annuncio vincente per l'utente in base a qualsiasi elenco del segmento di pubblico di cui potrebbe far parte (in ad esempio la colonna "prodotti nel carrello" segmento di pubblico personalizzato creato da SportingGoodsApp). Il flusso di lavoro di selezione degli annunci può essere configurato in modo da prendere in considerazione gli annunci recuperati dai server delle piattaforme di tecnologia pubblicitaria, oltre agli annunci sul dispositivo associati ai segmenti di pubblico personalizzati e ad altri indicatori sul dispositivo. Il flusso di lavoro può essere anche personalizzato dalla piattaforma ad tech e dall'SDK per gli annunci con logiche di offerta e di punteggio personalizzate per raggiungere obiettivi pubblicitari appropriati. Questo approccio consente di utilizzare i dati sugli interessi o sulle interazioni con le app dell'utente per determinare la selezione degli annunci, limitando al contempo la condivisione di questi dati con terze parti.

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

4. La piattaforma facilita la generazione di report sulle impressioni e sulla selezione degli annunci risultati. Questa funzionalità di reporting è complementare ai report sull'attribuzione tramite Google Cloud. Le piattaforme di tecnologia pubblicitaria possono essere personalizzate in base alle esigenze di generazione di report.

Ottenere l'accesso a Protected Audience sulle API Android

Le piattaforme di ad tech devono registrarsi per accedere all'API Protected Audience. Consulta Per saperne di più, registrati 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 di pubblico, ad esempio qualcuno che ha carrello degli acquisti" o "completato i livelli principiante" di un gioco. La piattaforma gestisce e memorizza le informazioni sul pubblico localmente sul dispositivo e non indica i segmenti di pubblico personalizzati di cui fa parte l'utente. I segmenti di pubblico personalizzati sono diversi I gruppi di interesse Protected Audience di Chrome, che non possono essere condivisi su web e app. Ciò consente di limitare la condivisione delle informazioni degli utenti.

L'app di un inserzionista o l'SDK integrato possono partecipare o abbandona un segmento di pubblico personalizzato basato, ad esempio, sull'utente coinvolgimento 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. È implicitamente impostato sul nome del pacchetto dell'app del chiamante.
• Acquirente: rete pubblicitaria dell'acquirente che gestisce gli annunci per questo segmento di pubblico personalizzato. L'acquirente rappresenta anche la parte che può accedere al segmento di pubblico personalizzato e recuperare informazioni pertinenti sugli annunci. L'acquirente viene specificato in base al formato eTLD+1.
• Nome: un nome o un identificatore arbitrario per la segmento di pubblico personalizzato, ad esempio un utente con "utenti che hanno abbandonato il carrello degli acquisti". Questo attributo potrebbe essere utilizzato, ad esempio, come uno dei criteri di targeting nelle campagne pubblicitarie dell'inserzionista o come stringa di query nell'URL per il recupero del codice di offerta.
• Ora di attivazione e ora di scadenza: questi campi definiscono il tempo quando questo segmento di pubblico personalizzato sarà effettivo. La piattaforma utilizza questo informazioni per ritirare l'appartenenza a un pubblico personalizzato. Data di scadenza non può superare una finestra di durata massima per limitare la durata di un pubblico.
• URL di aggiornamento giornaliero: l'URL della piattaforma utilizza per recuperare gli annunci candidati e altri metadati definiti nella sezione "Offerte per l'utente indicatori" e "Indicatori di offerta attendibili" su base ricorrente. Per maggiori informazioni consulta la sezione su come recuperare annunci candidati per segmenti di pubblico di destinazione.
• Indicatori per le offerte per gli utenti: indicatori specifici della piattaforma di 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 di offerta attendibili: le piattaforme di tecnologia pubblicitaria si basano su dati in tempo reale per fornire informazioni sul recupero e sul punteggio degli annunci. Ad esempio, un annuncio potrebbe esaurire il budget e la sua pubblicazione deve essere interrotta immediatamente. Una tecnologia pubblicitaria può definire un endpoint URL da cui è possibile recuperare questi dati in tempo reale e l'insieme di chiavi per le quali deve essere eseguita la ricerca in tempo reale. Il server che gestisce questo sarà considerata un account attendibile server gestito piattaforma di tecnologia pubblicitaria.
• URL logica di offerta: l'URL utilizzato dalla piattaforma per recuperare le offerte. 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 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, questo elenco di metadati dell'annuncio verrà preso in considerazione. Questo elenco di annunci verrà aggiornato utilizzando l'endpoint URL di aggiornamento giornaliero, se possibile. A causa delle limitazioni delle risorse sui dispositivi mobili, esiste un limite al numero di annunci che possono essere archiviati in un segmento di pubblico personalizzato.

Delegazione dei segmenti di pubblico personalizzati

La definizione e la configurazione tradizionali di segmenti di pubblico personalizzati si basano in genere su tecnologie e integrazioni lato server, determinate da tecnologie pubblicitarie in collaborazione con agenzie e inserzionisti e clienti e partner. L'API Protected Audience attiva definizione e configurazione dei segmenti di pubblico personalizzati proteggendo al contempo la privacy dell'utente. A entrare a far parte di un segmento di pubblico personalizzato, tecnologie pubblicitarie degli acquirenti che non hanno una presenza SDK nelle app devono collaborare con tecnici pubblicitari che hanno una presenza sul dispositivo, come i dispositivi mobili partner di misurazione (MMP) e Supply-Side Platform (SSP). L'obiettivo dell'API Protected Audience è supportare questi SDK fornendo soluzioni flessibili per la gestione dei segmenti di pubblico personalizzati, consentendo agli utenti che chiamano il dispositivo di invocare la creazione di segmenti di pubblico personalizzati per conto degli acquirenti. Questa procedura è chiamata segmento di pubblico personalizzato delega. Per configurare la delega per i segmenti di pubblico personalizzati:

Entrare a far parte di un segmento di pubblico personalizzato

Puoi partecipare a un segmento di pubblico personalizzato in due modi:

joinCustomAudience()

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

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

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

fetchAndJoinCustomAudience()

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

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

fetchAndJoinCustomAudience(fetchRequest);

L'endpoint URL, di proprietà dell'acquirente, risponde con un JSON CustomAudience nel corpo della risposta. I campi Acquirente e Proprietario del segmento di pubblico personalizzato vengono ignorati (e compilati automaticamente dall'API). L'API impone inoltre che l'applicazione l'URL di aggiornamento corrisponderà 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 possono essere alterati dalla risposta di recupero. Il proprietario CustomAudience è il nome del pacchetto dell'applicazione chiamante. Non esiste un'altra convalida fetchUri a parte il controllo eTLD+1 e, in particolare, non esiste un k-anon verifica. L'API fetchAndJoinCustomAudience() invia una richiesta HTTP GET a fetchUri e si aspetta un oggetto JSON che rappresenti il segmento di pubblico personalizzato. Uguale vincoli obbligatori e facoltativi e valori predefiniti per il segmento di pubblico personalizzato vengono applicati alla risposta. Scopri i requisiti e le limitazioni attuali nella nostra guida per gli sviluppatori.

Qualsiasi risposta di errore HTTP da parte dell'acquirente fa sì che fetchAndJoinCustomAudience errore. In particolare, una risposta di stato HTTP 429 (Troppe richieste) blocca le richieste provenienti dall'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 del nuovo tentativo a causa di errori temporanei (ad esempio il server non risponde) o della gestione di errori persistenti (ad esempio errori di convalida dei dati o altri errori non transitori con la comunicazione al server).

L'oggetto CustomAudienceFetchRequest consente all'autore della chiamata dell'API di definire alcune informazioni per il segmento di pubblico personalizzato utilizzando le proprietà facoltative mostrate nell'esempio precedente. Se impostati nella richiesta, questi valori non possono essere sovrascritti dalla risposta dell'acquirente ricevuta dalla piattaforma. L'API Protected Audience ignora i campi nella risposta. Se non sono impostati nella richiesta, devono devono essere impostati nella risposta, in quanto questi campi sono necessari per creare un'immagine pubblico. Una rappresentazione JSON dei contenuti di CustomAudience come parzialmente definito dal chiamante dell'API è incluso nella richiesta GET a fetchUri in un'intestazione speciale X-CUSTOM-AUDIENCE-DATA. Le dimensioni del formato serializzato la dimensione dei dati specificati per il segmento di pubblico personalizzato è limitata a 8 kB. Se le dimensioni superano il limite, la chiamata all'API fetchAndJoinCustomAudience non va a buon fine.

La mancanza di un controllo k-anon ti consente di utilizzare fetchUri per la verifica dell'acquirente e per attivare la condivisione delle informazioni tra l'acquirente e l'SDK. Per facilitare la verifica del segmento di pubblico personalizzato, l'acquirente può fornire un token di verifica. L'SDK on-device deve includere questo token in fetchUri in modo che l'endpoint ospitato dall'acquirente possa recuperare i contenuti del segmento di pubblico personalizzato e utilizzare il token di verifica per verificare che l'operazione fetchAndJoinCustomAudience() sia associata all'acquirente e che provenga da un partner on-device attendibile. Per condividere le informazioni, l'acquirente può concordare con il chiamante sul dispositivo alcune informazioni da utilizzare per creare il segmento di pubblico personalizzato aggiunti come parametri di query a fetchUri. In questo modo l'acquirente può controllare e rilevare se un token di convalida è stato utilizzato da una tecnologia pubblicitaria dannosa per 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 da Protected Audience. ed è facoltativo.

  • Il token di verifica può essere utilizzato dall'acquirente per verificare che i segmenti di pubblico in fase di creazione vengano creati per suo conto.
  • La proposta dell'API Protected Audience non specifica né un formato per il il token di verifica, né il modo in cui l'acquirente trasferisce il token chiamante. Ad esempio, il token di verifica potrebbe essere precaricato l'SDK o il backend del proprietario oppure possono essere recuperati in tempo reale SDK 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 nello snippet di codice illustrativo riportato di seguito:

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

Per contribuire a limitare 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 predeterminato di nel tempo. Il valore predefinito deve essere determinato. Il proprietario può eseguire l'override predefinito.

Controllo utente

• 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 tutte le segmenti di pubblico associati alle app e ne impediscono l'accesso a 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, che include l'API Protected Audience. Se l'utente ha scelto all'uscita da Privacy Sandbox, l'API Protected Audience non funziona in modo automatico.

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

Aggiornamenti pianificati

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

Per facilitare questa operazione, il team ad tech può chiamare il API scheduleCustomAudienceUpdate(). Questa API consente al chiamante di specificare un ritardo per l'invio della chiamata API, fornendo così tempo aggiuntivo alla tecnologia pubblicitaria che risponde per elaborare gli eventi a livello di app e determinare a quali segmenti di pubblico protetti l'utente deve partecipare o da cui deve essere rimosso.

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

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

ScheduleCustomAudienceUpdateRequest

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

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

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

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

ScheduleCustomAudienceUpdateRequest contiene le informazioni necessarie per registrare un job in ritardo da eseguire con la piattaforma. Dopo il ritardo specificato, un job in background verrà eseguito periodicamente e invierà le richieste. La 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 è necessario che sia esplicitamente fornito e non può essere modificato dalla risposta dell'aggiornamento. La richiesta GET si aspetta un oggetto JSON contenente un elenco di oggetti customAudience come risposta.
• DelayTime: tempo che indica il ritardo dal momento in cui viene effettuato il Chiamata API scheduleCustomAudienceUpdate() per pianificare l'aggiornamento.

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

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

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

Autorizzazioni e controllo delle app

La proposta intende fornire alle app il controllo sui relativi 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 segmenti di pubblico per suo conto.

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

Controllo della piattaforma ad tech

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

• Gli ad tech 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 utilizzati per verificare la creazione di un segmento di pubblico personalizzato. Quando questa procedura viene delegata a un partner, la creazione di segmenti di pubblico personalizzati può essere configurata in modo da richiedere il riconoscimento da parte della tecnologia pubblicitaria.
• Un ad tech può scegliere di disattivare le chiamate joinCustomAudience per suo conto e consenti solo all'API fetchAndJoinCustomAudience di abilitare tutte le chiamate personalizzate segmenti di pubblico di destinazione. Il controllo può essere aggiornato durante la registrazione a Privacy Sandbox. Tieni presente che il controllo consente tutte le tecnologie pubblicitarie o nessuna. A causa delle limitazioni della piattaforma, le autorizzazioni di delega non possono essere basate su ogni tecnologia pubblicitaria.

Annunci candidati e risposta dei metadati

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

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

Flusso di lavoro di selezione degli annunci

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

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

• Senza sul server le informazioni sui pacchetti installati, ad tech le piattaforme potrebbero voler inviare più annunci contestuali al dispositivo e richiama il flusso di lavoro di selezione degli annunci per abilitare il filtro basato sull'installazione di app in modo da per aumentare le probabilità di mostrare un annuncio pertinente.
• Poiché gli annunci di remarketing vengono recuperati al di fuori del normale flusso, potrebbe essere necessario aggiornare i modelli di offerta attuali. Le piattaforme ad tech potrebbero voler creare sottomodelli di offerta (l'implementazione potrebbe basarsi su un pattern chiamato modello a due torri) che possono lavorare separatamente alle funzioni degli annunci e agli indicatori di contesto e combinare gli output del sottomodello sul dispositivo per prevedere le offerte. Ciò può trarre vantaggio sia aste e aste lato server per una determinata opportunità pubblicitaria.

Questo approccio consente ai dati sulle interazioni con l'app dell'utente di determinare la selezione di 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 codice JavaScript fornito dalla tecnologia pubblicitaria basato su la seguente sequenza:

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

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

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

Avvia il flusso di lavoro di selezione degli annunci

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

• Venditore: identificatore della piattaforma pubblicitaria sell-side, nel formato eTLD+1
• URL della logica decisionale: quando viene avviata un'asta di annunci, la piattaforma utilizzerà questo URL per recuperare il codice JavaScript dalla piattaforma di vendita al fine di assegnare un punteggio all'annuncio vincente.
• Acquirenti di segmenti di pubblico personalizzati: un elenco di piattaforme lato acquisti con basata sul pubblico per questa asta, secondo il 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 da quali è possibile recuperare informazioni in tempo reale specifiche per le creatività.
• Segnali per acquirente: i lati della domanda partecipanti possono utilizzare questo parametro per fornire input per l'asta. Ad esempio, questo parametro può includere informazioni contestuali esaustive utili per determinare le offerte.

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

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

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

Logica di offerta lato acquisti

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

La piattaforma utilizzerà l'"URL della logica di offerta" del segmento di pubblico personalizzato per i metadati recupera 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 invoca questa funzione in sequenza per tutti gli annunci (contestuali o di remarketing). 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 preso in considerazione dal codice di offerta lato acquirente. Deve trattarsi di un annuncio di un segmento di pubblico personalizzato idoneo
• Indicatori asta: indicatori sell-side specifici della piattaforma.
• Indicatori per acquirente: le parti della domanda partecipanti possono utilizzare questo parametro per forniscono input per l'asta. Ad esempio, questo parametro può includere informazioni contestuali complete utili per determinare le offerte.
• Indicatori di offerta affidabili: le piattaforme di tecnologia pubblicitaria si basano su dati in tempo reale per per il recupero e il punteggio degli annunci. Ad esempio, una campagna pubblicitaria potrebbe esaurire deve essere interrotta immediatamente. Una tecnologia pubblicitaria può definire un endpoint URL da cui è possibile recuperare questi dati in tempo reale e l'insieme di chiavi per le quali è necessario eseguire la ricerca in tempo reale. Il server gestito della piattaforma ad tech che gestisce questa richiesta sarà un server attendibile gestito dalla piattaforma ad tech.
• Indicatori di contesto: possono includere timestamp approssimativo o informazioni sulla posizione approssimative o il costo per clic sull'annuncio.
• Indicatori utente: potrebbero essere incluse informazioni come i dati dei pacchetti installati disponibili.

Costo dell'annuncio

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

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

Se questo annuncio è vincente, adCost viene arrotondato stocasticamente a 8 bit per privacy. Il valore arrotondato di adCost viene quindi passato al valore contextual_signals in reportWin durante i report sulle impressioni.

Logica di filtro lato acquisti

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

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

Inoltre, le piattaforme lato acquisti potranno segnalare che un determinato annuncio devono essere filtrati in base a ulteriori indicatori sul dispositivo disponibili per Protected in modo da rimanere sul dispositivo. Man mano che consolidiamo i progetti logica di filtro aggiuntiva, le piattaforme lato acquisti seguiranno questa stessa struttura per segnalare che l'applicazione del filtro dovrebbe essere eseguita.

Logica di punteggio lato vendite

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

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

La funzione prevede i seguenti parametri:

• Annuncio: l'annuncio in fase di valutazione; output della funzione generateBid().
• Offerta: l'importo dell'offerta generato 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 informare il filtraggio e il punteggio degli annunci. Ad esempio, un publisher di app può impedire a una campagna pubblicitaria di pubblicare annunci nell'app. Questi dati vengono recuperati dal parametro URL degli indicatori di punteggio attendibili della configurazione dell'asta. Il server che gestisce questa richiesta deve essere un server attendibile gestito dalla tecnologia pubblicitaria.
• Indicatore contestuale: può includere informazioni approssimative sulla posizione o il timestamp approssimativo.
• Indicatore dell'utente: può includere informazioni quali lo store che ha avviato l'installazione dell'app.
• Indicatore relativo ai segmenti di pubblico personalizzati: se l'annuncio a cui viene assegnato un punteggio proviene da un segmento di pubblico personalizzato sul dispositivo, questo indicatore conterrà informazioni come il lettore e il nome del segmento di pubblico personalizzato.

Tempo di esecuzione del codice di selezione degli annunci

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

• L'esecuzione del codice dovrebbe terminare in un periodo di tempo predefinito. Questo limite si applicherà in modo uniforme a tutte le reti pubblicitarie degli acquirenti. I dettagli di questo limite saranno condiviso 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 ai dati privati degli utenti, come le origini di installazione delle app, il runtime non fornirà accesso alla rete o allo stoccaggio.

Linguaggio di programmazione

Il codice 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 piattaforme che supportano Privacy Sandbox.

Visualizzazione dell'annuncio vincente

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

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

Report sulle impressioni e sugli eventi

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

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

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

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

Protected Audience offre un meccanismo per iscriversi a eventi futuri relativi a un'asta vincente registrando i beacon. Nella funzione JavaScript reportResult() di un venditore, le piattaforme di scambio pubblicitario possono registrare i beacon utilizzando la funzione registerAdBeacon() della piattaforma. Analogamente, le piattaforme 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 l'endpoint a cui la piattaforma invia ping durante la generazione dei report sui risultati dell'asta.
• reporting_url: l'URL di proprietà della piattaforma ad tech per la gestione dell'evento.

Le chiavi evento sono identificatori di stringa di proprietà dell'SDK sell-side responsabile della generazione di report sui risultati dell'asta. Affinché venga richiamato, ad tech registra beacon con chiavi corrispondenti a quelle utilizzate dal lato vendite durante la segnalazione degli eventi. Non è necessario che siano k-anonymous, anche se ci sono limiti alla quantità e alla lunghezza delle chiavi che possono essere registrate per un un determinato segmento di pubblico personalizzato. Se viene chiamato reportEvent(), le piattaforme sell-side che hanno eseguito l'asta sono sempre idonee a ricevere questi report sugli eventi. Solo il la piattaforma lato acquisti vincente è idonea a ricevere questi report.

Report sell-side

La piattaforma richiama la funzione JavaScript reportResult() nell'offerta codice fornito dal lato scaricato dall'URL della logica di decisione del venditore parametro 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}};
}

Uscita: un oggetto JSON contenente

• Stato: 0 per esito positivo, qualsiasi altro valore per esito negativo.
• URL report: la piattaforma richiama questo URL restituito dalla funzione.
• Indicatori per l'acquirente: un oggetto JSON da passare all'oggetto reportWin dell'acquirente. personalizzata.

Il lato Supply potrebbe codificare indicatori pertinenti nell'URL dei report per aiutarli. Ottenere ulteriori informazioni sull'asta e sull'annuncio vincente. Ad esempio, includi gli indicatori seguenti:

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

Report lato acquisti

La piattaforma richiama la funzione JavaScript reportWin() nella domanda fornito dal lato scaricato dai metadati dell'URL della logica di offerta della sezione 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. Qualsiasi informazione che deve essere trasmessa dalla piattaforma lato acquisti l'URL del report può provenire da questo dato.
• signals_for_buyer è l'output di reportResult lato venditore. In questo modo, la piattaforma lato vendite ha la possibilità di condividere i dati con la piattaforma lato acquisti per la generazione di report.
• contextual_signals contiene informazioni quali nome dell'app e custom_audience_signals contiene le informazioni sul segmento di pubblico personalizzato. Altro informazioni potrebbero essere aggiunte in futuro.

Output:

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

Eventi di segnalazione

È possibile generare report sugli eventi solo al termine della generazione dei report sulle impressioni per l'asta. L'SDK lato vendite è responsabile della generazione di report su tutti gli eventi. La piattaforma espone un'API che accetta un ReportEventRequest che specifica la asta eseguita di recente, la chiave dell'evento registrata, i dati associati a quella chiave, se il report deve essere inviato all'acquirente o al venditore (o entrambi) e un evento di input facoltativo per gli eventi correlati agli annunci. Il client definisce l'evento chiave e la raccolta di dati da includere nei report.

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

reportEvent(request)

Input:

• ad_selection_id deve appartenere a un AdSelectionId di un'asta eseguita di recente recuperato da AdSelectionOutcome.
• event_key è una stringa definita dal lato sell-side che descrive l'evento di interazione.
• event_data è una stringa che rappresenta i dati associati al event_key
• reporting_destinations è una maschera di bit impostata utilizzando i flag forniti dalla piattaforma. Può essere uno di FLAG_REPORTING_DESTINATION_SELLER o FLAG_REPORTING_DESTINATION_BUYER o entrambe.
• Il campo input_event (facoltativo) viene utilizzato per l'integrazione con Attribution Reporting tramite Google Cloud CLI o tramite l'API Compute Engine. Può essere un oggetto InputEvent (per un evento di clic) o nullo (per un evento di visualizzazione). Per ulteriori dettagli su questo parametro, consulta la sezione Integrazione dell'API Attribution Reporting.

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

Integrazione dell'API Attribution Reporting

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

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

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

Quando un utente visualizza o fa clic su un annuncio:

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

Attivazione della registrazione delle origini

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

Poiché l'ARA su Android supporta gli eventi di visualizzazione e clic, InputEvents sono utilizzati per distinguere i due tipi. Proprio come nell'origine ARA registrazione, l'API reportEvent() interpreterà la verifica InputEvent come evento di clic. Se InputEvent manca, è nullo o non valido, la registrazione di origine sarà considerata una vista.

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

Esempio di report sul coinvolgimento e sulle conversioni

In questo esempio, lo esamineremo dal punto di vista dell'acquirente interessato 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 l'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 visualizzato viene inviato con lo stesso ID univoco. In seguito, l'ID univoco può essere utilizzato associare questi report.

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

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

Al termine della procedura descritta sopra, l'acquirente avrà un report sull'asta, un report sulle interazioni e un report sulle conversioni che possono essere correlati utilizzando l'ID univoco che può essere utilizzato per associarli tra loro.

Un flusso di lavoro simile si applica a un venditore se ha bisogno di accedere ai dati di attribuzione e il venditore può anche utilizzare un ID univoco da inviare con registerAdBeacon(). La La chiamata reportEvent() contiene una proprietà di destinazione che può essere utilizzata per inviare il rapporto 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 l'esaurimento del budget per determinare se i candidati degli annunci devono essere selezionati per l'asta. Sia le piattaforme di scambio pubblicitario sia quelle di scambio pubblicitario potranno ottenere queste informazioni dai server che gestiscono. Per ridurre al minimo la fuga di informazioni sensibili tramite questi server, la proposta prevede le seguenti limitazioni:

• Il comportamento di questi server, descritto più avanti in questa sezione, non causerebbe la fuga di informazioni degli utenti.
• I server non creerebbero profili pseudonimi in base ai dati che vede, ovvero dovrà essere "attendibile".

Lato acquirente: una volta che il lato acquirente avvia la logica di offerta lato acquirente, la piattaforma esegue un recupero HTTP dei dati di offerta attendibili dal server attendibile. URL è composto aggiungendo l'URL e le chiavi presenti nel documento Trusted Bidding Indica i metadati del segmento di pubblico personalizzato elaborati. Questo recupero viene eseguito solo durante l'elaborazione degli annunci dalla personalizzazione sul dispositivo segmenti di pubblico di destinazione. In questa fase, il lato acquisti può applicare i budget. stato di pausa / riattivazione, esecuzione di targeting e così via.

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

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

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

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

Di seguito è riportato un URL di esempio per recuperare informazioni sulle creatività considerate nel in base agli URL di rendering della 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 inviate nella richiesta.

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

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

Come meccanismo temporaneo, l'acquirente e il venditore possono recuperare queste offerte e segnali da qualsiasi server, incluso quello che gestiscono autonomamente. 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 di tipo chiave-valore affidabile e comune per piattaforme compatibili con Privacy Sandbox su Android e per il web.