In breve
Definisci il periodo anomalo, controlla la misurazione e confronta fonti diverse. Intervieni soltanto sul comportamento problematico, verificando che clienti, motori di ricerca e servizi necessari continuino ad accedere.
- Confrontare periodi e metriche omogenee.
- Controllare campagne, tag e attività tecniche recenti.
- Usare log e strumenti di protezione per verificare gli indizi.
- Distinguere pulizia dei report e protezione del sito.
Descrivere cosa è cambiato, prima di filtrare
Individua giorno, fascia oraria e metrica coinvolta: utenti, sessioni, visualizzazioni o eventi non rappresentano la stessa cosa. Confronta giorni della settimana equivalenti e controlla il fuso orario del rapporto. Un totale giornaliero può nascondere un picco concentrato in pochi minuti o un aumento distribuito e plausibile.
Annota quali pagine ricevono gli accessi, da quali canali arrivano e se crescono anche richieste valide, acquisti o telefonate. Non valutare il fenomeno solo attraverso il tasso di coinvolgimento: può cambiare per ragioni di contenuto, misurazione o pubblico.
Prepara una scheda sintetica con periodo, report e dimensioni utilizzate. Evita esportazioni complete con dati personali quando bastano valori aggregati. La domanda iniziale deve essere concreta: è cambiato il pubblico, il modo di contarlo oppure il numero di richieste tecniche?
Ricostruire campagne e modifiche recenti
Verifica invii di newsletter, campagne pubblicitarie, menzioni, eventi e collegamenti da altri siti. Un aumento inatteso può avere una spiegazione reale. Chiedi anche se qualcuno ha avviato controlli SEO, monitoraggi di disponibilità, importazioni o test automatici: sono attività diverse dalla visita di un possibile cliente.
Controlla gli interventi sul tracciamento. Un tag inserito due volte, un evento attivato ripetutamente o un cambiamento nelle impostazioni di consenso possono alterare la lettura dei dati. Cerca una coincidenza temporale fra modifica e anomalia, poi fai riprodurre il percorso con gli strumenti di debug disponibili.
La guida Google Analytics non registra più visite aiuta a controllare proprietà, tag e raccolta. Qui il primo obiettivo è evitare di chiamare “bot” un cambiamento generato dalla configurazione del sito.
Capire cosa esclude automaticamente GA4
Google dichiara che nelle proprietà Analytics il traffico di bot e spider noti viene escluso automaticamente. La documentazione sull’esclusione dei bot noti (si apre in una nuova scheda) precisa anche che non è possibile disattivare questa esclusione né vedere quanto traffico abbia rimosso.
Questo non equivale a una garanzia che ogni evento rimasto appartenga a una persona. Le automazioni non riconosciute e gli errori di implementazione richiedono altre verifiche. Allo stesso modo, una richiesta presente nei log del server può non comparire in Analytics: i due strumenti osservano fenomeni diversi.
Non aspettarti quindi che sessioni GA4 e richieste del server coincidano. Un caricamento può comportare più richieste di file; consenso, browser e modalità di accesso influenzano la raccolta degli eventi. Il confronto serve a cercare corrispondenze temporali e comportamenti, non a far combaciare due totali.
Valutare combinazioni di indizi
Una provenienza estera non dimostra traffico falso. Clienti in viaggio, reti aziendali, VPN e localizzazioni approssimative possono produrre dati inattesi. Anche pochi secondi su una pagina possono corrispondere a una persona che ha trovato un numero di telefono o ha abbandonato rapidamente.
Diventano più utili le combinazioni: frequenza elevata e regolare, sequenze ripetute, richieste verso percorsi inesistenti, tentativi seriali sul login, dispositivi sempre identici. Sono elementi da verificare, non criteri automatici di esclusione.
| Segnale | Controllo successivo |
|---|---|
| Visite da paesi nuovi | Canale, campagne, pagine e risultati delle richieste. |
| Eventi molto più numerosi | Duplicazioni del tag e condizioni di attivazione. |
| Accessi rapidi e ripetuti | Log, frequenza e risposte del server. |
| Molti tentativi sul login | Esiti, protezioni e andamento temporale. |
| Traffico senza contatti | Pertinenza del pubblico e funzionamento dei moduli. |
Confrontare log e identità dei crawler
Chiedi al referente hosting o sicurezza un’analisi mirata al periodo osservato: indirizzi richiesti, orari, codici di risposta, frequenza e identificativi tecnici disponibili. Valuta anche i dati del servizio che protegge il sito, se presente. Condividi solo quanto necessario e usa i canali concordati per informazioni riservate.
Il nome dichiarato da un programma non prova la sua identità. Google pubblica metodi per verificare le richieste dei propri crawler (si apre in una nuova scheda) attraverso indirizzi IP pubblicati o controlli DNS. Questa verifica spetta a chi amministra l’infrastruttura.
Anche i sistemi di protezione distinguono automazioni con finalità diverse: la documentazione Cloudflare sui bot verificati (si apre in una nuova scheda) include, fra gli esempi, crawler e servizi di monitoraggio. Disponibilità di dati e controlli dipende dal prodotto e dal piano utilizzati.
Separare analisi dei dati e protezione
Un confronto filtrato nei report aiuta a leggere un segmento sospetto, ma non impedisce richieste al server. Una regola di protezione limita gli accessi, ma non riscrive automaticamente la cronologia di Analytics. Definisci quale problema vuoi risolvere: qualità delle statistiche, sovraccarico, spam o tentativi di accesso.
Fai scegliere al referente tecnico un intervento proporzionato al comportamento rilevato, possibilmente osservabile e reversibile. Limitazioni di frequenza e verifiche aggiuntive possono essere applicate ai percorsi interessati, tenendo conto di utenti e integrazioni legittime. Evita blocchi geografici generali basati soltanto sul paese indicato in un rapporto.
Se l’anomalia riguarda esclusivamente messaggi commerciali falsi, approfondisci lo spam dal modulo contatti. Se il sito rallenta, controlla insieme i tempi di risposta e le risorse del server: il numero di sessioni da solo non misura il carico.
Esempio ipotetico: un picco con due cause
Un’azienda ipotetica vede raddoppiare le visualizzazioni dopo una modifica al sito. Nello stesso giorno aumentano i tentativi su indirizzi di amministrazione inesistenti. Il controllo del tracciamento rivela un evento di visualizzazione duplicato; i log mostrano anche richieste automatiche che non corrispondono alla normale navigazione.
I referenti correggono la duplicazione e trattano separatamente gli accessi ai percorsi anomali. Non attribuiscono l’intero aumento a un’unica causa. Nei report mantengono una nota sul periodo alterato, per non confrontarlo come se fosse una crescita commerciale.
Questo esempio mostra perché una diagnosi può richiedere due interventi diversi. Il risultato utile è un dato più interpretabile e un sito accessibile al pubblico pertinente, non semplicemente un contatore più basso.
Checklist dopo la verifica
- Periodo, metrica e fuso orario dell’anomalia sono documentati.
- Campagne, citazioni e attività tecniche sono state controllate.
- Il tracciamento è stato verificato su un percorso ripetibile.
- Gli indizi sono confrontati con log o strumenti di protezione.
- Clienti e crawler utili possono ancora accedere.
- Moduli, login e integrazioni funzionano dopo l’intervento.
- Report e risultati commerciali vengono riletti nello stesso intervallo.
Conserva causa accertata, elementi ancora incerti, intervento e responsabile. Se mancano dati sufficienti, programma una raccolta mirata prima di introdurre altre esclusioni. Il referente dell’assistenza del sito può coordinare il controllo con hosting e gestione delle statistiche.
Fonti e approfondimenti
Riferimenti ufficiali per approfondire i controlli e i criteri descritti nella guida. Le procedure vanno adattate agli strumenti e all’organizzazione effettivamente utilizzati.