Come risolvere il traffico web mancante in Astrina

Per “traffico mancante” di solito si intende una di due cose: Astrina mostra meno visite di quante te ne aspetti, oppure Astrina mostra visite in un report ma non in un altro. Il numero conta. Se un altro strumento, un log del server o il report dello store indica 120 sessioni e Astrina ne mostra 47, hai una discrepanza nei dati da spiegare, non una sensazione da inseguire.

Inizia dalla fonte di riferimento con cui stai facendo il confronto. Un report del CRM, una dashboard dei pagamenti e l’analytics del browser non misurano la stessa cosa, quindi il primo passo è confrontare dati omogenei. Se stai cercando di capire come risolvere traffico web mancante Astrina, poni una domanda semplice: quali visite mancano, su quali pagine, in quale intervallo di tempo e da quale fonte dati?

Sembra banale. Lo è. Un confronto pulito può farti risparmiare un’ora, mentre uno approssimativo può farti perdere una giornata. Se Astrina mostra traffico sulla homepage ma non sulle pagine prodotto, non è lo stesso problema di un calo su tutto il sito.

1. Verifica che il calo sia una discrepanza di reporting, non una perdita reale

Controlla se i visitatori arrivano ancora da un altro canale. I log del server, le conferme d’ordine, i clic dalle piattaforme adv o le voci della search console possono mostrare attività anche quando Astrina sembra vuoto. Un indizio comune è un andamento normale dei ricavi con un grafico del traffico basso. Un altro è un calo improvviso che inizia allo scoccare dell’ora, mentre gli ordini continuano. Questo pattern indica una misurazione mancante, non utenti mancanti.

Guarda la data, l’ora e il fuso orario esatti usati in Astrina. Un report che sembra vuoto per “oggi” può essere normale se il giorno lavorativo della tua azienda inizia in un fuso diverso da quello usato nella dashboard. Uno scarto di un’ora basta per far sembrare il traffico in ritardo, e un cambio dell’ora legale può far apparire il grafico rotto quando non lo è.

Se la discrepanza è reale, definiscila. Astrina non sta registrando tutte le sessioni, solo il traffico a pagamento, solo il traffico mobile o solo una singola campagna? Dire in modo generico “il traffico è sparito” è troppo vago per agire. Dire con precisione “il traffico dalla landing page /pricing è assente su Chrome per iPhone da martedì” è utile.

2. Controlla se il problema riguarda solo la vista del traffico in tempo reale

Non mescolare il reporting storico con il pannello live. Il traffico live che non si vede può essere allarmante, ma la vista in tempo reale è una superficie più breve e più reattiva rispetto ai report giornalieri. Un leggero ritardo, una mancata corrispondenza nei filtri o una breve pausa di ingestione possono far sembrare vuoto il pannello live mentre i report principali continuano a popolarsi.

Fai attenzione a tre modalità di comportamento. Primo: il traffico live arriva con un ritardo di alcuni minuti. Secondo: compare per una pagina ma non per un’altra. Terzo: appare e scompare durante una sessione. Nessuno di questi casi significa automaticamente che il sito sia rotto. Significa però che devi separare la dashboard live dal report che usi per le decisioni quotidiane.

Non ripetere la stessa checklist che useresti per un’interruzione completa del servizio. Se le pageview compaiono ancora nel report storico dopo 15 o 30 minuti, potrebbe essere solo il pannello live ad avere ritardo. Questa distinzione conta perché un display in ritardo si risolve in modo diverso da un percorso di raccolta dati mancante.

Un piccolo inciso: i team vanno spesso nel panico perché un collega vede un evento live e un altro no. Può succedere quando la dashboard è filtrata per proprietà, segmento o vista dispositivo senza visitatori attuali.

3. Verifica che lo script di analytics first-party si carichi sulle pagine interessate

Se il problema è limitato ad alcune pagine, ispeziona prima il sorgente di quelle pagine. Devi cercare un problema nello script di analytics first-party, non un generico “bug dell’analytics”. Verifica che il tag script sia presente, che venga caricato dal percorso first-party previsto e che compaia nel sorgente renderizzato della pagina, dove Astrina può riceverlo. In questa fase, un buon debug analytics Astrina fa la differenza tra un controllo rapido e una lunga caccia al fantasma.

Usa il pannello Network del browser e ricarica la pagina interessata. La richiesta dovrebbe restituire uno stato di successo normale, non una risposta bloccata, reindirizzata o riscritta. Se lo script viene inserito da un tag manager, confronta la pagina live con l’anteprima di deploy. Un deploy recente può spostare lo script, rimuovere il container o inserirlo in una condizione che lo nasconde da determinate route.

La cache può creare un falso positivo. Una versione della pagina potrebbe avere ancora il vecchio script, mentre un’altra versione serve un template più recente senza di esso. Anche le regole edge possono fare lo stesso, soprattutto se variano per Paese, dispositivo o punteggio bot. Se vedi traffico su un template e nulla su un altro, non dare per scontato che il problema sia Astrina finché non dimostri che lo script raggiunge entrambe le pagine.

Un test concreto aiuta: apri la pagina in una sessione nuova, fai un hard refresh e confronta l’HTML finale del browser con l’implementazione attesa. Se lo script scompare solo dopo un deploy, la correzione va nella revisione del rilascio, non nella dashboard.

4. Confronta i template di pagina funzionanti e non funzionanti

Scegli una pagina che registra traffico e una che non lo fa. Poi confronta il template, il pattern della route e il tipo di pagina. Un articolo del blog, una scheda prodotto e un passaggio del checkout spesso usano code path diversi. Il traffico mancante su uno solo di questi casi di solito indica una discrepanza a livello di pagina, non un problema su tutto il sito.

Cerca differenze che sembrano piccole ma contano. Una pagina funzionante può usare un file di layout, mentre quella rotta ne usa un altro. Un template può includere lo script Astrina nell’header; un altro può caricarlo dopo il consenso. Una route può essere renderizzata lato server, mentre un’altra viene idratata più tardi e perde la pageview iniziale. Queste differenze creano una separazione del traffico che sembra misteriosa finché non allinei i file sorgente.

Confronta non solo l’HTML, ma anche lo stato finale nel browser. Un template CMS può essere corretto nell’editor e sbagliato in produzione dopo una regola di deploy, un purge della cache o una variante di contenuto. Se il traffico appare su /blog ma non su /blog/tag/product, potresti trovarti davanti a un problema di ereditarietà del template, non a un’interruzione della misurazione.

Mantieni il confronto rigoroso. Due pagine, una funzionante e una no, stesso browser, stesso fuso orario, stesso dispositivo, stesso referrer se possibile. Questa disciplina elimina rapidamente il rumore.

5. Controlla consenso, privacy e condizioni di soppressione che possono nascondere le visite

Alcune visite vengono nascoste di proposito. Banner dei consensi, impostazioni privacy, soppressione del traffico interno e opt-out specifici per pagina possono escludere le sessioni prima che Astrina le conti. Per questo una diagnosi del traffico mancante dovrebbe sempre chiedersi se la visita fosse autorizzata a essere registrata fin dall’inizio.

La logica del consenso può essere particolarmente insidiosa sulle landing page. Un visitatore può arrivare, vedere il banner, rifiutare il tracciamento e continuare la navigazione. Un altro può accettare sulla homepage ma rifiutare al checkout. In entrambi i casi, il traffico può sparire da una sezione del sito pur continuando ad apparire in un’altra. Il pattern dipende da dove viene concesso il consenso e da dove lo script aspetta l’autorizzazione.

Anche i filtri sul traffico interno possono causare lo stesso effetto. Se un filtro si basa su IP, header o stato dell’account, le visite del tuo team possono sparire mentre i clienti reali continuano a comparire. Sembra ovvio finché qualcuno prova dalla rete dell’ufficio e pensa che il sito sia giù. Non è giù; è filtrato.

Contano anche gli opt-out specifici per pagina. Una pagina legale, una pagina account o un flusso sensibile possono sopprimere volutamente le analytics. Se la pagina mancante rientra in questi casi, verifica il comportamento previsto prima di trattarla come un difetto. Una buona diagnosi nomina la regola, la pagina e la conseguenza.

6. Esamina i problemi di sessionizzazione e continuità dell’identità

Il traffico può sembrare sparire quando una sessione si interrompe a metà percorso. Redirect cross-domain, passaggi tra sottodomini, navigazione SPA e identità visitatore interrotta possono dividere una visita in più frammenti. Astrina può comunque acquisire gli eventi, ma il percorso apparirà incompleto quando lo confronti con un altro strumento.

Per esempio, un visitatore arriva su shop.example.com, passa al checkout su checkout.example-payments.com, poi torna a una pagina di conferma su www.example.com. Se l’identità non persiste lungo ogni passaggio, Astrina può mostrare una sola pagina di ingresso e nessuna continuazione, mentre un altro sistema unisce la visita in modo diverso. Il sito non ha perso il traffico. È stata la catena dell’identità a rompersi.

Le route di una SPA meritano un’attenzione speciale. Se una transizione lato client aggiorna l’URL senza inviare l’evento previsto, la pagina può sembrare attiva per l’utente ma vuota per Astrina. Lo stesso può succedere se un redirect elimina un parametro di cui Astrina ha bisogno per collegare le sessioni. Un solo token rotto basta a rendere incoerenti i report per alcuni giorni.

Confronta Astrina con un’altra fonte di misurazione con attenzione. Se entrambi gli strumenti concordano sull’ingresso ma divergono dopo il primo clic, il problema è probabilmente la continuità della sessione. Se uno strumento mostra l’intero percorso e Astrina si ferma alla prima pagina, cerca redirect, timing dello script o reset dell’identità nel passaggio.

7. Valida la correzione con un test controllato e una revisione post-deploy

Dopo la correzione, esegui una visita controllata. Usa un browser, un dispositivo e un percorso di pagina che sai essere interessato. Visita la pagina, fai uno o due clic e verifica che il percorso atteso degli eventi compaia in Astrina entro il normale intervallo di reporting.

Poi controlla lo stesso report dopo il deploy. Una correzione che funziona in anteprima ma fallisce in produzione non è una correzione. Rivedi di nuovo la pagina interessata dopo che i livelli di cache, le regole edge e qualsiasi modifica del tag manager si sono assestati. Se hai cambiato la logica del consenso, testa sia lo stato di accettazione sia quello di rifiuto. Se hai cambiato il percorso dello script, verifica che la richiesta arrivi ancora all’endpoint first-party.

Monitora il report per alcuni giorni, non solo per una sessione. I problemi di traffico spesso si nascondono dietro una singola famiglia di browser, un singolo template o una landing page specifica. Un test controllato dimostra che il percorso può funzionare. Un follow-up di 3 giorni dimostra che continua a funzionare.

Se il tuo sito dipende da più team, condividi con chi gestisce il deploy la pagina esatta, la route e l’orario del test. In questo modo avrà qualcosa di concreto da controllare e il prossimo review non diventerà un tiro a indovinare.

Ultima nota pratica: se vuoi un riferimento pulito di implementazione prima di testare di nuovo il traffico, controlla * e la dimensione normalizzata del testo visibile per il percorso di setup, poi torna al report interessato e confronta il percorso live con ciò che Astrina riceve davvero.