Questa pagina è stata tradotta dall'API Cloud Translation.

Panoramica dell'API Protected Audience
bookmark_border Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Aste di annunci on-device per pubblicare annunci di remarketing e per pubblico personalizzato, senza monitoraggio di terze parti cross-site.

A chi è rivolto questo articolo?

Questo articolo illustra le nozioni di base dell'API Protected Audience e spiega alcuni concetti di base, ma non fornisce molti dettagli tecnici.

Se lavori nel settore pubblicitario o ad tech, potrai avere una panoramica di come funziona Protected Audience.
Se sei uno sviluppatore o un ingegnere del software, la Guida per gli sviluppatori dell'API Protected Audience fornisce dettagli tecnici più approfonditi sull'API. Leggi il stato più recente delle funzionalità di Protected Audience in attesa.

Consulta il glossario per i termini utilizzati nella documentazione di Protected Audience. Alla fine di questo articolo, scoprirai come coinvolgere e condividere feedback.

Che cos'è l'API Protected Audience?

L'API Protected Audience è una tecnologia Privacy Sandbox per la pubblicazione di casi d'uso di remarketing e segmenti di pubblico personalizzati, progettata in modo che terze parti non possano monitorare il comportamento di navigazione degli utenti sui siti.

L'API Protected Audience consente le aste on-device del browser per scegliere annunci pertinenti dai siti web che l'utente ha visitato in precedenza.

L'API Protected Audience è il primo esperimento da implementare in Chromium all'interno della famiglia di proposte TURTLEDOVE. La differenza tra Protected Audience e TURTLEDOVE riguarda principalmente la separazione del ruolo on-device dell'acquirente e del venditore di annunci. Le sezioni seguenti spiegano come funziona l'API Protected Audience.

API Protected Audience in un minuto

Per una panoramica più approfondita dell'API Protected Audience, consulta la guida per gli sviluppatori dell'API Protected Audience.

Panoramica di ogni fase del ciclo di vita dell'API Protected Audience — Il ciclo di vita dell'API Protected Audience

L'API Protected Audience utilizza i gruppi di interesse per consentire ai siti di mostrare annunci pertinenti per i propri utenti.

Ad esempio, quando un utente visita un sito che vuole pubblicizzare i suoi prodotti, un proprietario di un gruppo di interesse (ad esempio una Demand-Side Platform (DSP)) può chiedere al browser dell'utente di aggiungere l'appartenenza al gruppo di interesse. Se la richiesta va a buon fine, il browser registra:

Il nome del gruppo di interesse: ad esempio "biciclette personalizzate".
Il proprietario del gruppo di interesse: ad esempio, "https://dsp.example".
Informazioni di configurazione del gruppo di interesse per consentire al browser di accedere al codice di offerta, al codice annuncio e ai dati in tempo reale, se il proprietario del gruppo è invitato a fare offerte in un'asta di annunci.

In seguito, quando l'utente visita un sito con spazio pubblicitario disponibile, il venditore dello spazio pubblicitario (un fornitore sell-side (SSP) o il sito stesso) può utilizzare Protected Audience per eseguire un'asta di annunci al fine di selezionare gli annunci più appropriati da mostrare all'utente. Il venditore chiama la navigator.runAdAuction() funzione, che fornisce un elenco di proprietari di gruppi di interesse invitati a fare offerte.

Le offerte possono essere fornite solo dai gruppi di interesse di cui fa parte il browser e i cui proprietari sono stati invitati a fare offerte.

Il codice per le offerte viene recuperato da un URL fornito nella configurazione del gruppo di interesse. Questo codice fornisce dati sul gruppo di interesse e informazioni del venditore, nonché dati contestuali sulla pagina e dal browser.

Ogni gruppo di interesse che fornisce un'offerta è noto come acquirente.

Quando il browser chiama la funzione per eseguire l'asta di annunci, il codice di ciascun acquirente genera un'offerta con l'aiuto dei dati in tempo reale forniti dal suo servizio Protected Audience Key/Value. Il venditore riceve queste offerte, nonché i dati in tempo reale di sua proprietà, e assegna un punteggio a ogni offerta. L'asta viene vinta dall'offerta con il punteggio più alto.

L'annuncio vincente viene visualizzato in un riquadro delimitato. L'URL della creatività dell'annuncio è specificato nell'offerta e l'origine deve corrispondere a una nell'elenco fornito dalla configurazione del gruppo di interesse.

Il venditore può segnalare il risultato dell'asta (reportResult()) e gli acquirenti possono segnalare le proprie offerte vinte (reportWin()).

Scopri di più sui report sulle aste Protected Audience.

Perché abbiamo bisogno dell'API Protected Audience?

Comprendere gli interessi degli utenti può consentire di pubblicare annunci più pertinenti rispetto alla semplice scelta degli annunci in base ai contenuti del sito (targeting contestuale) o all'utilizzo delle informazioni fornite da un utente al sito su cui viene pubblicato l'annuncio (targeting per dati proprietari).

Tradizionalmente, le piattaforme pubblicitarie hanno appreso gli interessi degli utenti monitorandone il comportamento sui siti. I browser hanno bisogno di un modo per consentire alle piattaforme pubblicitarie di selezionare annunci pertinenti, in modo che i publisher di contenuti possano ottenere entrate pubblicitarie senza il monitoraggio tra siti.

L'obiettivo dell'API Protected Audience è avvicinare la piattaforma web a uno stato in cui il browser dell'utente sul suo dispositivo, non le piattaforme pubblicitarie o di ad tech, detiene informazioni su ciò che interessa a quella persona.

Come faccio a provare l'API Protected Audience?

La guida per gli sviluppatori dell'API Protected Audience descrive come utilizzare l'API e come eseguire test locali.
protected-audience-demo.web.app fornisce una procedura dettagliata per un deployment di Protected Audience di base sui siti di inserzionisti e publisher. Il video dimostrativo di Protected Audience spiega come funziona questo codice e mostra un'anteprima di come utilizzare gli strumenti di sviluppo di Chrome per il debug.

Quali configurazioni del browser sono disponibili?

Gli utenti possono modificare la propria partecipazione alle prove di Privacy Sandbox in Chrome attivando o disattivando l'impostazione di primo livello in chrome://settings/adPrivacy. Durante i test iniziali, gli utenti possono disattivare l'API Protected Audience utilizzando le impostazioni di Privacy Sandbox.

Chrome ha intenzione di consentire agli utenti di visualizzare e gestire l'elenco dei gruppi di interesse a cui sono stati aggiunti nei siti che hanno visitato. Come per le tecnologie Privacy Sandbox, le impostazioni utente possono evolversi in base al feedback di utenti, enti regolatori e altri.

Aggiorneremo le impostazioni disponibili in Chrome man mano che l'API Protected Audience progredisce, in base a test e feedback. In futuro, offriremo impostazioni più granulari per gestire Protected Audience e i dati associati.

I chiamanti dell'API non possono accedere all'appartenenza al gruppo quando gli utenti navigano in modalità di navigazione in incognito e l'appartenenza viene rimossa quando gli utenti cancellano i dati del sito.

Posso disattivare l'API Protected Audience?

Scopri come bloccare l'accesso all'API Protected Audience, come proprietario di un sito o come utente privato.

Concetti fondamentali

Cerchi ulteriori informazioni sulla terminologia relativa al pubblico protetto? Consulta il glossario di Privacy Sandbox.

Che cos'è un gruppo di interesse?

Un gruppo di interesse dell'API Protected Audience rappresenta un gruppo di persone con un interesse comune, corrispondente a un elenco per il remarketing.

Ogni gruppo di interesse dell'API Protected Audience ha un proprietario. Proprietari diversi creeranno tipi diversi di gruppi di interesse con casi d'uso diversi.

Il proprietario chiede al browser dell'utente di aggiungere l'appartenenza al gruppo di interesse chiamando la funzione JavaScript navigator.joinAdInterestGroup(), fornendo informazioni quali dati sugli annunci pertinenti al gruppo di interesse e un URL per JavaScript utilizzato nelle offerte. I dati del gruppo di interesse (ad es. gli annunci) possono essere aggiornati e un gruppo di interesse può essere attivato per un massimo di 30 giorni.

Tipi di gruppi di interesse

La tabella seguente fornisce esempi di diversi tipi di gruppi di interesse e proprietari dell'API Protected Audience.

Proprietario	Esempio	Interesse	Esempio	Casi d'uso
Inserzionista	Produttore di biciclette	Prodotti	Persone che hanno visualizzato pagine di prodotti per una determinata categoria di biciclette.	Remarketing per gli utenti che hanno interagito in precedenza con il brand.
Publisher	Sito web di notizie	Contenuti	Persone che leggono articoli sul ciclismo.	I publisher possono utilizzare i dati proprietari per consentire agli inserzionisti di acquistare annunci pertinenti per i lettori sul proprio sito. Un gruppo di interesse di proprietà del publisher potrebbe consentire ai publisher di fare lo stesso anche quando queste persone navigano su altri siti. I publisher potrebbero essere in grado di addebitare la possibilità di mostrare annunci a segmenti specifici del loro pubblico.
Ad tech	DSP	Categoria di prodotti	Persone che hanno mostrato interesse per l'attrezzatura da ciclismo.	Un'azienda di ad tech potrebbe creare e gestire un gruppo di interesse di utenti che ritiene essere alla ricerca di una determinata categoria di articoli. Questo gruppo di interessi potrebbe essere utilizzato per pubblicizzare prodotti su siti che vendono articoli appartenenti a quella categoria (e che collaborano con l'azienda di tecnologia pubblicitaria).

Chrome consente fino a 1000 gruppi di interessi per proprietario e fino a 1000 proprietari di gruppi di interessi. Questi limiti sono considerati come parapetti, che non devono essere raggiunti durante il normale funzionamento.

Che cos'è un acquirente?

Nell'API Protected Audience, un acquirente è una parte che possiede un gruppo di interesse e fa offerte in un'asta di annunci.

Ad esempio:

Inserzionista: che agisce per proprio conto.
Demand-Side Platform (DSP): agisce per conto degli inserzionisti.
Proprietario del gruppo di interesse: lavora per più inserzionisti.

Gli acquirenti hanno tre compiti:

Scegli se partecipare a un'asta.
Scegli gli annunci e calcola un'offerta.
Segnala il risultato dell'asta.

Questi job vengono eseguiti in modo programmatico nel codice fornito dall'acquirente e eseguito durante un'asta di annunci dell'API Protected Audience.

Quando un acquirente chiede al browser di un utente di aggiungere un gruppo di interesse ai gruppi di cui fa parte (chiamando la funzione JavaScript navigator.joinAdInterestGroup()), fornisce al browser:

Un URL per il codice di offerta che verrà utilizzato quando il venditore pubblica un'asta di annunci.
Potenzialmente, gli URL delle creatività degli annunci per il gruppo di interesse. Gli URL degli annunci potrebbero essere aggiunti in un secondo momento con un aggiornamento.
Un elenco di chiavi di dati su cui eseguire query e l'URL del servizio chiave/valore dell'acquirente, per consentire al codice di offerta di ricevere dati in tempo reale durante un'asta.

Il codice dell'acquirente può anche includere una funzione reportWin() per segnalare l'esito dell'asta.

Chi gestisce un'asta di annunci?

Esistono più parti che potrebbero organizzare un'asta per vendere spazio pubblicitario.

Ad esempio:

Publisher di contenuti: che agisce per conto proprio per ospitare i contenuti degli annunci sul proprio sito web.
Supply-Side Platform (SSP): collabora con il publisher e fornisce altri servizi.
Script di terze parti: agisce per conto di un publisher per consentire la partecipazione alle aste di annunci.

Con l'API Protected Audience, un venditore di spazi pubblicitari ha tre compiti:

Applicare le regole del publisher: indicare quali acquirenti e quali offerte sono idonei.
Esegui la logica dell'asta: JavaScript viene eseguito in worklet per calcolare un voto di desiderabilità per ogni offerta.
Segnala il risultato dell'asta.

Questi job vengono eseguiti in modo programmatico, nel codice fornito dal venditore quando avvia un'asta di annunci chiamando la funzione JavaScript navigator.runAdAuction().

Come funziona un'asta di annunci dell'API Protected Audience?

Il seguente diagramma illustra ogni fase di un'asta di annunci dell'API Protected Audience:

Sei fasi di un'asta di annunci dell'API Protected Audience — Fasi dell'asta di annunci Protected Audience

Nell'API Protected Audience, un'asta dell'annuncio è una raccolta di piccoli programmi JavaScript che il browser esegue sul dispositivo dell'utente per scegliere un annuncio. Per preservare la privacy, tutto il codice dell'asta degli annunci del venditore e degli acquirenti viene eseguito in worklet JavaScript isolati che non possono comunicare con l'esterno.

Un venditore (un publisher o una supply-side platform) avvia un'asta di annunci Protected Audience su un sito che vende spazio pubblicitario (ad esempio un sito di notizie). Il venditore sceglie gli acquirenti che possono partecipare all'asta, indica lo spazio in vendita e fornisce criteri aggiuntivi per l'annuncio. Ogni acquirente è il proprietario di un gruppo di interesse.

Il venditore fornisce al browser il codice per assegnare un punteggio alle offerte, che include il valore di ogni offerta, l'URL della creatività dell'annuncio e altri dati restituiti da ciascun acquirente. Durante l'asta, il codice di offerta degli acquirenti e il codice di valutazione delle offerte del venditore possono ricevere dati dai rispettivi servizi Key/Value. Una volta scelto e visualizzato un annuncio (in un frame delimitato per preservare la privacy), il venditore e l'acquirente vincente possono segnalare il risultato dell'asta.

Un utente visita un sito che mostra annunci.
Il codice del venditore avvia un'asta. Il venditore specifica quale spazio pubblicitario è in vendita, chi può fare offerte e un metodo per assegnare un punteggio a queste offerte.
Il codice dell'acquirente invitato viene eseguito per generare un'offerta, l'URL di una creatività dell'annuncio pertinente e altri dati. Lo script di offerta può eseguire query per recuperare i dati in tempo reale, come il budget rimanente della campagna pubblicitaria, dal servizio Key/Value dell'acquirente.
Il codice del venditore assegna un punteggio a ogni offerta e seleziona un'offerta vincente. Questa logica utilizza il valore dell'offerta e altri dati per restituire la desiderabilità di un'offerta e rifiutare un annuncio che non può battere l'annuncio contestuale vincente. Il venditore può utilizzare il proprio servizio Key/Value per i dati in tempo reale. Prima dell'inizio di un'asta, il venditore trova l'annuncio contestuale migliore per l'area annuncio disponibile.
L'annuncio vincente viene restituito come oggetto di configurazione del frame recintato quando il flag resolveToConfig è impostato nella configurazione dell'asta. La configurazione viene utilizzata per passare dal frame recintato alla creatività dell'annuncio e l'URL della creatività è nascosto sia al venditore sia al publisher. Se il flag resolveToConfig è impostato su false o non viene passato, l'annuncio vincente viene restituito come URN opaco che può essere utilizzato per visualizzare l'annuncio in un iframe. L'oggetto di configurazione dell'inquadratura recintata è disponibile a partire da M114.
L'asta viene segnalata al venditore e agli acquirenti vincitori.
Nota: il reportResult() del venditore e il reportWin() dell'acquirente possono includere una chiamata a sendReportTo(). Questa funzionalità è disponibile temporaneamente, fino a quando i report aggregati non saranno disponibili con l'aggregazione privata.

È in discussione un meccanismo di segnalazione per gli acquirenti persi.

Che cos'è un servizio chiave/valore dell'API Protected Audience?

Il servizio Chiave/Valore dell'API Protected Audience consente agli esperti di tecnologia pubblicitaria di eseguire query per recuperare dati in tempo reale quando viene effettuata un'offerta da parte dell'acquirente e ai venditori di assegnare un punteggio agli annunci, preservando al contempo la privacy. Puoi leggere informazioni sul servizio Chiave/valore dell'API Protected Audience e su altri servizi in Servizi dell'API Protected Audience.

Il servizio Key/Value viene implementato nell'infrastruttura cloud della stessa ad tech ed eseguito in un ambiente di esecuzione attendibile. Una richiesta a un servizio Key/Value non può comportare il logging a livello di evento o avere altri effetti collaterali. Il servizio Key/Value supporterà anche le funzioni definite dall'utente (UDF) che consentono agli esperti di tecnologia pubblicitaria di eseguire la propria logica personalizzata all'interno del servizio Key/Value.

Un acquirente o un venditore fornisce un elenco di "chiavi" per specificare i dati richiesti da un servizio API Protected Audience Key/Value. Il servizio Chiave/Valore risponde con un valore per ogni chiave.

Il codice di servizio chiave/valore dell'API Protected Audience è ora disponibile in un repository GitHub di Privacy Sandbox. Questo servizio può essere utilizzato dagli sviluppatori di Chrome e Android.

Scopri di più sul servizio Chiave/Valore dell'API Protected Audience dalla spiegazione dell'API e dalla spiegazione del modello di attendibilità.

Come vengono incorporati i dati in tempo reale nelle aste?

Gli acquirenti o il venditore in un'asta di annunci potrebbero dover accedere ai dati in tempo reale. Ad esempio, gli acquirenti potrebbero voler calcolare il budget rimanente di una campagna pubblicitaria oppure il venditore potrebbe dover verificare la conformità delle creatività degli annunci alle norme del publisher.

Per soddisfare i requisiti di privacy dell'API Protected Audience, i dati in tempo reale richiesti durante un'asta di annunci vengono forniti dal servizio Key/Value. Quando ogni acquirente chiama navigator.joinAdInterestGroup(), specifica un URL del servizio Key/Value e le chiavi da sottoporre a query al servizio durante un'asta. Analogamente, quando il venditore pubblica un'asta di annunci chiamando navigator.runAdAuction(), fornisce un URL per il proprio servizio Key/Value. Al servizio Key/Value del venditore verrà effettuata una query con l'URL di rendering della creatività.

Per i test iniziali, viene utilizzato il modello "Bring Your Own Server". A lungo termine, le tecnologie pubblicitarie dovranno utilizzare i servizi API Protected Audience open source in esecuzione in ambienti di esecuzione attendibili per recuperare i dati in tempo reale.

Per garantire all'ecosistema tempo sufficiente per i test, non prevediamo di richiedere l'utilizzo dei servizi Key/Value open source o degli ambienti di esecuzione attendibili fino a qualche tempo dopo il ritiro dei cookie di terze parti. Prima che questa transizione venga eseguita, daremo agli sviluppatori un preavviso sufficiente per iniziare i test e l'adozione.

In che modo vengono utilizzati i dati proprietari in un'asta Protected Audience?

I dati proprietari sono dati di proprietà del sito relativi ai suoi utenti. Ad esempio, se un utente ha specificato il suo colore preferito sul sito dell'inserzionista o del publisher, questo colore è considerato un dato proprietario.

In un'asta Protected Audience, l'inserzionista può utilizzare i propri dati proprietari per determinare l'appartenenza al gruppo di interesse dell'annuncio e può anche trasmettere i dati al gruppo di interesse come userBiddingSignals. I dati proprietari dell'inserzionista saranno disponibili solo per gli acquirenti durante la fase di generazione delle offerte e non per i venditori.

Ad esempio, se l'inserzionista conosce il colore preferito dell'utente, il valore può essere impostato nella configurazione del gruppo di interesse come userBiddingSignals quando l'utente viene aggiunto a un gruppo di interesse:

const interestGroup = {
  owner: 'https://example-buyer.com',
  name: 'running-shoes',
  userBiddingSignals: {
    favoriteColor: 'blue' // First-party data
  },
  // ...other interest group settings
};

navigator.joinAdInterestGroup(interestGroup, 3600);

Il publisher può anche trasmettere i propri dati proprietari impostando gli indicatori nella configurazione dell'asta al momento dell'avvio dell'asta e può controllare chi li riceve. Quando un publisher trasmette i dati proprietari come auctionSignals, questi sono disponibili sia per gli acquirenti che per i venditori. Quando i dati vengono passati come sellerSignals, sono disponibili solo per il venditore, mentre se vengono passati come perBuyerSignals, sono disponibili solo per gli acquirenti specificati. Il publisher può anche trasmettere i dati proprietari alle aste componenti. Il publisher e i partecipanti all'asta devono concordare in anticipo quali dati proprietari devono essere condivisi e come devono essere formattati.

L'esempio seguente descrive in che modo il publisher può trasmettere i dati proprietari ai vari partecipanti all'asta:

const auctionConfig = {
  seller: 'https://example-seller.com',
  auctionSignals: {
    favoriteColor: 'blue', // Both buyer and seller will receive this signal
  },
  sellerSignals: {
    favoriteIceCreamFlavor: 'chocolate', // Only the seller will receive this signal
  },
  perBuyerSignals: {
    'https://example-buyer.com': {
      favoriteDrink: 'tea', // Only a specific buyer will receive this signal
    },
  },
  // The same pattern applies to the component auction
  componentAuctions: [{
    seller: 'https://example-component-seller.com',
    auctionSignals: { ... },
    sellerSignals: { ... },
    perBuyerSignals { ... }
  }],
  // ...other auction settings
};

navigator.runAdAuction(auctionConfig);

Scopri di più