Tillde
Menu

Caso studio

Il 62% del fatturato online non era attribuito a nessuna sorgente: riconciliazione ordini su Shopify in 90 giorni

6 ordini reali per 1.905 euro contro 3 transazioni in GA4 per 720 euro. La perdita non era recente ma cronica, e la raccomandazione finale è stata di non comprare il servizio più costoso che vendiamo.

·Mattia Minafò
caso studioshopifyriconciliazionega4metaaudit

Un brand di abbigliamento tecnico da outdoor, su Shopify, con una spesa pubblicitaria di poche centinaia di euro al mese quasi interamente su Instagram.

Il vincolo: avevano appena cambiato agenzia, sospettavano che il tracciamento fosse rotto, e volevano sapere se rifare tutto da capo. Noi avevamo accesso in sola lettura, nessuna possibilità di intervenire sul tema, e una spesa pubblicitaria troppo bassa perché qualunque infrastruttura si ripagasse. Il lavoro doveva chiudersi con una raccomandazione difendibile sui numeri, non con un preventivo.

Il risultato: 6 ordini reali per 1.905,00 euro contro 3 transazioni registrate in Google Analytics per 720,00 euro. Il 62% del fatturato online del periodo non era attribuito ad alcuna sorgente, e la perdita è risultata cronica su dodici mesi invece che recente.

Qui sotto c’è come ci siamo arrivati, cosa abbiamo escluso lungo la strada, e perché abbiamo consigliato di non comprare il servizio più costoso che vendiamo.

Cosa contiene questo caso

  • come capire se un calo di conversioni è reale o è un problema di misurazione
  • come stabilire quale delle tre piattaforme sta dicendo la verità, invece di mediarle
  • come distinguere una rottura recente da un difetto che c’è sempre stato
  • come decidere se un’infrastruttura di tracciamento si ripaga, prima di venderla

Indice

  1. Il cliente e il punto di partenza
  2. Riconciliazione ordini contro registro gestionale
  3. Valutazione dell’infrastruttura Meta
  4. Analisi GA4 e igiene del dato sorgente
  5. Valutazione economica
  6. Nota di metodo sui numeri
  7. Cosa non ha funzionato
  8. Cosa faremmo adesso
  9. Conclusione

Il cliente e il punto di partenza

Brand nato a fine 2024, prima linea di abbigliamento active in lana merino, seconda linea in sviluppo. Vende su Shopify. L’acquisizione passa quasi solo da contenuti su Instagram, con un podcast e una serie editoriale a fare da traino.

Il rapporto con l’agenzia precedente si era chiuso per conversioni scarse e sospetti sul tracciamento. Da fine aprile gestivano Meta internamente. Nessuna spesa su Google Ads, nessun server-side configurato da noi, consenso gestito da una piattaforma di terze parti.

Lo stato iniziale, in numeri e con la fonte di ciascuno:

DatoValoreFonte
Fatturato online reale, 90 giorni1.905,00 €registro ordini Shopify
Transazioni registrate in GA4, stesso periodo720,00 €GA4, finestra 8 mag / 4 ago
Spesa Meta, 28 giorni262,10 €Events Manager
Spesa Meta, 90 giorni1.485,30 €Ads Manager
Eventi Purchase su Meta, 28 giorni0Events Manager
Ordini totali, 12 mesi92registro ordini Shopify

Riconciliazione ordini: il confronto che decide come si legge tutto il resto

IN SINTESI

Cosa abbiamo fatto: messo il registro ordini Shopify accanto alle transazioni GA4, riga per riga, prima di aprire qualunque piattaforma pubblicitaria.

Perché: senza questo confronto ogni analisi successiva parte da una base che potrebbe essere già sbagliata del 60%.

Cosa abbiamo trovato: 3 ordini su 6 senza percorso utente, e i campi di prima e ultima visita vuoti a livello di piattaforma.

Il numero della sezione: 1.185,00 € non attribuiti su 1.905,00 € di fatturato, cioè il 62%.

La prima decisione è stata di ordine, non di metodo. Abbiamo chiesto l’esportazione completa del registro ordini prima di guardare Meta, GA4 o Google Ads.

Il motivo è che le tre piattaforme si controllano a vicenda solo se esiste un quarto termine di paragone che non dipende da nessuna delle tre. Il registro ordini è quel termine, perché è contabilità e non misurazione.

Sulla finestra di 90 giorni il negozio aveva sei ordini reali provenienti dallo store online, per 1.905,00 euro. Altri quattro ordini erano vendite fatte di persona, correttamente assenti dai report web e fuori perimetro.

In GA4 ne risultavano tre, per 720,00 euro.

OrdineDataTotalePresente in GA4
#108510 mag63,00 €
#10891 giu360,00 €
#10903 lug297,00 €
#109110 lug280,00 €no
#109224 lug675,00 €no
#109325 lug230,00 €no

Gli ordini tracciati si fermavano tutti al 3 luglio. La lettura immediata era una rottura recente, e sarebbe stata la conclusione comoda.

Abbiamo esteso la finestra a dodici mesi per trovare la data esatta del guasto. Su 92 ordini totali, esclusi 48 ordini di test o importazione e 4 vendite di persona, restavano circa 40 ordini reali. Di quei 40, 22 avevano il percorso utente valorizzato, cioè il 55%.

Il 50% della finestra di audit era in linea con la media dello store. La data di rottura non esisteva, perché la perdita è cronica e riguarda l’intera vita del negozio.

Il tasso però degrada nel tempo: 85% a dicembre 2025, 50% a gennaio 2026, 20% a febbraio 2026. Da marzo i volumi mensili sono troppo bassi per essere interpretabili.

Sugli ordini non tracciati i campi di prima e ultima visita registrati da Shopify risultano nulli. E l’analitica interna della piattaforma, che non dipende né da Google né da Meta, attribuisce a una sessione solo 3 ordini su 6.

È la piattaforma a non riuscire ad associare l’ordine a una sessione di navigazione (l’aggancio fra chi ha comprato e la visita da cui arriva). Mancando quell’aggancio a monte, ogni sistema a valle resta senza materia prima. È la sola spiegazione compatibile con una perdita simultanea su tre sistemi indipendenti.

Cosa ha funzionato

Aver chiesto il registro ordini prima delle piattaforme ha cambiato il verdetto del lavoro. Con le sole tre transazioni GA4 avremmo scritto un audit su una base ridotta al 38% del reale, e ogni percentuale calcolata sopra sarebbe stata formalmente corretta e sostanzialmente falsa.


Valutazione dell’infrastruttura Meta: sana, e già più efficace di quanto pensassero

IN SINTESI

Cosa abbiamo fatto: verificato evento per evento la deduplica fra canale browser e canale server, e misurato il contributo netto del server.

Perché: prima di proporre un’infrastruttura server-side serve sapere se ne esiste già una attiva e quanto rende.

Cosa abbiamo trovato: entrambi i canali attivi dalle app native, deduplica sopra soglia, nessun Custom Pixel configurato.

Il numero della sezione: 23,9% del segnale arriva solo dal canale server, senza che nessuno l’avesse impostato.

Eventi ricevuti su 28 giorni: 7.352 PageView, 5.705 ViewContent, 7 Search, 5 InitiateCheckout, 2 AddToCart, 0 Purchase.

Lo zero su Purchase è la conseguenza della sezione precedente, non un difetto dell’integrazione. Con una perdita di fondo intorno al 45-50% a livello di sessione e tre ordini reali nella finestra, la probabilità di osservare zero per caso è intorno al 12%. Non serve postulare un guasto specifico.

Il prefisso sugli identificativi evento indica l’implementazione server-side nativa della piattaforma. Abbiamo verificato sul pannello: nessun Custom Pixel configurato. Entrambi i canali arrivano dalle app native.

Split browser 5.649 contro server 7.422. Su 13.071 eventi ricevuti, le coppie appaiabili sono 5.648 e gli eventi unici circa 7.423, quindi il valore in prima pagina di Events Manager è 1,76 volte il traffico reale. È un comportamento previsto, non un errore, ma va saputo prima di leggere qualunque numero su quella schermata.

Tasso di deduplica 78% (la quota di eventi che il sistema riconosce come già ricevuti dall’altro canale, e quindi non conta due volte), contro una soglia operativa di riferimento del 75%. Identificativo presente su tutti gli eventi e condiviso fra i due canali, controllato evento per evento.

Il contributo netto del canale server è di 1.774 eventi che esistono solo lì, cioè il 23,9% del segnale complessivo e il 31,7% sui soli ViewContent. In dettaglio: PageView 4.025 contro 3.327, più 21%. ViewContent 3.389 contro 2.316, più 46%.

Il valore è amplificato dalla composizione del traffico: 64% Safari e 27% browser interno di Instagram su Android, insieme oltre il 90%. Sono i due ambienti dove il canale browser perde di più.

Punteggio di corrispondenza degli eventi a 5,9 su PageView e ViewContent. Indirizzo IP e user agent presenti al 100%, identificativo utente interno al 100%, identificativo clic pubblicitario al 68,6% e 73,0%. Assenti email, telefono, nome e città, che è una proprietà di quegli eventi e non un difetto: su una visualizzazione di prodotto quei dati non esistono ancora.

Una nota di conformità che va dichiarata. La restrizione nativa sul consenso risulta attiva solo per l’Italia. Sul traffico italiano quel 23,9% è recupero tecnico dentro la popolazione che ha acconsentito. Sul traffico estero, che è la quota maggioritaria, può includere utenti non consenzienti, e va verificato sul pannello della piattaforma di consenso.

Cosa ha funzionato

Misurare il canale server prima di proporlo ha evitato di vendere una cosa che il cliente aveva già attiva. E ha prodotto il dato che ha poi ribaltato la raccomandazione economica.


Analisi GA4 e igiene del dato sorgente

IN SINTESI

Cosa abbiamo fatto: verificato il payload degli eventi e-commerce e incrociato i totali di riga con i totali transazione.

Perché: un dato sporco alla fonte produce report puliti e sbagliati, che è la condizione peggiore.

Cosa abbiamo trovato: sconto non propagato al prezzo di riga, ordini di test in produzione, un solo mercato configurato.

Il numero della sezione: 1 ordine su 92 riporta parametri di tracciamento nelle inserzioni.

Su tutte e tre le transazioni registrate la somma dei prezzi di riga è 800,00 euro contro 720,00 euro di valore transazione. Rapporto esattamente 0,9 su tutte e tre.

La causa l’abbiamo accertata sul registro ordini: un codice sconto del 10% applicato a tutti e tre. La piattaforma alloca correttamente lo sconto sulle righe, con importi visibili ordine per ordine, ma l’allocazione non viene propagata al campo prezzo inviato a GA4. Il campo prezzo barrato è vuoto su tutte le varianti, il che esclude la spiegazione alternativa.

Uno dei due codici usati non figura fra quelli attivi nel pannello. Origine da verificare col cliente.

48 ordini di test o importazione risultano in produzione, concentrati in due giornate (26 novembre 2025 e 22 aprile 2026), con importi ripetuti di 1, 18 e 45 euro, privi di indirizzo, in parte con primo accesso da pagina protetta da password. Rientrano in tutti i report nativi e alterano scontrino medio, conteggio clienti e ogni calcolo futuro di valore del cliente nel tempo.

Il rilievo più pesante riguarda il marketing, non il tracciamento. Su 92 ordini in dodici mesi, uno solo riporta parametri UTM (le etichette che dicono da quale campagna arriva una visita). Le inserzioni sono contenuti sponsorizzati non parametrizzati. La conseguenza è che nessun report, per quanto ben costruito, può stabilire se la spesa pubblicitaria produca ordini. Si corregge taggando le campagne, non migrando l’impianto.

Infine catalogo e mercati: un solo mercato configurato e codice paese di default generico sul catalogo. Nei titoli prodotto sono presenti tag di interruzione riga, che il canale Merchant Center non ammette.

Cosa ha funzionato

Aver letto il payload invece di dedurlo dai totali. Il rapporto 0,9 identico su tre transazioni è il tipo di regolarità che una media non mostra mai.


Valutazione economica: quando l’infrastruttura non si ripaga

IN SINTESI

Cosa abbiamo fatto: confrontato il costo ricorrente di un’infrastruttura server-side completa con la spesa pubblicitaria effettiva del negozio.

Perché: la raccomandazione doveva essere difendibile anche togliendoci il lavoro più remunerativo.

Cosa abbiamo trovato: la spesa è un ordine di grandezza sotto la soglia di convenienza.

Il numero della sezione: 262,10 € di spesa su 28 giorni, contro una soglia di riferimento fra 1.000 e 1.500 euro al mese.

La spesa Meta su 28 giorni è di 262,10 euro, che hanno generato 99.505 impression e 4.226 clic, con costo per mille impression di 2,63 euro e tasso di clic del 4,25%. Su 90 giorni la spesa sale a 1.485,30 euro. Google Ads risulta collegato ma inattivo, con spesa zero.

Il ragionamento è aritmetico. Un’infrastruttura server-side completa ha un costo di impianto e un costo mensile ricorrente. Perché si ripaghi serve che il segnale aggiuntivo si traduca in ottimizzazione di campagna, e perché quello accada serve un volume di spesa che generi abbastanza conversioni da far lavorare l’algoritmo.

Con questi numeri quella condizione non c’è. In più, come misurato nella sezione precedente, il canale server nativo è già attivo e porta il 23,9% del segnale senza costare nulla.

La raccomandazione finale è stata articolata su tre livelli, ordinati per rapporto fra impatto e costo.

Primo, correggere la perdita di sessione a livello di piattaforma. È l’unico intervento che agisce sulla causa individuata nella prima sezione, ed è l’unico che sblocca tutto il resto.

Secondo, parametrizzare le campagne. Costo zero, effetto immediato sulla possibilità stessa di misurare il ritorno della spesa.

Terzo, infrastruttura completa no, con scritta in chiaro nel documento la soglia di spesa oltre la quale rivalutare.

Cosa ha funzionato

Aver messo la valutazione economica dentro l’audit invece che dentro un preventivo separato. Il cliente ha ricevuto il criterio con cui rifiutare il nostro servizio, e questo ha reso credibili le due raccomandazioni che invece abbiamo fatto.


Nota di metodo sui numeri

Fonte di verità dichiarata: il registro ordini Shopify. Non GA4, non Events Manager. Il registro è contabilità, le piattaforme sono misurazione, e quando divergono ha ragione la contabilità.

Numero pubblicatoFonteFinestraModello
6 ordini, 1.905,00 €registro ordini Shopify90 gg, 8 mag / 4 agoordini Online Store, esclusi punto vendita
3 transazioni, 720,00 €GA490 gg, stessa finestraevento purchase, ultimo clic non diretto
55% journey valorizzatiregistro ordini Shopify12 mesi, 1 set 2025 / 6 ago 2026su ~40 ordini reali, esclusi 48 test e 4 punto vendita
Deduplica 78%Events Manager28 gg, 8 lug / 4 agocoppie appaiabili su eventi ricevuti
23,9% contributo serverEvents Manager28 gg, stessa finestraeventi solo-server su eventi unici
Punteggio corrispondenza 5,9Events Manager28 gg, stessa finestramedia su PageView e ViewContent
262,10 € di spesaEvents Manager28 gg, stessa finestraspesa effettiva, non budget

La distanza fra dato di piattaforma e dato di backend è del 62% sulla finestra di 90 giorni e del 45% circa sulla media dei dodici mesi. Non l’abbiamo mediata né arrotondata, perché sono due misure su due finestre diverse e vanno lette separatamente.

Cosa non siamo in grado di misurare, e con che grado di certezza.

La causa della mancata associazione fra sessione e ordine è accertata a livello di sistema, cioè è la piattaforma e non GA4 né il pixel, ma è stimabile con confidenza media a livello di meccanismo. Le due spiegazioni compatibili sono il rifiuto del consenso, dato che la restrizione risulta attiva solo per l’Italia e tutti gli ordini del periodo sono italiani, e la fragilità di sessione sul browser interno di Instagram, che da gennaio è la quota dominante del traffico. Per separarle serve un test attivo sul comportamento del cookie di sessione al rifiuto, che richiede accesso in scrittura e non era nel perimetro.

L’effetto della perdita sulle campagne non è quantificabile con i dati disponibili, perché su 92 ordini uno solo ha parametri di tracciamento. È un limite del dato sorgente e non dell’analisi, ed è correggibile in una settimana taggando le campagne.


Cosa non ha funzionato

Abbiamo aperto una criticità bloccante su un’ipotesi poi rivelatasi falsa. Nella prima stesura avevamo segnalato come blocco il sospetto che l’evento di aggiunta al carrello non scattasse con il selettore delle varianti, deducendolo dal rapporto anomalo fra visualizzazioni prodotto e aggiunte. Un test attivo sul negozio ha falsificato l’ipotesi, perché l’evento scatta correttamente. La conclusione era stata dedotta dai numeri invece che verificata sull’interfaccia. Cosa abbiamo fatto invece: abbiamo introdotto una gerarchia esplicita fra rilievi strutturali letti da configurazione, rilievi attivi verificati con test e riconciliazioni contabili, e adesso ogni verdetto dichiara a quale livello appartiene.

Abbiamo perso tempo guardando le piattaforme prima del registro ordini. La prima versione dell’analisi era organizzata per canale, con la riconciliazione contabile in fondo come controllo finale. Con quell’ordine il dato dei sei ordini reali è arrivato troppo tardi per orientare il lavoro, e diverse conclusioni intermedie sono state riscritte. Cosa abbiamo fatto invece: la riconciliazione con il gestionale è diventata la sezione uno di ogni nostro audit, prima di qualunque piattaforma.

Abbiamo letto lo split browser contro server su una base sbagliata. In una stesura intermedia i due canali risultavano 4.187 contro 3.054, numeri presi da una vista che non copriva lo stesso perimetro. Corretti in 5.649 contro 7.422 dopo il ricontrollo. Cosa abbiamo fatto invece: ogni coppia di numeri messa in relazione dentro un audit adesso porta scritta accanto la finestra e il perimetro, e se non coincidono si pubblica un numero solo.


Cosa faremmo adesso

Test attivo sul cookie di sessione al rifiuto del consenso. È l’unico modo per separare le due spiegazioni residue della perdita. Richiede accesso in scrittura e mezza giornata.

Parametrizzazione completa delle campagne e misura a 30 giorni. Con i parametri attivi, fra un mese esiste per la prima volta una base per dire se la spesa produce ordini. È l’intervento con il miglior rapporto fra impatto e costo di tutto il documento.

Pulizia dei 48 ordini di test. Finché restano in produzione, ogni calcolo di scontrino medio e di valore del cliente nel tempo parte viziato, incluso quello che servirà a decidere se l’infrastruttura completa ha senso.

Rivalutazione della soglia a sei mesi. Se la spesa mensile supera i 1.000 euro il calcolo economico cambia, e l’infrastruttura torna sul tavolo con numeri diversi.

Verifica di conformità sul traffico estero. La restrizione nativa sul consenso risulta attiva solo per l’Italia. Sul resto del traffico va controllato cosa fa la piattaforma di consenso.


Conclusione

Il 62% del fatturato online del periodo, cioè 1.185,00 euro su 1.905,00, non era attribuito ad alcuna sorgente. Non per un guasto recente, ma per un difetto di associazione fra ordine e sessione che accompagna il negozio da quando esiste.

Quello che questo lavoro lascia al cliente, ripreso dai quattro punti iniziali.

Come capire se un calo è reale o è misurazione: si mette il registro ordini accanto ai report prima di guardare qualunque piattaforma. Se i due elenchi non coincidono, il problema è di misurazione fino a prova contraria.

Come stabilire quale piattaforma dice la verità: non si mediano, si confrontano tutte contro una fonte che non dipende da nessuna di loro.

Come distinguere una rottura recente da un difetto cronico: si allarga la finestra fino a trovare la data del guasto. Se la data non esiste, il guasto non è mai iniziato perché c’è sempre stato.

Come decidere se un’infrastruttura si ripaga: si confronta il costo ricorrente con la spesa pubblicitaria effettiva, e si scrive la soglia oltre la quale rivalutare.


Quando questo lavoro ha senso, e quando no

Ha senso se hai più di una fonte che dice quanto hai venduto e almeno una volta ti sei chiesto a quale credere, e se qualcuno in azienda deve rispondere di quei numeri davanti a un socio o a un investitore.

Non ha senso se cerchi la garanzia che i numeri di due piattaforme coincidano, perché non coincideranno mai e una parte dello scarto è strutturale. E non ha senso se vuoi che il lavoro parta prima di un audit, perché su un sistema non diagnosticato il perimetro non è stimabile e un perimetro stimato male costa a entrambi.

Il primo passo è una riconciliazione fra il tuo registro ordini e le tue piattaforme su 90 giorni. Dieci giorni lavorativi, un documento, e la libertà di non fare nient’altro.