Caso studio
Il report su cui si decideva il budget mostrava 12.000 sessioni su 540.000: due settimane dopo il rilascio
Due report sulla stessa proprietà e sullo stesso periodo, due numeri diversi. Non era il nostro rilascio server-side: era un operatore che filtrava invece di classificare.
Un e-commerce consumer su Shopify, prodotto fisico, spesa continuativa su Google e Meta.
Il vincolo: avevamo appena messo online il tracciamento server-side, due settimane prima. Quando un report non torna subito dopo un rilascio, il sospetto cade sul rilascio, e la prima cosa da fare è escludere il proprio lavoro prima di guardare altrove. Il tempo per farlo era poco, perché su quel report si decideva la ripartizione del budget ogni lunedì.
Il risultato: sessioni correttamente assegnate raddoppiate dopo la correzione, e circa 30.000 sessioni nel solo raggruppamento social riportate nel canale giusto.
Qui sotto c’è come abbiamo escluso il nostro rilascio in dieci minuti, cosa c’era davvero, e la seconda cosa che è emersa una volta sistemata la prima.
Cosa contiene questo caso
- come escludere il proprio rilascio quando un report smette di tornare subito dopo
- come capire se un report personalizzato sta misurando o sta filtrando
- come distinguere un aumento di dati non attribuiti che è un guasto da uno che è un recupero
- come impedire che una modifica al tema sparisca senza lasciare traccia
Indice
- Il cliente e il punto di partenza
- Diagnosi del raggruppamento canali
- Il traffico senza sorgente e il ponte del consenso
- Nota di metodo sui numeri
- Cosa non ha funzionato
- Cosa faremmo adesso
- Conclusione
Il cliente e il punto di partenza
Negozio su Shopify con volumi di traffico nell’ordine delle centinaia di migliaia di sessioni per periodo di analisi, spesa costante su ricerca e social, e un team marketing interno che usa un raggruppamento canali personalizzato come report di riferimento.
Il raggruppamento canali è la regola che decide in quale canale finisce ogni visita, in base al nome della campagna e alla sorgente. Quello predefinito lo fornisce la piattaforma. Quello personalizzato lo scrive l’azienda, e serve a rispecchiare la propria struttura di campagne invece di quella standard.
Lo stato iniziale, con la fonte di ciascun dato:
| Dato | Valore | Fonte |
|---|---|---|
| Sessioni nel raggruppamento predefinito | ~540.000 | GA4 |
| Sessioni nel raggruppamento personalizzato | ~12.000 | GA4, stesso periodo |
| Data creazione del raggruppamento personalizzato | 27 maggio 2026 | GA4, cronologia |
| Data del nostro rilascio server-side | 9 giugno 2026 | registro rilasci interno |
Diagnosi: un operatore che filtra invece di classificare
IN SINTESI
Cosa abbiamo fatto: confrontato il raggruppamento personalizzato con quello predefinito sullo stesso periodo, poi letto le condizioni una per una.
Perché: due report sulla stessa proprietà e sullo stesso periodo che danno numeri diversi hanno una regola diversa, non un dato diverso.
Cosa abbiamo trovato: tutte le condizioni usavano corrispondenza esatta invece che parziale, e la piattaforma distingue maiuscole da minuscole.
Il numero della sezione: sessioni assegnate raddoppiate dopo la sostituzione dell’operatore.
La prima verifica è stata sulle date, ed è durata dieci minuti.
Il raggruppamento personalizzato era stato creato il 27 maggio. Il nostro rilascio era del 9 giugno. Il problema esisteva da due settimane prima che arrivassimo, e nessuno lo aveva visto perché nessuno aveva mai messo i due report uno accanto all’altro.
Escluso il rilascio, siamo andati a leggere le condizioni. Ogni regola usava l’operatore di corrispondenza esatta, che assegna la sessione al canale solo se il nome della campagna è identico carattere per carattere alla stringa scritta nella regola.
Le campagne reali non si chiamano come le regole. La condizione cercava una parola singola, la campagna aveva un nome composto con prefisso e suffisso. Nessuna corrispondenza, quindi nessuna assegnazione, quindi tutto nel raggruppamento residuo.
A questo si sommava la distinzione fra maiuscole e minuscole. Anche dove il nome era concettualmente corretto, una lettera diversa faceva cadere la sessione nello stesso raggruppamento residuo.
La correzione è stata sostituire la corrispondenza esatta con quella parziale su tutte le condizioni. Nessuna riga di codice, nessun rilascio, solo configurazione dentro l’interfaccia della piattaforma.
Le sessioni correttamente assegnate sono raddoppiate. Le campagne di ricerca a pagamento e quelle di shopping sono ricomparse nel report da cui erano sparite. Nel solo raggruppamento social c’erano circa 30.000 sessioni classificate male.
Una precisazione che conta per non far dire al caso più di quello che dice. Il team non era cieco sul traffico complessivo, perché il report predefinito ha sempre funzionato e ha sempre mostrato tutte e 540.000 le sessioni. Era cieco dentro il report costruito su misura, cioè quello usato per decidere.
Cosa ha funzionato
Aver controllato le date di creazione prima delle condizioni. È il controllo più veloce e ha escluso l’ipotesi più costosa, cioè che avessimo rotto qualcosa noi, prima di spendere tempo sul resto.
Il traffico senza sorgente e il ponte del consenso
IN SINTESI
Cosa abbiamo fatto: analizzato la quota di sessioni prive di sorgente e separato le due cause che la componevano.
Perché: un numero che peggiora dopo un rilascio può essere un guasto oppure l’effetto di un recupero, e le due cose richiedono azioni opposte.
Cosa abbiamo trovato: una parte era traffico recuperato dal server-side, l’altra era il ponte del consenso sparito dal tema.
Il numero della sezione: 17% delle sessioni senza sorgente e senza mezzo.
Sistemato il raggruppamento è emerso un secondo problema, più difficile del primo perché aveva due cause sovrapposte con segno opposto.
Il 17% delle sessioni arrivava senza sorgente e senza mezzo. Nessun canale, nessuna campagna.
Una parte di quel 17% era il recupero che funzionava. Il tracciamento server-side aveva iniziato a intercettare traffico che prima si perdeva del tutto. Visite che non comparivano affatto e che adesso comparivano, ma senza etichetta di provenienza, perché l’informazione si perde a monte. È un numero che peggiora perché il sistema ha cominciato a vedere di più.
L’altra parte era un guasto, e lo abbiamo isolato in un giorno. Il ponte fra il banner del consenso e il tag manager, cioè il pezzo di codice che comunica al tracciamento cosa ha scelto l’utente, era sparito dal tema.
La causa: alcune porzioni di codice erano state commentate modificando il tema dall’editor della piattaforma invece che dal sistema di versionamento. Senza versionamento non resta traccia di chi ha toccato cosa e quando. Il ponte è ricomparso dopo un aggiornamento banale sul tema, e da lì il consenso è tornato a essere trasmesso correttamente.
Cosa ha funzionato
Aver separato le due cause invece di trattare il 17% come un unico problema. Le azioni erano opposte: su una parte non c’era niente da fare perché il sistema stava lavorando bene, sull’altra c’era un ripristino urgente.
Nota di metodo sui numeri
Fonte di verità dichiarata: il raggruppamento canali predefinito di GA4. Non perché sia più accurato in assoluto, ma perché è l’unico dei due che non dipende da regole scritte dall’azienda, e serviva un termine di paragone indipendente dal report sotto esame.
| Numero pubblicato | Fonte | Finestra | Modello |
|---|---|---|---|
| ~540.000 sessioni | GA4, raggruppamento predefinito | periodo di analisi giugno 2026 | sessioni, definizione standard piattaforma |
| ~12.000 sessioni | GA4, raggruppamento personalizzato | stessa finestra, stessa proprietà | sessioni, regole personalizzate del cliente |
| ~30.000 sessioni social | GA4 | stessa finestra | sessioni nel raggruppamento social, prima della correzione |
| 17% senza sorgente | GA4 | stessa finestra | quota su sessioni con sorgente e mezzo |
La distanza fra i due raggruppamenti era del 97,8% sulla stessa proprietà e nello stesso periodo. È il numero che ha aperto il lavoro, ed è anche il tipo di scarto che non ha mai una spiegazione statistica.
Cosa non siamo in grado di misurare, e con che grado di certezza.
Il raddoppio delle sessioni assegnate dopo la correzione è verificato con osservazione diretta sul report, ma la coppia di valori assoluti prima e dopo proviene da due letture su finestre che non abbiamo riconciliato. Per questo pubblichiamo il rapporto e non le due cifre. È una scelta deliberata: due numeri assoluti su basi diverse messi in relazione sono esattamente il difetto che questo tipo di lavoro serve a trovare, e non lo commettiamo su un nostro caso.
La ripartizione del 17% fra recupero e guasto è stimabile con confidenza bassa. Sappiamo che entrambe le cause erano presenti, la prima per costruzione del server-side e la seconda per riscontro diretto sul tema. Non abbiamo misurato quanto pesa ciascuna, e servirebbe un confronto con il periodo precedente al rilascio sulle stesse definizioni.
Cosa non ha funzionato
Abbiamo rilasciato senza confrontare i due raggruppamenti. Il collaudo del rilascio server-side ha verificato eventi, deduplica e valori, ma non ha incluso un confronto fra il report personalizzato del cliente e quello predefinito. Se lo avessimo fatto, avremmo trovato il difetto due settimane prima, e per due settimane il sospetto è caduto sul nostro lavoro. Cosa abbiamo fatto invece: il collaudo adesso include il confronto fra ogni report personalizzato in uso dal cliente e il corrispondente predefinito, prima della consegna.
Abbiamo pubblicato internamente una coppia di valori assoluti sul recupero senza verificarne la base. In una nota di lavoro il risultato della correzione era riportato come passaggio fra due cifre precise, prese però da letture su finestre diverse. La coppia è stata ritirata e sostituita dal rapporto. Cosa abbiamo fatto invece: ogni coppia di numeri messa in relazione porta adesso scritta accanto finestra e perimetro, e se non coincidono si pubblica un valore solo o il rapporto.
Cosa faremmo adesso
Riconciliare la coppia di valori assoluti sul recupero. Serve una lettura unica su una finestra dichiarata, e restituirebbe al caso il suo numero più concreto.
Misurare la ripartizione del 17% fra recupero e guasto. Con un confronto sul periodo precedente al rilascio, usando le stesse definizioni di canale.
Portare il controllo sui report personalizzati dentro il monitoraggio continuo. Oggi è un passaggio di collaudo. Un confronto automatico fra personalizzato e predefinito segnalerebbe la divergenza il giorno in cui nasce invece che due settimane dopo.
Estendere la regola sul versionamento del tema a tutte le app installate. Il ponte del consenso è sparito da una modifica manuale. Lo stesso può accadere a qualunque altro frammento inserito da pannello.
Conclusione
Il report su cui si decideva la ripartizione del budget mostrava 12.000 sessioni contro le 540.000 del report predefinito, sulla stessa proprietà e nello stesso periodo. Dopo la correzione le sessioni assegnate sono raddoppiate.
Quello che questo lavoro lascia, ripreso dai quattro punti iniziali.
Come escludere il proprio rilascio: si confrontano le date di creazione prima delle condizioni. È il controllo più veloce e chiude l’ipotesi più costosa.
Come capire se un report personalizzato misura o filtra: lo si mette accanto al predefinito sullo stesso periodo. Se i due divergono in modo grande, la differenza sta nelle regole e non nei dati.
Come distinguere un guasto da un recupero: si guarda cosa è cambiato nel sistema poco prima. Un aumento di dati senza etichetta subito dopo un intervento che amplia la raccolta ha almeno una causa positiva.
Come impedire che una modifica sparisca senza traccia: le modifiche al tema passano dal versionamento e non dall’editor di pannello, così resta scritto chi ha toccato cosa.
Quando questo lavoro ha senso, e quando no
Ha senso se usi un raggruppamento canali personalizzato per decidere dove spostare il budget, e se hai più di un report che risponde alla stessa domanda con numeri diversi.
Non ha senso se il tuo volume di traffico è tale che la classificazione per canale non cambia nessuna decisione di spesa. E non ha senso aspettarsi che la correzione porti più traffico, perché il traffico c’era già: cambia solo dove viene contato.
Il primo passo è aprire il tuo raggruppamento personalizzato e quello predefinito sullo stesso periodo e confrontare il totale sessioni. Se la differenza supera qualche punto percentuale, sono le regole a non funzionare.