Se sei un proprietario di un negozio online, un marketer o uno specialista del traffico, e la tua conversione dal traffico mobile è improvvisamente diminuita, il problema potrebbe non essere nei creativi o nella pagina di atterraggio. La questione è il CAPTCHA, che appare per una parte degli utenti mobili semplicemente perché si sono connessi da un indirizzo IP di un operatore di telefonia mobile. Analizziamo perché accade, quanti acquirenti reali si perdono e come verificarlo autonomamente in 15 minuti.
Perché gli utenti mobili vedono più spesso CAPTCHA: la causa è il CGNAT
La maggior parte degli operatori mobili — MTS, Beeline, MegaFon, Tele2 e i loro analoghi in altri paesi — utilizza la tecnologia CGNAT (Carrier-Grade NAT). Questo significa che migliaia, a volte decine di migliaia di abbonati reali si connettono contemporaneamente dietro lo stesso indirizzo IP esterno. Per il tuo sito e per i sistemi di protezione contro i bot (Cloudflare, reCAPTCHA, regole WAF proprietarie) questo appare come se da un unico IP arrivassero un numero anomalo di richieste in breve tempo.
Il sistema anti-bot non riesce a distinguere tra "500 persone diverse dalla stessa zona della città accedono al sito tramite internet mobile" e "un bot fa 500 richieste al minuto". Pertanto, scatta la protezione e l'intero range di IP riceve un livello di sospetto elevato — CAPTCHA, rallentamenti, e a volte anche un blocco totale dell'accesso.
Aggiungi a questo che gli indirizzi IP mobili vengono riutilizzati periodicamente tra diversi abbonati (l'operatore li assegna dinamicamente), e la reputazione di un determinato indirizzo può essere "rovinata" da un utente precedente — ad esempio, se da questo stesso IP ha recentemente lavorato un parser o un bot di spam. Il successivo abbonato che ottiene questo IP erediterà la cattiva reputazione e riceverà CAPTCHA, senza nemmeno sospettare il motivo.
Quanti acquirenti perdi a causa del CAPTCHA su mobile
Secondo diversi studi sull'UX e sulla conversione, ogni ulteriore verifica nel percorso dell'utente (CAPTCHA, conferma via SMS, "attendere, verifica del browser in corso") riduce il completamento dell'azione desiderata del 15–40%. Su dispositivi mobili, questo effetto si amplifica: schermo piccolo, input di testo scomodo con immagini distorte, connessione instabile — e parte degli utenti semplicemente chiude la scheda.
Per un negozio online, questo significa una perdita diretta di entrate: l'acquirente ha aggiunto un prodotto al carrello, è passato alla fase di pagamento, ma il sistema di protezione ha considerato il suo traffico sospetto proprio perché si è connesso tramite un operatore mobile con un pool IP condiviso. Non è un bot, non è un parser e non è un truffatore — è semplicemente una persona normale che ha deciso di pagare l'ordine con il telefono in metropolitana o in taxi.
Questo è particolarmente doloroso nei segmenti con un'alta percentuale di traffico mobile: consegna di cibo, marketplace, biglietti, prenotazione di servizi. Se il 60–70% degli ordini proviene da dispositivi mobili e parte di questo traffico viene "tagliato" dal CAPTCHA all'ingresso o al momento del pagamento — perdi denaro senza accorgertene, perché nell'analisi appare semplicemente come "abbandono sulla pagina di pagamento", senza annotazione "CAPTCHA colpevole".
Quali segnali fanno attivare i sistemi anti-bot per mostrare CAPTCHA
Per capire perché il tuo sito mostra CAPTCHA agli acquirenti mobili, è utile sapere a quali segnali reagiscono i moderni sistemi di protezione:
| Segnale | Come influisce sugli utenti mobili |
|---|---|
| Frequenza delle richieste da un IP | Il CGNAT unisce centinaia di abbonati — la soglia di attivazione viene superata senza bot |
| Reputazione IP (liste nere) | L'indirizzo è stato precedentemente utilizzato da uno spammer o un parser, la reputazione passa al nuovo abbonato |
| Geolocalizzazione vs fuso orario del dispositivo | In roaming o cambiando stazione base, la discrepanza provoca una verifica |
| Assenza di cronologia cookies/sessione | Un nuovo utente senza cronologia di visite appare automaticamente più sospetto |
| Cambio brusco di IP durante la sessione | Il passaggio tra le stazioni base dell'operatore cambia l'IP esterno al volo |
Un punto importante: questi segnali influenzano allo stesso modo sia gli acquirenti normali che coloro che testano la pubblicità o gestiscono più account per affari. Pertanto, comprendere la logica della protezione anti-bot è utile non solo per i proprietari di siti, ma anche per gli arbitraggisti che impostano campagne su Facebook Ads e TikTok Ads e affrontano verifiche simili da parte delle piattaforme pubblicitarie.
Come controllare il proprio sito con gli occhi di un acquirente mobile
Il modo più affidabile per scoprire se i tuoi reali acquirenti vedono CAPTCHA è non indovinare attraverso l'analisi, ma riprodurre la loro esperienza. Per fare ciò, devi accedere al sito da un indirizzo IP simile a quello con cui si connettono realmente gli utenti mobili. Ecco un piano passo-passo:
- Apri il sito da una normale connessione Wi-Fi e verifica se appare CAPTCHA durante il pagamento, l'autenticazione o l'accesso al sito.
- Collegati a un proxy mobile con IP dell'operatore della tua regione target — ad esempio, da un range MTS o MegaFon, se il pubblico principale è in Russia.
- Ripeti lo stesso percorso dell'utente: passaggio dalla pubblicità, aggiunta del prodotto al carrello, pagamento, transazione.
- Confronta i risultati: se CAPTCHA appare solo tramite il proxy mobile e non appare tramite Wi-Fi normale o IP di data center — il problema è proprio nei range CGNAT degli operatori.
- Testa diversi operatori e diverse regioni — a volte CAPTCHA scatta solo per IP di un particolare operatore, che ha un pool di indirizzi particolarmente "sporco".
Per questo tipo di test, i proxy mobili sono i più adatti — utilizzano indirizzi IP reali degli operatori di telefonia mobile, quindi vedrai il sito esattamente come lo vede un vero acquirente con il telefono in rete mobile, e non tramite Wi-Fi domestico o IP server di un data center.
Strumenti per il testing: proxy e browser anti-detect
Per garantire che il test sia corretto e ripetibile, è comodo utilizzare una combinazione di un browser anti-detect e proxy. I browser anti-detect — Dolphin Anty, AdsPower, Multilogin, GoLogin, Octo Browser — consentono di creare profili di browser isolati con diversi parametri di dispositivo, fuso orario e indirizzo IP. Questo è utile se desideri testare il sito contemporaneamente con diversi "acquirenti virtuali" da diverse regioni e operatori senza dover continuamente pulire i cookie e modificare le impostazioni.
L'algoritmo è semplice: crei un nuovo profilo in Dolphin Anty o AdsPower → nelle impostazioni del profilo indichi il tipo di proxy SOCKS5 o HTTP → inserisci login, password, host e porta del proxy mobile → scegli la regione e l'operatore desiderati → apri il profilo e accedi al tuo sito, ripetendo il percorso di un reale acquirente. In questo modo, in 15–20 minuti puoi testare 5–10 combinazioni di "regione + operatore" e vedere dove appare esattamente CAPTCHA.
Per confronto, vale anche la pena testare il sito tramite proxy residenziali — questi sono IP di normali utenti domestici, che in alcuni casi si trovano anche dietro NAT, ma con modelli di blocco meno aggressivi rispetto a quelli degli operatori mobili. La differenza nel comportamento del CAPTCHA tra IP mobili e residenziali aiuta a capire meglio quale logica anti-bot scatta sul tuo sito.
| Tipo di proxy | Cosa imita | Quando usarlo per il test |
|---|---|---|
| Proxy mobili | IP degli operatori di telefonia mobile, CGNAT | Controllo dell'esperienza degli acquirenti con il telefono nella rete mobile |
| Proxy residenziali | IP di provider domestici | Controllo dell'esperienza degli utenti con Wi-Fi domestico |
| Proxy di data center | IP server | Gruppo di controllo — di solito CAPTCHA non appare quasi mai o appare per un'altra ragione |
Checklist per la diagnosi del CAPTCHA sul sito
Prima di trarre conclusioni, segui una breve checklist — aiuta a distinguere il reale problema del CGNAT da altre cause di apparizione del CAPTCHA:
- Il CAPTCHA appare solo con proxy mobili, ma non con quelli residenziali e di data center — segno dell'effetto CGNAT.
- Il CAPTCHA appare con tutti i tipi di IP in modo simile — il problema è probabilmente nei trigger comportamentali (velocità dei clic, assenza di movimento del mouse nella versione desktop, modelli di navigazione).
- Il CAPTCHA appare più frequentemente con un particolare operatore — controlla la reputazione dei suoi range IP in servizi come AbuseIPDB o nel pannello del tuo WAF/CDN.
- Il CAPTCHA appare solo durante il pagamento, e non sulla homepage — probabilmente il problema è nelle impostazioni di protezione del gateway di pagamento o del sistema anti-frode, e non nella protezione generale del sito.
- Il CAPTCHA scompare dopo una nuova richiesta dopo 1–2 minuti — classico segno di rate-limit per IP, caratteristico proprio del CGNAT.
Come ridurre il numero di CAPTCHA per acquirenti legittimi
Se il test ha confermato che il problema è proprio nei range CGNAT mobili, ci sono alcuni passi pratici che puoi discutere con lo sviluppatore o l'agenzia che gestisce il sito:
- Rivedi le soglie di rate-limit. Se il limite di richieste da un IP al minuto è troppo rigido, aumentalo per i range appartenenti a noti operatori mobili.
- Utilizza l'analisi comportamentale invece di un semplice filtro IP. I moderni servizi di protezione (Cloudflare Bot Management, sistemi anti-frode proprietari) possono analizzare il movimento del cursore, la velocità di compilazione dei moduli e i modelli di tap sullo schermo — questo è più affidabile rispetto alla semplice frequenza delle richieste da IP.
- Aggiungi un CAPTCHA "soft" invece di uno "hard". invisible reCAPTCHA o verifica con un clic riducono l'attrito per gli utenti reali, mantenendo la protezione contro i bot automatici.
- Configura eccezioni per sessione e dispositivo. Se un utente ha già superato la verifica una volta, non mostrare nuovamente CAPTCHA all'interno della stessa sessione, anche se l'IP è cambiato a causa del passaggio della stazione base.
- Testa regolarmente tramite proxy mobili e residenziali dopo ogni aggiornamento delle regole anti-frode — questo consente di monitorare se la situazione è peggiorata dopo un ulteriore "aggiustamento della sicurezza".
Questi passi sono particolarmente importanti per i progetti di e-commerce, dove il traffico mobile rappresenta una grande parte degli ordini. La perdita anche del 5–10% degli acquirenti nella fase di pagamento a causa di controlli superflui si riflette direttamente sulle entrate, e tali perdite raramente compaiono nei report standard di web analytics come causa separata di abbandono.
Conclusione
CAPTCHA sul sito non significa sempre attività di bot — spesso è un effetto collaterale del CGNAT degli operatori mobili, che fa sì che migliaia di acquirenti reali condividano un unico indirizzo IP e vengano percepiti dal sistema anti-bot come traffico sospetto. Per capire l'entità del problema sul tuo sito, non è necessario indovinare attraverso i grafici nell'analisi — basta riprodurre il percorso di un acquirente attraverso un reale IP mobile e confrontare il risultato con una connessione normale.
Se desideri testare come appare il tuo sito per gli acquirenti delle reti mobili di diversi operatori e regioni, ti consigliamo di provare i proxy mobili — forniscono un'idea precisa di ciò che affronta il pubblico reale e aiutano a trovare rapidamente la causa di blocchi superflui prima che si riflettano sulle entrate.