Parti dalla definizione aziendale dell'acquisto

Quando il fatturato di GA4 non coincide con il gestionale, il primo impulso è correggere il tag. Prima serve una domanda più semplice: i due sistemi stanno contando lo stesso fatto? Un ordine creato, uno pagato e uno spedito non hanno necessariamente la stessa data. Anche imposte, spedizione, sconti e resi possono seguire regole diverse. Senza un accordo sui valori, due numeri corretti possono apparire incompatibili.

Scriviamo quindi una scheda di misurazione con il responsabile e-commerce e chi gestisce il CMS. Deve indicare il momento dell'acquisto, la valuta, il calcolo del valore, l'origine degli identificatori prodotto e il trattamento dei rimborsi. Questa scheda diventa il riferimento per sviluppatore, analista e media buyer. Riduce le discussioni basate su schermate che mostrano metriche con significati diversi.

1. Costruisci un evento leggibile fino al prodotto

La guida e-commerce di Simo Ahava separa i parametri dell'evento dall'array items e richiama un dettaglio facile da perdere: quantity deve rappresentare una quantità intera. Purchase descrive l'acquisto; transaction_id ne conserva il riferimento. Controlla le righe prodotto e il collegamento delle variabili ai campi del dataLayer.

Per purchase, mantieni currency insieme a value. Il valore degli articoli va distinto da spedizione e imposte, che hanno campi dedicati. Nel controllo che proponiamo, ricalcola il valore sommando prezzo per quantità di ogni riga e confrontalo con quello trasmesso. Usa carrelli misti, sconti e più unità: il test con un solo articolo può mascherare errori.

Nel documento operativo affiancheremmo a ciascun campo la sua origine nel CMS. Evita descrizioni come 'totale ordine' se il campo comprende componenti che un altro sistema tratta separatamente. Scrivi il nome del campo sorgente e la trasformazione applicata: è ciò che permette di risalire all'errore quando cambia il checkout.

Esempio operativoDati illustrativi, non dati cliente
SegnaleControlloDecisione
Ordine #1048 · 129 €GA4 transaction_id 1048 · 129 €Riconciliato
Rimborso #1052 · 49 €Evento refund assenteInviare e verificare il rimborso
Ordine #1059 · 89 €Purchase presente due volteBloccare il reinvio del transaction_id
La decisione arriva dopo il controllo del dato e del contesto, non dal numero isolato.

2. Assegna un'identità stabile alla transazione

Il Duplicate Transaction Checker descritto da Stape consulta un archivio persistente degli identificatori già elaborati e restituisce un esito utilizzabile dal trigger. È un controllo prima dell'invio contro ricariche e tentativi ripetuti. Nel registro proposto separiamo anche destinazione e tipo di operazione: una vendita già comunicata non deve bloccare un rimborso successivo dello stesso ordine.

Per un e-commerce con negozi diversi, proponiamo una chiave che includa un prefisso di negozio e il riferimento ordine. Il criterio va stabilito nel backend. Browser, processo server e rimborso devono ricevere una medesima rappresentazione: se un sistema invia IT-842 e un altro 842, il lavoro di riconciliazione diventa ambiguo. Non affidare questa scelta al nome della pagina di conferma.

3. Progetta i resi come eventi del gestionale

Il rimborso può avvenire quando il cliente ha chiuso il browser da giorni. Per questo il processo operativo deve partire dallo stato amministrativo dell'ordine e dalla decisione su cosa costituisce un rimborso effettivo. Mantieni un registro interno delle operazioni di rimborso con ID univoco, ordine collegato, righe, quantità, importo ed esito di invio. Questo registro consente di gestire tentativi e controlli senza ricostruire tutto dai report.

La guida di Ahava distingue rimborso completo e parziale: refund conserva transaction_id e, per descrivere le unità restituite, usa items con identificativo e quantità. Da qui proponiamo due chiavi interne: riferimento dell'acquisto e identificativo dell'operazione di rimborso. Più resi dello stesso ordine rimangono distinguibili nel registro, senza perdere il collegamento alla vendita.

Esempio operativo: un ordine, due prodotti, un rimborso parziale

L'ordine IT-842 contiene due unità di un prodotto da 30 euro e una di un prodotto da 40 euro. Il valore degli articoli è 100 euro; eventuali componenti aggiuntive sono gestite separatamente secondo la specifica. Dopo alcuni giorni viene rimborsata una sola unità del primo prodotto. Il controllo parte dalla riga da 30 euro e dalla quantità uno, mantenendo il riferimento IT-842.

Nel foglio di riconciliazione costruiremmo tre viste: acquisti del periodo, rimborsi effettuati nel periodo e situazione degli ordini acquistati in una determinata settimana. Sono domande diverse. Un reso di settembre relativo a un acquisto di agosto cambia il movimento di settembre e il valore finale della coorte di agosto. Mescolare le due prospettive può far sembrare rotto un sistema che sta semplicemente applicando date diverse.

4. Verifica prima il payload, poi i report

Analytics Mania mostra perché il debug deve includere tutte le sorgenti: codice gtag e GTM insieme, plugin, regole Create Event e invii server possono produrre copie dello stesso evento. Julius Fedorovicius suggerisce di partire dal numero di attivazioni e dalle richieste effettive. Se il tag GTM parte una volta, cerca l'altra sorgente prima di cambiare il trigger.

Controlla il contenuto trasmesso, la ricezione e, dopo l'elaborazione, la metrica di destinazione. Un evento presente non garantisce che valore, valuta e prodotti siano compilati correttamente. Viceversa, una differenza aggregata non indica da sola quale campo sia sbagliato. Lavora con scostamenti classificati e mantieni separati ordini di test, annullati e realmente acquistati.

5. Trasforma il collaudo in un controllo ricorrente

Il controllo utile confronta record omogenei. Ogni giorno puoi estrarre gli ordini del perimetro concordato e verificare presenza degli identificatori, duplicati nella tua raccolta, valori incoerenti e ritardi. La soglia di allarme deve dipendere dal comportamento abituale del sito e dal campione, non da una percentuale universale arbitraria. Assegna un responsabile alle anomalie: CMS, raccolta, elaborazione o report.

Il risultato da consegnare all'azienda è un elenco di differenze spiegate e di correzioni verificabili. Dire che GA4 'ora funziona' è troppo generico. Dire che gli ordini con pagamento differito prima inviavano il valore provvisorio, e mostrare il collaudo della correzione, permette una decisione concreta. È qui che il dettaglio tecnico torna utile al budget pubblicitario.

Fonti e approfondimenti

Riferimenti citati nella guida. Gli esempi numerici sono illustrativi.