Uno degli errori più comuni — e più silenziosi — nelle implementazioni di tracciamento e-commerce è la mancata corrispondenza tra l’item_id inviato negli eventi GA4/Google Ads e l’identificativo con cui i prodotti sono indicizzati su Google Merchant Center. Il risultato pratico è che Google non riesce ad associare i dati di performance alle schede prodotto, compromettendo funzionalità come il remarketing dinamico, i report sui prodotti in Performance Max e le conversioni arricchite con dati del carrello. In questa guida vediamo come individuare e verificare questi ID utilizzando tre metodi: ispezione diretta del dataLayer dalla console del browser, verifica tramite Google Tag Manager in modalità preview, e l’uso di estensioni Chrome come Omnibug ed EventWatcher.
Indice
- Come funziona il match tra eventi e Merchant Center
- Dove e come viene definito l’item_id nel dataLayer
- Metodo 1: ispezione via console del browser
- Metodo 2: verifica tramite GTM Preview Mode
- Metodo 3: estensioni Chrome — Omnibug ed EventWatcher
- Errori frequenti e come risolverli
- Conclusioni
Come funziona il match tra eventi e Merchant Center
Quando Google riceve un evento e-commerce — sia tramite gtag.js che tramite GTM — cerca di abbinare ogni prodotto presente nell’array items a una scheda nel Merchant Center. Il parametro utilizzato per questo abbinamento è item_id.
Su Google Merchant Center, ogni prodotto è identificato dal campo id del feed. Affinché il match avvenga, il valore di item_id passato nell’evento deve essere esattamente identico al valore del campo id del feed — incluse maiuscole, minuscole, prefissi, zeri iniziali e qualsiasi altro carattere.
Nota importante: Se utilizzi un feed supplementare o varianti di prodotto, potresti dover includere il suffisso della variante nell’ID (es. 12345_rosso_L). In Google Merchant Center, le varianti vengono registrate come item_group_id per il prodotto padre e id univoco per ciascuna variante. L’item_id nell’evento deve corrispondere all’id della variante specifica, non all’item_group_id.
Il mancato match non genera errori visibili in GA4 o Google Ads: gli eventi vengono registrati normalmente, ma la colonna “prodotti” nei report Performance Max rimane vuota o incompleta, e il remarketing dinamico non mostra il prodotto corretto. È un’anomalia silenziosa che richiede verifica attiva.
Dove e come viene definito l’item_id nel dataLayer
In un’implementazione GA4 standard via dataLayer, gli eventi e-commerce seguono questo schema:
window.dataLayer.push({
event: 'view_item',
ecommerce: {
currency: 'EUR',
value: 99.90,
items: [
{
item_id: '12345', // ← questo deve corrispondere all'id nel feed GMC
item_name: 'Nome Prodotto',
item_category: 'Categoria',
price: 99.90,
quantity: 1
}
]
}
});In WooCommerce, l’item_id corrisponde tipicamente all’ID post di WordPress (es. 1234). In PrestaShop, di default coincide con l’ID prodotto o con la combinazione nel formato id_product-id_product_attribute (es. 42-7), a seconda di come è configurato il modulo di tracciamento. È esattamente questo punto che genera la maggior parte delle discrepanze: il feed GMC potrebbe usare un formato diverso rispetto a quello pushato nel dataLayer.
Prima di procedere con i metodi di verifica, recupera l’ID di alcuni prodotti direttamente da Google Merchant Center: Merchant Center → Prodotti → Tutti i prodotti, poi clicca su un prodotto e leggi il campo ID nella scheda attributi. Questo è il valore di riferimento con cui confrontare.
Metodo 1: ispezione via console del browser
È il metodo più diretto e non richiede strumenti aggiuntivi. Apri il browser su una pagina prodotto del sito, poi apri gli Strumenti per gli sviluppatori (F12 oppure Cmd+Option+I su Mac) e vai nella scheda Console.
Leggere l’intero dataLayer
Digita nella console:
console.log(JSON.stringify(dataLayer, null, 2));Questo stampa l’intero array dataLayer in formato leggibile. Cerca l’oggetto con event: 'view_item' (o add_to_cart, purchase, ecc.) e individua la proprietà items[0].item_id.
Filtrare solo gli eventi e-commerce
Se il dataLayer è molto popolato, usa questo snippet per isolare rapidamente solo i push che contengono dati e-commerce:
dataLayer
.filter(e => e.ecommerce && e.ecommerce.items)
.forEach(e => {
console.group('Evento: ' + e.event);
e.ecommerce.items.forEach(item => {
console.log('item_id:', item.item_id, '| item_name:', item.item_name);
});
console.groupEnd();
});L’output mostrerà solo gli eventi rilevanti, con ID e nome del prodotto affiancati — utile per verificare visivamente la coerenza.
Intercettare i push in tempo reale
Per le pagine dinamiche (SPA o funnels multi-step come il checkout), i push avvengono in risposta ad azioni utente e non sono già presenti nel dataLayer al caricamento della pagina. In questo caso, puoi sovrascrivere temporaneamente il metodo push per intercettare ogni nuovo evento:
const originalPush = dataLayer.push.bind(dataLayer);
dataLayer.push = function(obj) {
if (obj && obj.ecommerce && obj.ecommerce.items) {
console.group('[dataLayer intercept] Evento: ' + obj.event);
obj.ecommerce.items.forEach(item => {
console.log('item_id:', item.item_id, '| item_name:', item.item_name);
});
console.groupEnd();
}
return originalPush(obj);
};Incolla questo snippet in console prima di eseguire l’azione (es. click su “Aggiungi al carrello”). Ogni successivo dataLayer.push() con dati e-commerce verrà stampato in tempo reale.
Attenzione: questa sovrascrittura è temporanea e valida solo per la sessione corrente del browser. Non impatta il sito né gli utenti reali.
Verificare su più pagine
Esegui la verifica almeno su: pagina prodotto (view_item), pagina carrello (view_cart), checkout (begin_checkout, add_payment_info) e pagina di conferma ordine (purchase). Le discrepanze tra item_id e feed GMC possono essere presenti solo in alcuni eventi se il valore viene costruito in modo diverso in contesti diversi.
Metodo 2: verifica tramite GTM Preview Mode
Google Tag Manager offre una modalità di anteprima (Preview & Debug) che permette di ispezionare ogni push al dataLayer, i trigger attivati e i tag eseguiti, direttamente in una finestra affiancata al sito. È il metodo più robusto per verifiche sistematiche e per documentare il comportamento in un intero funnel.
Avviare la Preview Mode
Accedi a GTM → seleziona il container del sito → Anteprima (pulsante in alto a destra). Si apre Tag Assistant; inserisci l’URL del sito e clicca Connect. Il browser aprirà il sito con la modalità di debug attiva — riconoscibile dalla barra GTM in fondo alla pagina.
Leggere i dati e-commerce nel pannello Debug
Nel pannello Tag Assistant, ogni riga nell’elenco a sinistra corrisponde a un evento. Clicca sull’evento che ti interessa (es. view_item) e seleziona la scheda Data Layer. Qui troverai la rappresentazione completa dell’oggetto pushato, incluso l’array ecommerce.items con tutti i parametri prodotto.
Verificare le variabili dei tag
Se hai configurato tag Google Ads o tag GA4 con variabili per i parametri e-commerce, clicca sul tag eseguito e controlla Event Settings Variable: vedrai i valori effettivamente passati al tag nel momento dell’esecuzione. Questo ti permette di individuare eventuali trasformazioni applicate a monte (trim, lowercase, concatenazione di prefissi) che alterano l’ID prima che venga inviato a Google.
Verificare il tag Google Ads Remarketing
Il remarketing dinamico Google Ads utilizza parametri diversi rispetto agli eventi GA4. Nel tag Google Ads Remarketing, l’ID prodotto viene letto dall’array items del dataLayer. Nel pannello Debug, clicca sul tag di remarketing e controlla la sezione Tag Details: verifica che l’ID passato sia consistente con quello degli eventi GA4 e con il feed GMC.
Metodo 3: estensioni Chrome — Omnibug ed EventWatcher
Le estensioni browser specializzate in tracciamento intercettano le richieste di rete e i push al dataLayer in tempo reale, offrendo una visualizzazione strutturata senza necessità di accesso a GTM o di interventi in console. Sono particolarmente utili per audit su siti di terze parti o per verifiche rapide senza accesso al container GTM.
Omnibug
Omnibug intercetta le richieste HTTP in uscita verso le principali piattaforme di analytics e advertising (GA4, Google Ads, Meta Pixel, ecc.) e le decodifica in un pannello leggibile all’interno dei DevTools.
Come usarlo per verificare l’item_id:
- Installa l’estensione e ricarica la pagina con i DevTools aperti.
- Nella barra dei DevTools troverai una nuova scheda Omnibug.
- Naviga sulla pagina prodotto o esegui un’azione (es. aggiungi al carrello).
- Nel pannello Omnibug compariranno le richieste intercettate. Filtra per Google Analytics 4 o Google Ads.
- Clicca sulla richiesta corrispondente all’evento e-commerce. Omnibug mostra i parametri decodificati: cerca il campo Items e all’interno item_id.
Per gli eventi GA4 inviati via Measurement Protocol (es. in un setup server-side con sGTM), Omnibug non intercetterà i chiamate lato server, ma le richieste lato client verso il server GTM saranno comunque visibili (verso l’URL del tuo server container, es. https://gtm.tuosito.it/g/collect). In questo caso, usa la scheda Network dei DevTools per ispezionare il payload JSON direttamente.
EventWatcher (ex dataslayer)
EventWatcher è focalizzato specificamente sul dataLayer: intercetta ogni push() e lo presenta in un pannello strutturato nei DevTools, senza che tu debba interrogare manualmente la console.
Come usarlo per verificare l’item_id:
- Installa l’estensione e apri i DevTools (F12).
- Troverai la scheda EventWatcher (o in alcune versioni dataLayer) nella barra dei DevTools.
- Ricarica la pagina: EventWatcher catturerà tutti i push al dataLayer dall’inizio del caricamento.
- Ogni evento è espandibile: cerca
event: view_item(o l’evento che ti interessa) e naviga inecommerce → items → [0] → item_id. - Per gli eventi dinamici (add_to_cart, purchase), esegui l’azione — EventWatcher cattura i push in tempo reale senza necessità di sovrascrivere manualmente il metodo
push.
Nota su compatibilità: EventWatcher funziona correttamente con dataLayer standard (Array globale). Se il sito usa implementazioni non standard (es. GTM caricato in modo asincrono con ritardo, o variabili dataLayer con namespace personalizzati), potrebbe perdere alcuni push. In questi casi, la verifica via console con l’intercettore manuale descritto nel Metodo 1 rimane il fallback più affidabile.
Confronto tra i due strumenti
| Caratteristica | Omnibug | EventWatcher |
|---|---|---|
| Fonte dati | Richieste HTTP intercettate | Push al dataLayer |
| Mostra dati pre-tag | No (post-firing) | Sì (pre-tag, dati grezzi) |
| Utile per sGTM | Parzialmente (richieste client) | Sì (dataLayer lato client) |
| Multi-piattaforma | Sì (GA4, Ads, Meta, ecc.) | No (solo dataLayer) |
| Richiede accesso GTM | No | No |
L’approccio ottimale è usarli in combinazione: EventWatcher per verificare i dati grezzi nel dataLayer (prima di qualsiasi trasformazione applicata da GTM), Omnibug per verificare i dati effettivamente trasmessi al tag. Una discrepanza tra i due indica che GTM sta alterando l’ID prodotto — e il punto di modifica è isolabile nella configurazione delle variabili del container.
Errori frequenti e come risolverli
1. Prefisso o suffisso nel feed ma non nell’evento (o viceversa)
Alcuni merchant aggiungono prefissi agli ID nel feed GMC per distinguere tipologie di prodotto (es. RING_12345 nel feed, 12345 nell’evento). La soluzione è allineare il formato: o rimuovere il prefisso dal feed, oppure aggiungerlo dinamicamente nell’evento tramite una variabile GTM (JavaScript personalizzato o template variabile con concatenazione).
2. ID variante vs ID prodotto padre
In WooCommerce, i prodotti variabili hanno un ID per il prodotto padre e uno per ciascuna variante. Il feed GMC indicizza la variante con il proprio ID. Se nell’evento add_to_cart viene passato l’ID del prodotto padre anziché quello della variante selezionata, il match fallisce. Verifica che il tuo layer di dati passi item_id corrispondente alla variante effettivamente scelta dall’utente.
3. Cast di tipo: integer vs string
Nel dataLayer JavaScript, l’item_id potrebbe essere pushato come numero intero (item_id: 12345) anziché come stringa (item_id: "12345"). GTM legge entrambi, ma il Measurement Protocol di GA4 trasmette il valore come stringa. Nel feed GMC il campo id è sempre una stringa. Questo non causa normalmente problemi di match, ma vale la pena standardizzare usando sempre stringhe per evitare comportamenti imprevisti con ID che iniziano per zero.
4. Encoding o caratteri speciali
ID con caratteri non ASCII, slash o caratteri speciali (es. SKU/2024-XL) possono subire encoding differente tra feed e evento. Verifica il valore grezzo nel dataLayer rispetto al valore nel feed usando la console o EventWatcher, prima di qualsiasi encoding HTTP.
5. Reset dell’oggetto ecommerce mancante
Secondo le best practice di Google, prima di ogni push di un evento e-commerce occorre azzerare l’oggetto precedente con:
window.dataLayer.push({ ecommerce: null });L’omissione di questo reset può causare la contaminazione dell’oggetto ecommerce con dati di eventi precedenti — in particolare l’array items di un evento add_to_cart potrebbe essere ereditato da un view_item precedente se il secondo push non include la chiave ecommerce. Verifica che ogni push sia preceduto dal reset, sia nel codice nativo che nelle implementazioni GTM.
Conclusioni
La verifica del match tra item_id e il feed Google Merchant Center è un controllo che dovrebbe far parte di ogni audit di tracciamento e-commerce, non solo in fase di setup ma anche periodicamente — specialmente dopo aggiornamenti del CMS, migrazioni del feed o modifiche al container GTM.
I tre metodi descritti coprono scenari diversi: la console è il metodo più immediato e non richiede strumenti aggiuntivi; GTM Preview Mode è il più completo per verifiche sistematiche e per isolare trasformazioni applicate dalle variabili; Omnibug ed EventWatcher accelerano le verifiche su siti di terze parti o quando non si ha accesso al container GTM.
Il segnale di allarme principale da monitorare è la presenza di eventi purchase in GA4 con prodotti che non compaiono nei report “Prodotti” di Performance Max, o un tasso di match inferiore all’85–90% nel report Merchant Center → Diagnostica → Prodotti corrispondenti. In entrambi i casi, la causa è quasi sempre un disallineamento nel formato dell’item_id — e con i metodi descritti in questa guida è risolvibile in pochi minuti.
