Informazioni sulle chiavi di aggregazione per i report sull'attribuzione

bookmark_border Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Che cosa sono le chiavi di aggregazione, come vengono utilizzate nell'API Attribution Reporting e come puoi tradurre gli obiettivi in chiavi.

In qualità di azienda di ad tech che pubblica campagne in più località per varie categorie di prodotti, vuoi aiutare gli inserzionisti a rispondere alle seguenti domande:

1. Quanti acquisti di ogni categoria di prodotto ha generato ciascuna delle mie campagne in ogni regione geografica?
2. Quante entrate per ogni categoria di prodotto ha generato ciascuna delle mie campagne in ogni regione geografica?

Sebbene molte aziende di ad tech incoraggino gli inserzionisti a configurare una serie di tipi di conversione, concentrarsi sulle conversioni più importanti, come gli acquisti, è un buon modo per assicurarsi che i risultati di riepilogo siano dettagliati e accurati per questi eventi importanti.

Per farlo, devi pensare alle domande a cui vuoi rispondere prima che i dati vengano raccolti.

Dimensioni, chiavi e valori

Per rispondere a queste domande, diamo un'occhiata a dimensioni, chiavi e valori.

Dimensioni

Per capire in che modo le tue campagne generano entrate, come descritto qui, ti consigliamo di monitorare le seguenti dimensioni:

• ID campagna pubblicitaria: l'identificatore della campagna specifica.
• ID geografico: la regione geografica in cui è stato pubblicato l'annuncio.
• Categoria di prodotto: il tipo di prodotto così come lo hai definito.

Sebbene le dimensioni ID campagna e ID regione siano note al momento della pubblicazione dell'annuncio (data e ora di pubblicazione dell'annuncio), la categoria di prodotto sarà nota da un evento di attivazione, quando l'utente completa una conversione (data e ora di conversione).

Le dimensioni da monitorare per questo esempio sono mostrate nell'immagine seguente:

Che cosa sono le chiavi di aggregazione (bucket)?

I termini chiave di aggregazione e bucket si riferiscono alla stessa cosa. La chiave di aggregazione viene utilizzata nelle API del browser utilizzate per configurare i report. Il termine bucket viene utilizzato nei report aggregabili e di riepilogo e nelle API di servizio di aggregazione.

Una chiave di aggregazione (chiave per breve) è un dato che rappresenta i valori delle dimensioni monitorate. Successivamente, i dati vengono aggregati in base a ogni chiave di aggregazione.

Ad esempio, supponiamo che tu stia monitorando le dimensioni Categoria di prodotto, ID area geografica e ID campagna.

Quando un utente con sede nell'ID geografico 7 visualizza un annuncio per l'ID campagna 12 e in un secondo momento effettua una conversione acquistando un prodotto nella categoria di prodotto 25, puoi impostare una chiave di aggregazione simile a quella nell'immagine seguente:

Vedrai più avanti che una chiave di aggregazione non è esattamente così nella pratica, ma per il momento concentriamoci sulle informazioni contenute nella chiave.

Che cosa sono i valori aggregabili?

Per rispondere alle tue domande sulle dimensioni che abbiamo delineato, devi sapere:

• Il numero di acquisti (il conteggio acquisti). Una volta aggregato e reso disponibile in un report di riepilogo, questo sarà il numero totale di acquisti (valore di riepilogo).
• Le entrate per ogni acquisto (il valore di acquisto). Una volta aggregate e rese disponibili in un report di riepilogo, queste saranno le entrate totali (valore di riepilogo).

Ognuno di questi, il conteggio degli acquisti per una conversione e il valore di acquisto per una conversione, è un valore aggregabile. Puoi considerare i valori aggregabili come i valori dei tuoi obiettivi di misurazione.

Quando un utente con ID geografico 7 visualizza un annuncio per l'ID campagna 12 e in un secondo momento effettua una conversione acquistando un prodotto della categoria di prodotto 25 per 120 $ (supponendo che la valuta sia in $), puoi impostare una chiave di aggregazione e valori aggregabili come:

I valori aggregabili vengono sommati per chiave in molti utenti per generare approfondimenti aggregati, sotto forma di valori di riepilogo nei report di riepilogo.

I valori aggregabili vengono sommati per generare approfondimenti aggregati per i tuoi obiettivi di misurazione.

Tieni presente che questo diagramma omette la decrittografia e rappresenta un esempio semplificato senza rumore applicato. Nella sezione successiva illustreremo questo esempio con rumore.

Da chiavi e valori ai report

Ora vediamo in che modo le chiavi e i valori aggregabili si riferiscono ai report.

Report aggregabili

Quando un utente fa clic su un annuncio o lo visualizza e in seguito effettua una conversione, chiedi al browser di memorizzare una coppia {aggregation key, aggregatable value}.

Nel nostro esempio, quando un utente fa clic su un annuncio o lo visualizza e in seguito effettua una conversione, indichi al browser di generare due contributi (uno per ogni obiettivo di misurazione).

Vedrai in seguito che un report aggregabile {aggregation key, aggregatable value} non ha esattamente questo aspetto, ma per il momento concentriamoci sulle informazioni contenute nel report.

Quando indichi al browser di generare due contributi, il browser genera un report aggregabile (se può associare la conversione a una visualizzazione o a un clic precedente).

Un report aggregabile contiene:

• I contributi che hai configurato.
• Metadati sull'evento di clic o visualizzazione e sull'evento di conversione: il sito in cui si è verificata la conversione e altro ancora. Visualizza tutti i campi di un report aggregabile.

I report aggregabili sono formattati in JSON e includono, tra le altre cose, un campo del payload che verrà utilizzato come input di dati per il report di riepilogo finale.

Il payload contiene un elenco di contributi, ciascuno dei quali è una coppia {aggregation key, aggregatable value}:

• bucket: la chiave di aggregazione, codificata come stringa di byte.
• value: il valore aggregabile per l'obiettivo di misurazione, codificato come stringa di byte.

Ecco un esempio:

{
  "data": [
    {
      "bucket": "111001001",
      "value": "11111010000",
    }
  ],
  "operation": "histogram"
}

In pratica, i report aggregabili vengono codificati in modo che i bucket e i valori abbiano un aspetto diverso rispetto all'esempio precedente (ad esempio, un bucket potrebbe avere il seguente aspetto: \u0000\u0000\x80\u0000). Bucket e value sono entrambi stringhe di byte.

Report di riepilogo

I report aggregabili vengono aggregati su molti browser e dispositivi (utenti) come segue:

• Una tecnologia pubblicitaria richiede report di riepilogo per un determinato insieme di chiavi e un determinato insieme di report aggregabili provenienti da molti browser (utenti) diversi.
• I report aggregabili vengono decriptati dal servizio di aggregazione.
• Per ogni chiave, i valori aggregabili dei report aggregabili vengono sommati.
• Al valore di riepilogo viene aggiunto del rumore.

Il risultato è un report di riepilogo contenente un insieme di coppie {chiave di aggregazione, valore di riepilogo}.

Un report di riepilogo contiene un insieme di coppie chiave-valore in stile dizionario JSON. Ogni coppia contiene:

• bucket: la chiave di aggregazione, codificata come stringa di byte.
• value: il valore di riepilogo in decimale per un determinato obiettivo di misurazione, sommato da tutti i report aggregabili disponibili, con un livello aggiuntivo di rumore.

Esempio:

[
  {"bucket": "111001001", "value": "2558500"},
  {"bucket": "111101001", "value": "3256211"},
  {...}
]

In pratica, i report di riepilogo vengono codificati in modo che i bucket e i valori siano diversi da quanto indicato nell'esempio (ad esempio, un bucket potrebbe avere il seguente aspetto: \u0000\u0000\x80\u0000). Bucket e value sono entrambi stringhe di byte.

Chiavi di aggregazione nella pratica

Le chiavi di aggregazione (bucket) vengono definite da una società di ad tech, in genere in due passaggi: quando viene fatto clic su un annuncio o quando viene visualizzato e quando un utente effettua una conversione.

Struttura della chiave

Utilizzeremo il termine struttura della chiave per indicare l'insieme di dimensioni codificate in una chiave.

Ad esempio, ID campagna × ID geografico × Categoria di prodotto è una struttura chiave.

Tipi di chiavi

I valori aggregabili vengono sommati per una determinata chiave su più utenti/browser. Tuttavia, abbiamo riscontrato che i valori aggregabili possono monitorare diversi obiettivi di misurazione, ad esempio un valore di acquisto o un conteggio degli acquisti. Vuoi assicurarti che il servizio di aggregazione sommi i valori aggregabili dello stesso tipo.

A tal fine, in ogni chiave codifica un dato che indica cosa rappresenta il valore di riepilogo, ovvero lo scopo di misurazione a cui si riferisce la chiave. Un modo per farlo è creare una dimensione aggiuntiva per la chiave che rappresenti il tipo di obiettivo di misurazione.

Utilizzando l'esempio precedente, questo tipo di obiettivo di misurazione avrà due valori possibili diversi:

• Conteggio acquisti è il primo tipo di obiettivo di misurazione.
• Il valore di acquisto è il secondo tipo di obiettivo di misurazione.

Se hai n obiettivi di misurazione, il tipo di obiettivo di misurazione avrà n tipi diversi di valori.

Puoi considerare le dimensioni di una chiave come una metrica. Ad esempio, "il numero di acquisti di un determinato prodotto per campagna e per area geografica".

Dimensioni chiave, dimensioni delle dimensioni

La dimensione massima della chiave è definita in bit, ovvero il numero di zeri e uno in binario per creare la chiave completa. L'API consente una lunghezza della chiave di 128 bit.

Questa dimensione consente chiavi molto granulari, ma è più probabile che le chiavi più granulari generino valori con più rumore. Scopri di più sul rumore in Informazioni sul rumore.

Come introdotto in precedenza, le dimensioni vengono codificate nella chiave di aggregazione. Ogni dimensione ha una determinata cardinalità, ovvero il numero di valori distinti che può assumere. A seconda della cardinalità, ogni dimensione deve essere rappresentata da un determinato numero di bit. Con n bit, è possibile esprimere 2ⁿ opzioni distinte.

Ad esempio, una dimensione Paese può avere una cardinalità di 200, poiché ci sono circa 200 paesi al mondo. Quanti bit sono necessari per codificare questa dimensione?

Con 7 bit è possibile memorizzare solo 2⁷ = 128 opzioni distinte, meno delle 200 necessarie.

8 bit consentono di memorizzare 2⁸ = 256 opzioni distinte, ovvero più dei 200 necessari, quindi puoi utilizzare n=8 bit per codificare questa dimensione.

Codifica delle chiavi

Quando imposti le chiavi nel browser, devono essere codificate in esadecimale. Nei report di riepilogo, le chiavi vengono visualizzate in formato binario (e sono denominate bucket).

Impostare due pezzi di chiave per una chiave completa

Supponiamo che tu utilizzi una chiave per monitorare le seguenti dimensioni:

• ID campagna
• ID area geografica
• Categoria di prodotto

Sebbene le dimensioni ID campagna e ID regione siano note al momento della pubblicazione dell'annuncio (data e ora di pubblicazione dell'annuncio), la categoria di prodotto sarà nota da un evento di attivazione, quando l'utente completa una conversione (data e ora di conversione).

In pratica, dovrai impostare una chiave in due passaggi:

1. Imposterai una parte della chiave (ID campagna × ID area geografica) al momento del clic o della visualizzazione.
2. Imposterai la seconda parte della chiave, ovvero Categoria prodotto, al momento della conversione.

Queste diverse parti delle chiavi sono chiamate componenti della chiave.

Una chiave viene calcolata prendendo l'OR (v) dei relativi componenti.

Esempio:

• Componente chiave lato sorgente = 0x159
• Pezzo della chiave lato trigger = 0x400
• Chiave = 0x159 v 0x400 = 0x559

Allineamento dei componenti chiave

Con due componenti della chiave a 64 bit estesi a 128 bit utilizzando riempimenti/offset a 64 bit posizionati con cura (i sedici zeri), l'unione OR dei componenti della chiave è equivalente alla loro concatenazione, il che è più facile da comprendere e verificare:

• Componente chiave lato sorgente = 0xa7e297e7c8c8d0540000000000000000
• Pezzo della chiave lato trigger = 0x0000000000000000674fbe308a597271
• Chiave = 0xa7e297e7c8c8d0540000000000000000 v 0x0000000000000000674fbe308a597271 = 0xa7e297e7c8c8d054674fbe308a597271

Più chiavi per clic o visualizzazione dell'annuncio

In pratica, puoi impostare più chiavi per evento di origine dell'attribuzione (visualizzazione o clic sull'annuncio). Ad esempio, puoi impostare:

• Una chiave che monitora l'ID geografia × ID campagna.
• Un'altra chiave che monitora il tipo di creatività × ID campagna.

Dai un'occhiata alla strategia B per un altro esempio.

Codifica delle dimensioni in chiavi

Quando richiedi i report di riepilogo, devi indicare al servizio di aggregazione le metriche a cui vuoi accedere, richiedendo i report di riepilogo per un determinato insieme di chiavi di aggregazione.

I report di riepilogo contengono coppie {chiave, valore di riepilogo} non elaborate e nessuna informazione aggiuntiva sulla chiave. Ciò significa che:

• Quando imposti le chiavi quando l'utente visualizza o fa clic su un annuncio e in seguito effettua una conversione, devi impostarle in modo affidabile in base ai valori delle dimensioni che rappresentano.
• Quando definisci le chiavi per cui vuoi richiedere i report di riepilogo, devi generare o accedere in modo affidabile alle stesse chiavi impostate quando l'utente ha visualizzato o fatto clic su un annuncio e ha effettuato una conversione, in base ai valori delle dimensioni per cui vuoi visualizzare i dati aggregati.

Codifica delle dimensioni utilizzando le mappe della struttura delle chiavi

Per codificare le dimensioni nelle chiavi, puoi creare e gestire in anticipo una mappa della struttura delle chiavi, al momento della definizione delle chiavi (prima della pubblicazione degli annunci).

Una mappa della struttura della chiave rappresenta ciascuna delle dimensioni e la relativa posizione nella chiave.

In pratica, creare e gestire mappe delle strutture chiave significa dover implementare e gestire la logica di decodifica. Se cerchi un metodo che non ti richieda di farlo, ti consigliamo di utilizzare un approccio basato su hash.

Ecco un esempio:

Supponiamo che tu voglia monitorare sia gli acquisti sia i relativi valori per campagne, regioni geografiche e prodotti specifici.

La categoria di prodotto, l'ID geografico e l'ID campagna devono essere dimensioni nelle chiavi. Inoltre, poiché vuoi monitorare due diversi obiettivi di misurazione, ovvero il conteggio acquisti e il valore di acquisto, devi aggiungere una dimensione all'interno della chiave che tenga traccia del tipo di chiave. In questo modo, potrai definire cosa rappresenta effettivamente il valore aggregabile quando ricevi coppie {key, aggregatable value} nei report di riepilogo.

Con questi obiettivi di misurazione, la chiave ha le seguenti dimensioni:

• Categoria di prodotto
• Tipo di obiettivo di misurazione
• ID area geografica
• ID campagna

Ora, esaminando ogni dimensione, supponiamo per il tuo caso d'uso che tu debba monitorare quanto segue:

• 29 diverse categorie di prodotti.
• 8 diverse regioni geografiche: Nord America, America Centrale, Sud America, Europa, Africa, Asia, Caraibi e Oceania.
• 16 campagne diverse.

Di seguito è riportato il numero di bit necessari per codificare ogni dimensione nella chiave:

• Categoria di prodotto: 5 bit (2⁵ = 32 > 29).
• Tipo di obiettivo di misurazione: 1 bit. L'obiettivo di misurazione è il conteggio acquisti o il valore di acquisto, ovvero due possibilità distinte; pertanto, è sufficiente un bit per memorizzarlo.

• ID area geografica: 3 bit (2³ = 8). Dovresti anche definire una mappa delle dimensioni per l'ID geografico per sapere quale regione geografica rappresenta ogni valore binario. La mappa delle dimensioni per la dimensione ID geografico potrebbe avere il seguente aspetto:

  Valore binario nella chiave	Area geografica
  000	Nord America
  001	America centrale
  010	Sud America
  011	Europa
  100	Africa
  101	Asia
  110	Caraibici
  111	Oceania

• ID campagna: 4 bit (2⁴ = 16)

Le chiavi che seguono questa struttura sono lunghe 13 bit (5 + 1 + 3 + 4).

Per questo esempio, la mappa della struttura delle chiavi per queste chiavi sarà la seguente:

L'ordine delle dimensioni all'interno della chiave è a tua scelta.

Per illustrare come le dimensioni costituiscono una struttura di chiave, utilizzeremo una rappresentazione binaria, motivo per cui l'ID campagna (primi bit) è quello più a destra e la categoria di prodotto (ultimi bit) è quella più a sinistra.

All'interno di ogni dimensione, il bit più significativo, quello con il valore numerico più elevato, è il bit più a sinistra. Il bit meno significativo, quello con il valore numerico più piccolo, è il bit più a destra.

Vediamo come utilizzare una mappa della struttura della chiave per decodificare una chiave.

Prendiamo 0b1100100111100 come chiave di esempio arbitraria e supponiamo di avere un modo per sapere che questa chiave segue la mappa della struttura della chiave nell'illustrazione precedente.

In base alla mappa della struttura della chiave, questa chiave viene decodificata in:

`11001 0 011 1100`

Pertanto, la chiave 0b1100100111100 rappresenta il numero di acquisti della categoria di prodotto 25 per l'ID campagna 12 lanciato in Europa.

Codifica delle dimensioni utilizzando una funzione hash

Anziché utilizzare una mappa della struttura delle chiavi, puoi utilizzare una funzione di hashing per generare dinamicamente le chiavi in modo coerente e affidabile.

Ecco come funziona:

1. Seleziona un algoritmo di hashing.
2. Al momento della pubblicazione degli annunci, genera una stringa che includa tutte le dimensioni che vuoi monitorare e i relativi valori. Per generare il componente chiave lato sorgente, esegui l'hash di questa stringa e valuta la possibilità di aggiungere un suffisso di zeri a 64 bit per allinearlo al componente chiave lato trigger e semplificare il ragionamento sull'OR.
   • Componente chiave lato sorgente
     = <64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000…>
   • Tieni presente che COUNT codifica la stessa cosa di measurementGoalType=0 nell'approccio della mappa della struttura chiave. COUNT è un po' più snello ed esplicito.
3. Al momento della conversione, genera una stringa che includa tutte le dimensioni da monitorare e i relativi valori. Per generare un componente della chiave lato trigger, sottoponi questa stringa ad hashing e aggiungi un prefisso di zeri di 64 bit:
   • Pezzo della chiave lato trigger = <64-bit 00000000…><64-bit hex hash("productCategory=25")>
4. Il browser esegue l'OR di questi componenti chiave per generare una chiave.
   • Chiave di aggregazione a 128 bit
     = <64-bit hex source-side key piece hash><64-bit hex source-side key piece hash>
5. In un secondo momento, quando vuoi richiedere un report di riepilogo per questa chiave, generalo al volo:
   • In base alle dimensioni che ti interessano, genera un elemento chiave lato sorgente e lato attivatore come hai fatto in precedenza.
     • Componente della chiave lato sorgente
       = <64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000…>
     • Pezzo della chiave lato trigger
       = <64-bit 00000000…><64-bit hex hash("productCategory=25")>
     • Pezzo chiave lato trigger = toHex(hash("productCategory=25"))
   • Come nel browser, OR questi componenti della chiave per generare la stessa chiave generata in precedenza dal browser.
     • Chiave di aggregazione a 128 bit
       = <64-bit source-side key piece hash><64-bit source-side key piece hash>

Ecco alcuni suggerimenti pratici se utilizzi questo approccio basato su hash:

• Utilizza sempre la stessa organizzazione delle dimensioni. In questo modo, gli hash possono essere rigenerati in modo affidabile. ("COUNT, CampaignID=12, GeoID=7" non genera lo stesso hash di "COUNT, GeoID=7, CampaignID=12"). Un modo semplice per farlo è ordinare le dimensioni in ordine alfabetico. È ciò che faremo nell'esempio, tranne per il fatto che imposteremo sempre COUNT o VALUE come primo elemento della dimensione. Si tratta di una scelta per la leggibilità, in quanto COUNT o VALUE codificano informazioni concettualmente leggermente diverse da tutte le altre dimensioni.
• Tieni traccia dell'insieme di dimensioni che utilizzi nelle chiavi. Vuoi evitare di generare chiavi in base a un insieme di dimensioni che non hai mai utilizzato.
• Le collisioni di hash sono rare se viene utilizzata una funzione di hash adatta, ma il controllo rispetto agli hash utilizzati in precedenza (che devono essere archiviati per interpretare i risultati del servizio di aggregazione) può evitare di introdurre nuove chiavi che entrano in collisione con quelle precedenti.

Scopri come utilizzare le chiavi basate su hash nella pratica nell'esempio di una conversione per clic o visualizzazione.

Valori aggregabili nella pratica

La società di ad tech imposta valori aggregabili quando un utente effettua una conversione.

Per proteggere la privacy degli utenti, i contributi di ciascun utente hanno un limite massimo. Tra tutti i valori aggregabili associati a una singola origine (clic o visualizzazione dell'annuncio), nessun valore può essere superiore a un determinato limite di contributo.

Ci riferiremo a questo limite come CONTRIBUTION_BUDGET. Nell'articolo esplicativo, questo limite è chiamato budget L1, ma è uguale a CONTRIBUTION_BUDGET.

Per una discussione approfondita del budget dei contributi, consulta Budget dei contributi per i report di riepilogo.

Esempio: una conversione per clic o visualizzazione

Per questo esempio, supponiamo che tu voglia rispondere alle seguenti domande:

• Quali categorie di prodotti sono più redditizie in ogni regione?
• Quali strategie di campagna sono le più efficaci in ogni regione?

Supponiamo inoltre che per il tuo caso d'uso siano necessari approfondimenti settimanali.

Devi anche monitorare quanto segue:

• 16 campagne diverse.
• 8 diverse regioni geografiche: Nord America, America Centrale, Sud America, Europa, Africa, Asia, Caraibi e Oceania.
• 29 diverse categorie di prodotti.

Che cosa misurare

Sebbene molte aziende di ad tech incoraggino gli inserzionisti a configurare una serie di tipi di conversione, concentrarsi sulle conversioni più importanti, come gli acquisti, è un buon modo per assicurarsi che i risultati aggregati siano dettagliati e accurati per questi importanti eventi di conversione. Infatti, più metriche misuri, più piccolo sarà il budget per contributo per metrica e, di conseguenza, più elevato sarà il livello di rumore di ciascun valore. Pertanto, devi selezionare con attenzione cosa misurare.

In questo esempio, ci concentreremo sulle configurazioni delle campagne che misurano una sola conversione per clic o visualizzazione: un acquisto.

Continuerai a misurare sia il numero di acquisti sia il valore di acquisto e potrai accedere a una serie di statistiche aggregate importanti, come il valore totale degli acquisti e le suddivisioni geografiche. In questo modo, il rumore rimane ragionevole e viene garantito un approccio di scalabilità semplice per il budget dei contributi.

E per le valute?

La pubblicazione di campagne in regioni diverse implica che le valute devono essere prese in considerazione. Potresti:

• Rendi la valuta una dimensione dedicata nelle chiavi di aggregazione.
• In alternativa, deduci la valuta da un ID campagna e converti tutte le valute in valute di riferimento.

In questo esempio, supponiamo che tu possa dedurre la valuta da un ID campagna. In questo modo puoi convertire qualsiasi valore di acquisto dalla valuta locale dell'utente in una valuta di riferimento di tua scelta. Puoi anche eseguire la conversione al volo, quando l'utente acquista un articolo.

Con questa tecnica, tutti i valori aggregabili sono nella stessa valuta di riferimento e possono quindi essere sommati per generare un valore di acquisto aggregato totale, ovvero un valore di acquisto complessivo.

Tradurre gli obiettivi in chiavi

Con gli obiettivi e le metriche di misurazione, hai a disposizione diverse opzioni per la tua strategia principale. Concentriamoci su due di queste strategie:

• Strategia A: una struttura di chiavi granulare.
• Strategia B: due strutture chiave approssimative.

Strategia A: un albero profondo (una struttura di chiavi granulare)

Nella strategia A utilizzi una struttura di chiavi granulare che include tutte le dimensioni di cui hai bisogno:

Tutte le tue chiavi utilizzano questa struttura.

Suddividi questa struttura in due tipi di chiavi per supportare due scopi di misurazione.

• Tipo di chiave 0: tipo di obiettivo di misurazione = 0, che decidi di definire come conteggio acquisti.
• Tipo di chiave 1: tipo di obiettivo di misurazione = 1, che decidi di definire come valore di acquisto.

I report di riepilogo hanno il seguente aspetto:

Puoi considerare la strategia A come una strategia "ad albero singolo":

• Ogni valore di riepilogo nei report di riepilogo è associato a tutte le dimensioni monitorate.
• Puoi aggregare questi valori di riepilogo insieme a ciascuna di queste dimensioni, in modo che questi raggruppamenti possano essere approfonditi in base al numero di dimensioni di cui disponi.

Con la strategia A, risponderesti alle domande nel seguente modo:

Con la strategia A, puoi anche rispondere direttamente a questa terza domanda:

"Quante entrate per ogni prodotto ha generato ciascuna delle mie campagne in ogni regione geografica?"

Anche se i valori di riepilogo saranno poco affidabili, puoi determinare quando le differenze nel valore misurato tra ogni campagna non sono dovute solo al rumore. Scopri come farlo in Informazioni sul rumore.

Strategia B: due alberi poco profondi (due strutture chiave approssimative)

Nella strategia B utilizzi due strutture di chiavi approssimative, ciascuna contenente un sottoinsieme delle dimensioni di cui hai bisogno:

Dividi ciascuna di queste strutture chiave in due tipi di chiavi per supportare due scopi di misurazione.

• Tipo di obiettivo di misurazione = 0, che decidi di definire come conteggio acquisti.
• Tipo di obiettivo di misurazione = 1, che decidi di definire come valore di acquisto.

Hai a disposizione quattro tipi di chiavi:

• Tipo di chiave I-0: struttura della chiave I, conteggio acquisti.
• Tipo di chiave I-1: struttura della chiave I, valore di acquisto.
• Tipo di chiave II-0: struttura della chiave II, conteggio acquisti.
• Tipo di chiave II-1: struttura della chiave II, valore di acquisto.

I report di riepilogo hanno il seguente aspetto:

Puoi considerare la strategia B come una strategia "a due alberi poco profondi":

• I valori di riepilogo nei report di riepilogo vengono mappati a uno di due piccoli insiemi di dimensioni.
• Puoi aggregare questi valori di riepilogo insieme a ciascuna delle dimensioni in questi set. Ciò significa che questi raggruppamenti non sono così approfonditi come nell'opzione A, poiché ci sono meno dimensioni in base alle quali eseguire l'aggregazione.

Con la strategia B, risponderesti alle domande nel seguente modo:

Decisione: strategia A

La strategia A è più semplice: tutti i dati seguono la stessa struttura di chiavi, il che significa anche che devi gestire una sola struttura di chiavi.

Tuttavia, con la strategia A devi sommare i valori di riepilogo che ricevi nei report di riepilogo per rispondere ad alcune delle tue domande. Ognuno di questi valori di riepilogo è soggetto a errori. Sommando questi dati, sommi anche il rumore.

Non è così con la strategia B, in cui i valori di riepilogo esposti nei report di riepilogo forniscono già le informazioni di cui hai bisogno. Ciò significa che la strategia B probabilmente avrà un impatto minore del rumore rispetto alla strategia A.

Come dovresti determinare quale strategia utilizzare? Per gli inserzionisti o le campagne esistenti, puoi fare affidamento sui dati storici per determinare se il volume di conversioni è più adatto alla strategia A o alla strategia B. Tuttavia, per i nuovi inserzionisti o le nuove campagne, puoi decidere di:

• Raccogli i dati di un mese con le chiavi granulari (strategia A). Poiché estendi la durata della raccolta dei dati, i valori di riepilogo saranno superiori e il rumore sarà relativamente inferiore.
• Valuta con ragionevole precisione il numero di conversioni settimanali e il valore di acquisto.

In questo esempio, supponiamo che il conteggio degli acquisti settimanali e il valore di acquisto siano sufficientemente elevati da far sì che la strategia A generi una percentuale di rumore che ritieni accettabile per il tuo caso d'uso.

Poiché la strategia A è più semplice e comporta un impatto del rumore che non influisce sulla tua capacità di prendere decisioni, decidi di adottarla.

Seleziona un algoritmo di hashing

Decidi di adottare un approccio basato su hash per generare le chiavi. Per farlo, devi selezionare un algoritmo di hashing per supportare questo approccio.

Supponiamo che tu abbia selezionato SHA-256. Puoi anche utilizzare un algoritmo più semplice e meno sicuro, come MD5.

Nel browser: imposta chiavi e valori

Ora che hai scelto una struttura di chiavi e un algoritmo di hashing, puoi registrarle e registrarne i valori quando gli utenti fanno clic sugli annunci o li visualizzano e poi effettuano una conversione.

Di seguito è riportata una panoramica delle intestazioni che imposterai per registrare chiavi e valori nel browser:

Impostare gli elementi chiave lato sorgente

Quando un utente fa clic su un annuncio o lo visualizza, imposta le chiavi di aggregazione nell'Attribution-Reporting-Register-Aggregatable-Sourceheader. In questa fase, per ogni chiave puoi impostare solo la parte della chiave, o componente della chiave, che è nota al momento della pubblicazione dell'annuncio.

Generiamo gli elementi chiave:

Ora impostiamo gli elementi chiave:

// Upon receiving the request from the publisher site
res.set(
  "Attribution-Reporting-Register-Aggregatable-Source",
  JSON.stringify([
    {
      "id": "key_purchaseCount",
      "key_piece": "0x3cf867903fbb73ec0000000000000000"
    },
    {
      "id": "key_purchaseValue",
      "key_piece": "0x245265f432f16e730000000000000000"
    }
  ])
);

Tieni presente che gli ID chiave non verranno visualizzati nei report finali. Vengono utilizzati solo quando si impostano le chiavi nel browser, in modo che i componenti delle chiavi lato sorgente e lato attivatore possano essere mappati tra loro e combinati in una chiave completa.

(Facoltativo) Report a livello di evento

Se devi utilizzare i report a livello di evento insieme a quelli aggregabili, assicurati che per una determinata origine sia possibile associare i dati a livello di evento (ID evento di origine e dati sull'attivatore) e la chiave di aggregazione.

Potresti utilizzare entrambi i report se, ad esempio, prevedi di utilizzare i report a livello di evento per eseguire modelli sui tipi di annunci che tendono a generare il maggior numero di acquisti.

Un utente effettua una conversione

Quando un utente effettua una conversione, in genere viene inviata una richiesta di pixel al server ad tech. Al ricevimento di questa richiesta:

• Imposta i componenti della chiave lato conversione (lato attivatore) per completare la chiave. Imposterai questi componenti chiave tramite l'intestazione Attribution-Reporting-Register-Aggregatable-Trigger-Data.
• Imposta il valore aggregabile per la conversione tramite l'intestazione Attribution-Reporting-Register-Aggregatable-Values.

Imposta i componenti della chiave lato trigger per completare la chiave

Generiamo gli elementi chiave:

Ora impostiamo gli elementi chiave:

// Upon receiving the pixel request from the advertiser site
res.set(
  "Attribution-Reporting-Register-Aggregatable-Trigger-Data",
  JSON.stringify([
    // Each dictionary independently adds pieces to multiple source keys
    {
      "key_piece": "0x0000000000000000f9e491fe37e55a0c",
      "source_keys": ["key_purchaseCount", "key_purchaseValue"]
    },
  ])
);

Tieni presente che aggiungi lo stesso elemento chiave a più chiavi elencando più ID chiave in source_keys: l'elemento chiave verrà aggiunto a entrambe le chiavi.

Impostare valori aggregabili

Prima di impostare i valori aggregabili, devi aumentarli per ridurre il rumore.

Supponiamo che sia stato effettuato un acquisto per il tipo di prodotto 25 al prezzo di 52 $.

Non li imposterai direttamente come valori aggregabili:

• key_purchaseCount: 1 conversione
• key_purchaseValue: 52 $

Invece, prima di registrare questi valori aggregabili, devi scalarli per ridurre al minimo il rumore.

Hai due obiettivi in base ai quali spendere il budget di contributo, quindi potresti decidere di suddividerlo in due.

In questo caso, a ogni obiettivo viene allocato un massimo di CONTRIBUTION_BUDGET/2 (=65.536/2=32.768).

Supponiamo che il valore di acquisto massimo per un singolo utente, in base alla cronologia acquisti di tutti gli utenti del sito, sia di 1500 $. Potrebbero esserci valori anomali, ad esempio pochissimi utenti che hanno speso più di questa somma, ma puoi decidere di ignorarli.

Il fattore di scalabilità per il valore di acquisto deve essere:

((CONTRIBUTION_BUDGET/2) / 1500) = 32.768/1500 = 21,8 ≈ 22

Il fattore di scala per il conteggio degli acquisti è 32.768/1 = 32.768, poiché hai scelto di monitorare al massimo un acquisto per clic o visualizzazione dell'annuncio (evento di origine).

Ora puoi impostare i seguenti valori:

• key_purchaseCount: 1 × 32.768 = 32.768
• key_purchaseValue: 52 × 22 = 1144

In pratica, li imposterai come segue, utilizzando l'intestazione dedicataAttribution-Reporting-Register-Aggregatable-Values:

// Instruct the browser to schedule-send a report
res.set(
  "Attribution-Reporting-Register-Aggregatable-Values",
  JSON.stringify({
    "key_purchaseCount": 32768,
    "key_purchaseValue": 1144,
  })
);

Viene generato il report aggregabile

Il browser associa la conversione a una visualizzazione o a un clic precedente e genera un report aggregabile, che include il payload criptato accanto ai metadati del report.

Di seguito è riportato un esempio dei dati che potrebbero essere trovati nel payload del report aggregabile, se fosse leggibile in testo normale:

[
  {
    key: 0x3cf867903fbb73ecf9e491fe37e55a0c, // = source-side key piece OR conversion-side key piece for the key key_purchaseCount
    value: 32768 // the scaled value for 1 conversion, in the context of [CONTRIBUTION_BUDGET/2]
  },
  {
    key: 0x245265f432f16e73f9e491fe37e55a0c, // source-side key piece OR conversion-side key piece for the key key_purchaseValue
    value: 1144 // the scaled value for $52, in the context of [CONTRIBUTION_BUDGET/2]
  },
]

Qui puoi vedere due contributi distinti all'interno di un unico report aggregabile.

Richiedere un report di riepilogo

• Report aggregabili in batch. Segui i consigli forniti in Elaborazione collettiva.
• Genera le chiavi per cui vuoi visualizzare i dati. Ad esempio, per visualizzare i dati di riepilogo per COUNT (numero totale di acquisti) e VALUE (valore totale degli acquisti) per l'ID campagna 12 × ID area geografica 7 × Categoria prodotto 25:
  • Genera il frammento di chiave lato sorgente, come hai fatto quando l'hai impostato nel browser.
  • Genera il componente della chiave lato trigger, come hai fatto quando l'hai impostato nel browser.

• Richiedi al servizio di aggregazione i dati di riepilogo per queste chiavi.

Gestire il report di riepilogo

Alla fine, riceverai un report di riepilogo che potrebbe avere il seguente aspetto:

[
  {"bucket": "00111100111110000110011110010000001111111011101101110011111011001111100111100100100100011111111000110111111001010101101000001100",
    "value": "2558500"},
  {"bucket": "00100100010100100110010111110100001100101111000101101110011100111111100111100100100100011111111000110111111001010101101000001100",
    "value": "687060"},
  …
]

Il primo bucket è la chiave COUNT in binario. Il secondo bucket è la chiave VALUE in formato binario. Tieni presente che, sebbene le chiavi siano eterogenee (COUNT rispetto a VALUE), sono contenute nello stesso report.

Riduci i valori

• 2.558.500 si riferisce al numero di acquisti per questa chiave, aumentato in base al fattore di scala calcolato in precedenza. Il fattore di scalabilità per il contenuto del conteggio acquisti era 32.768. Dividi 2.558.500 per il budget di contributo dell'obiettivo: 2.558.500/32.768 = 156,15 acquisti.
• 687.060 → 687.060/22 = valore di acquisto totale di 31.230 $.

Di conseguenza, i report di riepilogo forniscono le seguenti informazioni:

- Within the reporting time period, campaign #12
  run in Europe drove about 156 purchases (± noise)
  for the product category #25
  ```

  ```text
- Within the reporting time period, campaign #12
  run in Europe drove $31,230 of purchases (± noise)
  for the product category #25.