Guardare l’attribuzione in Google Analytics 4 dà spesso una sensazione di ordine: i canali compaiono nei report, le conversioni vengono distribuite secondo una logica leggibile e il quadro sembra abbastanza stabile da poter essere commentato quasi direttamente. È proprio in questo passaggio che si annida una semplificazione pericolosa, perché la lettura dell’attribuzione tende a sembrare più oggettiva di quanto sia davvero.
Quando lo stesso tema viene affrontato partendo dall’export di GA4 verso BigQuery, il margine di interpretazione emerge molto più chiaramente e costringe a fare i conti con una realtà meno comoda: l’attribuzione non coincide con un report già pronto, ma con un insieme di regole che dipendono da come il dato è stato raccolto, da come vengono trattate le sorgenti e dal livello al quale scegli di leggere il percorso che porta alla conversione.
Questo passaggio conta molto, perché basta cambiare il modo in cui normalizzi source, medium e campaign, il criterio con cui ricostruisci la continuità della sorgente o lo scope che usi per leggere la conversione, e la valutazione della performance può spostarsi in modo tutt’altro che marginale. A quel punto il problema non è tanto recuperare più dati, quanto decidere con sufficiente chiarezza come interpretarli.
È anche il motivo per cui, lavorando su GA4 e BigQuery, ha poco senso pensare all’attribuzione come a una risposta da estrarre e molto più senso trattarla come una scelta metodologica: una scelta che deve restare coerente con il tracking disponibile, con la qualità delle informazioni raccolte e con il tipo di decisione che quei numeri dovranno sostenere.
Prima di costruire il modello, bisogna capire come viene raccolto il dato
Quando l’attribuzione viene analizzata a partire dall’export di GA4 verso BigQuery, la prima verifica riguarda il modo in cui le informazioni di sorgente entrano nei dati e si conservano lungo il percorso. BigQuery offre più controllo e più libertà di lettura, però lavora comunque su ciò che il tracking ha raccolto: se UTM, parametri di campagna, passaggi tra domini, naming delle sorgenti o valorizzazione degli eventi arrivano in modo incoerente, quella incoerenza resta presente anche fuori dall’interfaccia di GA4 e dentro i dati raccolti in BigQuery.
Questo passaggio conta perché molte differenze che emergono in fase di analisi non nascono dalla query in sé, ma da come il dato si è formato prima ancora di essere interrogato. Google chiarisce che le traffic-source dimensions sono alla base della lettura di attribuzione e acquisizione, mentre la documentazione su manual tagging e auto-tagging mostra bene quanto il modo in cui source, medium e campaign vengono popolati, condizioni la classificazione finale.
Nel passaggio verso BigQuery questa dipendenza diventa più visibile, anche perché l’analisi si appoggia a strutture tecniche precise, descritte nella documentazione ufficiale sugli schemi di export di GA4 verso BigQuery, dove Google distingue chiaramente tra dati evento, dati utente e campi collegati alla sorgente del traffico.
In termini pratici, questo significa che una campagna taggata in modo non uniforme, una sessione in cui la sorgente si interrompe, oppure un evento che non conserva bene le informazioni di contesto, possono spostare la lettura dell’attribuzione molto prima che entri in gioco il modello scelto. Per questo conviene trattare la tenuta del dato come una condizione preliminare dell’analisi: non serve darle il centro, serve riconoscere che il modello si appoggia sempre su un dato che arriva da monte con una sua storia, una sua coerenza e, a volte, con le sue fratture.
In BigQuery l’attribuzione si costruisce attraverso regole esplicite
Lavorare sull’export di GA4 porta l’attribuzione fuori da una lettura già confezionata e la riporta dentro un terreno in cui le regole contano in modo molto più evidente.
Il punto, a questo livello, non è ricostruire con più righe e più in dettaglio quello che l’interfaccia di GA4 mostra già, ma decidere come trattare source, medium, campaign, sessioni, continuità della sorgente e casi incompleti, sapendo che ognuna di queste scelte può modificare il modo in cui una conversione viene letta.
È qui che l’analisi cambia natura, perché non stai più semplicemente consultando un report ma stai definendo la logica con cui quel report, fuori dall’interfaccia, prende forma. Se due query applicano criteri diversi nel normalizzare le sorgenti, nel collegare una conversione all’ultima sessione valorizzata oppure nel gestire i passaggi in cui l’informazione di campagna si interrompe, la lettura finale della performance può cambiare anche in modo sensibile, pur partendo dallo stesso dataset.
Standardizzare source, medium e campaign non è una rifinitura
Quando lavori sull’attribuzione in BigQuery, source, medium e campaign non possono essere lasciati nella forma in cui compaiono “grezzi” nei dati, perché basta una minima variazione di naming per frammentare campagne che in realtà appartengono allo stesso canale, oppure per tenere insieme sotto la stessa etichetta sorgenti che andrebbero distinte.
In questa parte di analisi e messa a terra, la questione non è capire come il dato sia stato raccolto, ma decidere come renderlo confrontabile. Se questa standardizzazione non viene fatta con una logica chiara, l’analisi inizia a spostarsi su un terreno ambiguo: una campagna può apparire distribuita su più righe che sembrano realtà diverse, un canale può crescere o ridursi solo per effetto di una classificazione incoerente e il confronto tra periodi o tra sorgenti perde stabilità proprio nel momento in cui dovrebbe aiutare a prendere decisioni.
Per questo la normalizzazione di source, medium e campaign non va trattata come una rifinitura finale, ma come una parte della costruzione del modello, perché è in questo passaggio che il dato smette di essere solo raccolto e comincia davvero a diventare leggibile.
La continuità della sorgente non va data per scontata
Una volta resi confrontabili source, medium e campaign, resta un altro problema che incide direttamente sull’attribuzione: capire come leggere la continuità della sorgente lungo il percorso che porta alla conversione. Nei dati esportati questa continuità non si presenta quasi mai in una forma già pronta, perché può interrompersi, perdere definizione o riapparire in modo parziale tra una visita e l’altra.
È proprio in questo punto che il modello inizia a pesare davvero, perché devi decidere come trattare i passaggi in cui la sorgente iniziale non è più immediatamente leggibile, quanto valore assegnare all’ultima sessione valorizzata in modo completo e con quale criterio collegare la conversione a ciò che l’ha preceduta. Se queste regole non vengono chiarite, la lettura finale rischia di cambiare non solo tra un’analisi e l’altra, ma anche tra persone diverse che lavorano sullo stesso export.
Il tema, quindi, non è soltanto recuperare una sorgente precedente quando manca quella immediata, ma stabilire una logica coerente con cui leggere il percorso. È in questo passaggio che l’attribuzione smette di sembrare una semplice distribuzione del merito e comincia a mostrare il suo lato più delicato, cioè il fatto che la relazione tra touchpoint e conversione dipende sempre dal modo in cui decidi di ricostruirla.
Event level, session level e user level non rispondono alla stessa domanda
Una parte importante delle differenze che emergono quando si lavora sull’attribuzione in BigQuery dipende dal livello a cui scegli di leggere il dato, perché evento, sessione e utente non sono tre modi equivalenti di osservare la stessa realtà, ma tre prospettive che mettono a fuoco aspetti diversi del percorso e quindi possono portare a valutazioni diverse della performance.
Questo passaggio ha un peso concreto già nelle analisi più comuni. Se osservi la conversione a livello evento, stai guardando il contesto più vicino all’azione che ti interessa attribuire e quindi il rapporto tra quella conversione e l’informazione di sorgente disponibile in quel punto preciso del percorso. Se invece lavori a livello sessione, la lettura si sposta su un’unità più ampia, dentro la quale conta la continuità della visita e il modo in cui quell’ingresso si sviluppa fino a produrre un esito. Il livello utente apre ancora un’altra prospettiva, perché permette di leggere la relazione tra acquisizione iniziale, ritorni successivi e conversioni distribuite nel tempo.
La differenza, quindi, non riguarda un livello più corretto e uno meno corretto, ma il tipo di domanda che stai facendo al dato. Quando questa distinzione non viene chiarita, il rischio è usare uno scope per rispondere a una domanda che ne richiederebbe un altro, e da lì iniziano a comparire letture della performance che sembrano incoerenti anche se, in realtà, stanno semplicemente osservando il percorso da un punto di vista diverso.
Il livello sessione aiuta quando vuoi capire come si forma una visita che converte
Il livello sessione è spesso il più utile quando l’obiettivo è leggere il contributo di canali e campagne nella costruzione di una visita che porta a un risultato, perché consente di mantenere insieme l’ingresso, gli eventuali passaggi intermedi e la conversione finale dentro una logica più stabile. In questo tipo di analisi interessa meno l’ultimo dettaglio immediatamente precedente all’evento e molto di più il fatto che una certa sessione, partita da una determinata sorgente, abbia espresso o meno una capacità concreta di portare valore.
Questa prospettiva diventa particolarmente utile quando devi confrontare canali di acquisizione, valutare la qualità del traffico generato da campagne diverse o capire quali ingressi tendano a costruire sessioni che arrivano più spesso a una conversione. In tutti questi casi, il livello sessione offre una lettura più coerente con la domanda di business, perché evita di comprimere tutto sull’ultimo punto osservabile e restituisce un quadro più vicino al modo in cui una visita prende forma.
Il livello evento è più utile quando vuoi leggere il passaggio immediatamente vicino alla conversione
Il livello evento diventa più adatto quando l’analisi richiede una granularità maggiore e quando il focus si sposta sul rapporto tra una specifica azione e il contesto in cui quella azione si verifica. Qui il tema non è più capire quale sessione abbia generato valore nel suo insieme, ma osservare con maggiore precisione quale informazione di sorgente, quale passaggio o quale combinazione di segnali accompagni un evento rilevante.
Questa lettura può essere utile, per esempio, quando vuoi capire se la sorgente si conserva davvero fino ai momenti decisivi del percorso, quando devi individuare dove si interrompe la continuità dell’informazione o quando ti interessa distinguere il contributo di interazioni diverse che avvengono dentro la stessa visita. Proprio per questo il livello evento tende a essere più sensibile alle scelte di modellazione e alla qualità del tracciamento, perché basta poco per spostare il significato attribuito a ciò che osservi.
Il livello utente serve quando la domanda riguarda il rapporto tra acquisizione e conversione nel tempo
Il livello utente entra in gioco quando il problema non riguarda solo la sessione o l’evento che chiude il percorso, ma il legame tra il primo ingresso, i ritorni successivi e il modo in cui una persona arriva a convertire nel corso del tempo. In questo caso la lettura cambia ancora, perché il focus si allontana dal singolo touchpoint e si sposta sulla storia complessiva dell’acquisizione.
Questa prospettiva è utile soprattutto quando vuoi capire quali canali tendano a portare utenti che convertono più tardi, quali sorgenti aprano percorsi che maturano nel tempo e quanto la valutazione di una campagna cambi se la osservi non come generatrice di una singola sessione ma come punto di partenza di una relazione più lunga. Anche qui, però, il vantaggio analitico esiste solo se è chiaro che la domanda è cambiata, perché usare il livello utente per leggere ciò che andrebbe valutato a livello sessione, o viceversa, porta a conclusioni che sembrano discordanti ma nascono semplicemente da una prospettiva non dichiarata.
Il traffico direct merita una lettura prudente
Il direct è uno dei punti in cui l’attribuzione tende a essere letta con troppa rapidità, perché la sua crescita viene facilmente associata a un rafforzamento del brand o a una maggiore capacità del traffico di tornare spontaneamente sul sito, mentre in molti casi quella variazione dipende anche da come la sorgente viene raccolta, classificata e ricostruita lungo il percorso. La documentazione ufficiale di Google su (direct) / (none) va letta proprio in questa chiave, dato che collega il direct al modo in cui le traffic-source dimensions vengono valorizzate e chiarisce che questa categoria non rappresenta sempre un comportamento immediatamente interpretabile senza contesto.
Quando l’analisi si sposta in BigQuery, questa cautela diventa ancora più necessaria, perché basta modificare il criterio con cui recuperi la sorgente precedente, il modo in cui colleghi sessioni e conversioni oppure la logica con cui tratti i casi incompleti, e la quota di direct può cambiare in misura sensibile pur lavorando sullo stesso export. In una situazione del genere, leggere il direct come se fosse una risposta trasparente rischia di far coincidere un effetto del modello con un comportamento reale dell’utente.
Il direct cresce spesso dove la continuità della sorgente si indebolisce
Una parte del traffico che finisce nel direct non nasce necessariamente da un accesso davvero privo di referrer o di parametri utili, ma da un percorso in cui l’informazione della sorgente si interrompe, si perde o non viene più ricostruita con sufficiente continuità. Questo può accadere per diversi motivi, alcuni legati al tracking e altri al modello con cui il dato viene letto, e il risultato è che il direct inizia ad assorbire casi che, da un punto di vista analitico, meriterebbero una classificazione più prudente o almeno una verifica più attenta.
Per questo il direct va trattato come un’area da interpretare, non come una categoria autosufficiente da commentare in modo immediato. Se cresce dopo un cambio nella logica di query, nella gestione delle sessioni o nella normalizzazione delle sorgenti, la domanda utile non riguarda tanto il valore assoluto del direct quanto il motivo per cui quella logica lo stia facendo crescere.
Una lettura frettolosa del direct può spostare la valutazione dei canali
Questo passaggio ha un impatto diretto sulla lettura della performance, perché se una quota crescente di conversioni viene spostata verso il direct, il contributo dei canali che hanno generato la domanda o accompagnato il percorso tende a ridursi, a volte in modo solo apparente. Il problema, quindi, non riguarda solo l’etichetta finale assegnata alla conversione, ma la redistribuzione del merito tra sorgenti che fino a poco prima stavano sostenendo una parte diversa del percorso.
È qui che il direct smette di essere un dettaglio tecnico e diventa un punto critico dell’interpretazione, soprattutto quando l’analisi serve a discutere budget, priorità di investimento o confronto tra canali. Se la logica con cui viene valorizzato non è abbastanza chiara, il rischio è attribuire forza a ciò che sta semplicemente raccogliendo credito residuo e indebolire canali che stanno ancora svolgendo una funzione reale nel percorso di conversione.
Lo stesso dataset può produrre letture diverse della stessa campagna
Uno degli aspetti più delicati dell’attribuzione ricostruita in BigQuery è che differenze anche piccole nelle regole di lettura possono portare a valutazioni diverse della stessa campagna, pur partendo dallo stesso export. Questo è il punto in cui molte discussioni tra marketing, analytics e data team diventano poco produttive, perché il confronto si concentra sui numeri finali mentre resta sullo sfondo la cosa che li ha generati davvero, cioè il criterio con cui quei numeri sono stati costruiti.
Se una query normalizza in un certo modo source e medium, un’altra gestisce diversamente la continuità della sorgente e una terza attribuisce più peso all’ultima sessione valorizzata, la campagna che stai osservando può cambiare posizione nel confronto con gli altri canali senza che il dataset sia cambiato. Cambia la lettura, e questa differenza basta già a spostare il modo in cui viene giudicata la sua performance.
Le differenze non nascono sempre dai dati, ma da come vengono ricomposti
Quando due analisi arrivano a conclusioni diverse, la tentazione è pensare che una delle due abbia letto male i numeri oppure che il dataset presenti errori. In molti casi, però, il punto critico sta più a monte e riguarda il modo in cui gli stessi dati sono stati ricomposti dentro una logica di attribuzione non del tutto coincidente.
Questa distinzione è importante perché aiuta a leggere il problema nel modo corretto: non si tratta sempre di stabilire quale query sia giusta e quale sia sbagliata, ma di capire quale domanda stia davvero affrontando ciascuna analisi e con quali regole stia assegnando il merito alle sorgenti coinvolte. Quando questo chiarimento manca, il rischio è usare confronti solo apparentemente omogenei per prendere decisioni che poi ricadono su budget, canali e aspettative di performance.
Una campagna può sembrare più forte o più debole a seconda del modello usato
Questo effetto si vede molto bene proprio sulle campagne, perché basta spostare il criterio con cui leggi sessioni, touchpoint e direct, e la distribuzione delle conversioni cambia in modo tale da modificare anche il peso attribuito al canale. Una campagna che in una lettura mantiene continuità con la sorgente iniziale può perdere parte del proprio contributo in un’altra lettura più aggressiva sul direct, oppure può risultare più frammentata se source, medium e campaign non vengono ricondotti dentro una classificazione coerente.
Quando succede, il problema non è solo analitico. La stessa campagna può apparire profittevole in una dashboard e molto meno convincente in un’altra, con il risultato che il confronto tra report smette di aiutare e comincia a generare attrito tra interpretazioni diverse. Per questo, prima di discutere se una campagna stia performando bene o male, conviene chiarire quale logica di attribuzione la stia raccontando.
Un esempio semplice per capire dove si sposta la lettura
Immagina una campagna paid social che porti traffico verso una landing ben tracciata, con una classificazione apparentemente ordinata delle campagne e con un volume di conversioni che, nei report di GA4, sembra coerente con il peso del canale. Una parte degli utenti, però, non converte nella prima visita, torna in un secondo momento attraverso un accesso meno leggibile dal punto di vista della sorgente e completa il percorso solo dopo quel rientro.
Nel report standard la campagna può continuare a sembrare abbastanza stabile, soprattutto se la lettura resta a un livello aggregato e non entra troppo nelle condizioni che hanno determinato la classificazione. In BigQuery, invece, quello stesso percorso ti costringe a prendere decisioni più esplicite: devi stabilire se la conversione conserva continuità con la sorgente iniziale, se viene associata all’ultima sessione valorizzata in modo completo, se scivola nel direct oppure se cambia peso a seconda dello scope con cui la stai leggendo.
La campagna resta la stessa, ma la sua lettura può cambiare
Questo esempio è utile perché mostra una cosa molto concreta: la campagna non cambia, il dataset di partenza non cambia e neppure il fatto che l’utente abbia effettivamente convertito; ciò che cambia è la logica con cui colleghi il punto di ingresso al momento in cui assegni il credito alla conversione.
Se la continuità della sorgente viene mantenuta in qualche modo, la campagna paid social conserva una parte più ampia del proprio contributo. Se quella continuità viene trattata in modo più restrittivo, oppure se i passaggi intermedi non vengono letti con sufficiente coerenza, una quota di merito può spostarsi verso altre sorgenti o finire in aree meno interpretabili, come accade spesso con il direct.
È in questo punto che il modello inizia a produrre conseguenze di business
La differenza, finché resta dentro una query, può sembrare solo metodologica. Il problema diventa molto più concreto quando quella stessa lettura viene usata per valutare canali, confrontare campagne o prendere decisioni di budget, perché una campagna che in una ricostruzione appare solida può diventare molto meno convincente in un’altra anche se i dati raccolti sono gli stessi.
Questo è il motivo per cui l’attribuzione, quando viene ricostruita in BigQuery, va trattata come una scelta da formalizzare e non come una semplice traduzione tecnica dei report dell’interfaccia. L’esempio che ho proposto, serve proprio a mostrare dove si sposta la lettura: non nei dati in sé, ma nel modo in cui il modello collega i passaggi del percorso e distribuisce il credito finale.
Lo stesso ragionamento vale anche fuori dall’attribuzione. Un caso tipico è quello dei nuovi utenti: in BigQuery può venire spontaneo filtrare first_visit e contare i user_pseudo_id, ma questa scorciatoia non coincide sempre con la definizione analitica che ti interessa davvero, perché anche in questo caso stai lavorando su una regola di lettura e non su una metrica che conserva automaticamente lo stesso significato del report. Anche qui il punto non è solo recuperare un dato, ma decidere quale logica lo renda coerente con la domanda che stai facendo.
Il modello utile è quello coerente con la decisione che devi prendere
A questo punto il tema centrale si vede con più chiarezza: in BigQuery non serve inseguire il modello più sofisticato in assoluto, ma costruire una logica di attribuzione che resti coerente con il tipo di dato disponibile, con il livello di analisi scelto e con le decisioni che quei numeri devono sostenere.
L’errore più comune, in questi casi, consiste nel dare per scontato che più complessità produca automaticamente una lettura migliore, mentre nella pratica una logica difficile da spiegare, instabile nel tempo o troppo sensibile a piccole variazioni di query rischia di creare più rumore che utilità.
Un modello diventa davvero utile quando permette di leggere le performance in modo abbastanza stabile da sostenere confronti, priorità e scelte operative senza cambiare significato ogni volta che cambia la mano di chi scrive la query o il contesto in cui i risultati vengono discussi. Questo vale ancora di più quando l’attribuzione non serve a una riflessione astratta sul percorso utente, ma entra in decisioni molto concrete come la redistribuzione del budget, il confronto tra canali, la valutazione della qualità del traffico o il peso assegnato a campagne che lavorano in fasi diverse del funnel.
La coerenza con il tracking disponibile viene prima dell’ambizione del modello
Un modello di attribuzione può essere elegante sulla carta, ma se poggia su un tracking che non conserva in modo abbastanza affidabile le informazioni di sorgente, la sua sofisticazione resta più teorica che reale. In questi casi il punto non è rinunciare all’analisi, ma calibrare il modello sulla qualità effettiva del dato disponibile, evitando di costruire una precisione apparente sopra informazioni che entrano in modo discontinuo o incompleto.
La coerenza con la domanda analitica evita letture fuori fuoco
Ogni modello porta con sé un certo modo di guardare il percorso, e per questo ha senso solo se resta allineato alla domanda da cui è partito. Se il problema è capire quali canali generino sessioni che convertono, la logica dovrà preservare quella continuità; se invece l’interesse riguarda il passaggio immediatamente vicino alla conversione, servirà una lettura diversa. Quando questa corrispondenza tra domanda e modello non viene esplicitata, il rischio non è soltanto tecnico: diventa facile usare una risposta formalmente corretta per una domanda che, in realtà, era un’altra.
La coerenza con la decisione di business è ciò che rende il modello davvero utile
L’attribuzione ha senso finché aiuta a decidere meglio, quindi il valore del modello non si misura solo dalla sua pulizia metodologica ma anche dalla sua capacità di sostenere decisioni comprensibili, difendibili e replicabili. Se una logica attribuisce merito in modo poco leggibile, se cambia troppo facilmente tra un’analisi e l’altra oppure se porta a conclusioni che il team non riesce a interpretare in modo condiviso, il problema non è soltanto nel reporting ma soprattutto nel fatto che quel modello sta perdendo aderenza al contesto in cui dovrebbe essere usato.
Per questo, quando si lavora sull’attribuzione in BigQuery, la domanda più utile non riguarda quale modello sia il più avanzato in astratto, ma quale modello resti abbastanza coerente da leggere il contributo dei canali senza deformarlo ogni volta che cambia la prospettiva. È in questo equilibrio che l’analisi smette di essere una ricostruzione elegante e diventa uno strumento che regge davvero quando entra nelle decisioni.
Conclusioni
Lavorare sull’attribuzione di GA4 dentro BigQuery obbliga a vedere con più chiarezza qualcosa che nell’interfaccia resta molto più nascosto: i numeri non arrivano mai da soli, ma prendono significato attraverso regole che riguardano il modo in cui il dato entra, il modo in cui le sorgenti vengono rese confrontabili e il livello a cui scegli di leggere il percorso di conversione.
È proprio per questo che la ricostruzione dell’attribuzione non coincide con una semplice esportazione più dettagliata dei report. Nel momento in cui source, medium, campaign, continuità della sorgente, direct e scope di lettura entrano nella query, entra anche una parte di modellazione che può spostare la valutazione di campagne e canali in misura tutt’altro che trascurabile.
Da qui nasce anche il punto centrale di questo articolo: lo stesso dataset può sostenere letture diverse, e questa possibilità non va trattata come un’anomalia da correggere in automatico, ma come un segnale del fatto che l’attribuzione richiede scelte esplicite, condivise e coerenti con la decisione che l’analisi deve supportare.
Quando questa coerenza manca, il rischio non si ferma al piano tecnico. Diventa facile sovrastimare ciò che raccoglie il credito più vicino alla conversione, sottostimare i canali che lavorano nella costruzione della domanda e discutere i numeri come se il problema fosse nel dato, quando in realtà sta nelle regole con cui quel dato viene letto.
Per questo, se lavori con GA4 e BigQuery, ha più senso investire tempo nella definizione del modello che inseguire una ricostruzione solo apparentemente neutra. Un’attribuzione utile è quella che resta leggibile, stabile e difendibile quando passa dalla query al report, dal report al confronto tra team e dal confronto tra team alle decisioni di budget.
Se hai un problema da risolvere, un sistema dati da rimettere in ordine o un progetto da impostare meglio, descrivimi il contesto e ti ricontatto per capire se e come posso esserti utile.
FAQ rapide
Non necessariamente. Quando lavori sull’export di GA4 verso BigQuery, la lettura dell’attribuzione dipende dalle regole con cui ricostruisci sorgenti, sessioni, continuità del percorso e criterio di assegnazione del credito. Per questo due analisi costruite sullo stesso dataset possono restituire risultati diversi, anche se entrambe sono formalmente corrette.
Il direct può crescere quando la sorgente non viene recuperata con continuità, quando alcuni passaggi del percorso perdono informazioni utili oppure quando la logica di attribuzione tratta in modo diverso sessioni e touchpoint incompleti. In questi casi il direct non va letto come una risposta automatica, ma come un segnale che richiede di capire meglio come il modello sta interpretando il percorso.
Dipende dalla domanda che stai facendo al dato. Il livello evento è più utile quando vuoi leggere il contesto immediatamente vicino alla conversione, mentre il livello sessione funziona meglio quando ti interessa capire quali ingressi o quali visite portino più spesso a un risultato. Nessuno dei due livelli è corretto in assoluto: cambia la prospettiva e, con essa, cambia anche la lettura della performance.
Sì, perché source, medium e campaign entrano direttamente nella classificazione del traffico e nella ricostruzione del contributo dei canali. Se gli UTM sono incoerenti, incompleti o gestiti con naming poco controllato, la lettura dell’attribuzione perde stabilità e diventa più facile frammentare campagne simili o attribuire il merito in modo poco affidabile.
Un modello affidabile non è quello più complesso, ma quello più coerente con il tracking disponibile, con la qualità del dato raccolto e con la decisione che l’analisi deve supportare. Prima conviene verificare come entrano le sorgenti, poi rendere confrontabili source, medium e campaign, scegliere il livello di analisi più adatto e solo dopo definire la logica con cui assegnare il credito alle conversioni.