Quando si lavora con Meta Ads, uno dei problemi più frustranti è scoprire che gli eventi vengono effettivamente ricevuti da Meta, ma la loro qualità dell’associazione è bassa.

È esattamente quello che mi è successo durante un’attività di verifica del tracking Meta implementato tramite Google Tag Manager e Facebook Pixel by Stape.

Gli eventi erano presenti, le conversioni arrivavano, apparentemente il tracking funzionava. Eppure, entrando in Gestione eventi, Meta mostrava diversi eventi con un punteggio di qualità dell’associazione intorno a 6 o 6,5.

Tra gli eventi coinvolti c’erano:

• PageView
• ViewContent
• ViewPromotion
• AddToCart
• InitiateCheckout
• Purchase

A prima vista può sembrare il classico caso del “tracking rotto”.

In realtà il problema era molto più sfumato.

Cos’è la qualità dell’associazione degli eventi Meta

Meta utilizza diversi dati per cercare di collegare un evento registrato sul sito a una persona o, più precisamente, a un browser o utente già conosciuto dalla piattaforma.

Tra questi dati possiamo trovare, quando disponibili:

• email;
• numero di telefono;
• external ID;
• indirizzo IP;
• user agent;
• Browser ID (fbp);
• Click ID (fbc).

Più informazioni affidabili vengono ricevute, maggiore può essere la capacità di Meta di associare l’evento a un utente e attribuire correttamente una conversione alle campagne pubblicitarie.

Questo però porta a una prima considerazione importante:

un Event Match Quality non altissimo non significa automaticamente che il tracking sia sbagliato.

Un evento PageView, ad esempio, viene normalmente generato quando non conosciamo ancora praticamente nulla dell’utente.

Al momento del Purchase, invece, potremmo avere a disposizione molti più dati.

Non ha quindi molto senso aspettarsi lo stesso livello di associazione da tutti gli eventi del funnel.

Il parametro che Meta segnalava: fbc

Analizzando il dettaglio degli eventi ho notato che Meta indicava spesso il parametro:

ID clic (fbc)

come parametro condiviso, ma con una copertura non particolarmente elevata.

Ed è qui che è iniziata l’analisi vera.

Il parametro fbc è collegato ai clic provenienti dalle inserzioni Meta.

Quando un utente clicca su una pubblicità Facebook o Instagram, Meta può aggiungere all’URL un parametro simile a questo:

?fbclid=IwARxxxxxxxxxxxxxxxx

Il Pixel Meta utilizza questo valore per generare un identificatore memorizzato normalmente nel cookie:

_fbc

Il valore assume una forma simile a:

fb.1.1756812345678.IwARxxxxxxxxxxxxxxxx

Questo identificatore permette a Meta di capire che gli eventi successivi di quell’utente possono essere collegati a uno specifico clic pubblicitario.

Il flusso, semplificato, è quindi:

Click sull'annuncio Meta

↓ 

Landing page con fbclid

↓

creazione di _fbc

↓

ViewContent

↓

AddToCart

↓

InitiateCheckout

↓

Purchase

Se _fbc viene mantenuto lungo tutto il percorso, Meta dispone di un segnale in più per attribuire correttamente gli eventi.

Un errore da evitare: aspettarsi fbc nel 100% degli eventi

Questa è probabilmente una delle cose più importanti che ho chiarito durante l’analisi.

Il parametro fbc non deve essere presente nel 100% degli eventi.

Se un utente arriva:

• da Google;
• dalla ricerca organica;
• digitando direttamente il dominio;
• da una newsletter;
• da un referral;
• da una sorgente diversa da Meta Ads;

non esiste necessariamente alcun fbclid.

Di conseguenza è assolutamente normale che Meta non riceva fbc.

La domanda corretta quindi non è:

“Perché fbc non è presente in tutti gli eventi?”

ma:

“Quando l’utente arriva da una campagna Meta con fbclid, riusciamo a mantenere correttamente fbc fino alla conversione?”

È una differenza apparentemente sottile, ma cambia completamente il modo di affrontare il debugging.

Facebook Pixel by Stape e copertura di fbc

Nel mio caso il Pixel Meta era implementato tramite il template Facebook Pixel by Stape per Google Tag Manager.

Prima di creare soluzioni personalizzate ho quindi controllato direttamente la configurazione del template.

Nelle impostazioni avanzate del tag Stape è disponibile l’opzione:

Increase Browser ID and Click ID Cookies Coverage

Questa funzione è particolarmente interessante perché aiuta nella gestione dei due identificativi:

_fbp
_fbc

Prima di iniziare a creare script JavaScript personalizzati per generare manualmente fbc, conviene quindi:

1. verificare di utilizzare una versione aggiornata del template Stape;
2. controllare che questa impostazione sia attiva;
3. testare il comportamento reale del Pixel.

Come ho testato fbc

Il test è abbastanza semplice.

Ho aperto una pagina del sito aggiungendo manualmente un fbclid di test:

https://www.esempio.it/?fbclid=TEST123456789

Poi ho aperto gli strumenti per sviluppatori di Chrome:

DevTools
→ Application
→ Cookies

e ho verificato la presenza dei cookie:

_fbp
_fbc

Una volta creato _fbc, il test non era però terminato.

La cosa realmente importante era verificare cosa succedeva durante la navigazione:

Landing page
↓
Prodotto
↓
AddToCart
↓
Checkout
↓
Purchase

Se _fbc esiste inizialmente ma viene perso durante questo percorso, Meta potrebbe ricevere correttamente il Click ID sul primo evento ma non sugli eventi più importanti del funnel.

Attenzione ai redirect che eliminano fbclid

Un altro punto che vale la pena verificare riguarda i redirect.

Immaginiamo questo ingresso:

https://esempio.it/prodotto/?fbclid=ABC123

Il sito esegue un redirect:

https://www.esempio.it/prodotto/

Se durante il redirect la query string viene eliminata, fbclid può andare perso prima che il Pixel abbia avuto modo di utilizzarlo.

Lo stesso può succedere con:

• redirect HTTP → HTTPS;
• redirect www → non-www;
• redirect non-www → www;
• redirect linguistici;
• WPML;
• plugin di redirect;
• canonical redirect;
• JavaScript redirect;
• redirect verso una landing differente.

In un sito multilingua, ad esempio, bisogna evitare situazioni come:

/landing/?fbclid=ABC123

che diventano:

/it/landing/

perdendo completamente la query string.

Idealmente dovremmo ottenere:

/it/landing/?fbclid=ABC123

Il consenso può influire sulla copertura di fbc

Un’altra situazione particolarmente delicata riguarda la CMP e il consenso pubblicitario.

Supponiamo che l’utente arrivi da Facebook:

/landing/?fbclid=ABC123

Compare il cookie banner.

Il Pixel Meta non può ancora partire perché l’utente non ha espresso il consenso.

Nel frattempo l’utente naviga verso:

/prodotto/

A questo punto fbclid non è più presente nell’URL.

L’utente accetta il consenso.

Meta Pixel finalmente parte, ma il parametro originale che identificava il clic pubblicitario potrebbe ormai non essere più disponibile.

Potremmo quindi ritrovarci con:

_fbp presente
_fbc assente

Questo può spiegare almeno una parte della mancata copertura di fbc.

Naturalmente la soluzione non può essere quella di salvare indiscriminatamente identificatori pubblicitari prima del consenso.

Il comportamento deve sempre essere compatibile con la CMP utilizzata e con le decisioni privacy adottate dal sito.

Il punto è piuttosto comprendere quando il parametro viene perso.

Configurare correttamente AddToCart con Facebook Pixel by Stape

Durante la stessa analisi ho dovuto verificare anche un altro aspetto: l’evento AddToCart.

Non basta infatti comunicare a Meta:

AddToCart

È molto utile inviare anche i dati del prodotto aggiunto al carrello.

Se il sito utilizza già un dataLayer ecommerce compatibile con GA4, possiamo sfruttarlo anche per Meta.

Per esempio:

dataLayer.push({
  event: 'add_to_cart',
  ecommerce: {
    currency: 'EUR',
    value: 59.90,
    items: [{
      item_id: 'SKU123',
      item_name: 'Prodotto esempio',
      price: 59.90,
      quantity: 1
    }]
  }
});

Questa struttura contiene già praticamente tutte le informazioni necessarie.

Nel tag Facebook Pixel by Stape possiamo utilizzare l’evento proveniente dal dataLayer e sfruttare il mapping automatico dei parametri ecommerce.

Concettualmente Meta dovrebbe ricevere qualcosa di equivalente a:

fbq('track', 'AddToCart', {
  content_ids: ['SKU123'],
  content_type: 'product',
  contents: [{
    id: 'SKU123',
    quantity: 1,
    item_price: 59.90
  }],
  value: 59.90,
  currency: 'EUR'
});

I parametri più importanti sono:

content_ids

Contiene gli ID dei prodotti.

content_ids: ['SKU123']

Questi ID devono essere coerenti con quelli utilizzati nel catalogo Meta, soprattutto quando si utilizzano campagne dinamiche.

content_type

Per un normale ecommerce il valore più comune è:

product

contents

Permette di specificare maggiori informazioni sui prodotti.

Per esempio:

contents: [{
    id: 'SKU123',
    quantity: 1,
    item_price: 59.90
}]

value

Indica il valore economico dell’evento.

59.90

currency

Indica la valuta:

EUR

Meglio utilizzare il dataLayer esistente

Quando è possibile preferisco evitare di costruire un secondo sistema parallelo esclusivamente per Meta.

Se abbiamo già:

dataLayer ecommerce

utilizzato per:

GA4
Google Ads

possiamo utilizzare la stessa sorgente dati anche per:

Meta

Il risultato è un’architettura molto più semplice:

Sito ecommerce

↓

dataLayer

↓

Google Tag Manager

├── GA4
├── Google Ads
└── Meta Pixel

In questo modo esiste una sola fonte dei dati ecommerce.

Quando un prezzo, una quantità o un ID prodotto cambia, tutti i sistemi ricevono lo stesso dato.

Si riducono così enormemente gli errori dovuti a implementazioni separate.

Cosa controllare in Meta Events Manager

Dopo aver modificato il tracking è fondamentale non fermarsi al Debug Mode di Google Tag Manager.

GTM può dirci che il tag è partito.

Ma questo non significa necessariamente che Meta abbia ricevuto esattamente quello che ci aspettiamo.

Bisogna quindi verificare anche:

Meta Business Manager
→ Gestione eventi
→ Origine dati
→ Test degli eventi

Per ogni evento conviene controllare:

• nome dell’evento;
• URL;
• value;
• currency;
• content_ids;
• contents;
• fbp;
• fbc;
• eventuali dati utente disponibili.

Nel caso di AddToCart, in particolare, controllerei sempre che Meta riceva almeno:

content_ids
contents
value
currency

quando disponibili.

Event Match Quality: non inseguiamo semplicemente un numero

Questa esperienza mi ha ricordato una cosa importante.

Quando Meta mostra un punteggio come:

6
6.5
7

è molto facile cadere nella tentazione di trasformarlo in un KPI tecnico:

“Dobbiamo arrivare almeno a 8.”

Ma non sempre è un approccio corretto.

L’obiettivo dovrebbe essere piuttosto:

fornire a Meta tutti i segnali corretti che possiamo legittimamente e tecnicamente fornire.

Per esempio è ragionevole migliorare:

• la copertura di fbp;
• la copertura di fbc;
• i dati ecommerce;
• email e telefono quando vengono effettivamente raccolti;
• external ID quando disponibile;
• deduplicazione browser/server nel caso di Conversion API.

Molto meno sensato sarebbe raccogliere dati aggiuntivi soltanto per vedere aumentare il punteggio mostrato dall’interfaccia Meta.

Il punteggio dovrebbe essere una conseguenza di un buon tracking.

Non il contrario.

Checklist finale per migliorare il tracking Meta con GTM e Stape

Alla fine dell’analisi mi sono costruita questa checklist.

Facebook Pixel

Verificare:

PageView
ViewContent
ViewPromotion
AddToCart
InitiateCheckout
Purchase

Identificativi

Controllare quando disponibili:

_fbp
_fbc

Click Meta

Testare:

?fbclid=TEST

e verificare che venga creato:

_fbc

Navigazione

Controllare che _fbc rimanga presente durante:

landing
→ prodotto
→ carrello
→ checkout
→ purchase

Redirect

Verificare che non eliminino:

fbclid

CMP

Controllare cosa succede al parametro fbclid prima e dopo il consenso.

Stape

Verificare:

Increase Browser ID and Click ID Cookies Coverage

Ecommerce

Per AddToCart controllare almeno:

content_ids
contents
value
currency

DataLayer

Quando possibile utilizzare un unico dataLayer ecommerce per:

GA4
Google Ads
Meta

Meta Events Manager

Concludere sempre il test in:

Gestione eventi
→ Test degli eventi

per verificare ciò che Meta riceve realmente.

Conclusioni

Quando ho iniziato questa verifica, il problema sembrava semplicemente un basso punteggio di qualità dell’associazione degli eventi Meta.

In realtà dietro quel numero c’erano diverse domande.

fbc viene creato?

Viene mantenuto durante la navigazione?

Il consenso ne influenza la disponibilità?

Un redirect elimina fbclid?

L’evento AddToCart contiene davvero gli ID e il valore dei prodotti?

Meta riceve gli stessi dati che vediamo nel dataLayer?

Sono domande decisamente più utili rispetto al semplice:

“Come faccio a portare il punteggio da 6 a 8?”

Quando si lavora con tracking, advertising e consent management, raramente esiste un interruttore magico da attivare.

Bisogna seguire il percorso del dato.

Dal clic sull’annuncio fino alla conversione.

Ed è proprio qui che strumenti come Google Tag Manager, il dataLayer, Facebook Pixel by Stape e Meta Events Manager diventano davvero utili: non tanto per “far partire un tag”, quanto per capire se l’informazione arriva correttamente da un sistema all’altro.

Ed è anche il motivo per cui, davanti a un punteggio basso, cerco sempre prima di capire quale dato manca e perché, invece di aggiungere parametri alla cieca.

Perché un tracking affidabile non è quello che mostra il punteggio più alto.

È quello di cui possiamo spiegare esattamente il funzionamento.

Hai problemi con il tracking del tuo sito. Parliamone.