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 è stato rinominato API Protected Audience.
- È stata aggiunta una proposta per la delega dei segmenti di pubblico personalizzati.
- È stato rimosso il requisito di k-anonymity per l'URL di aggiornamento giornaliero.
Protected Audience è in versione beta ed è disponibile per i test su dispositivi pubblici.
Con Protected Audience puoi:
- Gestisci i segmenti di pubblico personalizzati in base alle azioni precedenti degli utenti.
- Avvia aste on-device con il supporto della mediazione a cascata o singolo venditore.
- Esercitati con i report sulle impressioni dopo la selezione degli annunci.
Per iniziare, leggi la guida per gli sviluppatori di Protected Audience. Il tuo feedback è importante per noi durante lo sviluppo di Protected Audience.
Sequenza temporale
Nei prossimi mesi lanceremo nuove funzionalità. Le date di uscita esatte variano a seconda della funzionalità e questa tabella verrà aggiornata con i link alla documentazione non appena disponibile.
Funzionalità | Disponibile in Anteprima per gli sviluppatori | Disponibile in versione beta |
---|---|---|
Report a livello di evento | T1 '23 | T3 '23 |
Mediazione con struttura a cascata | T1 '23 | T4 2023 |
Filtro annunci per l'installazione di app | T2 2023 | T3 '23 |
Filtro della quota limite | T2 2023 | T3 '23 |
Trasmettere gli annunci contestuali al flusso di lavoro di selezione degli annunci per l'applicazione di filtri | T2 2023 | T3 '23 |
Report sulle interazioni | T2 2023 | T3 '23 |
Partecipare alla delega dei segmenti di pubblico personalizzati | T3 '23 | T4 2023 |
fatturazione non CPM | T3 '23 | T4 2023 |
Integrazione dei servizi di offerte e aste | T3 '23 | T4 2023 |
Report di debug | T3 '23 | T4 2023 |
Integrazione dei report sull'attribuzione | N/A | T4 2023 |
Mediazione Open Bidding | T4 2023 | T4 2023 |
Gestione della valuta | T1 24 | T2 2024 |
Integrazione K-anon | N/A | T2 2024 |
Integrazione dei report aggregati | T3 2024 | T4 '24 |
Panoramica
Nella pubblicità mobile, di solito gli inserzionisti devono mostrare annunci a utenti potenzialmente interessati in base a come hanno precedentemente interagito con l'app dell'inserzionista. Ad esempio, lo sviluppatore di SportingGoodsApp potrebbe voler fare pubblicità per gli utenti che hanno lasciato degli articoli nel carrello degli acquisti, mostrando annunci per ricordare agli utenti di completare l'acquisto. Di solito, il settore descrive questa idea generale con termini quali "remarketing" e "targeting per pubblico personalizzato".
Oggi, questi casi d'uso in genere vengono implementati condividendo informazioni contestuali su come viene mostrato l'annuncio (ad esempio il nome dell'app) e informazioni private come gli elenchi dei segmenti di pubblico con le piattaforme di tecnologia pubblicitaria. Utilizzando queste informazioni, gli inserzionisti possono selezionare annunci pertinenti sui propri server.
L'API Protected Audience su Android (precedentemente nota come FLEDGE) comprende le seguenti API per piattaforme di tecnologia pubblicitaria e inserzionisti al fine di supportare casi d'uso comuni basati sull'interazione, in modo da limitare la condivisione di identificatori tra le app e delle informazioni sull'interazione di un utente con terze parti:
- API Custom Audience: si concentra sull'astrazione "segmento di pubblico personalizzato", che rappresenta un segmento di pubblico designato dall'inserzionista con intenzioni comuni. Le informazioni sul pubblico vengono memorizzate sul dispositivo e possono essere associate ad annunci candidati pertinenti per il segmento di pubblico e a metadati arbitrali, come gli indicatori di offerta. Queste informazioni possono essere utilizzate per definire le offerte degli inserzionisti, i filtri degli annunci e il rendering.
- API Ad Selection: fornisce un framework che orchestra i flussi di lavoro delle piattaforme di tecnologia pubblicitaria che sfruttano gli indicatori sul dispositivo per determinare un annuncio "vincente" considerando gli annunci candidati archiviati localmente ed eseguendo ulteriori elaborazioni sugli annunci candidati che una piattaforma di tecnologia pubblicitaria restituisce al dispositivo.
A livello generale, l'integrazione funziona nel seguente modo:
SportingGoodsApp vuole ricordare ai suoi utenti di acquistare articoli di merchandising lasciati nel carrello se non hanno completato l'acquisto entro 2 giorni. SportingGoodsApp utilizza l'API Custom Audience per aggiungere l'utente all'elenco del segmento di pubblico "Prodotti nel carrello". La piattaforma gestisce e memorizza questo elenco del segmento di pubblico sul dispositivo, limitando la condivisione con terze parti. SportingGoodsApp collabora con una piattaforma di ad tech per mostrare i suoi annunci agli utenti nel suo elenco del segmento di pubblico. La piattaforma di ad tech gestisce i metadati per gli elenchi dei segmenti di pubblico e fornisce annunci candidati, che vengono messi a disposizione del flusso di lavoro di selezione degli annunci per la valutazione. La piattaforma può essere configurata per recuperare periodicamente annunci basati sul pubblico aggiornati in background. In questo modo, l'elenco di annunci candidati basati sul pubblico è aggiornato e non è correlato alle richieste inviate agli ad server di terze parti durante l'opportunità di annuncio (ad es. una richiesta di annuncio contestuale).
Quando l'utente gioca a FrisbeeGame sullo stesso dispositivo, potrebbe visualizzare un annuncio che lo invita a completare l'acquisto degli articoli rimasti nel carrello di SportingGoodsApp. A questo scopo, FrisbeeGame (con un SDK per gli annunci integrato) richiama l'API Ad Selection per la selezione di un annuncio vincente per l'utente in base all'elenco del segmento di pubblico di cui potrebbe far parte (in questo esempio, il segmento di pubblico personalizzato "prodotti nel carrello" creato da SportingGoodsApp). Il flusso di lavoro di selezione degli annunci può essere impostato in modo da prendere in considerazione gli annunci recuperati dai server delle piattaforme di tecnologia pubblicitaria, oltre agli annunci on-device associati ai segmenti di pubblico personalizzati e ad altri indicatori on-device. Il flusso di lavoro può anche essere personalizzato dalla piattaforma ad tech e dall'SDK per gli annunci con offerte personalizzate e logiche di punteggio per raggiungere gli obiettivi pubblicitari appropriati. Questo approccio consente ai dati sugli interessi dell'utente o sulle interazioni con l'app di indirizzare la selezione degli annunci, limitando la condivisione di questi dati con terze parti.
L'SDK dell'app di pubblicazione degli annunci o della piattaforma di tecnologia pubblicitaria mostra l'annuncio selezionato.
La piattaforma semplifica la generazione di report sulle impressioni e sui risultati della selezione degli annunci. Questa funzionalità di reporting è complementare all'API Attribution Reporting. Le piattaforme di ad tech possono personalizzare in base alle esigenze di reporting.
Ottenere l'accesso a Protected Audience sulle API Android
Le piattaforme di ad tech devono registrarsi per accedere all'API Protected Audience. Per ulteriori informazioni, consulta la pagina Registrazione per un account Privacy Sandbox.
Gestione dei segmenti di pubblico personalizzati
Segmento di pubblico personalizzato
Un segmento di pubblico personalizzato rappresenta un gruppo di utenti determinato dall'inserzionista con intenzioni o interessi comuni. Un'app o un SDK può utilizzare un segmento di pubblico personalizzato per indicare un determinato segmento, ad esempio qualcuno che ha "lasciato articoli nel carrello" o "ha completato i livelli per principianti" di un gioco. La piattaforma gestisce e archivia le informazioni sul pubblico localmente sul dispositivo e non mostra a quali segmenti di pubblico personalizzati si trova l'utente. I segmenti di pubblico personalizzati sono distinti dai gruppi di interesse di Protected Audience di Chrome e non possono essere condivisi tra web e app. Ciò consente di limitare la condivisione delle informazioni degli utenti.
L'app di un inserzionista o l'SDK integrato può join o abbandonare un segmento di pubblico personalizzato in base, ad esempio, al coinvolgimento degli utenti in un'app.
Metadati dei segmenti di pubblico personalizzati
Ogni segmento di pubblico personalizzato contiene i seguenti metadati:
- Proprietario: nome del pacchetto dell'app del proprietario. È impostato implicitamente sul nome del pacchetto dell'app del chiamante.
- Acquirente: rete pubblicitaria dell'acquirente che gestisce gli annunci per questo segmento di pubblico personalizzato. L'acquirente rappresenta anche la parte che può accedere al segmento di pubblico personalizzato e recuperare le informazioni pertinenti sull'annuncio. L'acquirente viene specificato in base al formato eTLD+1.
- Nome: un nome o un identificatore arbitrario per il segmento di pubblico personalizzato, ad esempio un utente con "utenti che hanno abbandonato il carrello degli acquisti". Questo attributo può essere utilizzato, ad esempio, come uno dei criteri di targeting nelle campagne pubblicitarie dell'inserzionista o come stringa di query nell'URL per recuperare il codice di offerta.
- Ora di attivazione e ora di scadenza: questi campi definiscono l'intervallo temporale in cui entrerà in vigore il segmento di pubblico personalizzato. La piattaforma utilizza queste informazioni per ritirare l'appartenenza a un pubblico personalizzato. La scadenza non può superare una finestra di durata massima per limitare la durata di un segmento di pubblico personalizzato.
- URL di aggiornamento giornaliero: l'URL utilizzato dalla piattaforma per recuperare annunci candidati e altri metadati definiti nei campi "Indicatori offerte per l'utente" e "Indicatori di offerta attendibili" su base ricorrente. Per ulteriori dettagli, consulta la sezione su come recuperare annunci candidati per segmenti di pubblico personalizzati.
- Indicatori di offerta per l'utente: indicatori specifici della piattaforma per la tecnologia pubblicitaria per qualsiasi offerta di annunci di remarketing. Esempi di indicatori includono: la posizione approssimativa dell'utente, le impostazioni internazionali preferite e così via.
- Dati sulle offerte attendibili: le piattaforme di ad tech si basano su dati in tempo reale per raccogliere e valutare gli annunci. Ad esempio, un annuncio potrebbe esaurire il budget e la pubblicazione deve essere interrotta immediatamente. Un ad-tech può definire un endpoint URL da cui è possibile recuperare questi dati in tempo reale e l'insieme di chiavi per le quali è necessario eseguire la ricerca in tempo reale. Il server che gestisce questa richiesta sarà un server attendibile gestito dalla piattaforma ad tech.
- URL logica di offerta: l'URL utilizzato dalla piattaforma per recuperare il codice di offerta dalla Demand-Side Platform. La piattaforma esegue questo passaggio quando viene avviata un'asta dell'annuncio.
- Annunci:un elenco di annunci candidati per il segmento di pubblico personalizzato. Sono inclusi metadati degli annunci specifici della piattaforma di tecnologia pubblicitaria e un URL per eseguire il rendering dell'annuncio. Quando viene avviata un'asta per il segmento di pubblico personalizzato, viene preso in considerazione questo elenco di metadati dell'annuncio. Se possibile, questo elenco di annunci verrà aggiornato utilizzando l'endpoint URL di aggiornamento giornaliero. A causa della carenza di risorse sui dispositivi mobili, esiste un limite al numero di annunci che possono essere archiviati in un segmento di pubblico personalizzato.
Delega segmenti di pubblico personalizzati
La definizione e la configurazione dei segmenti di pubblico personalizzati tradizionali in genere si basano su tecnologie lato server e integrazioni basate su tecnologie pubblicitarie in collaborazione con clienti e partner di agenzie e inserzionisti. L'API Protected Audience consente la definizione e la configurazione di segmenti di pubblico personalizzati proteggendo al contempo la privacy degli utenti. Per entrare a far parte di un segmento di pubblico personalizzato, i tecnici pubblicitari degli acquirenti che non hanno una presenza SDK nelle app devono collaborare con quelli che hanno una presenza sul dispositivo, come i partner di misurazione mobile (MMP) e le Supply-Side Platform (SSP). L'API Protected Audience mira a supportare questi SDK fornendo soluzioni flessibili per la gestione dei segmenti di pubblico personalizzati, consentendo ai chiamanti sul dispositivo di richiamare la creazione di segmenti di pubblico personalizzati per conto degli acquirenti. Questa procedura è chiamata delega dei segmenti di pubblico personalizzati. Per configurare la delega per i segmenti di pubblico personalizzati:
Entrare a far parte di un segmento di pubblico personalizzato
Puoi entrare in un segmento di pubblico personalizzato in due modi:
joinCustomAudience()
Un'app o un SDK può richiedere di partecipare a un segmento di pubblico personalizzato chiamando
joinCustomAudience()
dopo aver creato un'istanza dell'oggetto CustomAudience
con i
parametri previsti. Di seguito è riportato un esempio di snippet di codice illustrativo:
CustomAudience audience = new CustomAudience(
Buyer = "example-dsp.com",
Name = "running-shoes",
ActivationTime = now(),
ExpirationTime = ActivationTime.plus(30 days),
DailyUpdateURL = Uri.parse("https://..."),
UserBiddingSignals = new JSONObject("{...}"),
TrustedBiddingURL = Uri.parse("https://..."),
TrustedBiddingKeys = {'key1","key2", ...,"key n"},
BiddingLogicURL = Uri.parse("https://..."),
Ads = [new AdData(renderUrl = Uri.parse("https://..."),
metadata = new JSONObject("{...}"), ...];
// Invoke ad services API to join a custom audience.
joinCustomAudience(audience);
fetchAndJoinCustomAudience()
Un'app o un SDK può richiedere di unirsi a un segmento di pubblico personalizzato per conto di una tecnologia pubblicitaria che
non ha una presenza sul dispositivo chiamando fetchAndJoinCustomAudience()
con i parametri previsti, come nell'esempio seguente:
FetchAndJoinCustomAudienceRequest fetchRequest = new FetchAndJoinCustomAudienceRequest(
// Example: Optional verification token passed inside the fetch URL
FetchURI = Uri.parse("https://example-dsp.com/...?mytoken=arbitrary1234"),
// All the following parameters are optional
Name = "running-shoes",
ActivationTime = now(),
ExpirationTime = ActivationTime.plus(30 days),
UserBiddingSignals = new JSONObject("{...}")
);
fetchAndJoinCustomAudience(fetchRequest);
L'endpoint URL, di proprietà dell'acquirente, risponde con un oggetto JSON CustomAudience
nel corpo della risposta. I campi dell'acquirente e del proprietario del segmento di pubblico personalizzato vengono ignorati e vengono compilati automaticamente dall'API. L'API impone inoltre che l'URL di aggiornamento giornaliero corrisponda anche all'eTLD+1 dell'acquirente.
{
"name": "running-shoes",
"activation_time": 1680603133000,
"expiration_time": 1680803133000,
"user_bidding_signals" : {"signal1": "value"},
"trusted_bidding_data": {
"trusted_bidding_uri": "https://example-dsp.com/.."
"trusted_bidding_keys": ["k1", "k2"],
},
"bidding_logic_uri": "https://example-dsp.com/...",
"daily_update_uri": "https://example-dsp.com/...",
"ads": [
{
"render_uri": "https://example-dsp.com/...",
"metadata": {},
"ad_filters": {
"frequency_cap": {
"win": [
{
"ad_counter_key": 1,
"max_count": 2,
"interval_in_seconds": 60
},
],
"view": [
{
"ad_counter_key": 2,
"max_count": 10,
"interval_in_seconds": 3600
},
]
},
"app_install": {
"package_names": [
"package.name.one",
"package.name.two", ...
]
}
}
},
...
]
}
L'API fetchAndJoinCustomAudience()
determina l'identità dell'acquirente dall'eTLD+1 di fetchUri
. L'identità dell'acquirente CustomAudience
viene utilizzata per eseguire
gli stessi controlli di registrazione e autorizzazione dell'app effettuati da joinCustomAudience()
e non può essere modificata dalla risposta di recupero. Il proprietario CustomAudience
è il nome del pacchetto dell'applicazione chiamante. Non esiste nessun'altra convalida di
fetchUri
oltre al controllo eTLD+1 e, in particolare, non esiste
un controllo k-anon. L'API fetchAndJoinCustomAudience()
invia una richiesta GET HTTP a
fetchUri
e prevede un oggetto JSON che rappresenti il segmento di pubblico personalizzato. Alla risposta vengono applicati gli stessi vincoli obbligatori e facoltativi e gli stessi valori predefiniti per i campi degli oggetti pubblico personalizzati. Scopri di più sui
requisiti e sulle limitazioni attuali nella nostra Guida per gli sviluppatori.
Qualsiasi risposta di errore HTTP da parte dell'acquirente provoca un errore di fetchAndJoinCustomAudience
. In particolare, una risposta dello stato HTTP 429 (Troppe richieste) blocca
le richieste dell'applicazione corrente per un periodo da definire. La chiamata API
non va a buon fine anche se la risposta dell'acquirente non è valida. Gli errori vengono segnalati al chiamante dell'API responsabile di riprovare a causa di errori temporanei (ad esempio il server non risponde) o della gestione di errori persistenti (ad esempio errori di convalida dei dati o altri errori non di transito di comunicazione con il server).
L'oggetto CustomAudienceFetchRequest
consente al chiamante dell'API di definire alcune
informazioni per il segmento di pubblico personalizzato utilizzando le proprietà facoltative mostrate nell'esempio in alto. Se impostati nella richiesta, questi valori non possono essere sovrascritti
dalla risposta dell'acquirente ricevuta dalla piattaforma; l'API Protected Audience ignora
i campi nella risposta. Se non sono impostati nella richiesta, devono essere impostati nella risposta, poiché questi campi sono obbligatori per creare un segmento di pubblico personalizzato. Una rappresentazione JSON dei contenuti di CustomAudience
, parzialmente definita dal chiamante dell'API, è inclusa nella richiesta GET a fetchUri
in un'intestazione speciale X-CUSTOM-AUDIENCE-DATA
. La dimensione del formato serializzato
dei dati specificati per il segmento di pubblico personalizzato è limitata a 8 kB. Se la dimensione viene
superata, la chiamata API fetchAndJoinCustomAudience
non va a buon fine.
In assenza di un controllo k-anon, puoi utilizzare fetchUri
per la verifica dell'acquirente
e per attivare la condivisione delle informazioni tra acquirente e SDK. Per facilitare la verifica
dei segmenti di pubblico personalizzati, l'acquirente può fornire un token
di verifica. L'SDK sul dispositivo deve includere questo token in fetchUri
affinché
l'endpoint ospitato dall'acquirente possa recuperare i contenuti del segmento di pubblico personalizzato e
utilizzare il token di verifica per verificare che l'operazione fetchAndJoinCustomAudience()
corrisponda all'acquirente e provenga da un partner
sul dispositivo attendibile. Per condividere le informazioni, l'acquirente può concordare con il chiamante sul dispositivo
che alcune delle informazioni da utilizzare per creare il segmento di pubblico personalizzato verranno aggiunte come parametri di query a fetchUri
. In questo modo l'acquirente può controllare le chiamate e rilevare se un token di convalida è stato utilizzato da una tecnologia pubblicitaria dannosa per creare diversi segmenti di pubblico personalizzati.
Nota sulla definizione e sull'archiviazione del token di verifica
Il token di verifica non viene utilizzato per alcuno scopo dall'API Protected Audience ed è facoltativo.
- Il token di verifica può essere utilizzato dall'acquirente per verificare che i segmenti di pubblico creati vengono eseguiti per suo conto.
- La proposta dell'API Protected Audience non specifica né un formato per il token di verifica né il modo in cui l'acquirente trasferisce il token di verifica al chiamante. Ad esempio, il token di verifica potrebbe essere precaricato nell'SDK o nel backend del proprietario oppure potrebbe essere recuperato in tempo reale dall'SDK del proprietario dal server dell'acquirente.
Uscire da un segmento di pubblico personalizzato
Il proprietario di un segmento di pubblico personalizzato può scegliere di uscire chiamando
leaveCustomAudience()
, come illustrato nello snippet di codice illustrativo riportato di seguito:
// Invoke ad services API to leave a custom audience.
leaveCustomAudience(buyer, name);
Per contribuire a preservare l'utilizzo dello spazio di archiviazione e di altre risorse del dispositivo, i segmenti di pubblico personalizzati scadono e vengono rimossi dallo store sul dispositivo dopo un periodo di tempo predeterminato. Devi determinare il valore predefinito. Il proprietario può sostituire questo valore predefinito.
Controllo utenti
- La proposta intende dare agli utenti visibilità sull'elenco delle app installate che hanno creato almeno un segmento di pubblico personalizzato
- Gli utenti possono rimuovere app da questo elenco. La rimozione cancella tutti i segmenti di pubblico personalizzati associati alle app e impedisce che queste si uniscano a nuovi segmenti di pubblico personalizzati.
- Gli utenti hanno la possibilità di reimpostare completamente l'API Protected Audience. In questo caso, i segmenti di pubblico personalizzati esistenti sul dispositivo vengono cancellati.
- Gli utenti hanno la possibilità di disattivare completamente Privacy Sandbox su Android, inclusa l'API Protected Audience. Se l'utente ha disattivato Privacy Sandbox, l'API Protected Audience non va a buon fine.
La progettazione di questa funzionalità è ancora in fase di sviluppo e i dettagli verranno inclusi in un aggiornamento successivo.
Aggiornamenti programmati
Le soluzioni descritte in precedenza richiedono che l'SDK per app o ad tech richiami le API quando l'app è in primo piano e forniscano le proprietà complete del segmento di pubblico personalizzato, direttamente o mediante la delega. Tuttavia, non è sempre possibile per gli inserzionisti e i fornitori di tecnologia pubblicitaria definire a quali segmenti di pubblico appartiene un utente in tempo reale mentre utilizza l'app.
Per facilitare questa operazione, il team ad tech può chiamare
l'API scheduleCustomAudienceUpdate()
. Questa API consente al chiamante di specificare un
ritardo nel momento in cui deve essere effettuata la chiamata API, fornendo quindi tempo aggiuntivo
affinché la tecnologia pubblicitaria che risponda per elaborare gli eventi a livello di app e determinare a quali
segmenti di pubblico protetti l'utente deve partecipare o da cui deve essere rimosso.
/**
* API To schedule delayed update events for Custom Audience
*
* @param delayedCustomUpdates List of Delayed Update events that trigger a
* call to DSP endpoint provided inside the DelayedCustomUpdate object
*/
public void scheduleCustomAudienceUpdates(
@NonNull DelayedCustomUpdate delayedCustomAudienceUpdate,
@NonNull @CallBackExecutor Executor executor,
@NonNull AdServicesOutcomeReceiver<Object, Exception> receiver)
DelayedCustomAudienceUpdate
public final class DelayedCustomAudienceUpdate {
// Required Field
@NonNull public Uri getUpdateUri() {
return mUpdateUri;
}
// Required Field
@NonNull public Duration getMinDelay() {
return mMinDelay;
}
// Required Field
@NonNull public List<PartialCustomAudience> getPartialCustomAudiences() {
return mPartialCustomAudiences;
}
}
L'elemento DelayedCustomAudienceUpdate
contiene le informazioni necessarie per
registrare un job in ritardo da eseguire con la piattaforma. Dopo il ritardo specificato, verrà eseguito periodicamente un job in background che invierà le richieste. DelayedCustomAudienceUpdate
può contenere le seguenti informazioni:
- UpdateUri: endpoint URI a cui verrebbe inviata una chiamata GET per recuperare l'aggiornamento.
L'identità dell'acquirente viene dedotta intrinsecamente dall'eTLD+1, non deve essere fornita esplicitamente e non può essere modificata dalla risposta di aggiornamento. La richiesta GET prevede la restituzione di un oggetto JSON contenente un elenco di oggetti
customAudience
. - DelayTime: tempo che indica il ritardo dall'esecuzione della chiamata API
scheduleCustomAudienceUpdate()
per pianificare l'aggiornamento.
PartialCustomAudience: l'API consente inoltre all'SDK sul dispositivo di inviare un elenco di segmenti di pubblico personalizzati parzialmente creati. Ciò consente agli SDK in-app di svolgere il duplice ruolo, dal controllo completo al controllo parziale sulla gestione dei segmenti di pubblico personalizzati in base alla loro partnership con le DSP.
- Inoltre, l'API è compatibile con l'API
fetchAndJoinCustomAudience()
, che consente la condivisione di informazioni simili.
- Inoltre, l'API è compatibile con l'API
Autorizzazioni e controllo delle app
La proposta intende fornire alle app il controllo sui propri segmenti di pubblico personalizzati:
- Un'app può gestire le proprie associazioni con i segmenti di pubblico personalizzati.
- Un'app può concedere alle piattaforme di tecnologia pubblicitaria di terze parti le autorizzazioni per gestire i segmenti di pubblico personalizzati per suo conto.
La progettazione di questa funzionalità è ancora in fase di sviluppo e i dettagli verranno inclusi in un aggiornamento successivo.
Controllo della piattaforma ad tech
Questa proposta descrive i modi in cui i tecnici pubblicitari possono controllare i propri segmenti di pubblico personalizzati:
- Gli ad tech si registrano a Privacy Sandbox e forniscono un dominio eTLD+1 che corrisponde a tutti gli URL per un segmento di pubblico personalizzato.
- I tecnici pubblicitari possono collaborare con app o SDK per fornire token di verifica utilizzati per verificare la creazione di segmenti di pubblico personalizzati. Quando questo processo viene delegato a un partner, la creazione di segmenti di pubblico personalizzati può essere configurata in modo da richiedere l'accettazione da parte della tecnologia pubblicitaria.
- Un ad tech può scegliere di disattivare le chiamate
joinCustomAudience
per suo conto e consentire solo all'APIfetchAndJoinCustomAudience
di attivare tutti i segmenti di pubblico personalizzati di chiamata. Il controllo può essere aggiornato durante la registrazione a Privacy Sandbox. Tieni presente che il controllo consente tutte le tecnologie pubblicitarie o nessuna. A causa delle limitazioni della piattaforma, le autorizzazioni di delega non possono essere basate su singole tecnologie pubblicitarie.
Annunci candidati e risposta dei metadati
Gli annunci candidati e i metadati restituiti da una piattaforma lato acquisti devono includere i seguenti campi:
- Metadati: metadati degli annunci lato acquisti, specifici per la tecnologia pubblicitaria. Potrebbero essere incluse, ad esempio, informazioni sulla campagna pubblicitaria e criteri di targeting come località e lingua.
- URL di rendering: endpoint per il rendering della creatività dell'annuncio.
- Filtro:informazioni facoltative necessarie all'API Protected Audience per filtrare gli annunci in base ai dati sul dispositivo. Per ulteriori dettagli, leggi la sezione sulla logica di filtro lato acquisti.
Flusso di lavoro per la selezione degli annunci
Questa proposta mira a migliorare la privacy introducendo l'API di selezione degli annunci, che orchestra l'esecuzione dell'asta per le piattaforme di tecnologia pubblicitaria.
Oggi le piattaforme di ad tech in genere eseguono offerte e selezione degli annunci esclusivamente sui propri server. Con questa proposta, i segmenti di pubblico personalizzati e altri indicatori utente sensibili, come le informazioni disponibili sui pacchetti installati, saranno accessibili solo tramite l'API Ad Selection. Inoltre, per il caso d'uso del remarketing, gli annunci candidati verranno recuperati fuori dalla banda (ovvero non nel contesto in cui verranno mostrati gli annunci). Le piattaforme di ad tech dovranno prepararsi per il deployment e l'esecuzione di alcune parti della loro attuale logica di asta e selezione degli annunci sul dispositivo. Le piattaforme ad tech potrebbero prendere in considerazione le seguenti modifiche al flusso di lavoro di selezione degli annunci:
- Senza le informazioni sui pacchetti installati disponibili sul server, le piattaforme di ad tech potrebbero voler inviare più annunci contestuali al dispositivo e richiamare il flusso di lavoro di selezione degli annunci per attivare il filtro basato sull'installazione di app al fine di massimizzare le probabilità di mostrare un annuncio pertinente.
- Poiché gli annunci di remarketing vengono recuperati fuori banda, potrebbe essere necessario aggiornare i modelli di offerta correnti. Le piattaforme ad tech potrebbero voler creare sottomodelli di offerta (l'implementazione potrebbe essere basata su un pattern chiamato modello a due torri) in grado di lavorare separatamente sulle funzionalità pubblicitarie e sugli indicatori di contesto e combinare gli output del modello secondario sul dispositivo per prevedere le offerte. Questo può trarre vantaggio sia dalle aste lato server sia dalle aste per ogni opportunità pubblicitaria.
Questo approccio consente ai dati delle interazioni con l'app dell'utente di determinare la selezione degli annunci, limitando al contempo la condivisione di questi dati con terze parti.
Questo flusso di lavoro per la selezione degli annunci orchestra l'esecuzione sul dispositivo del codice JavaScript fornito dalla tecnologia pubblicitaria in base alla seguente sequenza:
- Esecuzione della logica delle offerte lato acquisti
- Filtro ed elaborazione degli annunci lato acquisti
- Esecuzione della logica decisionale lato vendite
Per la selezione di annunci che prevede segmenti di pubblico personalizzati, la piattaforma recupererà il codice JavaScript fornito dal lato acquisto in base all'endpoint dell'URL pubblico definito dai metadati "URL logica di offerta" del segmento di pubblico personalizzato. L'endpoint URL per il codice decisionale lato vendite verrà inoltre trasmesso come input per avviare il flusso di lavoro di selezione degli annunci.
La progettazione delle selezioni di annunci che non prevedono segmenti di pubblico personalizzati è in fase di progettazione attiva.
Avvia flusso di lavoro di selezione degli annunci
Quando un'app deve mostrare un annuncio, l'SDK della piattaforma ad tech può avviare il flusso di lavoro di selezione degli annunci chiamando il metodo selectAds()
dopo aver creato un'istanza dell'oggetto AdSelectionConfig
con i parametri previsti:
- Venditore: identificatore della piattaforma pubblicitaria lato vendite, secondo il formato eTLD+1
- URL logica decisionale: quando viene avviata un'asta dell'annuncio, la piattaforma utilizza questo URL per recuperare il codice JavaScript dalla Sell-Side Platform ed assegnare un punteggio a un annuncio vincente.
- Acquirenti di segmenti di pubblico personalizzati: un elenco di piattaforme lato acquisti con domanda personalizzata basata sul pubblico per questa asta, nel formato eTLD+1.
- Indicatori di selezione degli annunci: informazioni sull'asta (dimensioni dell'annuncio, formato dell'annuncio e così via).
- Indicatori del venditore: fornisci indicatori specifici della piattaforma laterale.
- URL indicatori di punteggio attendibili: endpoint URL dell'indicatore attendibile lato vendite da cui è possibile recuperare informazioni in tempo reale specifiche della creatività.
- Indicatori per acquirente: le parti della domanda partecipanti possono utilizzare questo parametro per fornire input per l'asta. Ad esempio, questo parametro può includere informazioni contestuali complete utili per determinare le offerte.
Il seguente snippet di codice illustrativo mostra l'SDK di una piattaforma di tecnologia pubblicitaria che avvia il flusso di lavoro di selezione degli annunci definendo innanzitutto AdSelectionConfig
e poi richiamando selectAds
per ottenere l'annuncio vincente:
AdSelectionConfig myAdSelectionConfig = new AdSelectionConfig {
Seller = "example-ssp1.com",
DecisionLogicURL = Uri.parse("https://..."),
CustomAudienceBuyerList = Arrays.asList("example-dsp1.com","bexample-dsp2.com"),
AdSelectionSignals = "{"min_price": 10,"auction_attempts": 3}"
SellerSignals = "{"seller_type": "news", "content_category": "sports","mature_ads_accepted" :"false"}"
PerBuyerSignals = " {"buyer1Name": {"key1" : "value1"},
"buyer2Name": {"key1" : "value1", "key2" : "value2" }"
};
// Invoke ad services API to initiate ad selection workflow.
Ad winningAd = selectAds(myAdSelectionConfig);
Logica di offerta lato acquisti
In genere, la logica di offerta è fornita dalle piattaforme lato acquisti. Lo scopo del codice è determinare le offerte per gli annunci candidati. Potrebbe applicare logica di business aggiuntiva per determinare il risultato.
La piattaforma utilizzerà i metadati "URL logica di offerta" del segmento di pubblico personalizzato per recuperare il codice JavaScript che dovrebbe includere la firma della funzione riportata di seguito:
generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
contextual_signals, user_signals, custom_audience_signals) {
// ...
return {'bid': ...};
}
Il metodo generateBid()
restituisce l'importo dell'offerta calcolato. La piattaforma richiamerà questa funzione per tutti gli annunci (contestuali o di remarketing) in sequenza. Se
sono presenti più fornitori di logica di offerta, il sistema non garantisce
la sequenza di esecuzione tra i provider.
La funzione prevede i seguenti parametri:
- Annuncio: l'annuncio considerato dal codice delle offerte lato acquisti. Sarà un annuncio di un segmento di pubblico personalizzato idoneo
- Indicatori d'asta: indicatori lato vendite e specifici per piattaforma.
- Indicatori per acquirente: le parti della domanda partecipanti possono utilizzare questo parametro per fornire input per l'asta. Ad esempio, questo parametro può includere informazioni contestuali complete utili per determinare le offerte.
- Indicatori di offerte affidabili: le piattaforme di ad tech si basano su dati in tempo reale per informare il recupero e il punteggio degli annunci. Ad esempio, una campagna pubblicitaria potrebbe esaurire il budget e deve essere interrotta immediatamente. Un Ad-Tech può definire un endpoint URL da cui è possibile recuperare questi dati in tempo reale e l'insieme di chiavi per cui deve essere eseguita la ricerca in tempo reale. Il server gestito della piattaforma ad tech che soddisfa questa richiesta sarà un server affidabile gestito dalla piattaforma ad tech.
- Indicatori di contesto: possono includere timestamp approssimativi o informazioni sulla posizione approssimative oppure il costo per clic sull'annuncio.
- Indicatori utente: potrebbero includere informazioni quali le informazioni disponibili sui pacchetti installati.
Costo dell'annuncio
Oltre all'offerta, le piattaforme lato acquisti hanno la possibilità di restituire il costo per clic come parte di generateBid()
. Ad esempio:
generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
contextual_signals, user_signals, custom_audience_signals) {
// ...
return {'bid': ..., 'adCost': ...,};
}
Se questo annuncio si aggiudica l'asta, adCost
viene arrotondato stocasticamente a 8 bit per motivi di privacy. Il valore arrotondato di adCost
viene quindi trasmesso al parametro contextual_signals
in reportWin
durante i report sulle impressioni.
Logica di filtro lato acquisti
Le piattaforme lato acquisti potranno filtrare gli annunci in base a ulteriori indicatori on-device disponibili durante la fase di selezione degli annunci. Ad esempio, qui le piattaforme di tecnologie possono implementare la quota limite. Se sono presenti più provider di filtro, il sistema non garantisce la sequenza di esecuzione tra i provider.
La logica di filtro lato acquisti può essere implementata come parte della logica di offerta restituendo un valore dell'offerta pari a 0
per un determinato annuncio.
Inoltre, le piattaforme lato acquisti potranno segnalare che un determinato annuncio deve essere filtrato in base a ulteriori indicatori sul dispositivo disponibili per Protected Audience e che non escono dal dispositivo. Man mano che consolidiamo i progetti di una logica di filtro aggiuntiva, le piattaforme lato acquisti seguiranno questa stessa struttura per segnalare che il filtro dovrebbe avvenire.
Logica di punteggio lato vendite
La logica di punteggio è in genere fornita dalla Sell-Side Platform. Lo scopo
del codice è determinare un annuncio vincente in base agli output della logica di offerta. Potrebbe
applicare logica di business aggiuntiva per determinare il risultato. Se sono presenti più provider di logica decisionale, il sistema non garantisce la sequenza di esecuzione tra i provider. La piattaforma utilizzerà il parametro di input "URL logica decisionale"
dell'API selectAds()
per recuperare il codice JavaScript che dovrebbe
includere la firma della funzione di seguito:
scoreAd(ad, bid, auction_config, trusted_scoring_signals,
contextual_signals, user_signals, custom_audience_signals) {
// ...
return score_for_this_ad;
}
La funzione prevede i seguenti parametri:
- Annuncio: l'annuncio che viene valutato; output dalla funzione
generateBid()
. - Offerta: l'importo dell'offerta restituito dalla funzione
generateBid()
. - Configurazione asta: inserisci parametro per il metodo
selectAds()
. - Indicatori di punteggio attendibili: le piattaforme di tecnologia pubblicitaria si basano su dati in tempo reale per il filtro e i punteggi degli annunci. Ad esempio, un publisher di app potrebbe impedire a una campagna pubblicitaria di mostrare annunci nell'app. Questi dati vengono recuperati dal parametro URL degli indicatori di punteggio attendibile della configurazione dell'asta. Il server che gestisce questa richiesta deve essere un server attendibile gestito dalla tecnologia pubblicitaria.
- Indicatore di contesto: può includere un timestamp approssimativo o informazioni sulla posizione approssimative.
- Indicatore utente: può includere informazioni quali lo store che ha avviato l'installazione dell'app.
- Indicatore del segmento di pubblico personalizzato: se l'annuncio a cui viene assegnato il punteggio proviene da un segmento di pubblico personalizzato on-device, conterrà informazioni come il lettore e il nome del segmento di pubblico personalizzato.
Tempo di esecuzione del codice di selezione degli annunci
Nella proposta, il sistema recupera il codice dell'asta fornito dalla piattaforma di tecnologia pubblicitaria dagli endpoint URL configurabili ed esegue sul dispositivo. Dati i vincoli delle risorse sui dispositivi mobili, il codice dell'asta deve rispettare le seguenti linee guida:
- L'esecuzione del codice dovrebbe terminare entro un periodo di tempo predefinito. Questo vincolo verrà applicato in modo uniforme a tutte le reti pubblicitarie dell'acquirente. I dettagli di questo limite verranno condivisi in un aggiornamento successivo.
- Il codice deve essere autonomo e non deve avere dipendenze esterne.
Poiché il codice dell'asta, ad esempio la logica di offerta, potrebbe richiedere l'accesso a dati utente privati, come le origini di installazione di app, il runtime non fornirà l'accesso alla rete o allo spazio di archiviazione.
Linguaggio di programmazione
Il codice asta fornito dalla piattaforma per la tecnologia pubblicitaria deve essere scritto in JavaScript. Ciò consentirebbe alle piattaforme delle tecnologie pubblicitarie, ad esempio, di condividere il codice di offerta tra le piattaforme che supportano Privacy Sandbox.
Rendering dell'annuncio vincente
L'annuncio con il punteggio più alto viene considerato il vincitore dell'asta. In questa proposta iniziale, l'annuncio vincente viene passato all'SDK per il rendering.
Il piano prevede di evolvere la soluzione per garantire che le informazioni sull'iscrizione al segmento di pubblico personalizzato o sulla cronologia del coinvolgimento in app di un utente non possano essere determinate dall'app o dall'SDK tramite le informazioni sull'annuncio vincente (come per la proposta di frame recintati di Chrome).
Report sulle impressioni e sugli eventi
Una volta visualizzato l'annuncio, l'impressione vincente può essere riportata alle piattaforme lato acquisti e lato vendite partecipanti. In questo modo acquirenti e venditori possono includere informazioni provenienti dall'asta, come il nome dell'offerta o del segmento di pubblico personalizzato, nel report sulle impressioni vincenti. Inoltre, la Sell-Side Platform e gli acquirenti vincenti sono idonee a ricevere report aggiuntivi a livello di evento sull'annuncio vincente. Ciò consente di includere informazioni sull'asta (offerta, nome del segmento di pubblico personalizzato e così via) con clic, visualizzazioni e altri eventi relativi agli annunci. La piattaforma richiama la logica di reporting in questo ordine:
- Report lato vendite.
- Report lato acquisti.
In questo modo, le piattaforme lato acquisti e lato vendite possono inviare importanti informazioni sul dispositivo ai server per abilitare funzionalità come la definizione del budget in tempo reale, gli aggiornamenti dei modelli di offerta e flussi di lavoro di fatturazione accurati. Questo supporto per i report sulle impressioni è complementare all'API Attribution Reporting.
Sono necessari due passaggi per supportare i report sugli eventi: JavaScript lato vendite e lato acquisti deve registrare l'evento per cui deve ricevere i report sugli eventi, mentre il lato vendite è responsabile dei report sulle informazioni a livello di evento.
Protected Audience offre un meccanismo per iscriversi a eventi futuri correlati a
un'asta vincente mediante la registrazione dei beacon. Nella funzione JavaScript reportResult()
di un venditore, le Sell-Side Platform possono registrare beacon utilizzando la
funzione registerAdBeacon()
della piattaforma. Analogamente, le piattaforme lato acquisti possono chiamare il metodo registerAdBeacon()
dalla funzione JavaScript reportWin()
.
registerAdBeacon(beacons)
Input:
event_key
: una stringa che indica il tipo di interazione da utilizzare. Viene utilizzato come chiave per cercare il punto finale segnalato dalla piattaforma durante i report sui risultati dell'asta.reporting_url
: l'URL di proprietà della piattaforma ad tech per la gestione dell'evento.
Le chiavi evento sono identificatori di stringa di proprietà dell'SDK lato vendite responsabile della generazione di report sui risultati dell'asta. Affinché venga eseguito il callback,
il team ad tech registra i beacon con chiavi corrispondenti a quelle utilizzate dal lato vendite
quando segnalano gli eventi. Non è necessario che siano k-anonymous, anche se esistono dei limiti alla quantità e alla lunghezza delle chiavi che è possibile registrare per un determinato segmento di pubblico personalizzato. Se viene chiamata reportEvent()
, le piattaforme lato vendite che
eseguono l'asta sono sempre idonee a ricevere questi report sugli eventi. Solo la piattaforma lato acquisti vincente è idonea a ricevere questi report.
Report lato vendite
La piattaforma richiama la funzione JavaScript reportResult()
nel codice fornito lato fornitura scaricato dal parametro URL logica decisionale del venditore per l'API selectAds()
:
reportResult(render_url, bid, auction_config, contextual_signals) {
// ...
beacons = {"click":clickUri}
registerAdBeacon(beacons)
return {
"status": 0,
"results": {"reporting_url": reporting_url,
"signals_for_buyer": signals_for_buyer}};
}
Output: un oggetto JSON contenente
- Stato:
0
per l'operazione riuscita, qualsiasi altro valore per l'errore. - URL di reporting: la piattaforma richiama questo URL restituito dalla funzione.
- Indicatori per l'acquirente: un oggetto JSON da passare alla funzione
reportWin
dell'acquirente.
Il lato offerta potrebbe codificare indicatori pertinenti nell'URL dei report per ottenere ulteriori informazioni sull'asta e sull'annuncio vincente. Ad esempio, potrebbe includere gli indicatori riportati di seguito:
- URL di rendering dell'annuncio
- Importo offerta vincente
- Nome dell'app
- Identificatori di query
- Indicatori per l'acquirente: per supportare la condivisione dei dati tra il lato offerta e la domanda, la piattaforma trasmette questo valore restituito come parametro di input per il codice dei report sul lato domanda.
Report lato acquisti
La piattaforma richiama la funzione JavaScript reportWin()
nel codice fornito lato domanda scaricato dai metadati dell'URL della logica di offerta del segmento di pubblico personalizzato associato all'asta.
reportWin(render_url, bid, auction_signals, per_buyer_signals,
signals_for_buyer, contextual_signals, custom_audience_signals) {
// ...
beacons = {"click":clickUri}
registerAdBeacon(beacons)
return {
"status": 0,
"results": {"reporting_uri": reporting_uri}};
}
Input:
auction_signals
eper_buyer_signals
recuperati daAuctionConfig
. Tutte le informazioni che la piattaforma lato acquisti deve trasmettere all'URL dei report possono provenire da questo dato.signals_for_buyer
è l'output del reportResult lato vendite. Ciò offre alla Sell-Side Platform l'opportunità di condividere i dati con la Piattaforma lato acquirente per la generazione di report.contextual_signals
contiene informazioni come il nome dell'app ecustom_audience_signals
contiene informazioni sul segmento di pubblico personalizzato. In futuro potrebbero essere aggiunte altre informazioni.
Output:
- Stato:
0
per l'operazione riuscita, qualsiasi altro valore per l'errore. - URL di reporting: la piattaforma richiama questo URL restituito dalla funzione.
Eventi dei report
Gli eventi di generazione dei report sono possibili solo dopo che il report sulle impressioni per l'asta è
completato. L'SDK lato vendite è responsabile della generazione di report su tutti gli eventi. La piattaforma espone un'API che utilizza un ReportEventRequest
che specifica l'asta eseguita di recente, la chiave evento segnalata, i dati associati alla chiave, se il report deve essere inviato all'acquirente o al venditore (o entrambi) e un evento di input facoltativo per gli eventi annuncio. Il client definisce la chiave evento
e la raccolta di dati da segnalare.
ReportEventRequest request = new ReportEventRequest(
AdSelectionId = ad_selection_id,
event_key = "view"
event_data = "{ "viewTimeInSeconds" :1 }",
reporting_destinations =
FLAG_REPORTING_DESTINATION_SELLER |
FLAG_REPORTING_DESTINATION_BUYER,
input_event = clickInputEvent // or null for view
)
reportEvent(request)
Input:
ad_selection_id
deve essere unAdSelectionId
di un'asta eseguita di recente recuperata daAdSelectionOutcome
.event_key
è una stringa definita dal lato vendite che descrive l'evento di interazione.event_data
è una stringa che rappresenta i dati associati all'elementoevent_key
reporting_destinations
è una maschera di bit impostata utilizzando i flag forniti dalla piattaforma. Può essere uno diFLAG_REPORTING_DESTINATION_SELLER
,FLAG_REPORTING_DESTINATION_BUYER
o entrambi.input_event
(facoltativo) viene utilizzato per l'integrazione con l'API Attribution Reporting. È un oggettoInputEvent
(per un evento di clic) o nullo (per un evento di visualizzazione). Per ulteriori dettagli su questo parametro, consulta Integrazione dell'API Attribution Reporting.
Dopo che l'SDK lato vendite richiama reportEvent
e, a seconda del flag
reporting_destinations
, la piattaforma tenta di abbinare event_key
alle
chiavi registrate da acquirenti e venditori nelle loro funzioni JavaScript reportWin
e
reportResult
. Se viene trovata una corrispondenza, la piattaforma PUBBLICA
event_data
nell'elemento reporting_url
associato. Il tipo di contenuti della richiesta
è in testo normale, con il corpo event_data
. Questa richiesta viene effettuata secondo il criterio del "best effort" e non va a buon fine in caso di errore di rete, risposta a un errore del server o se non sono state trovate chiavi corrispondenti.
Integrazione dell'API Attribution Reporting
Per supportare gli acquirenti che partecipano a un'asta Protected Audience, stiamo fornendo funzionalità cross-API nell'API Protected Audience e Attribution Reporting (ARA). Questa funzionalità consente ai tecnici pubblicitari di valutare il rendimento dell'attribuzione attraverso diverse tattiche di remarketing, in modo da poter capire quali tipi di segmenti di pubblico generano il ROI più elevato.
Grazie a questa integrazione tra API, i tecnici pubblicitari possono:
- Crea una mappa chiave-valore degli URI da utilizzare sia per i report sull'interazione con gli annunci sia per la registrazione dell'origine.
- Includi i dati dell'asta dell'asta Protected Audience nella mappatura delle chiavi lato origine per i report di riepilogo aggregati (utilizzando l'API Attribution Reporting). Per saperne di più, consulta la proposta di progettazione ARA.
Quando un utente visualizza o fa clic su un annuncio:
- L'URL utilizzato per segnalare queste interazioni di eventi con Protected Audience fornirà all'acquirente i dati necessari da utilizzare per registrare una visualizzazione o un clic come origine idonea con l'API Attribution Reporting.
- La tecnologia pubblicitaria può scegliere di trasferire
CustomAudience
(o altre informazioni contestuali pertinenti sull'annuncio, come il posizionamento dell'annuncio o la durata di visualizzazione) utilizzando questo URL, in modo che questi metadati possano essere propagati nei report di riepilogo quando la tecnologia pubblicitaria sta esaminando il rendimento aggregato della campagna.
Abilitazione della registrazione di origine
reportEvent()
accetterà un nuovo parametro facoltativo InputEvent
. Gli acquirenti vincitori che registrano beacon degli annunci possono scegliere quali report reportEvent devono essere registrati con le API Attribution Reporting come origine registrata. L'intestazione
della richiesta Attribution-Reporting-Optimized verrà aggiunta a tutte le richieste di report sugli eventi
inviate da reportEvent()
. Tutte le risposte con intestazioni ARA appropriate verranno analizzate come qualsiasi altra risposta di registrazione di origine ARA standard. Consulta il messaggio esplicativo dell'API Attribution Reporting per scoprire come registrare un URL di origine.
Poiché ARA su Android supporta gli eventi di visualizzazione e clic, vengono utilizzati InputEvents
per distinguere i due tipi. Proprio come per la registrazione della sorgente ARA, l'API reportEvent()
interpreterà un InputEvent
con piattaforma verificata come un evento di clic. Se InputEvent
non è presente, è nullo o non è valido, la registrazione di origine verrà considerata una visualizzazione.
Tieni presente che l'elemento eventData
dopo l'asta potrebbe contenere informazioni sensibili, pertanto la piattaforma elimina il eventData
nelle richieste di registrazione dell'origine reindirizzate.
Esempio di report sul coinvolgimento e sulle conversioni
In questo esempio, lo esamineremo dal punto di vista dell'acquirente che è interessato ad associare i dati dell'asta, dell'annuncio visualizzato e dell'app di conversione.
In questo flusso di lavoro, l'acquirente si coordina con il venditore per inviare un ID univoco nell'asta. Durante l'asta, l'acquirente invia questo ID univoco con i dati dell'asta. Durante il tempo di rendering e di conversione, anche i dati dell'annuncio visualizzato vengono inviati con lo stesso ID univoco. In seguito, l'ID univoco può essere utilizzato per associare questi report.
Flusso di lavoro:
prima dell'inizio dell'asta, l'acquirente invia un ID univoco al venditore come parte
della risposta all'offerta programmatica per le offerte in tempo reale ("RTB"). L'ID può essere
impostato come una variabile come auctionId
. L'ID viene trasmesso come perBuyerSignals
nell'elemento auctionConfig
e diventa disponibile nella logica di offerta dell'acquirente.
- Durante l'esecuzione di
reportWin
, l'acquirente può registrare un beacon dell'annuncio da attivare durante il tempo di rendering dell'annuncio e per eventi di interazione specifici (registerAdBeacon()
). Per associare gli indicatori delle aste per un evento dell'annuncio, impostaauctionId
come parametro di query dell'URL di beaconing. - Durante il tempo di rendering dell'annuncio, i beacon registrati al momento dell'asta possono essere attivati o migliorati con i dati a livello di evento. Il venditore deve attivare
reportEvent()
e trasmettere i dati a livello di evento. La piattaforma invierà un ping all'URL di beaconing degli annunci registrato dell'acquirente correlato all'elementoreportEvent()
che è stato attivato. - L'acquirente registrerà l'annuncio con l'API Attribution Reporting
rispondendo alle richieste di beacon degli annunci con l'intestazione
Attribution-Reporting-Register-Source
. Per associare gli indicatori di asta a un evento di conversione, impostaauctionId
nell'URL di origine della registrazione.
Al termine della procedura descritta sopra, l'acquirente dispone di un report sulle aste, sulle interazioni e sulle conversioni, che possono essere correlati tramite l'ID univoco che può essere utilizzato per essere associati tra loro.
Un flusso di lavoro simile si applica a un venditore se ha bisogno di accedere ai dati di attribuzione e
il venditore può anche utilizzare un ID univoco da inviare con registerAdBeacon()
. La chiamata reportEvent()
contiene una proprietà di destinazione che può essere utilizzata per inviare il report sia all'acquirente sia al venditore.
Server affidabile gestito dalla piattaforma ad tech
Oggi la logica di selezione degli annunci richiede informazioni in tempo reale, come lo stato di esaurimento del budget, per determinare se i candidati degli annunci devono essere selezionati per l'asta. Sia le piattaforme lato acquisti sia le piattaforme lato vendite saranno in grado di ottenere queste informazioni dai server che gestiscono. Per ridurre al minimo la fuga di informazioni sensibili tramite questi server, la proposta richiede le seguenti restrizioni:
- I comportamenti di questi server, descritti più avanti in questa sezione, non divulgano le informazioni degli utenti.
- I server non creerebbero profili con pseudonimi in base ai dati che vede, ovvero dovranno essere "attendibili".
Lato acquisto: una volta che il lato acquisti avvia la logica di offerta lato acquisti, la piattaforma esegue un recupero HTTP dei dati di offerte attendibili dal server attendibile. L'URL è composto aggiungendo l'URL e le chiavi presenti nei metadati degli indicatori delle offerte attendibili del segmento di pubblico personalizzato in fase di elaborazione. Questo recupero viene eseguito solo durante l'elaborazione degli annunci dai segmenti di pubblico personalizzati sul dispositivo. In questa fase, il lato acquisti può applicare i budget, controllare lo stato di pausa / riattivazione della campagna, eseguire il targeting e così via.
Di seguito è riportato un URL di esempio per recuperare i dati di Trusted Bidding in base ai metadati degli indicatori di Trusted Bidding provenienti dal segmento di pubblico personalizzato:
https://www.kv-server.example/getvalues?keys=key1,key2
La risposta dal server dovrebbe essere un oggetto JSON le cui chiavi sono key1, key2 e così via e i cui valori saranno resi disponibili alle funzioni di offerta dell'acquirente.
Lato vendita: in modo analogo al flusso lato acquisti riportato sopra, il lato vendite potrebbe voler recuperare informazioni sulle creatività considerate nell'asta. Ad esempio, un publisher potrebbe voler richiedere che determinate creatività non vengano mostrate nella sua app in base a problemi di sicurezza del brand. Queste informazioni possono essere recuperate e messe a disposizione della logica dell'asta lato vendite. Analogamente alla ricerca server attendibili lato acquisti, anche la ricerca server attendibili lato vendite avviene tramite un recupero HTTP. L'URL è composto aggiungendo l'URL Indicatori di punteggio attendibili con gli URL di rendering delle creatività per le quali devono essere recuperati i dati.
Di seguito è riportato un URL di esempio per recuperare informazioni sulle creatività considerate nell'asta, in base agli URL di rendering delle creatività:
https://www.kv-server.example/getvalues?renderUrls=render_url1,render_url2
La risposta dal server deve essere un oggetto JSON le cui chiavi sono URL di rendering inviati nella richiesta.
Questi server funzionerebbero in modo affidabile per offrire diversi vantaggi in termini di sicurezza e privacy:
- È possibile considerare attendibile il valore restituito dal server per ogni chiave, in modo che sia basato solo su quella chiave.
- Il server non esegue il logging a livello di evento.
- Il server non ha altri effetti collaterali basati su queste richieste.
Come meccanismo temporaneo, l'acquirente e il venditore possono recuperare questi indicatori di offerta da qualsiasi server, incluso uno che operano in modo autonomo. Tuttavia, nella versione di release, la richiesta verrà inviata solo a un server di tipo chiave-valore attendibile.
Acquirenti e venditori potrebbero utilizzare un server coppia chiave-valore affidabile per le piattaforme compatibili con Privacy Sandbox su Android e per il web.