Come il traffico interno altera le metriche del sito
Dipendenti, sviluppatori e agenzie possono gonfiare visite e sessioni e distorcere coinvolgimento e conversioni. Scopri come riconoscere il traffico interno.
Perché le metriche di analisi del sito web sono gonfiate dal traffico interno?
Prima del lancio, una responsabile marketing controlla una nuova landing page. Uno sviluppatore testa il checkout, un addetto all’assistenza cerca l’ordine di un cliente e un’agenzia verifica i tag della campagna. Ogni visita può generare dati di analisi, anche se nessuna proviene da un potenziale cliente.
Il traffico interno non domina necessariamente un report. Tuttavia, su una pagina con poche visite, bastano alcuni accessi del personale per alterare il tasso di coinvolgimento apparente o far sembrare un test più efficace di quanto sia davvero. Capire come il traffico interno altera le metriche del sito aiuta a interpretare meglio i dati. La domanda utile non è soltanto perché le metriche di analisi del sito web sono gonfiate dal traffico interno, ma anche quali visite siano interne, come influiscano sulle decisioni e se escluderle sia una scelta sicura.
Che cosa si considera traffico interno quando il team usa il sito?
Per traffico interno si intende l’attività delle persone che lavorano per l’organizzazione o al suo interno, anziché quella di clienti o potenziali clienti. Può includere dipendenti, collaboratori esterni, un’agenzia web e il personale dell’assistenza. I loro ruoli sono diversi, ma le loro visite possono finire nella stessa proprietà di analytics di quelle dei clienti.
La provenienza non si limita alla rete dell’ufficio. Un dipendente potrebbe controllare il sito da un portatile collegato al Wi-Fi dell’ufficio e poi tornarci da casa, usando il proprio telefono. Un collaboratore esterno potrebbe usare una VPN aziendale, mentre un membro dell’agenzia potrebbe visitare il sito da un altro ufficio. Tutti questi accessi potrebbero essere attività interne, anche se ciascuno compare con un indirizzo di rete o un dispositivo diverso.
Conta anche lo scopo della visita. Se un addetto all’assistenza consulta una pagina di aiuto per rispondere a un cliente, non sta testando una campagna, ma si tratta comunque di attività del personale. Se uno sviluppatore controlla che una pagina si carichi dopo un rilascio, è chiaramente una visita di lavoro. In genere, gli strumenti di analytics registrano ciò che accade sul sito, non il motivo per cui la persona lo visita.
Perché le normali attività di lavoro generano visite ripetute?
La maggior parte delle visite del personale avviene nell’ambito del lavoro quotidiano. Un redattore apre una bozza, la pubblica e controlla la versione online dal telefono. Un responsabile delle campagne segue un link con tag per verificarne la destinazione. Uno sviluppatore ricarica la pagina di un prodotto mentre corregge un problema di layout.
Questi controlli possono generare diverse visualizzazioni di pagina o sessioni, soprattutto se il personale torna sul sito più volte durante la giornata o usa più browser. Anche le impostazioni dei cookie, i profili del browser e le regole con cui gli strumenti di analytics definiscono una sessione possono determinare se una visita successiva venga conteggiata come parte di una sessione esistente o come una nuova sessione.
L’assistenza clienti genera dinamiche proprie. Per rispondere a più richieste distinte, un operatore potrebbe cercare informazioni nel centro assistenza pubblico, aprire una pagina sui resi e consultare quella di un prodotto. Si tratta di attività reale, ma non rappresenta un interesse indipendente dei clienti per quelle pagine.
È facile trascurare le attività di test. Un team potrebbe aprire il checkout online per verificare il flusso di pagamento senza effettuare un ordine, oppure tornare su una pagina della campagna dopo aver modificato un pulsante. Annotare brevemente questi controlli fornisce agli analisti un contesto utile quando un report mostra un picco insolito.
Quali metriche risentono maggiormente delle visite interne?
Le diverse metriche reagiscono in modo diverso all’attività del personale. Una visualizzazione di pagina conta i caricamenti della pagina, quindi i controlli ripetuti la aumentano direttamente. Il numero di sessioni può salire quando le visite iniziano in condizioni che fanno partire sessioni separate. Il conteggio degli utenti dipende da come lo strumento di analytics identifica una persona: un dipendente che usa due dispositivi può risultare come un solo utente oppure come più utenti.
Le metriche di coinvolgimento possono variare in entrambe le direzioni. Un membro del personale che legge a lungo una pagina di aiuto può aumentare il tempo di coinvolgimento, mentre uno sviluppatore che apre una pagina e la abbandona subito può ridurre il tasso medio di coinvolgimento. Nessuno dei due andamenti indica cosa faccia un cliente tipico.
I tassi di conversione richiedono particolare attenzione. Se un membro del personale prova un modulo e lo invia, il sistema di analytics potrebbe conteggiare una conversione, a meno che l’evento non sia configurato per distinguere i test da un contatto reale. Se le visite del personale aumentano le sessioni ma non le conversioni, il tasso di conversione riportato può diminuire. Se invece l’invio di prova viene conteggiato come conversione, può aumentare.
L’effetto si nota spesso di più sulle pagine con poco traffico. Immaginiamo che, durante un periodo di reporting, una pagina riceva solo poche visite da parte dei clienti e diversi accessi di controllo del personale. Questi ultimi possono modificare sensibilmente le medie visualizzate, pur senza cambiare affatto il comportamento dei clienti.
Come capire se le visite sono interne senza dare nulla per scontato?
Per capire come identificare le visite interne sul sito web, parti da un’ipotesi, non da una conclusione. Confronta l’attività insolita con una routine di lavoro nota: per esempio, un picco di visite subito dopo un rilascio potrebbe coincidere con la finestra di test di uno sviluppatore. Prima di classificare il traffico come interno, chiedi a chi ha apportato la modifica.
I dati di rete possono essere utili, ma non costituiscono una prova. Un indirizzo dell’ufficio o un intervallo noto di una VPN possono aiutare a identificare alcune visite del personale, ma dipendenti da remoto, collaboratori esterni e configurazioni di rete variabili potrebbero non rientrare in quegli intervalli. Anche un cliente che usa la stessa VPN aziendale potrebbe condividere l’indirizzo con il personale.
Cerca più indizi che, insieme, permettano di farsi un’idea. Una sequenza ripetuta di pagine su un percorso simile a quello di un ambiente di test, ma presente sul sito online, un link usato dal personale per i test e un orario che coincide con le note di rilascio possono indicare un’attività interna. Una singola visita da una località sconosciuta non basta. Annota gli elementi che hanno portato alla classificazione, così che un altro analista possa verificarla in seguito.
Tra i controlli utili ci sono chiedere al personale di annotare gli orari dei test, confrontare le sessioni di lavoro note con le date e gli orari registrati da analytics e verificare quali pagine sono state visitate. Se la configurazione consente di usare un ambiente di test separato o un indicatore specifico per il personale, sfruttalo per riconoscere più facilmente i controlli futuri. Non considerare il tipo di dispositivo o la breve durata della visita come un metodo affidabile per identificare i dipendenti.
Cosa cambia quando il traffico interno si mescola a quello dei clienti?
La sovrapposizione del traffico può cambiare la storia che sembra raccontare un report. Una pagina di aiuto usata spesso dal personale dell’assistenza può sembrare una delle destinazioni più visitate dai clienti. I controlli rapidi di uno sviluppatore possono far apparire una nuova pagina molto visitata, ma con un coinvolgimento basso. I numeri continuano a descrivere le attività registrate, ma rappresentano in modo meno accurato il comportamento dei clienti.
Gli esperimenti di piccole dimensioni sono particolarmente sensibili. Se un nuovo pulsante viene visto da poche persone, i clic del personale o gli invii di prova possono influenzare il risultato apparente. Il team potrebbe mantenere un design che i clienti non preferiscono o scartarne uno che funziona bene, perché l’attività interna ha alterato il confronto.
Le prestazioni delle conversioni possono essere distorte in entrambe le direzioni. Se un ordine di prova viene conteggiato come acquisto, i risultati sembrano migliori; se molte sessioni del personale non portano ad acquisti, il tasso può apparire peggiore. Prima di agire sulla base di una piccola differenza, verifica se durante il periodo di reporting si sono svolte attività interne note e se l’evento di conversione è stato attivato durante i test.
Per questo è importante leggere i dati di analytics insieme al contesto operativo. Se i numeri di una pagina sono cambiati lo stesso giorno di un rilascio del sito o di una campagna di assistenza, annota la coincidenza prima di attribuire la variazione alla domanda dei clienti. I team che esaminano i contatti registrati possono anche confrontare i risultati di analytics con i dati del CRM; scopri come riconciliare le conversioni registrate da analytics con quelle del sito web.
Come dovrebbe decidere un team quale traffico interno escludere?
Per decidere come escludere il traffico interno da Google Analytics, considera prima quale decisione deve supportare il report. Escludere il traffico può rendere più chiara l’analisi dei clienti, ma un filtro può anche nascondere informazioni utili o eliminare visitatori reali. Per esempio, un team che blocca un’intera rete dell’ufficio potrebbe perdere anche l’attività dei clienti che usano la stessa rete. Inoltre, un cambiamento nelle modalità di lavoro da remoto potrebbe rendere incompleta una vecchia regola di rete.
Per molti team, etichettare l’attività interna o mantenere una vista separata per i report è più sicuro che eliminarla da tutti i report. In una vista dedicata ai clienti si può omettere il traffico contrassegnato come attività del personale, conservandolo però in una vista separata per controllare il comportamento del sito online. È utile quando gli sviluppatori devono verificare che una pagina o un modulo funzioni dopo un rilascio.
Scegli un metodo in base alla decisione che il report deve supportare. Se l’obiettivo è stimare la domanda dei clienti, escludi o separa le attività di test note. Se invece vuoi verificare che il checkout online funzioni, le visite di prova del personale potrebbero essere rilevanti. Documenta chi è responsabile della regola, quale traffico copre e quali dati potrebbe escludere.
Verifica la modifica prima di farci affidamento. Confronta un report con l’esclusione applicata con uno senza esclusione, quindi controlla che l’attività prevista del personale scompaia e che i normali test continuino a funzionare come previsto. Se una regola di filtraggio non riesce a distinguere con sufficiente sicurezza il personale dai clienti, lascia i dati visibili e segnala il limite, invece di fingere che la separazione sia esatta.
Come si può evitare che il traffico interno comprometta le analisi future?
Definisci una procedura semplice per il team. Prima di un test sul sito online, annota chi lo eseguirà, quali pagine o eventi coinvolgerà e più o meno quando avverrà. Basta una nota nel ticket di rilascio per aiutare un analista a spiegare in seguito una variazione temporanea del traffico.
Stabilisci una procedura di test chiara per il personale. Per esempio, quando è possibile usa un profilo del browser dedicato o un ambiente di test e avvisa il responsabile di analytics prima di inviare un modulo o completare un acquisto di prova sul sito online. In questo modo si riducono le conversioni accidentali senza impedire al team di controllare l’esperienza dei clienti.
Rivedi le esclusioni dopo qualsiasi modifica alle reti dell’ufficio, all’accesso VPN, ai tag di analytics o alla struttura del team. Un filtro basato su un vecchio intervallo di rete potrebbe non intercettare più le visite del personale; una regola più ampia potrebbe invece includere i clienti. Verifica la regola con una visita di prova del personale e controlla il risultato nella vista dei report.
Infine, assicurati che la definizione di traffico interno sia chiara a tutti coloro che consultano il report. Una breve nota che specifichi quale attività del personale viene esclusa e quale resta inclusa evita che un dato filtrato venga scambiato per un resoconto completo di tutte le visite. La distinzione è importante quando il test successivo di una pagina riguarda solo poche sessioni.
