La tua analitica dice che il sito ha incassato 42 180 il mese scorso. La tua base dati degli ordini dice 39 650. Qualcuno chiede quale delle due abbia ragione, e la risposta onesta di solito è nessuna delle due, per motivi che presi da soli sono noiosi e nell'insieme sono costosi.

Ecco le cinque cause, più o meno in ordine di quanto spesso ognuna si rivela quella giusta, con un modo per distinguerle.

1. La pagina di conferma scatta più di una volta

È di gran lunga la causa più comune, e gonfia sempre il totale.

L'evento di acquisto di solito si trova sulla pagina di conferma dell'ordine. Quella pagina viene ricaricata ogni volta che qualcuno la aggiorna, preme indietro e poi avanti, la apre dalla propria email, o se la vede ripristinata da un browser che riapre le schede all'avvio. Ognuna di quelle cose fa scattare di nuovo l'evento con lo stesso valore.

Lo riconosci dalla forma della discrepanza: l'analitica dà un totale più alto della base dati degli ordini, la differenza è un multiplo esatto su una manciata di ordini grandi, e l'effetto è peggiore su mobile, dove la navigazione all'indietro è più comune.

La soluzione è un numero dell'ordine. Manda il numero dell'ordine insieme all'evento di acquisto e lascia che l'analitica elimini i duplicati in base a quello. In GA4 il campo è transaction_id; la maggior parte degli strumenti usa quel nome perché ha vinto la convenzione di GA. Se il modello del tuo gestore di tag ha un campo per questo e l'hai lasciato vuoto, l'errore è tuo.

Vale la pena essere diretti su quanto costa sbagliare questa cosa. Una pagina di acquisto che scatta di nuovo e conta una singola vendita quattro volte non sembra un errore in una dashboard. Sembra un buon mese.

2. Due valute sommate insieme

Se vendi in più di una valuta e la tua analitica riporta un unico totale di ricavi, scopri che cosa sta facendo prima di fidartene.

Certi strumenti convertono in una valuta di riferimento a un tasso fissato quando i dati sono arrivati. Certi convertono al tasso del giorno in cui guardi, il che vuol dire che un mese chiuso cambia valore a seconda di quando lo apri. Certi sommano semplicemente i numeri e ci mettono davanti un simbolo, producendo una cifra che non è denaro in nessuna valuta.

Il segnale è un totale che sta fra la cifra convertita corretta e la somma ingenua, oppure un totale che si muove quando riapri un report per un mese chiuso da tempo.

La soluzione più sicura è che la valuta venga fissata sull'evento quando questo viene registrato e che lo strumento non converta mai. Un report con valute miste allora o divide per valuta o si rifiuta di dare un totale unico, e tutte e due le cose sono più utili di un numero sbagliato presentato con sicurezza.

3. Rimborsi, annullamenti e incassi falliti

La tua base dati degli ordini è sempre aggiornata. Sa che l'ordine 8814 è stato rimborsato il 14. La tua analitica ha registrato l'acquisto il 2 e, a meno che tu non le abbia mandato un evento di rimborso, ci crede ancora.

Nell'arco di un mese con tassi di reso normali questo da solo può valere diversi punti percentuali, ed è la causa che fa sembrare l'analitica alta rispetto a un report finanziario invece che rispetto a una tabella di ordini.

Collegata, e più facile da non notare: un ordine che è stato creato e mai incassato. Se l'evento scatta sulla pagina di conferma e il pagamento fallisce dopo, oppure l'ordine resta non pagato e viene annullato da un limite di tempo, l'analitica ha una vendita che la tua contabilità non ha mai avuto.

4. Eventi bloccati, persi e mai inviati

Questa riduce sempre il totale, ed è per questo che l'analitica di solito è più bassa della tabella degli ordini quando non viene gonfiata dalle cause qui sopra.

I bloccatori di contenuti fermano la richiesta. Lo fanno anche certe reti aziendali, certi filtri a livello di DNS, e certi browser attenti alla privacy di serie. Se la tua analitica ha bisogno del consenso, manca anche chiunque abbia rifiutato. E un evento di acquisto che scatta al caricamento della pagina fa a gara con la persona che chiude la scheda, cosa che fa molto spesso nell'istante in cui l'ordine è confermato.

La dimensione della frazione bloccata varia enormemente con il pubblico (un sito di strumenti per chi sviluppa perde molto di più di un fioraio), quindi qualunque percentuale pubblicata non vale niente per il tuo caso. Misura la tua: conta gli ordini che la tua base dati ha registrato contro gli eventi di acquisto che l'analitica ha registrato, abbinati sul numero dell'ordine, per una sola settimana pulita.

Se non riesci ad abbinarli sul numero dell'ordine, è di nuovo la causa numero 1.

5. I due sistemi contano momenti diversi

Infine, la causa noiosa, quella che spiega il piccolo resto che rimane dopo che hai sistemato tutto il resto.

L'analitica marca l'ora dell'evento nella sessione di chi visita, nel fuso orario per cui il report è impostato. La tua base dati degli ordini marca l'ora della riga quando il processore dei pagamenti ha confermato, in UTC, forse minuti dopo e ogni tanto dall'altra parte della mezzanotte. Il cambio di mese trasforma questo scarto in una differenza reale: sempre nella stessa direzione, sempre piccola.

L'attribuzione ci si aggiunge. L'analitica assegna i ricavi alla sessione che ha convertito (o a una sessione precedente, a seconda del modello di attribuzione), mentre la tua tabella degli ordini non li assegna a niente. Confrontare un totale di ricavi all'ultimo clic con un totale di ordini grezzo è confrontare le risposte a due domande diverse.

Una riconciliazione che puoi davvero fare

  1. Scegli una settimana già chiusa.
  2. Esporta gli ordini: numero, data e ora in UTC, valuta, valore netto dopo i rimborsi.
  3. Esporta gli eventi di acquisto con gli stessi campi.
  4. Uniscili sul numero dell'ordine.

I quattro gruppi che ne escono sono la diagnosi. Gli eventi senza ordine sono eventi scattati due volte o traffico di prova. Gli ordini senza evento sono blocco o un tag rotto. Le coppie abbinate con valori diversi sono il trattamento delle valute, o un disallineamento fra valori con e senza imposte. Le coppie abbinate in giorni diversi sono il fuso orario.

Fallo una volta, scriviti il resto come percentuale, e hai qualcosa di molto più prezioso di un totale che coincide: una differenza conosciuta e stabile. Due sistemi che divergono di un 4% costante sono utilizzabili tutti e due. Due sistemi che coincidono per caso no.

Dove si colloca Skomi

Skomi legge il numero dell'ordine da order_id, e anche dal transaction_id di GA, quindi un sito già etichettato per GA4 non ha bisogno di nessun cambiamento. Un evento che porta un numero che ha già visto non viene contato di nuovo.

I ricavi vengono registrati con la loro valuta nel momento in cui arrivano, e Skomi non converte mai fra valute: un report che copre due valute mostra due cifre, perché la cifra unica sarebbe una finzione. C'è dell'altro sulla pagina Analytics, e installare lo snippet copre l'invio dell'evento.

Due definizioni fanno qui la maggior parte del lavoro: i ricavi sono attribuiti alla visita che li ha generati invece che alla pagina su cui sono stati pagati, e la valuta dei ricavi viene fissata alla ricezione e non viene mai convertita.