Pixel Meta: come valutare la qualità degli eventi

Perché parliamo di Pixel Meta? (più o meno)

Il codice di installazione del Pixel Meta odierno è uno snippet di codice JavaScript che una volta posizionato sulla pagina del nostro sito scarica la libreria di Meta ed inoltra a quest’ultima le informazioni che abbiamo deciso di condividere.

Se recuperiamo però lo script di installazione della libreria del Pixel dalla documentazione per sviluppatori, possiamo notare che il codice da inserire sulla pagina è composto da due parti:

• Uno Script.
• Un tag <noscript>.

La seconda parte del codice di installazione contiene un tag <img>, che posiziona sullo schermo un’immagine di 1 pixel.

Questa seconda parte del codice di tracciamento del Pixel Meta viene ad oggi utilizzata per gestire i problemi di tracciamento causati dai browser che non supportano JavaScript. In questo caso però per noi è anche un ottimo strumento didattico che ci aiuta a comprendere il funzionamento di un basilare sistema di tracciamento.

Vediamolo insieme.

Quando un utente visita il nostro sito, il browser scarica tutti i contenuti presenti sulla pagina per poterli visualizzare. Poiché il browser deve scaricare tutto, includerà anche l’immagine presente all’interno del tag <noscript> di Meta.

I server di Meta riceveranno quindi una richiesta di download dell’immagine (sanno che un utente sta scaricando un’immagine che per noi rappresenta un evento importante). Questa richiesta può essere arricchita con l’uso di parametri GET. Nel caso specifico del Pixel Meta, ad esempio, vengono aggiunti parametri come l’ID del pixel, il nome dell’evento (ev) e altri.

Questo sistema di tracciamento permette di monitorare le azioni che l’utente compie sul nostro sito, senza l’utilizzo di sistemi complessi. Ad oggi, questo tipo di sistemi tuttavia non è abbastanza performante al fine di far fronte ai problemi che dobbiamo affrontare ogni giorno.

Tuttavia, questo è solo l’inizio del viaggio che ci consentirà innanzitutto di comprendere l’importanza dettata dalla qualità del dato e, successivamente, come possiamo valutare questa qualità per gli eventi ricevuto dal Pixel Meta.

Dal Pixel al Dataset

Compreso perché la maggior parte dei sistemi di tracciamento delle piattaforme vengono comunemente chiamati “Pixel”, possiamo fare un passo avanti per porre l’accento su di un cambiamento che Meta sta portando avanti da un po’ di tempo.

Ricordo ancora quando nel menù delle impostazioni è stata aggiunta la sezione dedicata ai Dataset e molti dei Pixel già creati non erano più visibili sotto la sezione “Pixel” ma sotto la sezione “Dataset”.

Questo leggerissimo cambiamento seppure possa sembrare banale è in realtà di vitale importanza poiché ci aiuta a comprendere su cosa Meta ci sta chiedendo di porre attenzione.

Da documentazione, l’azienda definisce i Dataset in questo modo:

I Dataset consentono di collegare e gestire in un unico luogo i dati sugli eventi provenienti da fonti diverse, come il tuo sito web, la tua app mobile, il tuo punto vendita fisico o le chat business.

Come possiamo intuire da questo semplice passaggio, il concetto di Dataset è molto più esteso rispetto a quello di Pixel. Meta non è semplicemente interessata a raccogliere i dati di navigazione degli utenti sul nostro sito, vuole seguirli in tutto il ciclo di vita in modo da comprenderli al meglio e poter determinare con estrema precisione se una data conversione è da imputare al loro sistema pubblicitario.

I Dataset raccolgono le azioni dei clienti su tutti gli endpoint e queste azioni vengono o meglio, dovrebbero essere arricchite con quante più informazioni possibili che consentano alla piattaforma di identificare l’utente.

In un panorama così complesso, la qualità del dato acquisisce sempre maggiore rilevanza ed è per questo che voglio insegnarti a fare una valutazione di massima della qualità dei tuoi eventi Meta.

Verificare il numero di eventi

La primissima cosa da valutare, direi, è proprio la ricezione degli eventi al nostro Dataset. Se gli eventi non arrivano o arrivano in modo scostante chiaramente non ha senso procedere oltre con la nostra valutazione.

Il tema del “numero di eventi” è molto delicato è va trattato a dovere, ma lo strumento di riferimento, in questo caso (ma come per tutte le analisi) è proprio Events Manager. Si tratta di un Tool di Meta attraverso il quale possiamo monitorare i nostri Dataset comprendendo cosa arriva e in che qualità/quantità.

Sulla sinistra possiamo selezionare il Pixel di cui vogliamo leggere i dati e naturalmente possiamo spostarci da un BM all’altro. Sulla destra, invece, possiamo leggere i dati del Pixel selezionato.

La prima cosa da valutare è sicuramente la trendline che vediamo al centro della pagina. Se quest’ultima si muove pesantemente in modo negativo (e soprattutto in modo ingiustificato) possiamo già intuire che qualcosa non va.

Attenzione che i periodi vuoti non vengono riempiti.

Ad esempio, si può notare come nel grafico dello screenshot sopra si passi dal 26 Agosto al 5 Settembre: si nota chiaramente che dopo il 5 non ci sono altri eventi ricevuti dal Pixel Meta.

Sulla parte centrale, in basso, è possibile osservare quali eventi sono stati ricevuti dal Dataset nel periodo di tempo selezionato e in che quantità. Cliccando su di un singolo evento siamo in grado di osservare meglio come l’evento si è mosso nel corso del tempo selezionato.

In questo secondo caso si nota chiaramente che, a un certo punto, il Dataset ha smesso di funzionare. Anche il Pixel ci segnala che l’evento non sta ricevendo nuovi dati da un po’ di tempo.

A destra possiamo osservare il numero totale di eventi ricevuti dal Dataset per l’evento selezionato. Tuttavia, per essere più precisi, quel numero rappresenta il totale degli eventi provenienti da browser, server e fonti offline, per il periodo di tempo selezionato.

In pratica, questo significa che, quando valutiamo il numero totale di eventi ricevuti, dobbiamo fare alcune considerazioni. Non possiamo considerare quel numero come “il totale” degli eventi ricevuti per diversi motivi.

Motivo 1: in caso di eventi provenienti sia dal browser che dal server con deduplicazione, entrambi gli eventi verrebbero conteggiati, ma, come sappiamo, sono in realtà duplicati.

Quando implementiamo le CAPI in modo corretto, infatti, Meta consiglia di inviare lo stesso evento sia lato browser che lato server, utilizzando specifici parametri che permettono di scartare uno degli eventi durante l’analisi.

Motivo 2: se gli eventi offline vengono inoltrati al Dataset, anche questi andrebbero considerati nel conteggio.

Quindi, come possiamo valutare il numero di eventi in caso di CAPI attive?
Il metodo più immediato è quello di considerare circa la metà degli eventi (senza contare le offline naturalmente), eliminando i duplicati.

Non è un metodo preciso! Tuttavia, in questa fase, quello che ci interessa è avere una stima del numero di eventi totali ricevuti.

Ed una volta che abbiamo un numero di eventi?
Beh, a questo punto, abbiamo bisogno di uno strumento di controllo con cui confrontare il numero che abbiamo ottenuto (almeno nell’ordine di grandezza).

Possiamo anche utilizzare GA4 che avendo un modello ad eventi dovrebbe avere un numero simile di eventi ricevuti. Quindi procediamo a confrontare l’evento ricevuto dal Pixel Meta con il numero di eventi ricevuto da GA4. Se il tracciamento funziona correttamente, questi numeri dovrebbero essere perlomeno dello stesso ordine di grandezza.

Chiaramente questo primo controllo non è “scientifico”, ma a colpo d’occhio ci consente di capire se un evento ha smesso di funzionare e di avere un termine di confronto tramite l’utilizzo di un’altra piattaforma.

Ah, considera sempre che quel numero rappresenta il “numero totale di eventi ricevuti” e non gli eventi effettivamente attribuiti alle nostre campagne. Il Pixel riceve infatti tutti gli eventi. Successivamente, Meta stessa deciderà quanti e quali di questi eventi attribuire alle campagne.

Verificare la qualità delle CAPI

A questo punto, dovremmo avere una chiara idea del numero di eventi ricevuti dal Pixel e, confrontandoli con uno strumento di terze parti, possiamo determinare se il Pixel si attiva correttamente oppure no.

Un altro aspetto da considerare è la qualità della configurazione delle CAPI (Conversion API). Il primo passo consiste nel verificare se le CAPI sono attive per tutti gli eventi. Questo aspetto è facilmente verificabile.

Osserva lo screenshot qui sotto.

In Event Manager, sotto la colonna “Integrazioni”, possiamo vedere come gli eventi ricevuti sono stati inoltrati. Nel caso in cui l’inoltro avvenga tramite un solo canale (ad esempio, solo browser), verrà riportata la relativa dicitura.

Nello screenshot mostrato, ad esempio, l’evento personalizzato “View Item” viene inoltrato esclusivamente lato browser e non viene inviato anche lato server.

Se, invece, osserviamo altri eventi, come ad esempio “Pageview”, possiamo notare la dicitura “Più metodi” sotto la colonna “Integrazioni”. Questo indica, con un’alta probabilità (circa 90%), che le CAPI sono abilitate per quegli eventi.

Naturalmente, potrebbero esserci anche eventi inviati esclusivamente tramite server. In tal caso, vedremo un’ulteriore dicitura sull’evento.

Grazie a questo sistema, possiamo identificare a colpo d’occhio per quali eventi le CAPI sono abilitate e per quali no.
Ora, è il momento di valutare la corretta implementazione delle CAPI.

Senza dilungarci troppo, per valutare la corretta implementazione delle CAPI dobbiamo tenere conto di due parametri:

• La copertura.
• La deduplicazione.

Valutare la copertura degli eventi nelle CAPI

Per quanto riguarda la copertura, si tratta di una nuova tab aggiunta di recente da Meta. Per comprenderla è necessario fare una piccola premessa.

Nell’implementazione delle CAPI Meta consiglia sempre di inoltrare i nostri eventi sia lato browser che lato server.

In termini di performance, questo significa raddoppiare i punti di inoltro e di conseguenza raddoppiare la possibilità di ricevere i nostri eventi. Questo significa che, in un setting perfettamente funzionante, dovremmo trovarci con un numero uguale o di poco differente di eventi inviati lato server ed eventi inviati lato browser.

Può però succedere che gli eventi inviati lato browser possano essere inferiori agli eventi lato server. Se questo è il tuo caso, non preoccuparti è assolutamente normale. Quando chiediamo al browser dell’utente di effettuare l’inoltro degli eventi a Meta entrano in gioco tante variabili che non sono sotto il nostro controllo e che possono portare ad un mancato inoltro.

È qui che entrano in gioco gli eventi lato server che, in un implementazione raddoppiata, coprono gli eventi che lato browser non riusciamo ad inviare.

Il problema potrebbe sorgere nel momento in cui gli eventi inoltrati lato browser superano gli eventi ricevuti lato server. La nuova tab sulla copertura degli eventi ci aiuta a comprendere a colpo d’occhio tale problematica, segnalandoci un errore nel momento in cui gli eventi lato browser dovessero superare gli eventi lato server.

Un numero di eventi lato browser superiore a quelli lato server potrebbe indicare:

• Tracciamento lato browser raddoppiato (magari è presente un tag su GTM e del codice sulla pagina).
• Eventi impostati tramite lo strumento di configurazione degli eventi.
• Problemi nell’implementazione delle CAPI (parametri non compilati correttamente che causano un messaggio di errore).

Questi sono i problemi che in genere riscontriamo con il team tracking negli account che hanno un numero di eventi lato browser superiore a quelli lato server.

Valutare la deduplicazione degli eventi

Un altro aspetto da considerare per determinare la qualità dei nostri eventi Meta è la percentuale di deduplicazione degli eventi. Come accennato in precedenza, Meta raccomanda di inviare gli eventi sia lato browser che lato server.

Questo significa che, per ogni evento, vengono effettivamente inviati due segnali: uno dal server e uno dal browser. Tuttavia, ciò non implica che entrambi gli eventi vengano memorizzati. Meta, infatti, elimina uno dei due quando riconosce che si tratta di un duplicato.

Questo processo di eliminazione degli eventi duplicati è chiamato deduplicazione, ed è fondamentale che venga configurato correttamente. Se la deduplicazione non dovesse funzionare, ci potremmo trovare con eventi duplicati, il che potrebbe compromettere l’accuratezza dei dati.

La deduplicazione avviene grazie all’aggiunta di specifici ID agli eventi. In sintesi, quando inviamo un evento sia dal lato browser che dal lato server, assegniamo una serie di ID all’evento, che saranno poi utilizzati da Meta per eseguire la deduplicazione.

Il corretto invio di questi parametri può essere verificato nella scheda “Deduplicazione degli eventi”, visibile nello screenshot qui sotto.

Per ogni evento, è possibile osservare il numero di ID evento, ID Esterno e FBP ricevuti, espressi in percentuale, e la loro sovrapposizione. Inoltre, già da questa scheda, l’Event Manager segnala eventuali problemi legati alla deduplicazione.

Se non stiamo inviando un numero sufficiente di ID o se la sovrapposizione tra questi non è adeguata, potremmo riscontrare problemi di deduplicazione, che potrebbero portare a un disallineamento nelle performance riportate dalle nostre campagne.

Valutare la qualità dell’associazione degli eventi

Un ultimo aspetto da considerare è la qualità dell’associazione degli eventi. Mi riferisco ai punteggi numerici che puoi vedere in Events Manager accanto ad alcuni dei tuoi eventi.

Osserva lo screenshot qui sotto.

Come puoi notare, a ogni evento è associato un punteggio che va da 0 a 10, visibile nella colonna “Qualità dell’associazione degli eventi”. Naturalmente, più alto è il punteggio, meglio è.

Ma cosa rappresentano esattamente questi punteggi? Come possiamo valutarli? E, soprattutto, come possiamo migliorarli?
Per rispondere a queste domande, dobbiamo innanzitutto aprire uno dei nostri eventi e navigare verso la sezione “Qualità degli eventi”.

Qui dovresti trovare qualcosa del genere:

Nella sezione centrale, “Parametri condivisi”, possiamo verificare quanti parametri utente sono stati associati ai nostri eventi. Ad esempio, per l’evento selezionato, vengono trasmesse informazioni come l’indirizzo IP, lo user agent e, occasionalmente, anche il numero di telefono.

Come avrai intuito, quindi, il punteggio di qualità dell’associazione degli eventi è influenzato dalla quantità di informazioni utente che inviamo insieme agli eventi. Più dettagli inviamo, più alto sarà il punteggio. Tuttavia, non è sempre possibile inviare dati utente completi per ogni evento. È naturale che, per alcuni eventi, non si disponga di tutte le informazioni utente, ma dove possibile, è consigliabile inviarne il maggior numero possibile per aumentare il punteggio.

Va però sottolineato che il punteggio non si basa esclusivamente sulla quantità di dati utente inviati. Come spiegato nella documentazione di Meta, la qualità dell’associazione degli eventi dipende anche dal matching che Meta riesce a fare tra i dati utente inviati e le informazioni già in suo possesso.

In pratica, quel punteggio è influenzato dalla capacità di Meta di riconoscere l’utente coinvolto nell’evento grazie ai dati che abbiamo inviato. Questo significa che, anche se inviamo molti dati utente, potremmo ottenere un punteggio basso se Meta non riesce a identificare l’utente in modo efficace.

Quando valutiamo quindi i punteggi di qualità, dobbiamo fare attenzione non solo alla quantità di dati inviati, ma anche alla loro correttezza e conformità con le linee guida di Meta. Un controllo accurato delle informazioni inviate e della loro formattazione può aiutarci a migliorare il matching e, di conseguenza, il punteggio.

Conclusioni

Ok, siamo arrivati alla fine del post ed è anche arrivato il momento di tirare le somme.

Comprendo bene che in alcuni punti sono sceso un po’ nel tecnico, tuttavia quelle indicate solo le cose che assolutamente dovresti guardare al fine di valutare il tuo setting di Meta.

Naturalmente un Audit approfondito richiederebbe anche ulteriori considerazioni, tuttavia, se hai qualche dubbio sulla qualità del tuo tracciamento Meta, osservare già questi aspetti ti garantirà di comprendere meglio come sta funzionando il setting.

Grazie infinite per essere arrivati fin qui e ci vediamo nel prossimo post.

PS: se non lo hai già fatto, ricordati di iscriverti alla newsletter Loop per non perderti i prossimi post!