La maggior parte delle campagne con traffic bot fallisce per motivi banali: il ritmo di erogazione è sbagliato, il mix di referrer è implausibile, la proprietà di analytics non è mai stata segmentata, oppure nessuno ha messo per iscritto che aspetto avrebbe avuto un buon risultato. Sono questi i dettagli operativi che decidono se una campagna produce dati di test utilizzabili o un mese di numeri che non si riescono a interpretare.
In sintesi
- Etichettare prima di lanciare. Quasi ogni problema descritto qui sotto è recuperabile se in seguito il traffico può essere isolato, ed è quasi irrecuperabile se non lo è.
- Regolare il ritmo su una curva, non su un totale giornaliero. Un flusso piatto e ininterrotto è il segnale più chiaro di traffico sintetico e distorce ogni media che si calcola.
- Copiare la propria plausibilità. L'analytics già in uso descrive una geografia e un mix di dispositivi credibili: va usato come specifica.
- Scegliere prima la metrica di successo. In una campagna di test quella metrica è di norma la fedeltà degli eventi, non le sessioni.
Impostare la campagna con traffic bot in modo che i dati restino leggibili
L'errore di impostazione più difficile da correggere è inviare visite sintetiche nella stessa vista di analytics degli utenti reali. È comunque possibile separarle in un secondo momento con segmenti e confronti, ma solo se l'etichettatura era presente fin dall'inizio, e in ogni caso le sessioni restano nella proprietà. Ciò che non si può fare è applicare retroattivamente un filtro dei dati. La decisione va presa prima che arrivi la prima sessione.
- Etichettare ogni campagna con parametri UTM che non si userebbero mai in modo organico. Un
utm_sourcededicato rende l'esclusione un filtro da un solo clic. Non è ordinaria manutenzione facoltativa: è la differenza tra un esperimento reversibile e una proprietà contaminata per sempre. - Creare il filtro di esclusione prima del lancio, non dopo. In GA4 i filtri non sono retroattivi. Un filtro aggiunto al dodicesimo giorno lascia undici giorni di dati misti in ogni report storico che si eseguirà d'ora in poi.
- Usare una proprietà separata o un flusso di dati dedicato se il sito ha una reportistica sui ricavi. Tutto ciò che alimenta una presentazione per il consiglio o il segnale di conversione di una piattaforma pubblicitaria non dovrebbe mai vedere sessioni sintetiche.
- Mettere per iscritto in una sola frase lo scopo della campagna prima di spendere. «Verificare che il funnel di checkout generi correttamente gli eventi sotto carico da tre Paesi» è uno scopo. «Aumentare il traffico» non lo è.
Ritmo del traffic bot: la forma conta più del totale giornaliero
Il ritmo di una campagna va regolato sulla curva giornaliera del mercato di riferimento, aumentando il volume nell'arco di più giorni anziché attivarlo subito a pieno regime. Un flusso piatto e ininterrotto è al tempo stesso il segnale più chiaro di traffico sintetico e il modo più rapido per rendere prive di significato le proprie medie.
Una campagna che eroga 3.000 visite al giorno in un flusso piatto e uniformemente distribuito non somiglia affatto al traffico umano e non insegna nulla su come si comporta il sito in condizioni reali. Il pubblico reale arriva secondo una curva: più intenso nelle ore di veglia locali, più rado di notte, con forme diverse tra giorni feriali e fine settimana.
Due regole pratiche:
- Allineare la curva di erogazione al fuso orario della geografia di destinazione. Se si sta testando una landing page tedesca, un traffico che culmina alle 04:00 CET segnala che qualcosa è configurato male, e rende inoltre priva di significato qualsiasi media di coinvolgimento calcolata, perché media sulle ore sbagliate.
- Aumentare gradualmente anziché accendere di colpo. Passare da zero al volume pieno in un solo passo rende impossibile capire quale livello di volume abbia causato un problema al server o al tracciamento. Salendo a gradini nell'arco di più giorni si ottiene una soglia anziché un mistero.
Il ritmo protegge anche ciò che si sta misurando. Il tempo di risposta del server si degrada in modo non lineare sotto carico; un picco può produrre caricamenti lenti che deprimono le metriche di coinvolgimento per ragioni che nulla hanno a che fare con la qualità della fonte di traffico.
Mix di referrer e dispositivi: la plausibilità batte la varietà
C'è la tentazione di massimizzare la varietà (molti referrer, molti dispositivi, molti Paesi) partendo dall'idea che la diversità appaia naturale. Di solito appare peggio. Un sito piccolo che non si è mai posizionato al di fuori di un Paese non riceve all'improvviso visitatori da quaranta.
| Impostazione | Errore comune | Approccio migliore |
|---|---|---|
| Geografia | Distribuzione globale su un sito monomercato | Rispecchiare i Paesi già presenti nei dati organici |
| Mix di dispositivi | 100% desktop, oppure una divisione esatta 50/50 | Copiare dall'analytics il proprio rapporto tra mobile e desktop |
| Referrer | Decine di domini senza attinenza | Due o tre fonti plausibili, oppure solo traffico diretto |
| Profondità di sessione | Tutte le sessioni identiche | Una distribuzione: molte brevi, alcune profonde |
Il principio di fondo: i dati di analytics già disponibili descrivono che aspetto ha il plausibile per il proprio sito. Vanno usati come specifica, anziché inventarne una.
Scegliere la metrica di successo prima di guardare la dashboard
Una metrica scelta dopo l'arrivo dei dati non è una metrica: è la ricerca di qualcosa di lusinghiero. Si scelgano in anticipo un numero primario e un numero di controllo.
In una campagna orientata al test la metrica primaria di norma non è affatto il traffico, ma la fedeltà degli eventi: gli eventi che ci si aspettava sono davvero scattati, alla frequenza attesa, con i parametri attesi? Una campagna che rivela un evento purchase difettoso si è ripagata da sola, a prescindere da come sono andate le sessioni.
Il numero di controllo è quello che impone di fermarsi. Di solito: tasso di errori del server, tempo mediano di caricamento della pagina o tasso di sessioni con coinvolgimento. Se il numero di controllo si muove nella direzione sbagliata, la campagna si mette in pausa anche se la metrica primaria sembra a posto.
Cinque modalità di fallimento del traffic bot da riconoscere per tempo
- Il miraggio della frequenza di rimbalzo. Sessioni sintetiche con un tempo di permanenza definito da script producono una splendida frequenza di rimbalzo che non significa nulla. Se la frequenza di rimbalzo migliora nella settimana in cui parte una campagna, si tratta di un artefatto di misurazione, non di un miglioramento.
- Gonfiamento delle conversioni dovuto ai moduli di test. Se un bot raggiunge un modulo e il modulo genera un evento di conversione, il conteggio delle conversioni cresce e può crescere anche il tasso di conversione. A valle, quel numero può confluire nell'ottimizzazione delle piattaforme pubblicitarie e distorcere silenziosamente le offerte reali.
- L'illusione della pagina in cache. Richieste ripetute sullo stesso URL riscaldano la cache della CDN, quindi i tempi di caricamento scendono. Sembra un guadagno di prestazioni. Per verificarlo, si testi un URL a freddo.
- Limitazione silenziosa della frequenza. L'hosting o il WAF iniziano a limitare il traffico o a rispondergli con challenge senza avvisare. Le sessioni vengono comunque registrate, ma registrano fallimenti. Vanno osservati i log lato server, non solo l'analytics.
- Contaminazione dei report scoperta tardi. Qualcuno estrae un dato di traffico trimestrale che include la campagna. È il fallimento che danneggia la fiducia interna, ed è del tutto evitabile con disciplina nell'etichettatura.
Leggere i risultati insieme ai log del server, non con il solo analytics
È anche il modo per distinguere un tipo di traffico automatizzato da un altro. L'analytics racconta le sessioni che hanno eseguito JavaScript e inviato dati. I log del server raccontano ogni richiesta arrivata. Nello scarto tra i due si annidano i problemi interessanti.
Se il fornitore dichiara 10.000 visite, l'analytics mostra 6.000 sessioni e il log di accesso registra 10.000 richieste, si è imparato qualcosa di preciso: circa il 40% del traffico non esegue il tracciamento. Può andare bene per un test di carico ed essere inutile per un test comportamentale. In ogni caso, ora si sa quale dei due.
Quando fermare una campagna con traffic bot
Le condizioni di arresto vanno scritte prima del lancio e devono essere abbastanza meccaniche da poter essere applicate da un collega senza chiedere pareri:
- Il tasso di errori 5xx del server supera la sua banda normale per più di un'ora.
- Il tempo mediano di caricamento della pagina peggiora oltre una soglia concordata.
- Un evento di conversione scatta a una frequenza implausibile per il volume inviato.
- Il volume dichiarato dal fornitore e il log del server divergono oltre un margine concordato.
- Lo scopo della campagna ha ricevuto risposta: la condizione di arresto più spesso dimenticata.
Che cosa annotare al termine
Vanno registrate la configurazione (volume, ritmo, geografia, mix di dispositivi, referrer, durata), che cosa si stava testando, che cosa si è osservato e che cosa si è cambiato di conseguenza. Si includano anche le impostazioni che non hanno funzionato: altrimenti chi lancerà la prossima campagna le riscoprirà allo stesso prezzo.
Una nota utile sta in un paragrafo e risponde a una domanda: se rifacessimo tutto domani, che cosa faremmo di diverso?
Domande frequenti
Le campagne con traffic bot miglioreranno il mio posizionamento?
No. Il posizionamento risponde ai contenuti, ai link, alla scansionabilità e alla corrispondenza con l'intento, e nulla di tutto ciò è in vendita: il punto è trattato nella nostra guida a che cosa si vende davvero come traffico SEO. Una campagna può aiutare a verificare che l'analytics, il server e il funnel si comportino correttamente, il che è un vantaggio tecnico reale, ma di altra natura.
Quanto volume serve per un test utile?
Meno di quanto lascino intendere i pacchetti in offerta. Verificare che gli eventi scattino correttamente richiede decine di sessioni, non migliaia. Un volume elevato serve solo quando la domanda riguarda il carico.
Il traffico sintetico va escluso dall'analytics in modo permanente?
Sì, da qualsiasi vista di reportistica usata per decisioni aziendali. Va però mantenuto visibile in una vista o in un segmento dedicati, così da poter comunque esaminare i dati del test.
Qual è l'abitudine più preziosa in assoluto?
Etichettare ogni campagna in modo distinto fin dalla prima sessione. Quasi ogni problema serio di questo elenco diventa recuperabile se in seguito il traffico può essere isolato, e quasi irrecuperabile se non lo è.