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

Inviare un feedback

Aggiornamenti recenti

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

Con Protected Audience puoi:

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

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

Cronologia

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

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

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 possono essere associate ad annunci candidati pertinenti per il pubblico e arbitrarie come gli indicatori di offerta. 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.
di Gemini Advanced.
Grafico di flusso che mostra il flusso di lavoro personalizzato per la gestione dei segmenti di pubblico e la selezione degli annunci in Privacy Sandbox su Android.
di Gemini Advanced.

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 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 ad tech per mostrare i suoi annunci agli utenti nel proprio 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 facilita la generazione di report sulle impressioni e sulla selezione degli annunci personalizzati. 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 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 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. 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 sull'annuncio. 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 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 ulteriori 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 metadati degli annunci specifici della piattaforma di tecnologia pubblicitaria e un URL per il rendering dell'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'URL di aggiornamento giornaliero quando è 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. 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). 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 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 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 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 controllo. 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 non riuscito. 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 la risposta dell'acquirente ricevuta dalla piattaforma; l'API Protected Audience ignora nei campi della 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 la dimensione è superato, la chiamata API fetchAndJoinCustomAudience non riesce.

In assenza di un assegno k-anon puoi utilizzare fetchUri per la verifica dell'acquirente e abilitare 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 sul dispositivo deve includere questo token in fetchUri affinché l'endpoint ospitato dall'acquirente può recuperare i contenuti del segmento di pubblico personalizzato usa il token di verifica per verificare che fetchAndJoinCustomAudience() corrisponde all'acquirente e proviene da un partner. 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 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 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 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, gli eventuali 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 di 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 programmati

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 delayedCustomUpdates List of Delayed Update events that trigger a
* call to DSP endpoint provided inside the DelayedCustomUpdate object
*/

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

DelayedCustomAudienceUpdate

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

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

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

Il DelayedCustomAudienceUpdate contiene le informazioni necessarie per la registrazione di un job in ritardo per l'esecuzione sulla piattaforma. Dopo il ritardo specificato, verrà eseguito periodicamente un job in background e invierà le richieste. La DelayedCustomAudienceUpdate può contenere le seguenti informazioni:

  • UpdateUri: endpoint URI a cui verrebbe inviata una chiamata GET per recuperare l'aggiornamento. L'identità dell'acquirente viene dedotta intrinsecamente dall'eTLD+1 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.
di Gemini Advanced.
  • 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.

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 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 consente tutte le tecnologie pubblicitarie o nessuna. A causa delle limitazioni della piattaforma, le autorizzazioni di delega non possono essere basate sulla 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 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 ad tech dovranno prepararsi ad avere alcune parti dell'asta e della logica di selezione degli annunci di cui è stato eseguito il deployment 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.

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

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 vendite viene inoltre trasmesso come input per avviare il flusso di lavoro di selezione degli annunci.

La progettazione delle selezioni di annunci che non prevedono segmenti di pubblico personalizzati è 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 richiamare questa funzione per tutti gli annunci (contestuali o di remarketing) in sequenza. Se sono presenti più fornitori di logica di offerta, il sistema non garantisce la sequenza di esecuzione tra i provider.

La funzione prevede i seguenti parametri:

  • Annuncio: l'annuncio considerato dal codice delle offerte lato acquisti. Si tratterà di Annuncio di un segmento di pubblico personalizzato idoneo
  • Indicatori d'asta: indicatori lato vendite e specifici per piattaforma.
  • Indicatori per acquirente: le parti della domanda partecipanti possono utilizzare questo parametro per forniscono 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 includere informazioni quali i fornitori di servizi installati le informazioni sul pacchetto.

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 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 ci sono più parametri provider di filtro, 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 ci sono più parametri dai 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 potrebbe bloccare una campagna pubblicitaria in modo che non mostri annunci nell'app. Questi dati vengono recuperati da account attendibili degli indicatori di punteggio parametro URL 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 del segmento di pubblico personalizzato: se l'annuncio a cui viene assegnato un punteggio proviene da un dispositivo segmento di pubblico personalizzato, conterrà informazioni quali il lettore e il nome il 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 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, il lato vendite e le piattaforme lato acquisti vincente sono idonee a ricevere ulteriori vantaggi a livello di evento e creare report 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 lato vendite.
  2. Report lato acquisti.

In questo modo le piattaforme lato acquisti e lato vendite possono inviare importanti comunicazioni sul dispositivo i dati ai server per abilitare funzionalità come la definizione del budget in tempo reale, aggiornamenti dei modelli di offerta e flussi di lavoro di fatturazione precisi. 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 lato acquisti possono chiamare il metodo registerAdBeacon() dalla funzione JavaScript reportWin().

registerAdBeacon(beacons)

Input:

  • event_key: una stringa che indica il tipo di interazione da utilizzare. Viene utilizzato come chiave per cercare il punto finale a cui la piattaforma invia un ping mentre registrando i 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 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 lato vendite è responsabile della generazione di report su tutti gli 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 vendite che descrive l'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 contenuti della richiesta è un testo normale con il corpo event_data. Questa richiesta è stata effettuata nel miglior modo possibile senza sforzi e fallisce automaticamente in caso di errore di rete, errore del server o se non sono state trovate chiavi corrispondenti.

Integrazione dell'API Attribution Reporting

Per supportare gli acquirenti che partecipano a un'asta Protected Audience, 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 di URI chiave-valore da utilizzare per entrambi 1) report sull'interazione con gli annunci e 2) registrazione dell'origine.
  • Includere i dati dell'asta dell'asta Protected Audience nel lato origine mappatura delle chiavi per report di riepilogo aggregati (utilizzando Attribution Reporting API) Per ulteriori informazioni, consulta la proposta di progettazione 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. La richiesta l'intestazione Attribution-Reporting-Idoneo verrà aggiunta a tutti i report sugli eventi richieste 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, dopo l'asta, l'elemento eventData potrebbe contenere informazioni sensibili, pertanto elimina eventData nelle richieste di registrazione dell'origine reindirizzate.

Esempio di report sul coinvolgimento e sulle conversioni

In questo esempio, lo esamineremo dal punto di vista dell'acquirente che è interessato nell'associazione dei dati dell'asta, dell'annuncio visualizzato e dell'app di conversione in sinergia.

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 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 entro il giorno rispondere alle richieste di beacon degli annunci con 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 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. Entrambi le piattaforme lato acquisti e lato vendite potranno ottenere queste informazioni ai 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. 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 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 server attendibile lato acquisti, la ricerca lato server attendibile avviene anche 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 informazioni sulle creatività considerate nel basata sugli 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 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 queste offerte e segnali da qualsiasi server, incluso quello che gestiscono autonomamente. Tuttavia, release, la richiesta verrà inviata solo a una coppia chiave-valore attendibile o 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.