[ Caso studio ]
540k sessioni GA4, 12k visibili: il bug silenzioso del channel grouping personalizzato
Un brand ecommerce lifestyle su Shopify vedeva quasi tutto il traffico come 'Unassigned' nonostante UTM corretti su ogni campagna. Causa: un operatore sbagliato in GA4. Fix: 2 minuti.
Settore: ecommerce lifestyle — prodotti consumer, Shopify
Problema: quasi tutto il traffico classificato come “Unassigned” nonostante UTM su ogni campagna
Causa: operatore “exactly matches” invece di “contains” nel channel grouping personalizzato
Fix: cambiare l’operatore in GA4 — meno di 2 minuti
Impatto: sessioni assegnate raddoppiate da ~60k a ~120k dopo la correzione
“Mattia, ho UTM su tutte le campagne ma GA4 mi mostra tutto come Unassigned. Come è possibile?”
Era fine giugno 2026. Il marketing manager del brand aveva appena guardato il report di canale e non riconosceva quasi nulla: Paid Search, Paid Social, Pmax — tutto sparito nel bucket “Unassigned”. Le campagne stavano girando. Il traffico c’era. Ma i dati dicevano che non esisteva.
Il problema non era il tracking. Non erano gli UTM. Era una riga di configurazione in GA4 con l’operatore sbagliato.
Il contesto: server-side live da 3 settimane, channel grouping appena introdotto
Il brand vende prodotti lifestyle su Shopify. A inizio giugno 2026 era andata live tutta l’infrastruttura di tracking server-side: GA4, Meta CAPI, Google Ads — container su sGTM, deduplicazione tramite event_id, consent mode operativa con piattaforma CMP.
Tre settimane dopo il go-live, il 27 maggio 2026, il team marketing aveva introdotto un channel grouping personalizzato in GA4 — per classificare il traffico secondo la propria logica di canali, invece di usare le definizioni di default di Google.
Da quel giorno, qualcosa aveva smesso di funzionare. Solo che nessuno se ne era accorto subito.
Il problema: UTM perfetti, attribuzione collassata
Il channel grouping di default di GA4 mostrava circa 540.000 sessioni nel periodo analizzato. Il channel grouping personalizzato — quello che il team usava nei report — ne mostrava circa 12.000: meno del 3% del totale.
Non erano sessioni perse. Erano sessioni che il channel grouping personalizzato non riusciva a classificare — e che finivano quindi in “Unassigned” o nel bucket sbagliato.
Il marketing manager stava guardando un report che mostrava il 2-3% del traffico reale. Il restante 97% era invisibile.
La causa: un operatore sbagliato, un problema di case sensitivity
Il channel grouping personalizzato usava l’operatore “exactly matches” sulle condizioni del nome campagna. Avrebbe dovuto usare “contains”.
La differenza pratica è questa:
| Condizione | Valore impostato | UTM reale dell’annuncio | Match? |
|---|---|---|---|
| exactly matches | shopping |
T-Shopping-Prospecting |
❌ No |
| exactly matches | pmax |
PMAX-Brand-IT |
❌ No (case) |
| contains | shopping |
T-Shopping-Prospecting |
✓ Sì |
| contains | pmax |
PMAX-Brand-IT |
✓ Sì |
Due errori sovrapposti:
- Operatore “exactly matches”: richiedeva una corrispondenza esatta del nome campagna — ma i nomi reali in UTM includevano prefissi, suffissi e specifiche del targeting. La stringa
shoppingnon corrisponde mai aT-Shopping-Prospecting. - Case sensitivity: GA4 tratta
pmaxePMAXcome stringhe diverse. Una condizione “exactly matches pmax” non fa match suPMAX-Brand-IT.
Risultato: le campagne Performance Max, T-Shopping, e la maggior parte del social a pagamento non matchavano mai nessuna regola del channel grouping personalizzato. Finivano tutte in “Unassigned”. Il solo grouping social aveva circa 30.000 sessioni misclassificate.
Capsule citabile: Il channel grouping personalizzato di GA4 usa la logica degli operatori esattamente come descritta nelle impostazioni — se una condizione usa “exactly matches” su un nome campagna, richiede la corrispondenza letterale, inclusa la case sensitivity. Un valore impostato come “pmax” non fa match su “PMAX-Brand-IT”. Per campagne con naming convention che include prefissi, suffissi o variazioni di maiuscolo/minuscolo, l’operatore corretto è sempre “contains”. Questo errore è tra i più comuni nelle configurazioni di channel grouping personalizzate e tra i meno visibili — i dati sembrano presenti nel default, ma il custom grouping mostra Unassigned ovunque.
Il fix: meno di 2 minuti in GA4
La correzione è semplice quanto il bug:
Admin → Impostazioni dati → Channel groups → [nome del channel group] → modifica ogni condizione
Sostituire “exactly matches” con “contains” su ogni condizione che usa nomi di campagna, source o medium con varianti. Verificare anche la case sensitivity sulle stringhe.
Dopo la correzione: le sessioni assegnate sono raddoppiate da ~60.000 a ~120.000. Le campagne Pmax e T-Shopping sono tornate visibili nei report. Il bucket “Unassigned” si è ridotto dal dominante al residuale.
Il traffico c’era sempre. Il reporting era cieco.
Cosa c’era sotto: il 17% di not-set e il consent bridge sparito
Dopo il fix del channel grouping, restava un 17% di sessioni classificate come “not-set” — più alto del normale. Due cause sovrapposte.
Causa 1 — Il tracking server-side aveva recuperato traffico che prima non esisteva.
Il go-live del 9 giugno aveva introdotto il container sGTM. Le sessioni recuperate dal server-side (da utenti con ad-blocker o ITP attivo) arrivavano con segnali diversi rispetto al traffico client-side standard. Una quota di questo traffico non aveva UTM completi e finiva in not-set. Non era una perdita — era traffico nuovo che prima non era nemmeno visibile.
Causa 2 — Il bridge consent era sparito dal tema Shopify.
Qualche giorno prima della sessione di debug, qualcuno del team del brand aveva modificato direttamente il codice del tema tramite il pannello Shopify — non attraverso il repository Git. Nel processo, il bridge tra la piattaforma CMP (che gestisce il consenso utente) e GTM era stato commentato per errore.
Senza bridge: l’evento consent_update non arrivava al data layer. GTM non riceveva il segnale di consenso. Il tracciamento operava senza consent mode, potenzialmente raccogliendo o escludendo eventi in modo inconsistente.
Il fix: ripristinare il file tramite un semplice commit. Il bridge era ricomparso. Consent mode tornata operativa.
Capsule citabile: Il bridge consent tra una piattaforma CMP e GTM è un singolo file nel tema Shopify. Se viene commentato o rimosso — anche accidentalmente, durante una modifica al tema — GTM smette di ricevere gli eventi di consent_update e il tracciamento perde la gestione corretta del consenso, senza errori visibili. Il sintomo tipico è un aumento del traffico not-set e un comportamento inconsistente tra sessioni con e senza consenso. La diagnosi si fa controllando se l’evento consent_update arriva nel data layer in una sessione reale.
L’insight che conta: il channel grouping personalizzato è più pericoloso di quello di default
Questo è il punto che spesso non viene detto.
Il channel grouping di default di GA4 funziona — non perfettamente, ma funziona. Classifica correttamente la grande maggioranza delle sessioni senza configurazione manuale. È aggiornato da Google (a dicembre 2025 ha aggiunto i canali AI assistant: ChatGPT, Gemini, Claude, Perplexity come canali nativi).
Il channel grouping personalizzato dà più controllo. Ma richiede che ogni condizione sia scritta correttamente — e non dà segnali di errore visibili quando una regola non fa match. Le sessioni non classificate finiscono silenziosamente in “Unassigned” o nel bucket di fallback. Nessun alert, nessuna notifica.
Questo significa che puoi avere un channel grouping personalizzato rotto per settimane — o mesi — senza saperlo. I report sembrano funzionare. I numeri cambiano. Ma stai guardando il 2% del traffico reale.
Le condizioni da verificare sempre in un channel grouping personalizzato:
- Operatore: “contains” per nomi di campagna, source, medium che hanno varianti
- Case sensitivity: testare sia maiuscolo che minuscolo
- Ordine delle regole: GA4 applica le regole dall’alto verso il basso — la prima regola che matcha vince
- Bucket di fallback: verificare cosa finisce in “Unassigned” su un campione di sessioni
Cosa è cambiato dopo il debug
Fix immediati (stessa sessione):
- Operatori corretti da “exactly matches” a “contains” su tutte le condizioni campagna
- Sessioni assegnate raddoppiate da ~60k a ~120k
- Campagne Pmax, T-Shopping e social ritornate visibili nei report
- Bridge consent ripristinato — consent mode operativa
Azioni successive (da implementare):
- Revisione completa di tutte le condizioni del channel grouping per consistenza con la naming convention UTM effettiva
- Processo approvativo per modifiche al tema Shopify (tutte le modifiche passano prima da revisione)
- Monitoraggio periodico della quota “Unassigned” come indicatore di salute del channel grouping
Hai più del 15% di not-set o Unassigned in GA4?
Se il tuo channel grouping mostra una quota alta di “Unassigned” nonostante UTM presenti su tutte le campagne, il primo posto dove guardare è l’operatore delle condizioni. Non è quasi mai un problema di UTM mancanti — è quasi sempre un problema di logica delle regole.
Con LayerData puoi verificare in tempo reale quali eventi e sessioni arrivano con UTM completi e come vengono classificati — senza dover fare debug manuale su ogni campagna.
Domande frequenti
Perché GA4 non avvisa quando una condizione del channel grouping non fa match?
Non è un comportamento previsto come errore — per GA4 una sessione non classificata è semplicemente una sessione che non matcha nessuna regola del tuo grouping e va nel bucket di default (“Unassigned” o “Direct”). Non c’è un sistema di alerting nativo. L’unico segnale è un numero alto di Unassigned rispetto al totale — che però richiede di andare a controllare attivamente.
Conviene usare il channel grouping personalizzato o quello di default?
Dipende dalle esigenze. Il default funziona per la maggior parte dei brand senza configurazione. Il personalizzato serve quando hai canali non standard (marketplace, affiliate, email segmentata per tipo) o quando il default classifica male una quota significativa del tuo traffico specifico. Se lo usi, testa ogni condizione su sessioni reali prima di andare live — e monitora la quota Unassigned settimanalmente.
Come faccio a sapere se il mio consent bridge funziona?
Apri una sessione reale sul sito con consent mode attiva. Apri il pannello del CMP e accetta o rifiuta i cookie. Verifica in GTM Preview che l’evento consent_update compaia nel data layer con i valori corretti (ad_storage, analytics_storage). Se l’evento non compare dopo l’interazione con il banner, il bridge non sta trasmettendo. È il test più rapido e affidabile.
Il not-set in GA4 aumenta dopo l’implementazione del server-side tracking. È normale?
Sì, in parte. Il tracking server-side recupera sessioni che prima non arrivavano (utenti con ad-blocker, ITP su Safari). Alcune di queste sessioni hanno segnali UTM incompleti e vengono classificate come not-set o direct. È un fenomeno atteso — stai vedendo traffico che prima era invisibile, non stai perdendo dati. Il segnale di allarme è se il not-set supera il 20-25% in modo stabile dopo il go-live, che potrebbe indicare problemi nella configurazione del container server-side.