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 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 per ciascuna categoria di prodotto sono stati generati da ciascuna delle mie campagne in ogni regione geografica?
2. Quante entrate sono state generate per ogni categoria di prodotto da ciascuna delle mie campagne in ogni regione geografica?

Anche se molte aziende di ad tech incoraggiano gli inserzionisti a configurare diversi tipi di conversione, concentrarsi sulle conversioni più importanti, come gli acquisti, è un buon modo per garantire che i risultati riepilogativi siano dettagliati e precisi per questi eventi importanti.

A questo scopo, devi pensare a quali domande 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.

Nota: le chiavi di aggregazione descritte in questo documento sono specifiche dell'API Attribuion Reporting.

Dimensioni

Per capire in che modo 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: la regione geografica in cui è stato pubblicato l'annuncio.
• Categoria di prodotto: il tipo di prodotto definito.

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

Nota: per il diagramma riportato in questo documento, le dimensioni sono le seguenti: - Dimensioni note al momento della pubblicazione degli annunci su sfondo verde. - Dimensioni note al momento della conversione su sfondo giallo e sottolineato.

Le dimensioni che vuoi monitorare per questo esempio sono quelle mostrate nell'immagine seguente:

Dimensioni da monitorare

Che cosa sono le chiavi di aggregazione (bucket)?

I termini chiave di aggregazione e bucket fanno riferimento 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 per i servizi di aggregazione.

Una chiave di aggregazione è un dato che rappresenta i valori delle dimensioni monitorate. I dati vengono successivamente aggregati in base a ogni chiave di aggregazione.

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

Quando un utente che si trova nell'ID area geografica 7 vede 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 nell'immagine seguente:

Più avanti noterai che una chiave di aggregazione non avrà in pratica il seguente aspetto, ma per ora concentriamoci sulle informazioni contenute nella chiave.

Cosa sono i valori aggregabili?

Per rispondere alle tue domande in merito alle dimensioni descritte, tieni presente quanto segue:

• Il numero di acquisti (numero di acquisti). Dopo averli aggregati e resi disponibili in un report di riepilogo, questo sarà il conteggio totale degli 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).

Ciascuno di questi, il conteggio dell'acquisto per una conversione e il valore di acquisto per una conversione, è un valore aggregabile. Puoi considerare i valori aggregabili come i valori degli obiettivi di misurazione.

Domanda	Valore aggregato = obiettivo di misurazione
		Quanti acquisti...	Numero di acquisti
A quanto entrate...	Valore di acquisto

Se un utente che si trova nell'ID area geografica 7 vede un annuncio per l'ID campagna 12 e in seguito effettua una conversione acquistando un prodotto della categoria di prodotto 25 per 120 $ (supponendo che la valuta sia USD), puoi impostare una chiave di aggregazione e valori aggregabili simili a questi:

Chiave di aggregazione e valori aggregabili. Tieni presente che i valori aggregabili sono in grassetto su uno sfondo blu.

I valori aggregati vengono sommati per chiave per più utenti per generare approfondimenti aggregati, sotto forma di valori di riepilogo nei report di riepilogo.

I valori aggregati vengono sommati per generare informazioni aggregate per i tuoi obiettivi di misurazione.

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

Da chiavi e valori ai report

Ora vediamo come le chiavi e i valori aggregabili sono correlati ai report.

Report aggregati

Quando un utente fa clic su un annuncio o lo visualizza e poi effettua una conversione, indichi al browser di memorizzare una coppia {aggregation key, aggregable value}.

Nota: nel <a href="https://github.com/WICG/conversion-measurement-api/blob/main/AGGREGATE.md">spiegatore</a>, una coppia di {aggregation key,aggregable value} è chiamata anche contributo dell'histogramma, che rappresenta il modo in cui questa conversione, nonché le dimensioni e i valori associati, contribuisce al report di riepilogo.

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

Più avanti scoprirai che un report aggregabile {aggregation key, aggregatoble value}aggregabile non assomiglia esattamente a questo, ma per il momento concentriamoci sulle informazioni contenute nel report.

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

Un report aggregabile contiene:

• I contributi che hai configurato.
• I metadati relativi all'evento di clic o visualizzazione e all'evento di conversione: il sito in cui si è verificata la conversione e altro ancora. Vedi tutti i campi nel report aggregabile.

I report aggregati sono in formato JSON e includono, tra le altre cose, un campo 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 di {aggregation key, aggregateble value}:

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

Esempio:

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

In pratica, i report aggregabili sono codificati in modo da rendere i bucket e i valori diversi rispetto all'esempio precedente (ossia un bucket potrebbe essere simile a \u0000\u0000\x80\u0000). Bucket e value sono entrambi stringhe di byte.

Report di riepilogo

I report aggregati vengono aggregati per molti browser e dispositivi (utenti), come indicato di seguito:

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

Il risultato è un report di riepilogo che contiene un insieme di coppie {aggregation key, summary value}.

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

• bucket: la chiave di aggregazione, codificata come bytestring.
• value: il valore di riepilogo in decimale per un determinato obiettivo di misurazione, riassunto da tutti i report aggregabili disponibili, con un ulteriore livello 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 (ossia, un bucket può essere simile a \u0000\u0000\x80\u0000). Bucket e valore sono entrambi stringhe di byte.

Chiavi di aggregazione nella pratica

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

Struttura chiave

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

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

Tipi di chiavi

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

A questo scopo, codifica all'interno di ogni chiave un dato che indichi che cosa rappresenta il valore di riepilogo, ovvero l'obiettivo di misurazione a cui fa riferimento questa 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 avrebbe due diversi valori possibili:

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

Se avevi n obiettivi di misurazione, l'obiettivo di misurazione avrebbe n tipi diversi di valori.

Le dimensioni di una chiave sono considerate come una metrica. Ad esempio, "il numero di acquisti di un determinato prodotto per campagna per area geografica".

Dimensioni chiave, dimensione dimensione

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

Questa dimensione consente di utilizzare chiavi molto granulari, ma quelle più granulari hanno maggiori probabilità di generare valori più "rumorosi". Per saperne di più sul rumore, consulta Comprendere il rumore.

Come introdotto in precedenza, le dimensioni sono codificate nella chiave di aggregazione. Ogni dimensione ha una certa 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 2n opzioni distinte.

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

7 bit archiviano solo 27 =128 opzioni distinte, che sono inferiori ai 200 necessari.

8 bit archiviano 28 =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 binario (e saranno denominate bucket).

Nota: i dati esadecimali hanno in genere come prefisso 0x ("x" per esadecimale). Ad esempio, 0 x 19 è 19 in esadecimale; è 25 in decimale, non 19. I numeri binari sono in genere preceduti da 0b ("b" per i numeri binari). Ad esempio, 0b11001 corrisponde a 11001 in formato binario; vale a dire 25 in decimale, non 11.001.

Crea due elementi chiave per una chiave completa

Supponiamo che utilizzi 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 (data e ora di pubblicazione dell'annuncio), la categoria di prodotto sarà nota da un evento di attivazione, quando l'utente completa una conversione (ora della conversione).

In pratica, questo significa che dovrai impostare una chiave in due passaggi:

1. Dovrai impostare una parte della chiave, ID campagna x ID area geografica, al momento del clic o della visualizzazione.
2. Dovrai impostare la seconda parte della chiave, Categoria di prodotto, al momento della conversione.

Queste diverse parti delle chiavi sono chiamate pezzi chiave.

Una chiave viene calcolata prendendo lo XOR (^) delle parti chiave.

Esempio:

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

Allineamento degli elementi chiave

Con due parti chiave a 64-bit estesi a 128 bit utilizzando riempitivi/offset a 64 bit posizionati accuratamente (i sedici zeri), pezzi chiave XOR-ing equivale a concatenarli, il che è più facile ragionare e verificare:

• Elemento chiave lato origine = 0xa7e297e7c8c8d0540000000000000000
• Elemento chiave lato trigger = 0x0000000000000000674fbe308a597271
• Chiave =
  • 0xa7e297e7c8c8d0540000000000000000 ^ 0x000000000000000674fbe308a597271 =
  • 0xa7e297e7c8c8d054674fbe308a597271

Più chiavi per visualizzazione o clic sull'annuncio

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

• Una chiave che tiene traccia dell'ID area geografica x dell'ID campagna.
• Un'altra chiave che monitora Tipo di creatività x ID campagna.

Per un altro esempio, guarda la Strategia B.

Codificare le dimensioni in chiavi

Quando richiedi 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 non elaborate {key, summary value} e non 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 cui vuoi richiedere report di riepilogo, devi generare o accedere in modo affidabile e immediato 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 dati aggregati.

Codifica delle dimensioni utilizzando le mappe struttura di chiavi

Per codificare le dimensioni in chiavi, puoi creare e mantenere in anticipo una mappa della struttura di chiavi al momento della definizione delle chiavi (prima della pubblicazione dell'annuncio).

Una mappa struttura chiave rappresenta tutte le dimensioni e la loro posizione nella chiave.

In pratica, creare e gestire mappe della struttura chiave significa che è necessario implementare e mantenere la logica del decoder. Se stai cercando un metodo che non lo richieda, valuta la possibilità di utilizzare un approccio basato su hash.

Esempio:

Supponiamo che tu preveda di monitorare sia gli acquisti sia i valori di acquisto per campagne, regioni geografiche e prodotti specifici.

La categoria di prodotto, l'ID area geografica e l'ID campagna devono essere dimensioni nelle chiavi. Inoltre, poiché vuoi monitorare due diversi obiettivi di misurazione (conteggio degli acquisti e 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 di {key, aggregable 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 che per il tuo caso d'uso sia necessario monitorare quanto segue:

• 29 diverse categorie di prodotti.
• 8 regioni geografiche diverse: Nord America, America Centrale, 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 (25 = 32 > 29).
• Tipo di obiettivo di misurazione: 1 bit. L'obiettivo di misurazione è il conteggio degli acquisti o il valore di acquisto, ossia due possibilità distinte; pertanto, un bit è sufficiente per memorizzarlo.

• ID area geografica: 3 bit (23 = 8). Devi anche definire una mappa di dimensioni per l'ID area geografica per conoscere la regione geografica rappresentata da ciascun valore binario. La mappa delle dimensioni per la dimensione ID geografica 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 (24 = 16)

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

Per questo esempio, la mappa della struttura di chiavi per queste chiavi sarebbe la seguente:

L'ordine delle dimensioni all'interno della chiave spetta a te.

Per illustrare come le dimensioni costituiscono una struttura chiave, utilizzeremo una rappresentazione binaria, motivo per cui l'ID campagna (i 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 che porta il valore numerico più basso, è il bit più a destra.

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

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

In base alla mappa della struttura delle chiavi, questa chiave deve decodificare 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.

Codificare le dimensioni utilizzando una funzione hash

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

L'operazione funziona nel seguente modo:

1. Seleziona un algoritmo di hashing.
2. Al momento della pubblicazione degli annunci, genera una stringa che includa tutte le dimensioni da monitorare e i relativi valori. Per generare la parte chiave sul lato sorgente, esegui l'hashing di questa stringa e valuta la possibilità di aggiungere un suffisso di zeri a 64 bit per allinearla con la parte chiave lato trigger e rendere più semplice il ragionamento di XOR.
   • Pezzo di chiave lato sorgente
     = <hash esadecimale a 64 bit("COUNT, campaignID=12, geoID=7"))><64-bit 00000000...>
   • Tieni presente che COUNT codifica la stessa cosa di MeasurementGoalType=0 nell'approccio della mappa con 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 una chiave lato trigger, esegui l'hashing di questa stringa e aggiungi un prefisso di zeri a 64 bit:
   • Parte chiave lato trigger = <00000000...> Hash esadecimale a 64 bit("productCategory=25")>
4. Il browser XOR esegue questi elementi chiave per generare una chiave.
   • Chiave di aggregazione a 128 bit
     = <hash della parte di chiave lato sorgente esadecimale a 64 bit><Hash della parte di chiave lato sorgente esadecimale a 64 bit>
5. In seguito, quando vuoi richiedere un report di riepilogo per questa chiave, generala all'istante:
   • In base alle dimensioni che ti interessano, genera un elemento chiave lato origine e lato attivatore come hai fatto in precedenza.
     • Pezzo di chiave lato sorgente
       = <hash esadecimale a 64 bit("COUNT, campaignID=12, geoID=7"))><64-bit 00000000...>
     • Elemento chiave lato trigger
       = <00000000...><64-bit hex hash("productCategory=25")>
     • pezzo chiave lato trigger = toHex(hash("productCategory=25"))
   • Proprio come il browser, XOR questi elementi chiave generano la stessa chiave che il browser ha generato in precedenza.
     • Chiave di aggregazione a 128 bit
       = <hash della parte di chiave lato sorgente a 64 bit>< Hash della parte di chiave lato sorgente a 64 bit>

Di seguito sono riportati alcuni suggerimenti pratici se utilizzi questo approccio basato su hash:

• Utilizza sempre lo stesso ordine delle dimensioni. In questo modo, gli hash possono essere rigenerati in modo affidabile. ("CONTA.NUMERI, IDCampagna=12, ID GeoID=7" non genererà lo stesso hash di "CONTA.NUMERI, IDID=7, IDCampagna=12"). Un modo semplice per raggiungere questo obiettivo è ordinare le dimensioni in modo alfanumerico. Questo è ciò che faremo nell'esempio, tranne per il fatto che COUNT o VALORE saranno sempre impostati come primo elemento della dimensione; si tratta di una scelta di leggibilità, poiché COUNT o VALORE codificano informazioni concettualmente diverse rispetto a tutte le altre dimensioni.
• Tieni traccia dell'insieme di dimensioni che utilizzi nelle chiavi. Vuoi evitare di generare chiavi basate su un insieme di dimensioni che non hai mai usato.
• I conflitti di hash sono rari se si utilizza una funzione hash adatta, ma il controllo con gli hash utilizzati in precedenza (che dovrebbero essere archiviati per interpretare i risultati del servizio di aggregazione) può evitare di introdurre nuove chiavi che entrano in conflitto con chiavi meno recenti.

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

Valori aggregati nella pratica

La società di tecnologia pubblicitaria imposta valori aggregabili quando un utente effettua una conversione.

Per proteggere la privacy degli utenti, i contributi di ogni utente hanno un limite massimo. In tutti i valori aggregabili associati a un'unica fonte (clic o visualizzazione sull'annuncio), nessun valore può essere superiore a un determinato limite di contribuzione.

Ci riferiremo a questo limite come CONTRIBUTION_BUDGET. Nel spiegatore, questo limite è chiamato budget L1, ma è uguale al CONTRIBUTION_BUDGET.

Per un'analisi approfondita del budget per i contributi, consulta l'articolo Budget per il contributo per i report di riepilogo.

Esempio: una conversione per clic o visualizzazione

Per questo esempio, supponiamo che tu stia cercando di rispondere alle seguenti domande:

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

Supponiamo anche che per il tuo caso d'uso siano necessari insight settimanali.

Devi monitorare anche quanto segue:

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

Che cosa misurare

Anche se molte aziende di ad tech incoraggiano gli inserzionisti a configurare vari tipi di conversione, concentrarsi sulle conversioni più importanti, come gli acquisti, è un buon modo per garantire che i risultati aggregati siano dettagliati e accurati per questi importanti eventi di conversione. Infatti, più metriche misuri, minore è il budget per il contributo per metrica e, di conseguenza, più rumoroso è probabile che ogni valore sia. 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.

Potrai comunque misurare sia il numero degli acquisti sia il valore degli acquisti e accedere a una serie di importanti statistiche aggregate, come il valore totale degli acquisti e le suddivisioni geografiche. Ciò garantisce che il rumore sia ragionevole e garantisce un semplice approccio alla scalabilità per il budget per i contributi.

E le valute?

La pubblicazione di campagne in regioni diverse implica che le valute debbano essere prese in considerazione. Cosa puoi fare:

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

In questo esempio, supponiamo che tu possa dedurre la valuta da un ID campagna. Ciò ti consente di convertire qualsiasi valore di acquisto specifico dalla valuta locale dell'utente a una valuta di riferimento a tua scelta. Puoi anche eseguire la conversione in tempo reale, 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.

Trasforma gli obiettivi in chiavi

Con gli obiettivi e le metriche di misurazione, hai a disposizione una serie di opzioni per la tua strategia chiave. Analizziamo due di queste strategie:

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

Strategia A: un albero profondo (una struttura chiave granulare)

Nella strategia A utilizzi un'unica struttura chiave granulare, che include tutte le dimensioni necessarie:

Tutte le chiavi utilizzano questa struttura.

Questa struttura chiave può essere suddivisa in due tipi di chiavi per supportare due obiettivi di misurazione.

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

I report di riepilogo hanno il seguente aspetto:

Puoi pensare alla strategia A come a una strategia basata su un singolo albero:

• Ogni valore di riepilogo nei report di riepilogo è associato a tutte le dimensioni che stai monitorando.
• Puoi aggregare questi valori di riepilogo insieme a ciascuna di queste dimensioni, in modo che possano raggiungere la stessa profondità delle dimensioni.

Con la strategia A, dovresti rispondere alle domande come segue:

Domanda	Risposta
Quali sono le categorie di prodotti più redditizie in ogni regione?	Somma i conteggi e i valori degli acquisti di riepilogo nei report di riepilogo per tutte le campagne. Questi dati ti forniscono il numero di acquisti e il valore per ID geografico x categoria di prodotto. Per ogni regione, confronta il valore e il numero di acquisto delle diverse categorie di prodotti.
Quali sono le strategie di campagna più efficaci in ogni regione?	Somma i conteggi e i valori degli acquisti di riepilogo nei report di riepilogo per tutte le categorie di prodotto. Si tratta del numero e del valore degli acquisti per ID campagna x ID geografico. Per ogni regione, confronta il valore di acquisto e conteggia le diverse campagne.

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

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

Anche se i valori di riepilogo saranno "rumorosi", puoi determinare quando le differenze nel valore misurato tra ogni campagna non sono dovute solo al rumore. Scopri come farlo nella pagina Comprendere il rumore.

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

Nella strategia B utilizzi due strutture chiave approssimative, ciascuna con un sottoinsieme delle dimensioni necessarie:

Dividi ognuna di queste strutture chiave in due tipi di chiave per supportare due obiettivi 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.

Otterrai 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 chiave II, conteggio acquisti.
• Tipo di chiave II-1: struttura chiave II, valore di acquisto.

I report di riepilogo hanno il seguente aspetto:

La strategia B può essere considerata come una strategia basata sui "due alberi poco profondi":

• I valori di riepilogo nei report di riepilogo sono mappati a uno dei due piccoli insiemi di dimensioni.
• Puoi aggregare questi valori di riepilogo insieme a ciascuna delle dimensioni in questi insiemi, ciò significa che questi dati di aggregazione non sono così dettagliati come nell'opzione A, poiché esistono meno dimensioni in base a cui eseguire l'aggregazione.

Con la strategia B, dovresti rispondere alle domande come segue:

Domanda	Risposta
Quali sono le categorie di prodotti più redditizie in ogni regione?	Accedere direttamente al riepilogo dei conteggi e dei valori degli acquisti presenti nei report di riepilogo.
Quali sono le strategie di campagna più efficaci in ogni regione?	Accedere direttamente al riepilogo dei conteggi e dei valori degli acquisti presenti nei report di riepilogo.

Decisione: strategia A

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

Tuttavia, con la strategia A, devi sommare i valori di riepilogo che ricevi nei report di riepilogo per rispondere ad alcune delle tue domande. Ciascuno di questi valori di riepilogo è rumoroso. Sommando questi dati, sembra anche il rumore.

Questo non avviene con la strategia B, in cui i valori di riepilogo esposti nei report di riepilogo forniscono già le informazioni necessarie. Ciò significa che probabilmente la strategia B otterrà un impatto minore dal rumore rispetto alla strategia A.

Come dovresti stabilire quale strategia utilizzare? Per le campagne o gli inserzionisti esistenti, puoi utilizzare i 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, l'utente può decidere di:

• Raccogliete un mese di dati con le chiavi granulari (Strategia A). Poiché stai estendendo la durata della raccolta dei dati, i valori di riepilogo saranno più elevati e il rumore sarà relativamente più basso.
• Valuta con ragionevole precisione il conteggio delle conversioni settimanali e il valore di acquisto.

Nota: non fare affidamento sui conteggi dei report o sui dati disponibili solo tramite i report di debug come fonte attendibile nei tuoi progetti. In futuro, i dati disponibili nei report di debug cambieranno e i report sui rumori verranno generati insieme a report reali, quindi questi indicatori dovrebbero essere utilizzati solo per convalidare l'implementazione e la strategia di test.

In questo esempio, supponiamo che il numero di 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 porta a un impatto del rumore che non influisce sulla tua capacità di prendere decisioni, scegli la strategia A.

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 che supporti questo approccio.

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

Nel browser: imposta chiavi e valori

Ora che hai deciso una struttura di chiavi e un algoritmo di hashing, sei pronto a registrare le chiavi e i valori quando gli utenti fanno clic sugli annunci o li visualizzano e poi effettuano una conversione.

La prossima è una panoramica delle intestazioni che imposterai per registrare chiavi e valori nel browser:

Impostare le parti principali sul lato sorgente

Quando un utente fa clic o visualizza un annuncio, imposta le chiavi di aggregazione nell'intestazione Attribution-Reporting-Register-Aggregatable-Source. In questa fase, per ogni chiave puoi impostare solo la parte della chiave, o parte chiave, nota al momento della pubblicazione degli annunci.

Generiamo gli elementi chiave:

Elemento chiave lato origine per l'ID chiave...	Stringa contenente i valori delle dimensioni da impostare	Hash di questa stringa come esadecimale, tagliato ai primi 64 bit (64/4 = 16 caratteri^1)	Hash esadecimale con zeri aggiunti per semplificare l'operazione XOR. Questa è la parte chiave lato sorgente.
key_purchaseCount	CONTA.NUMERI, ID campagna=12, ID geografico=7	0x3cf867903fbb73ec	0x3cf867903fbb73ec0000000000000000
key_purchaseValue	VALORE, ID campagna=12, ID geografico=7	0x245265f432f16e73	0x245265f432f16e730000000000000000

¹Ogni cifra esadecimale rappresenta quattro bit (cifre binarie).

Esaminiamo 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 quando si impostano le chiavi nel browser, in modo che i pezzi chiave lato origine e lato trigger 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 fonte, i dati a livello di evento (ID evento di origine e dati trigger) e la chiave di aggregazione possano essere abbinati.

Puoi utilizzare entrambi i report se, ad esempio, prevedi di utilizzare 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 all'ad tech server. Alla ricezione di questa richiesta:

• Per completare la chiave, imposta le parti principali sul lato conversione (lato attivatore). Imposterai queste parti chiave tramite l'intestazione Attribution-Reporting-Register-Aggregatable-Trigger-Data.
• Imposta il valore aggregabile per questa conversione tramite l'intestazione Attribution-Reporting-Register-Aggregatable-Values.

Imposta i pezzi chiave lato trigger per completare la chiave

Generiamo gli elementi chiave:

Elemento chiave lato trigger per l'ID chiave...	Stringa contenente i valori delle dimensioni da impostare	Hash di questa stringa come esadecimale, tagliato ai primi 64 bit (64/4 = 16 caratteri^1)	Hash esadecimale con zeri aggiunti per simplify l'operazione XOR. Questa è la parte chiave del lato sorgente.
key_purchaseCount	ProductCategory=25	0x1c7ce88c4904bbe2	0x0000000000000000f9e491fe37e55a0c
key_purchaseValue	(uguale)	(uguale)	(uguale)

¹Ogni cifra esadecimale rappresenta quattro bit (cifre binarie).

Esaminiamo 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 stai aggiungendo la stessa parte a più chiavi, elencando diversi ID chiave in source_keys: la parte chiave verrà aggiunta a entrambe le chiavi.

Valori aggregabili

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

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

Non imposterai questi valori aggregabili direttamente:

• 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 per il contributo, quindi potresti decidere di dividerlo in due.

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

Supponiamo che il valore di acquisto massimo per un singolo utente, basato sulla cronologia acquisti di tutti gli utenti del sito, sia di 1500 €. Potrebbero esserci delle anomalie, ad esempio un numero molto ridotto di utenti che hanno speso più di tale somma, ma potresti decidere di ignorarle.

Il fattore di scala per il valore di acquisto dovrebbe 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 di origine).

Ora puoi impostare questi valori:

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

In pratica, imposteresti come segue, utilizzando l'intestazione dedicata Attribution-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,
    }
))

Il report aggregabile viene generato

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

Di seguito è riportato un esempio dei dati che potrebbero essere trovati all'interno del payload del report aggregabile, se fosse leggibile in testo in chiaro:

[ {
  key: 0x3cf867903fbb73ecf9e491fe37e55a0c, // = source-side key piece XOR 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 XOR 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 separati in un unico report aggregabile.

Richiedere un report di riepilogo

• Report aggregabili in blocco. Segui i consigli offerti in Batch.
• Genera le chiavi di cui vuoi visualizzare i dati. Ad esempio, per visualizzare i dati di riepilogo per COUNT (numero totale di acquisti) e VALORE (valore di acquisto totale) per ID campagna 12 x ID area geografica 7 x Categoria di prodotto 25:
  • Genera la parte della chiave lato sorgente, come hai fatto durante l'impostazione nel browser.
  • Genera la chiave lato trigger, come hai fatto durante l'impostazione nel browser.

Metrica che vuoi richiedere^1	Elemento chiave lato origine	Elemento chiave sul lato del grilletto	Chiave da richiedere al servizio di aggregazione^2
Numero totale di acquisti (COUNT)	0x3cf867903fbb73ec 0000000000000000	0x00000000000000 00f9e491fe37e55a0c	0x3cf867903fbb73 ecf9e491fe37e55a0c
Valore totale di acquisto (VALUE)	0x245265f432f16e73 0000000000000000	0x0000000000000000 f9e491fe37e55a0c	0x245265f432f16e73 f9e491fe37e55a0c

¹ Metrica che vuoi richiedere (per ID campagna 12 x ID area geografica 7 x Categoria di prodotto 25). ² Chiave da richiedere al servizio di aggregazione = parte di chiave lato trigger XOR parte di chiave lato trigger.

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

Gestire il report di riepilogo

In ultima analisi, si ottiene 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 formato binario. Il secondo bucket è la chiave VALUE nel programma binario. Tieni presente che, sebbene le chiavi siano eterogenee (COUNT o VALORE), vengono contenute nello stesso report.

Nota: in pratica, i report di riepilogo sono codificati in modo da rendere i bucket e i valori diversi da quanto hai appena visto (ossia, un bucket potrebbe avere il seguente aspetto: \u0000\u0000\x80\u0000). Bucket e valore sono entrambi bytestring. Un esempio è disponibile qui.

Riduci i valori

• 2.558.500 fa riferimento al numero di acquisti per questa chiave, aumentato in base al fattore di scalabilità calcolato in precedenza. Il fattore di scalabilità per il conteggio degli acquisti era pari a 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 = 31.230 € di valore di acquisto totale.

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

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

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