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

Inviare un feedback

Aggiornamenti recenti

• Sono state aggiunte informazioni sulla pianificazione di 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 è stata rinominata API Protected Audience.
• È stata aggiunta una proposta per la delega dei segmenti di pubblico personalizzati.
• È stato rimosso il requisito di k-anonymity per l'aggiornamento giornaliero .

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

Con Protected Audience puoi:

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

Per iniziare, leggi la guida per gli sviluppatori di Protected Audience. Il tuo il tuo feedback è apprezzato mentre continuiamo 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 al modo in cui hanno interagito in precedenza 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. Il settore descrive comunemente questo idea generale di termini come "remarketing" e "targeting per pubblico personalizzato".

Oggi questi casi d'uso vengono in genere implementati condividendo informazioni Informazioni su come l'annuncio viene visualizzato (ad esempio il nome dell'app) e privato informazioni come gli elenchi dei segmenti di pubblico con 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) comprende la classe le seguenti API per consentire agli inserzionisti e alle piattaforme di ad tech per supportare casi d'uso basati sull'interazione in modi che limitano la condivisione di entrambi gli identificatori tra le app e le informazioni sull'interazione di un utente con terze parti:

1. API Custom Audience: è incentrata sulla "segmento di pubblico personalizzato" un'astrazione, che rappresenta un'entità pubblico 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 le offerte degli inserzionisti, i filtri degli annunci e il rendering.
2. API Ad Selection: fornisce un framework che orchestra le piattaforme di ad tech flussi di lavoro che sfruttano gli indicatori sul dispositivo determinare un "vincente" prendendo in considerazione gli annunci candidati archiviati localmente eseguendo ulteriori elaborazioni sugli annunci candidati che una piattaforma di ad tech torna al dispositivo.

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

1. SportingGoodsApp vuole ricordare agli utenti di acquistare gli articoli di merchandising lasciati nel carrello se non ha 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 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 ad tech gestisce i metadati per il pubblico che elenca e fornisce gli annunci candidati, messi a disposizione dell'annuncio flusso di lavoro per la selezione. La piattaforma può essere configurata per Recuperare periodicamente gli annunci aggiornati basati sul pubblico in background. Questo consente di mantenere l'elenco di annunci candidati basati sul pubblico sempre aggiornato e non correlato di richieste inviate ad ad server di terze parti durante l'opportunità annuncio (ad es. richiesta di annuncio contestuale).

2. Quando un utente gioca a FrisbeeGame sullo stesso dispositivo, potrebbe visualizzare un annuncio ricordando loro di completare l'acquisto degli articoli rimasti nell'app carrello degli acquisti. 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 impostato in modo da prendere in considerazione gli annunci recuperati dall'annuncio delle piattaforme tecnologiche server, oltre agli annunci sul dispositivo associati ai segmenti di pubblico personalizzati e altri indicatori sul dispositivo. Il flusso di lavoro può anche personalizzati dalla piattaforma ad tech e dall'SDK per gli annunci con le offerte personalizzate di valutazione per raggiungere gli obiettivi pubblicitari appropriati. Questo approccio consente i dati sugli interessi o sulle interazioni con l'app dell'utente per determinare la selezione di annunci, mentre limitare 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 ai report sull'attribuzione tramite Google Cloud. Le piattaforme di ad tech possono personalizzare in base alle esigenze di generazione dei 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 potrebbe utilizzare un segmento di pubblico personalizzato per indicare un pubblico specifico, ad esempio un utente che ha "lasciato articoli nel carrello degli acquisti" o "ha completato i livelli per principianti" di un gioco. La piattaforma conserva e memorizza le informazioni sul pubblico a livello locale sul dispositivo e non esponi i segmenti di pubblico personalizzati a cui appartiene 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. In questo modo, la condivisione delle informazioni degli utenti viene limitata.

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

Metadati dei segmenti di pubblico personalizzati

Ogni segmento di pubblico personalizzato contiene i seguenti metadati:

• Proprietario:nome del pacchetto dell'app 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 sull'annuncio. L'acquirente viene specificato in base al formato eTLD+1.
• Nome: un nome o un identificatore arbitrario per il pubblico personalizzato, ad esempio un utente che ha "abbandonato il carrello degli acquisti". Questo attributo può essere utilizzato, ad esempio, come uno dei criteri di targeting nelle campagne pubblicitarie dell'inserzionista o una stringa di query nell'URL per 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 vita 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 di offerta per l'utente:indicatori specifici della piattaforma per la tecnologia pubblicitaria per qualsiasi offerte degli annunci di remarketing. Esempi di indicatori includono: la posizione approssimativa dell'utente, le impostazioni internazionali preferite e così via.
• Dati sulle offerte affidabili: le piattaforme di tecnologia pubblicitaria si basano su dati in tempo reale. per il recupero e il punteggio degli annunci. Ad esempio, un annuncio potrebbe esaurire il budget e deve essere interrotta immediatamente. Un AdTech può definire un URL endpoint da cui è possibile recuperare questi dati in tempo reale e l'insieme di chiavi che 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 l'asta dell'annuncio in corso.
• Annunci:un elenco di annunci candidati per il segmento di pubblico personalizzato. Sono inclusi i metadati degli annunci specifici della piattaforma ad tech e un URL per visualizzare l'annuncio. Quando in un'asta per il segmento di pubblico personalizzato, questo elenco di metadati dell'annuncio verrà considerati. Questo elenco di annunci verrà aggiornato utilizzando l'endpoint URL di aggiornamento giornaliero, se possibile. A causa delle risorse limitate sui dispositivi mobili, un limite al numero di annunci che possono essere memorizzati in un segmento di pubblico personalizzato.

Delega segmenti di pubblico personalizzati

La definizione e la configurazione tradizionali di segmenti di pubblico personalizzati si basano in genere su di tecnologie e integrazioni lato server, basate su 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. Per integrare un segmento di pubblico personalizzato, le tecnologie pubblicitarie per gli acquirenti che non hanno un SDK nelle app devono collaborare con quelle che hanno una presenza on-device, come i partner di misurazione mobile (MMP) e le Supply-Side Platform (SSP). The Protected L'API Audience mira a supportare questi SDK fornendo soluzioni flessibili per la gestione personalizzata dei segmenti di pubblico attivando i chiamanti sul dispositivo creazione di segmenti di pubblico 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 entrare in un segmento di pubblico personalizzato in due modi:

joinCustomAudience()

Un'app o un SDK può richiedere di unirsi a un segmento di pubblico personalizzato chiamando joinCustomAudience() dopo aver creato l'istanza dell'oggetto CustomAudience con e 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 un ad tech che non ha una presenza sul dispositivo chiamando fetchAndJoinCustomAudience() con i parametri previsti, come nell'esempio seguente:

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

fetchAndJoinCustomAudience(fetchRequest);

L'endpoint URL, di proprietà dell'acquirente, risponde con un oggetto JSON CustomAudience nel corpo della risposta. I campi Acquirente e Proprietario del segmento di pubblico personalizzato sono ignorati (e vengono compilati automaticamente dall'API). L'API impone inoltre che l'applicazione inoltre, l'URL di aggiornamento corrisponderà 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 dalla eTLD+1 di fetchUri. L'identità dell'acquirente di CustomAudience viene utilizzata per eseguire gli stessi controlli di registrazione e autorizzazione dell'app eseguiti da joinCustomAudience() e non può essere modificata dalla risposta del recupero. Il proprietario di CustomAudience è 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 GET HTTP a fetchUri e prevede 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 di più sulla corrente requisiti e limitazioni nella nostra Guida per gli sviluppatori.

Qualsiasi risposta di errore HTTP da parte dell'acquirente fa sì che fetchAndJoinCustomAudience errore. In particolare, una risposta dello stato HTTP di blocchi 429 (troppe richieste) 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 a il chiamante dell'API responsabile di riprovare a causa di errori temporanei (come server non risponde) o che gestisce gli errori persistenti (come la convalida dei dati o altri errori non di transito nella comunicazione con il server).

L'oggetto CustomAudienceFetchRequest consente al chiamante dell'API di definire informazioni per il segmento di pubblico personalizzato utilizzando le proprietà facoltative mostrate in dell'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 dall'autore della chiamata dell'API è inclusa 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 la dimensione è superato, la chiamata API fetchAndJoinCustomAudience non riesce.

La mancanza di un controllo k-anon ti consente di utilizzare fetchUri per la verifica dell'acquirente e di attivare la condivisione delle informazioni tra l'acquirente e l'SDK. Per agevolare la personalizzazione, della verifica del pubblico, l'acquirente può fornire una verifica di accesso. 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.

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 vengono creati a loro nome.
  • 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 nell'SDK o nel backend del proprietario oppure potrebbe essere recuperato in tempo reale dall'SDK del proprietario dal server dell'acquirente.

Lasciare un segmento di pubblico personalizzato

Il proprietario di un segmento di pubblico personalizzato può scegliere di uscire chiamando leaveCustomAudience(), come mostrato nello snippet di codice illustrativo 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 scadono e vengono rimossi dallo store sul dispositivo dopo un periodo prestabilito di nel tempo. Devi determinare il valore predefinito. Il proprietario può eseguire l'override 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 le 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. In questo caso, tutti i segmenti di pubblico personalizzati esistenti sul dispositivo vengono cancellati.
• Gli utenti hanno la possibilità di disattivare completamente Privacy Sandbox su Android, inclusa l'API Protected Audience. Se l'utente ha 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 il metodo quando l'app è in primo piano e forniscono le proprietà complete un segmento di pubblico personalizzato, direttamente o tramite delega. Tuttavia, non sempre a disposizione di inserzionisti e fornitori di tecnologia pubblicitaria per definire a quali segmenti di pubblico a cui appartengono in tempo reale mentre usano l'app.

Per facilitare questa operazione, il team ad tech può chiamare il API scheduleCustomAudienceUpdate(). Questa API consente al chiamante di specificare ritardo nel momento in cui deve essere effettuata la chiamata API, fornendo quindi tempo aggiuntivo della tecnologia pubblicitaria che risponda per elaborare gli eventi a livello di app e determinare quali Segmenti di pubblico protetti a cui 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, verrà eseguito periodicamente un job in background e invierà le richieste. La ScheduleCustomAudienceUpdateRequest 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 e non è necessario che sia esplicitamente fornito e non può essere modificato dalla risposta dell'aggiornamento. Il comando GET prevede un oggetto JSON contenente un elenco di customAudience oggetti in per tornare indietro.
• 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 personalizzati parzialmente costruiti. Ciò consente agli SDK in-app di pubblicare il doppio 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 fetchAndJoinCustomAudience() API che consente la condivisione di informazioni simili.

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

Autorizzazioni e controllo delle app

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

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

La progettazione di questa funzionalità è ancora in fase di sviluppo e i dettagli saranno incluse 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 di un segmento di pubblico personalizzato.
• I tecnici pubblicitari possono collaborare con app o SDK per fornire token di verifica che siano utilizzati per verificare la creazione di un segmento di pubblico personalizzato. Quando questo processo viene delegato a un partner, la creazione di segmenti di pubblico personalizzati può essere configurata in modo da richiedere l'accettazione dalla tecnologia pubblicitaria.
• Un fornitore di tecnologia pubblicitaria può scegliere di disattivare le chiamate joinCustomAudience per suo conto e consentire solo all'API fetchAndJoinCustomAudience di attivare tutti i segmenti di pubblico personalizzati delle chiamate. Il controllo può essere aggiornato durante la registrazione a Privacy Sandbox. Tieni presente 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, possono essere incluse informazioni sulla campagna pubblicitaria e criteri di targeting come località e lingua.
• URL di rendering: endpoint per il rendering della creatività dell'annuncio.
• Filtro:informazioni facoltative necessarie 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 per la 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.

Le piattaforme di ad tech oggi in genere eseguono offerte e 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 dei candidati verranno recuperati dalla banda (ovvero non nel contesto in cui gli annunci ). 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 fuori banda, i modelli di offerta correnti possono devono essere aggiornati. 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 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 recupera il codice JavaScript fornito dal lato acquisti basato sull'endpoint URL pubblico definito da all'"URL della logica di offerta" del segmento di pubblico personalizzato metadati. 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.

La progettazione delle selezioni di annunci che non prevedono segmenti di pubblico personalizzati è poco attiva la progettazione.

Avvia 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 richiamando il metodo selectAds() dopo aver creato l'istanza l'oggetto AdSelectionConfig con i parametri previsti:

• Venditore: identificatore della piattaforma pubblicitaria lato vendite, conforme al dominio eTLD+1 formato
• URL logica decisionale: quando viene avviata un'asta dell'annuncio, la piattaforma utilizza questo URL per recuperare il codice JavaScript dalla Sell-Side Platform e assegnare un punteggio a 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à.
• 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 esaustive utili per determinare le offerte.

Il seguente snippet di codice illustrativo mostra l'avvio dell'SDK di una piattaforma di tecnologia pubblicitaria il flusso di lavoro di selezione degli annunci definendo prima AdSelectionConfig e poi richiamando selectAds per ottenere l'annuncio vincente:

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

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

Logica di offerta lato acquisti

In genere, la logica di offerta è fornita dalle piattaforme lato acquisti. Lo scopo di il codice consente di 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 esistono più fornitori di logica di offerta, il sistema non garantisce la sequenza di esecuzione tra i fornitori.

La funzione prevede i seguenti parametri:

• Annuncio: l'annuncio considerato dal codice delle offerte lato acquisti. Si tratterà di Annuncio di un segmento di pubblico personalizzato idoneo
• Indicatori asta: indicatori sell-side specifici della piattaforma.
• 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.
• 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. Un AdTech può definire Endpoint URL da cui è possibile recuperare questi dati in tempo reale e l'insieme di chiavi per il quale deve essere eseguita la ricerca in tempo reale. Le risorse della piattaforma di ad tech che gestisce questa richiesta sarà un server attendibile gestito la piattaforma ad tech.
• Indicatori di contesto: possono includere timestamp approssimativi o informazioni sulla località o costo per clic sull'annuncio.
• Indicatori utente: potrebbero essere incluse informazioni come i dati dei pacchetti installati disponibili.

Costo dell'annuncio

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

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

Se questo annuncio è il vincitore, adCost viene arrotondato in modo stocastico a 8 bit per motivi di privacy. Il valore arrotondato di adCost viene quindi passato al valore 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 disponibili durante la fase di selezione degli annunci. Ad esempio, piattaforme di ad tech qui puoi implementare le funzionalità di quota limite. Se sono presenti più fornitori di filtri, il sistema non garantisce la sequenza di esecuzione tra i fornitori.

La logica di filtro lato acquisti può essere implementata come parte 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 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 sono presenti più fornitori di logica decisionale, il sistema non garantisce la sequenza di esecuzione tra i fornitori. La piattaforma utilizzerà l'"URL della logica decisionale" input dell'API selectAds() per recuperare il codice JavaScript che dovrebbe includi 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. 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 ad tech si basano su dati in tempo reale per per definire il filtro 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 il traffico questa richiesta deve essere un server affidabile gestito dalla tecnologia pubblicitaria.
• Indicatore di contesto: può includere un timestamp approssimativo o i dati sulla posizione.
• Indicatore dell'utente: può includere informazioni quali lo store che ha avviato l'installazione dell'app.
• Indicatore pubblico personalizzato: se l'annuncio a cui viene assegnato un punteggio proviene da un pubblico personalizzato sul dispositivo, questo indicatore conterrà informazioni come il lettore e il nome del pubblico personalizzato.

Esecuzione del codice di selezione degli annunci

Nella proposta, il sistema recupererà il codice dell'asta fornito dalla piattaforma di tecnologia pubblicitaria da endpoint URL configurabili ed essere eseguiti sul dispositivo. Data la risorsa vincoli sui dispositivi mobili, il codice asta deve rispettare le seguenti linee guida:

• L'esecuzione del codice dovrebbe terminare entro un periodo di tempo predefinito. Questo limite verranno applicati in modo uniforme a tutte le reti pubblicitarie dell'acquirente. 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 logica di offerta potrebbe richiedere l'accesso a un account utente privato come le origini di installazione delle app, il runtime non fornisce l'accesso 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 piattaforme che supportano Privacy Sandbox.

Rendering dell'annuncio vincente

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

Il piano prevede l'evoluzione della soluzione per garantire che le informazioni relative agli l'appartenenza a un segmento di pubblico personalizzato o la cronologia del coinvolgimento in app non possono essere determinate da all'app o all'SDK tramite le informazioni sull'annuncio vincente (simile ai modelli proposta di frame recintati).

Report sulle impressioni e sugli eventi

Una volta visualizzato l'annuncio, l'impressione vincente può essere riportata a le piattaforme lato acquisti e lato vendite partecipanti. In questo modo acquirenti e venditori per includere informazioni dall'asta, ad esempio l'offerta o il segmento di pubblico personalizzato con il 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. Consente di includere informazioni sull'asta (offerta, nome del segmento di pubblico personalizzato ecc.) con clic, visualizzazioni e altro eventi annuncio. La piattaforma richiama la logica di reporting 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: lato vendite e lato acquisti JavaScript deve registrare l'evento per il quale deve ricevere i report sugli eventi. Il lato vendite è responsabile di generare report sulle informazioni a livello di evento.

Protected Audience offre un meccanismo per iscriversi a eventi futuri relativi a un'asta vincente registrando i beacon. In reportResult() di un venditore JavaScript, le Sell-Side Platform possono registrare beacon utilizzando della piattaforma registerAdBeacon(). Analogamente, le piattaforme di acquisto possono chiamare la funzione registerAdBeacon() dalla funzione JavaScript reportWin().

registerAdBeacon(beacons)

Input:

• event_key: una stringa che indica il tipo di interazione per cui registrare. 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 lato vendite responsabile di generare 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(), sono le Sell-Side Platform (piattaforme lato vendite) dell'asta sono sempre idonei a ricevere questi report sugli eventi. Solo il la piattaforma lato acquisti vincente è idonea a ricevere questi report.

Report lato vendite

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 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 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 del reportResult lato vendite. Ciò fornisce la Sell-Side Platform (piattaforma lato vendite) con l'opportunità di condividere i dati con il 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 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 reporting sono possibili solo dopo che la generazione di report sulle impressioni per l'asta è completata. L'SDK sell-side è responsabile della segnalazione di eventuali eventi. La espone un'API che prende un ReportEventRequest che specifica eseguito di recente, ovvero la chiave dell'evento registrata nei report, i dati associati chiave, se il report deve essere inviato all'acquirente o al venditore (oppure entrambi) e un evento di input facoltativo per gli eventi annuncio. 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 essere 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 completamente gestita. 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. È un oggetto InputEvent (per un evento clic) o nullo. (per un evento di visualizzazione). Per saperne di più, consulta Integrazione dell'API Attribution Reporting su questo parametro.

Dopo che l'SDK lato vendite richiama reportEvent e, a seconda del flag reporting_destinations, la piattaforma tenta di abbinare event_key a le chiavi registrate da acquirenti e venditori nei loro reportWin e reportResult Funzioni JavaScript. Se c'è una corrispondenza, la piattaforma PUBBLICA event_data all'elemento reporting_url associato. Il tipo di contenuto della richiesta è testo normale con il corpo event_data. Questa richiesta viene effettuata secondo il criterio del "best effort" e non genera alcun messaggio in caso di errore di rete, risposta di errore del server o se non vengono trovate chiavi corrispondenti.

Integrazione dell'API Attribution Reporting

Per supportare gli acquirenti che partecipano a un'asta Protected Audience, fornendo funzionalità cross-API per Protected Audience e Attribution API di reporting (ARA). Questa funzionalità consente ai tecnici pubblicitari di valutare rendimento dell'attribuzione in diverse tattiche di remarketing, in modo che possano a 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 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 segnalare le interazioni di questi eventi con Protected Audience fornire 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 trasmettere CustomAudience (o altri contenuti contestuali pertinenti informazioni sull'annuncio, come il posizionamento o la durata di visualizzazione), utilizzando l'URL. in modo che questi metadati possano propagarsi nei report di riepilogo quando la tecnologia pubblicitaria esaminare il rendimento aggregato delle campagne.

Abilitazione della registrazione di origine

reportEvent() accetterà un nuovo parametro facoltativo InputEvent. Vincita Gli acquirenti che registrano beacon degli annunci possono scegliere quali report sugli eventi report registrate 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(). Qualsiasi risposta con intestazioni ARA appropriate verranno analizzati allo stesso modo di qualsiasi altra normale registrazione di un'origine ARA come risposta. Consulta il messaggio esplicativo 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 visualizzazione.

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

Esempio di report sul coinvolgimento e sulle conversioni

In questo esempio, lo esamineremo dal punto di vista dell'acquirente interessato 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 dell'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 come parte la risposta all'offerta in tempo reale ("RTB") di pubblicità programmatica. L'ID può essere impostato come una variabile come 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 degli annunci per Essere attivati durante il rendering dell'annuncio e per eventi di interazione specifici (registerAdBeacon()). Per associare gli indicatori di asta a un evento dell'annuncio, imposta auctionId come parametro di query dell'URL di beaconing.
2. Durante il tempo di rendering dell'annuncio, i beacon che hai registrato al momento dell'asta possono essere possono essere attivati o migliorati con i dati a livello di evento. Il venditore deve attivare reportEvent() e trasmetti i dati a livello di evento. La piattaforma invierà un ping l'URL di beaconing dell'annuncio registrato dell'acquirente correlato al reportEvent() che è stata attivata.
3. L'acquirente registrerà l'annuncio con l'API Attribution Reporting rispondendo alle richieste di beacon degli annunci con l'intestazione Attribution-Reporting-Register-Source. Per associare gli indicatori delle aste per un evento di conversione, imposta auctionId nell'URL di origine della registrazione.

Al termine della procedura descritta sopra, l'acquirente dispone di un rapporto sulle aste, sul report sulle interazioni e sul report sulle conversioni, che possono essere correlati utilizzando ID univoco che può essere utilizzato per l'associazione tra loro.

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

Server 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. Al fine di ridurre al minimo la fuga di informazioni sensibili tramite a questi server la proposta richiama le seguenti restrizioni:

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

Lato acquisti: dopo che il lato acquisti ha avviato la logica di offerta lato acquisti, la piattaforma esegue un recupero HTTP dei dati di Trusted Bidding dal server attendibile. L'URL viene composto aggiungendo l'URL e le chiavi presenti nei metadati di Trusted Bidding Signals del segmento di pubblico personalizzato in lavorazione. Questo recupero viene eseguito solo durante l'elaborazione degli annunci 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 delle offerte affidabili, in base ai metadati degli indicatori delle offerte affidabili del segmento di pubblico personalizzato:

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

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

Sell side: come nel flusso di acquisto precedente, il sell side potrebbe voler recuperare informazioni sulle creatività prese in considerazione nell'asta. Ad esempio, un publisher potrebbe voler imporre che determinate creatività non vengano mostrate nella loro app in base al problemi 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 tramite un recupero HTTP. L'URL è composto aggiungendo l'URL degli indicatori di punteggio attendibili agli URL di rendering delle creatività per il quale devono essere recuperati i dati.

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

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

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

Questi server funzionerebbero in modo affidabile per offrire diverse soluzioni di sicurezza e vantaggi per la privacy:

• È possibile considerare attendibile il valore restituito dal server per ogni chiave, in modo che sia basato solo su 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 per le offerte da qualsiasi server, incluso uno di loro. Tuttavia, release, la richiesta verrà inviata solo a una coppia chiave-valore attendibile server web.

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.