La tua analitica dice che il sito ha fatto 42 180 il mese scorso. La tua base dati degli ordini dice 39 650. Qualcuno chiede quale sia giusta, e la risposta onesta di solito è nessuna delle due, per motivi che presi da soli sono noiosi e nell'insieme sono cari.
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.
L'evento di acquisto di solito vive 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 è più alta della base dati degli ordini, la differenza è un multiplo netto su una manciata di ordini grossi, 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 deduplichi su 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 quello e l'hai lasciato vuoto, il tuo difetto è questo.
Vale la pena essere diretti su quanto costa sbagliare questa cosa. Una pagina di acquisto che riscatta 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 report 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 sistemazione più sicura è che la valuta venga marcata sull'evento quando 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 detto con sicurezza.
3. Rimborsi, annullamenti e incassi falliti
La tua base dati degli ordini è un documento vivo. 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 contro un report amministrativo invece che contro una tabella di ordini.
Collegata, e più facile da perdere: 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 il tuo libro contabile non ha mai avuto.
4. Eventi bloccati, buttati via e mai mandati
Questa sgonfia sempre, 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 corre contro 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, quella noiosa 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. Un confine di mese trasforma quello in una differenza vera: 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
- Scegli una settimana che si è chiusa.
- Esporta gli ordini: numero, data e ora in UTC, valuta, valore netto dopo i rimborsi.
- Esporta gli eventi di acquisto con gli stessi campi.
- Uniscili sul numero dell'ordine.
I quattro contenitori che ne escono sono la diagnosi. Gli eventi senza ordine sono scatti doppi 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 disaccordano 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 sono marcati con la loro valuta nel momento in cui vengono registrati, 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 guadagnati invece che alla pagina su cui sono stati pagati, e la valuta dei ricavi viene marcata alla ricezione e non viene mai convertita.