Come confrontare il traffico live di Astrina con i log del server
Confrontare il traffico live di Astrina con i log del server sembra semplice, finché non compare il primo scostamento. Un report dice 18 visite. Il log mostra 24 richieste. Di solito quel divario ha una spiegazione, e spesso è una di quelle noiose nel migliore dei modi: un redirect, un bot, un proxy o un timestamp sfasato di 60 secondi.
Il compito non è far coincidere i due numeri a tutti i costi. Il compito è rendere il confronto abbastanza onesto da potersi fidare del risultato. Se vuoi capire come confrontare Astrina e log del server in pratica, inizia restringendo il problema prima di discutere con i numeri.
1. Conferma il perimetro dei log del server prima di confrontarli
Per prima cosa scegli i file di log esatti. Molti team mescolano traffico di produzione, staging e preview in un unico foglio di calcolo, poi si chiedono perché Astrina mostri un andamento e il server un altro. Tieni un solo sito, un solo ambiente e una sola porzione di traffico. Vuol dire indicare in modo chiaro host, app e origine del log prima di qualsiasi altra cosa.
Se la tua configurazione del server scrive più file al giorno, annota la regola di rotazione. Se hai log separati per il CDN edge e per il server origin, scegli un solo percorso e mantienilo per la prima analisi. Un perimetro pulito riduce il resto del lavoro. Un perimetro confuso fa sembrare sospetto ogni scostamento.
Un esempio pratico: confronta solo www.example.com in produzione, solo le richieste di pagina e solo le ultime 24 ore. Non aggiungere nel confronto il traffico API, i controlli di salute o gli URL di amministrazione. Sono cose diverse.
2. Scegli una finestra temporale esatta e normalizza i timestamp
Il traffico live di Astrina funziona meglio quando la finestra è precisa. Anche i log del server funzionano meglio quando la finestra è precisa. Usa lo stesso minuto iniziale e lo stesso minuto finale in entrambi i casi, non “verso mezzogiorno” o “dopo pranzo”. Il taglio al minuto conta, perché una richiesta sul confine può cambiare il totale.
Usa un solo fuso orario per entrambi i lati. Se Astrina mostra UTC e i log del server sono in ora locale, il confronto fallirà ancora prima di partire. Converti i timestamp dei log una sola volta, poi mantienili in quel formato per tutta l’analisi. Uno scarto di 15 minuti può creare un falso picco. Uno di un’ora può far sembrare i dati rotti.
Una regola semplice che fa risparmiare tempo: non confrontare mai una finestra mobile di 5 minuti di Astrina con un estratto di log giornaliero. Sembra ovvio. Eppure succede. Scegli una finestra, scrivila e usala ovunque.
3. Riduci i log del server alle sole richieste di pagina fatte da esseri umani
I log del server contengono di tutto, ed è proprio questo il problema. Immagini, CSS, bundle JavaScript, richieste del favicon, prefetch e hit dei crawler stanno tutti accanto alle visite di pagina. Astrina di solito conta le visite di pagina, quindi il log va ristretto allo stesso tipo di richiesta.
Escludi prima gli asset. Poi rimuovi i controlli di salute, le sonde di uptime, gli endpoint di amministrazione e gli strumenti interni. Se il tuo load balancer chiama /health ogni minuto, quelle righe possono alterare rapidamente i totali. Una pagina come /pricing non andrebbe confrontata con 400 richieste di asset e tre ping di monitoraggio.
Anche il filtro dei bot merita attenzione. Alcuni bot sembrano umani per qualche secondo, e alcuni browser sembrano robotici per via dello user agent. Non affidarti a un solo segnale. Usa, quando puoi, una combinazione di percorso della richiesta, user agent e range IP interni noti. Se il tuo log include un indicatore “bot” proveniente da un WAF o da un reverse proxy, conserva quell’etichetta. Sarà utile più avanti.
4. Mappa i campi di Astrina ai campi del log
Crea una semplice mappa dei campi prima di provare ad allineare i record. Astrina può mostrare timestamp, percorso della pagina, referrer e un identificatore simile a una sessione. Il log può mostrare la riga di richiesta grezza, il codice di stato, lo user agent e l’indirizzo IP. Non sono la stessa cosa e non dovrebbero essere trattati come se lo fossero.
Prepara una tabella a due colonne su carta o in un foglio di calcolo. A sinistra: campo di Astrina. A destra: campo del log. Il timestamp corrisponde al timestamp, il path al percorso della richiesta, il referrer all’header referrer e lo user agent alla stringa user agent. Gli ID simili a sessione sono più complessi, perché il log del server magari non ne ha affatto uno. Non è un fallimento. È solo un limite.
| Campo di Astrina | Campo log più vicino | Note |
|---|---|---|
| Timestamp | Orario della richiesta | Prima convertilo in un solo fuso orario |
| Path della pagina | Path dell'URL | Rimuovi le query string per il raggruppamento |
| Referrer | Header Referer | Può mancare o essere troncato |
| User agent | Stringa user agent | Utile per i controlli sui bot |
Non aspettarti che ogni campo di Astrina abbia un campo equivalente nel log. Alcuni valori sono dedotti. Alcuni sono modellati. Alcuni semplicemente non compaiono nei log del server. Ecco perché la mappa è importante: ti dice dove il confronto diretto è possibile e dove è solo approssimato.
5. Riconcilia il traffico per path URL, non per riga di richiesta grezza
Le righe di richiesta grezze sono rumorose. Una visita a /docs può apparire come /docs, /docs/ o /docs?utm_source=newsletter. Se confronti queste stringhe in modo letterale, dividerai una sola pagina in tre. Astrina potrebbe già normalizzare parte di questo. Il tuo log probabilmente no.
Usa path canonici. Raggruppa tutte le varianti sulla stessa pagina prima di confrontare i conteggi. Rimuovi le query string se non fanno parte dell’identità della pagina. Uniforma gli slash finali quando il sito tratta le varianti come la stessa pagina. Se sono coinvolti dei redirect, conta la destinazione finale, non il primo passaggio.
Questo passaggio spesso rivela una sorpresa. Una pagina con 50 visite su Astrina può mostrare 63 voci di log perché 13 richieste hanno colpito prima la versione non canonica e poi sono state reindirizzate. Non è un errore del traffico. È un problema di path. Correggi la regola di raggruppamento prima di cambiare interpretazione.
6. Verifica gli scostamenti causati da caching, proxy o CDN
Gli strati intermedi cambiano ciò che arriva al server origin. Un CDN può rispondere alla richiesta prima che l’origin la veda. Un proxy può riscrivere gli header. Un cache hit può servire una pagina all’utente senza lasciare alcuna riga corrispondente nell’origin. Questo significa che Astrina può vedere una visita mentre il log del server resta in silenzio.
Può succedere anche il contrario. Il log dell’origin può registrare una richiesta che Astrina non conta perché il browser non ha completato il caricamento della pagina, lo script è stato bloccato oppure la richiesta è partita prima che il codice di tracciamento venisse eseguito. Una piccola pagina di test può rendere tutto evidente. Apri la pagina in un browser, controlla la scheda network e verifica se la richiesta di tracciamento parte prima che il caricamento finisca.
Se usi un CDN, controlla se la fonte del log è l’edge o l’origin. Sono registri diversi. Una risposta 304, una risposta HTML in cache o un oggetto edge obsoleto possono produrre differenze false. È qui che una breve nota nel foglio di confronto ti fa risparmiare un’ora dopo.
Per i team che configurano il tracker per la prima volta, conta anche il percorso di installazione. La configurazione dell’agente è più facile da verificare se segui lo stesso metodo di deploy usato in produzione, ed è per questo che molti team tengono la guida di configurazione accanto allo script di esportazione dei log nel proprio runbook.
7. Usa un breve registro delle discrepanze per classificare ogni divario
Non lasciare gli scostamenti come celle rosse anonime. Scrivi un registro delle discrepanze con una riga per ogni gap. Assegna a ogni riga una categoria. Di solito bastano cinque categorie all’inizio: rumore da bot, copertura mancante nei log, ingestione ritardata, hit duplicati e problema di normalizzazione dei path.
Ecco un formato semplice: path della pagina, conteggio Astrina, conteggio log, dimensione del gap, categoria, nota. La nota dovrebbe indicare una causa concreta, non una sensazione. “Il CDN ha servito HTML in cache” è utile. “Sembra strano” no. Se un gap si ripete su tre pagine, è un indizio. Se compare una sola volta, è comunque un indizio, solo più piccolo.
Un team potrebbe scoprire che un gap di 12 richieste è causato da un ritardo nell’invio dei log. Un altro potrebbe trovare che un’estensione del browser blocca lo script di tracciamento sui dispositivi interni. Un terzo potrebbe capire che il server scrive righe duplicate in caso di retry. Le categorie ti impediscono di trattare ogni discrepanza come se fosse lo stesso tipo di errore.
Se vuoi un quadro operativo più ampio per questo lavoro, astrina per i team interni di prodotto che tracciano può essere un utile testo complementare, soprattutto quando uno scostamento di traffico si rivela legato a un deploy.
8. Riesegui il confronto su un campione piccolo prima di scalare
Inizia con una pagina o un giorno. Non dieci pagine. Non un mese intero. Un solo campione costringe le regole a diventare esplicite, e questo è un bene. Se il campione include solo /pricing, puoi esaminare a mano ogni scostamento e vedere se il metodo regge.
Cerca stabilità prima dell’ampiezza. Se lo stesso filtro, la stessa regola sul path e la stessa finestra temporale producono due volte lo stesso risultato, passa a una seconda pagina. Se i numeri cambiano quando aggiungi un altro giorno, fermati e controlla se nel mezzo è avvenuto un deploy, un cambio di cache o una rotazione dei log. Un campione piccolo è più rapido da correggere di uno grande.
C’è una disciplina utile qui: cambia una sola variabile alla volta. Passa da una pagina a tre pagine, oppure da un giorno a due giorni, ma non entrambe le cose insieme. Altrimenti non saprai quale cambiamento ha rotto la corrispondenza. Sembra lento. In realtà è più veloce che tornare indietro su 40 righe di assunzioni sbagliate.
I team che migrano da un altro strumento di analytics spesso vedono lo stesso schema durante la transizione. Se è il tuo caso, come migrare da Plausible è un riferimento pratico da tenere aperto mentre verifichi il primo campione con i log.
Cosa controllare quando i numeri continuano a non combaciare
Se dopo gli otto passaggi sopra il confronto continua a sembrare sbagliato, controlla tre cose in ordine: la fonte del log, la regola sul path e la finestra temporale. Non saltare subito allo script di tracciamento. Un numero sorprendente di “bug di tracking” sono in realtà bug di estrazione dei log. Un’altra causa comune è un redirect trascurato da /page a /page/.
Controlla anche se la sessione del browser termina prima che la richiesta di tracciamento si completi. Le connessioni mobile sono più fragili di quelle desktop. Una pagina può caricarsi visivamente mentre la chiamata analytics viene cancellata. Così Astrina registra meno visite del log del server. Può succedere anche il contrario, quando il browser ritenta una richiesta e il server conta entrambi i tentativi.
Un ultimo dettaglio: se il sito ha una pagina di manutenzione o una modalità manutenzione, tratta quel traffico separatamente. Un evento di manutenzione cambia sia il comportamento degli utenti sia la forma dei log. Se ti serve un riferimento complementare per quella situazione, cosa fare quando l'uptime di Astrina può aiutarti a inquadrare l’incidente prima di confrontarlo con i log.
I confronti migliori sono piccoli, documentati e ripetibili. Un perimetro pulito, una sola finestra temporale, richieste di pagina filtrate e path canonici spiegano di solito la maggior parte del divario. La differenza residua è il punto in cui si trova il lavoro davvero utile, soprattutto quando devi allineare report Astrina con log web senza confondere i segnali operativi con il rumore di fondo.
