Informazioni sulle chiavi di aggregazione per i report sull'attribuzione

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

In qualità di società 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 per ogni categoria di prodotto sono stati generati da 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 a quali domande rispondere prima di raccogliere i dati.

Dimensioni, chiavi e valori

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

Dimensioni

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

• ID campagna pubblicitaria: l'identificatore della campagna specifica.
• ID area geografica: l'area geografica in cui è stato pubblicato l'annuncio.
• Categoria di prodotto: il tipo di prodotto che 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 che vuoi monitorare per questo esempio sono quelle 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 dei servizi di aggregazione.

Una chiave di aggregazione (chiave per breve) è un dato che rappresenta i valori delle dimensioni monitorate. I dati vengono successivamente aggregati insieme 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 che si trova nell'ID area geografica 7 visualizza un annuncio per l'ID campagna 12 e in seguito effettua una conversione acquistando un prodotto nella categoria di prodotto 25, puoi impostare una chiave di aggregazione simile a quella dell'immagine seguente:

Più avanti vedremo che una chiave di aggregazione non ha esattamente questo aspetto nella pratica, ma per ora concentriamoci sulle informazioni contenute nella chiave.

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 aggregati vengono sommati per chiave di più utenti al fine di 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 che sia stato applicato rumore. Nella sezione successiva illustreremo questo esempio con il 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 o visualizza un annuncio e in seguito effettua una conversione, chiedi al browser di memorizzare una coppia di {aggregation key, aggregable value}.

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

Più avanti vedrai che un report aggregabile {aggregation key,aggregable value}non ha esattamente questo aspetto, ma per ora concentriamoci sulle informazioni contenute nel report.

Quando chiedi al browser di generare due contributi, quest'ultimo genera un report aggregabile (se può corrispondere alla conversione con una visualizzazione o un clic precedente).

Il 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 aggregati sono in formato JSON e includono, tra le altre cose, un campo del payload che verrà utilizzato come input dei 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 siano diversi da quelli dell'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:

• Un ad tech richiede report di riepilogo per un determinato insieme di chiavi e un determinato insieme di report aggregabili provenienti da molti browser (utenti).
• 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 sono codificati in modo da rendere i bucket e i valori diversi da quanto indicato nell'esempio (in altre parole, un bucket potrebbe essere simile a \u0000\u0000\x80\u0000). Bucket e value sono entrambi bytestring.

Le chiavi di aggregazione nella pratica

Le chiavi di aggregazione (bucket) sono definite da un'azienda di ad tech, solitamente in due passaggi: quando viene fatto clic o visualizzato su un annuncio 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: 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 sua cardinalità, ogni dimensione deve essere rappresentata da un certo numero di bit. Con n bit, è possibile esprimere 2ⁿ opzioni distinte.

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

7 bit memorizzerebbero solo 2⁷ = 128 opzioni distinte, meno dei 200 necessari.

8 bit memorizzerebbero 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, queste devono essere codificate in esadecimale. Nei report di riepilogo, le chiavi verranno visualizzate in formato binario (e denominate bucket).

Imposta due pezzi chiave per una chiave completa

Supponiamo di utilizzare una chiave per monitorare le seguenti dimensioni:

• ID campagna
• ID area geografica
• Categoria di prodotto

Mentre le dimensioni ID campagna e ID area geografica sono note al momento della pubblicazione dell'annuncio (tempo di pubblicazione dell'annuncio), la categoria di prodotto sarà nota per un evento di attivazione, quando l'utente completa una conversione (ora della 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, Categoria di prodotto, al momento della conversione.

Queste diverse parti dei tasti sono dette parti fondamentali.

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

Esempio:

• Elemento della chiave lato origine = 0x159
• Elemento chiave lato trigger = 0x400
• Chiave = 0x159 v 0x400 = 0x559

Allineamento dei componenti chiave

Con due pezzi della chiave a 64 bit estesi a 128 bit utilizzando riempimento/offset a 64 bit accuratamente posizionati (i sedici zeri), l'OR-ing pezzi chiave è equivalente a concatenarli, il che è più facile da ragionare e verificare:

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

Più chiavi per ogni clic o visualizzazione sull'annuncio

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

• Una chiave che monitora l'ID area geografica × ID campagna.
• Un'altra chiave che monitora Tipo di creatività × ID campagna.

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

Codifica delle dimensioni in chiavi

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

I report di riepilogo contengono coppie {key, summary value} 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 impostare le chiavi in modo affidabile in base ai valori delle dimensioni che rappresentano.
• Quando definisci le chiavi per le quali vuoi richiedere i report di riepilogo, devi generare o accedere rapidamente in modo affidabile alle stesse chiavi impostate quando l'utente ha visualizzato o fatto clic su un annuncio e ha effettuato la conversione, in base ai valori delle dimensioni per le quali vuoi visualizzare i dati aggregati.

Codifica delle dimensioni utilizzando le mappe strutturali delle chiavi

Per codificare le dimensioni in 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, la creazione e la gestione delle mappe delle strutture chiave richiedono l'implementazione e la gestione della logica di decodifica. Se cerchi un metodo che non ti richieda di farlo, valuta la possibilità di utilizzare un approccio basato su hash.

Ecco un esempio:

Supponiamo che tu abbia intenzione di monitorare sia gli acquisti sia i valori di acquisto 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 ciascuna dimensione, supponiamo per il tuo caso d'uso che tu debba monitorare quanto segue:

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

Ecco 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). Devi inoltre definire una mappa delle dimensioni per l'ID geografia in modo da conoscere la regione geografica rappresentata da ciascun 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 sarebbero lunghe 13 bit (5 + 1 + 3 + 4).

Per questo esempio, la mappa della struttura delle chiavi per queste chiavi sarebbe simile alla 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 che porta il valore numerico maggiore) è il bit più a sinistra. Il bit meno significativo, quello con il valore numerico più piccolo, è il bit più a destra.

Vediamo come useresti una mappa struttura delle chiavi 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 delle chiavi, questa chiave verrebbe decodificata in:

`11001 0 011 1100`

Quindi 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 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 dell'annuncio, genera una stringa che includa tutte le dimensioni che vuoi monitorare e i relativi valori. Per generare il pezzo della chiave sul lato di origine, esegui l'hashing di questa stringa e valuta la possibilità di aggiungere un suffisso di zeri a 64 bit per allinearlo con la chiave lato trigger e semplificare il ragionamento di OR.
   • Componente della 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 e più 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:
   • Elemento chiave lato trigger = <64-bit 00000000…><64-bit hex hash("productCategory=25")>
4. Il browser esegue l'OR di questi componenti della 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.
     • Elemento della chiave lato di origine
       = <64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000…>
     • Elemento chiave lato trigger
       = <64-bit 00000000…><64-bit hex hash("productCategory=25")>
     • elemento chiave lato trigger = toHex(hash("productCategory=25"))
   • Come per il browser, OPPURE questi elementi 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 lo stesso ordinamento delle dimensioni. In questo modo, gli hash possono essere rigenerati in modo affidabile. ("COUNT, CampaignID=12, GeoID=7" non genererà lo stesso hash di "COUNT, GeoID=7, CampaignID=12"). Un modo semplice per ottenere questo risultato è ordinare le dimensioni in modo alfanumerico. Questo è ciò che faremo nell'esempio, ad eccezione del fatto che renderemo sempre COUNT o VALUE il primo elemento della dimensione. Si tratta di una scelta per la leggibilità, poiché COUNT o VALUE codificano informazioni concettualmente diverse da quelle di tutte le altre dimensioni.
• Tieni traccia dell'insieme di dimensioni in uso nelle chiavi. Vuoi evitare di generare chiavi basate su un insieme di dimensioni mai utilizzate.
• 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 conflitto 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 un'analisi approfondita del budget per il contributo, consulta Budget contributo 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 sono le strategie delle campagne più efficaci in ogni regione?

Supponiamo anche che per il tuo caso d'uso tu abbia bisogno di insight settimanali.

Devi inoltre 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 prodotto.

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. Per questo motivo, devi selezionare con attenzione gli elementi da 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 è ragionevole e garantisce un semplice approccio di scalabilità per il budget di contributo.

E 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, assumeremo che tu possa dedurre la valuta da un ID campagna. In questo modo puoi convertire qualsiasi valore di acquisto dalla valuta locale dell'utente a una valuta di riferimento a 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 riepilogativo.

Tradurre gli obiettivi in chiavi

Gli obiettivi e le metriche di misurazione offrono diverse opzioni per la tua strategia chiave. Concentriamoci su due di queste strategie:

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

Strategia A: un albero approfondito (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 chiavi utilizzano questa struttura.

Suddividi questa struttura di chiavi 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 "un albero profondo":

• Ogni valore di riepilogo nei report di riepilogo è associato a tutte le dimensioni monitorate.
• Puoi aggregare questi valori di riepilogo accanto a ciascuna di queste dimensioni, in modo da avere una profondità pari al numero di dimensioni disponibili.

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 presenteranno rumore, è possibile determinare quando le differenze nel valore misurato tra ciascuna campagna non sono dovute unicamente al rumore. Scopri come farlo in Informazioni sul rumore.

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

Nella strategia B vengono utilizzate due strutture chiave approssimative, ciascuna delle quali include un sottoinsieme delle dimensioni necessarie:

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

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

Si finisce per avere 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 codice II-0: struttura del codice II, numero di 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 dei 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.

Questo non è il caso della 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 devi stabilire la strategia da utilizzare? Per gli inserzionisti o le campagne esistenti, potresti fare affidamento sui dati storici per determinare se il volume delle 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 relativi a 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 numero di acquisti settimanali e il valore di acquisto siano sufficientemente elevati da permettere alla strategia A di generare 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 di aver selezionato l'algoritmo SHA-256. Puoi anche utilizzare un algoritmo più semplice e meno sicuro, come MD5.

Nel browser: impostazione di chiavi e valori

Ora che hai scelto una struttura di chiavi e un algoritmo di hashing, puoi registrarne le chiavi e 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 i componenti 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 elemento chiave, nota al momento della pubblicazione dell'annuncio.

Generiamo gli elementi chiave:

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 utilizzate solo durante l'impostazione delle chiavi nel browser, in modo che le chiavi lato sorgente e lato trigger possano essere mappate tra loro e combinate 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. Puoi impostare questi elementi 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:

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"]
    },
  ])
);

Nota come aggiungi la stessa parte della chiave a più chiavi, elencando diversi ID chiave in source_keys: la chiave verrà aggiunta 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 di un prodotto di tipo 25 per 52 $.

Non li imposterai direttamente come valori aggregabili:

• key_purchaseCount: 1 conversione
• key_purchaseValue: 52 $

Prima di registrare questi valori aggregabili, devi invece 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 dei valori anomali, ad esempio pochissimi utenti che hanno speso oltre 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 scalabilità per il conteggio degli acquisti è 32.768/1 = 32.768, poiché hai deciso di monitorare al massimo un acquisto per clic o visualizzazione sull'annuncio (evento sorgente).

Ora puoi impostare questi 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 vista o a un clic precedente e genera un report aggregabile che include il payload criptato accanto ai metadati dei 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 singolo 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 della 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 dati di riepilogo al servizio di aggregazione 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 nel file binario. Tieni presente che, sebbene le chiavi siano eterogenee (COUNT o VALUE), sono contenute nello stesso report.

Fai lo scale down dei valori

• 2.558.500 si riferisce al numero di acquisti per questa chiave, aumentato in base al fattore di scalabilità calcolato in precedenza. Il fattore di scalabilità per il conteggio acquisti era 32.768. Dividi 2.558.500 per il budget per il 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.