Perché i Tuoi Analytics dei Deck Sono Sbagliati: Come i Bot di Sicurezza Email Gonfiano i Tuoi Conteggi

HummingDeck Team··11 min di lettura

Condividi il link di una proposta con un prospect. Due minuti dopo, il tuo strumento di tracciamento dice che l'hanno aperta, hanno sfogliato sei pagine e hanno dedicato 30 secondi a ciascuna.

Invii un'email di follow-up. Non hanno idea di cosa stai parlando — non l'hanno ancora aperta.

Cosa è successo: lo scanner di sicurezza email della loro azienda ha aperto il tuo link prima di loro. La "visualizzazione" era un bot. E a meno che la tua piattaforma di analytics non gestisca specificamente questo, non puoi distinguere la differenza.

Questo non è un caso limite raro. Succede praticamente su ogni email inviata a destinatari enterprise che usano Microsoft 365 o Google Workspace.

15–40%
of deck views are bots
Enterprise recipients with Microsoft 365
~6
pages navigated per scan
SafeLinks browses regardless of deck length
22–48s
average bot session duration
Enough to look like a quick browse
< 500ms
synthetic events after page load
Real humans take 3+ seconds to interact

Poco tempo?

Vai direttamente a come lo risolviamo con tre livelli di rilevamento bot, oppure scopri cosa significa per i tuoi analytics.

I bot che gonfiano i tuoi analytics

Ci sono tre categorie di traffico automatizzato che colpiscono i link dei deck condivisi:

Quando incolli un link in Slack, LinkedIn, Twitter o iMessage, un bot recupera immediatamente la pagina per generare una scheda di anteprima. Queste richieste provengono da user agent identificabili — Slackbot-LinkExpanding, LinkedInBot, Twitterbot. Sono facili da rilevare e filtrare. La maggior parte degli strumenti di tracciamento li gestisce correttamente.

Crawler dei motori di ricerca

Googlebot, Bingbot e le loro varianti indicizzano regolarmente i contenuti pubblici. Anche questi si identificano apertamente e sono semplici da filtrare. Se i tuoi link condivisi sono dietro autenticazione o usano slug unici, i crawler li trovano raramente comunque.

Scanner di sicurezza email

Questa è la categoria che rompe gli analytics.

Microsoft Defender SafeLinks, Proofpoint URL Defense, Mimecast e Google Safe Browsing scansionano ogni link nelle email in arrivo prima che il destinatario le veda. Il loro compito è rilevare pagine di phishing e malware. Lo fanno aprendo effettivamente il link, caricando la pagina e in molti casi navigando attraverso il suo contenuto.

Cosa li rende quasi impossibili da distinguere dagli utenti reali:

  • User agent falsificati. SafeLinks non si annuncia come bot. Usa user agent reali del browser — cose come "Chrome 120 su Windows 11" o persino stringhe di dispositivi mobili come "itel A27 Android". Il tuo server vede quella che sembra una visita legittima del browser.
  • Navigazione nelle pagine. SafeLinks non carica solo la prima pagina. Naviga attraverso circa 6 pagine del tuo deck, indipendentemente dalla lunghezza totale. Proofpoint fa una scansione multi-pagina simile.
  • Timing realistico. Queste sessioni durano 22-48 secondi. Non passano tutto istantaneamente come uno scraper grezzo — il timing appare plausibile per una sfogliata veloce.
  • Eventi DOM sintetici. Alcuni scanner attivano eventi JavaScript — scroll programmatici, touch simulati, persino eventi di clic — per innescare eventuali script malevoli nascosti dietro l'interazione dell'utente.

L'effetto netto: ogni volta che invii un link a un deck via email a qualcuno in un'azienda che usa Microsoft 365 (cioè la maggior parte dei tuoi prospect enterprise), ottieni una "visualizzazione" falsa che sembra reale. A volte due — una dallo stack di sicurezza del mittente e una da quello del destinatario.

Ecco come una sessione bot di SafeLinks si confronta con un visualizzatore umano reale fianco a fianco:

Signal
SafeLinks Bot
Real Human
User agent
"Chrome 120 on Windows 11"
"Chrome 120 on Windows 11"
First page load
< 100ms after email delivered
Seconds to minutes after open
Pages visited
Same count every scan of the same doc
Varies by interest
Session duration
22–48 seconds
30 seconds to 15+ minutes
Mouse movement
None or single synthetic event
Organic curves with micro-corrections
Scroll behavior
Programmatic jumps
Variable speed with pauses
Click events
Dispatched via JavaScript
Preceded by mouse hover
IP origin
Azure / AWS datacenter
ISP, office, or mobile network
Timing pattern
Identical cadence every scan
Unpredictable, varies each visit
Highlighted rows show where bot and human behavior differ most — these are the signals that matter for detection.

La riscrittura degli URL peggiora le cose

Alcuni strumenti di sicurezza non si limitano a pre-scansionare i link — li riscrivono completamente. SafeLinks sostituisce ogni URL nel corpo dell'email con un redirect attraverso i server di Microsoft (https://nam02.safelinks.protection.outlook.com/...). Proofpoint fa lo stesso con le sue riscritture URL Defense (https://urldefense.proofpoint.com/v2/...).

Quando il destinatario finalmente clicca il link nella sua email, non sta aprendo il tuo URL originale direttamente. Sta cliccando l'URL SafeLinks riscritto, che passa attraverso il proxy di Microsoft prima — e il proxy di Microsoft apre la tua pagina per ri-scansionarla in quel momento. Poi redirige il browser dell'utente alla tua pagina effettiva.

Il risultato: la scansione del bot e la visita reale avvengono simultaneamente. Lo scanner di sicurezza apre il tuo deck da un IP di datacenter nello stesso secondo in cui l'utente reale lo apre dal suo ufficio. Ottieni due sessioni concorrenti — una bot, una umana — con timestamp quasi identici. Se i tuoi analytics non riescono a distinguerle, o le conti entrambe (gonfiate) o rischi di filtrare quella reale (sottostimate).

Questo è lo scenario più difficile da gestire correttamente. La scansione pre-consegna è facile da identificare in isolamento — arriva minuti prima che qualcuno clicchi. Ma la ri-scansione al momento del clic arriva insieme all'utente reale, da un IP diverso, con un user agent diverso, creando una sessione separata che si sovrappone a quella legittima.

La trappola del follow-up

Se usi le notifiche delle visualizzazioni per tempificare i tuoi follow-up, le visualizzazioni bot sono attivamente dannose. Chiami un prospect "mentre sta guardando il tuo deck" e non ha ancora aperto la sua email. Sembri aggressivo invece che attento. E con la riscrittura degli URL, persino il timing è ingannevole — la sessione bot inizia nello stesso momento di quella reale.

Perché il rilevamento bot standard non funziona

L'approccio standard — controllare gli user agent contro una lista di bot noti — cattura i bot di anteprima link e i crawler ma manca completamente gli scanner di sicurezza email. SafeLinks usa deliberatamente user agent dall'aspetto reale specificamente per evitare di essere identificato, perché le pagine di phishing che rilevano i bot servono contenuti diversi rispetto a quelli che servono agli utenti reali.

Il rate limiting basato su IP non aiuta nemmeno. SafeLinks ruota attraverso un pool di IP di datacenter Azure, quindi ogni scansione proviene da un indirizzo diverso. Non puoi bloccare per IP senza bloccare utenti legittimi su VPN aziendali.

Il fingerprinting del browser (canvas, WebGL, enumerazione dei font) non funziona perché SafeLinks esegue un browser completo basato su Chromium. La sua impronta è indistinguibile da un'installazione reale di Chrome.

Come lo risolviamo: tre livelli di rilevamento

Abbiamo costruito un sistema di rilevamento che cattura gli scanner di sicurezza email senza bloccare gli utenti legittimi — inclusi quelli su VPN e proxy aziendali.

Ecco come il traffico fluisce attraverso i tre livelli. Passa il mouse su qualsiasi nodo per tracciare il suo percorso:

Livello 1: Matching dello user agent

La parte semplice. Controlliamo le richieste in arrivo contro 60+ pattern di bot noti — bot di anteprima link, crawler di ricerca, browser headless, librerie client HTTP. Se una richiesta si identifica come Slackbot o python-requests, la rifiutiamo immediatamente. Nessuna sessione viene creata.

Questo cattura circa il 40% del traffico bot. Il 40% facile.

Livello 2: Rilevamento IP di datacenter

Gli scanner di sicurezza email falsificano il loro user agent ma non possono nascondere da dove vengono eseguiti. SafeLinks opera dai datacenter Azure. Proofpoint gira su AWS. Questi sono range di IP di hosting provider noti.

Quando un visualizzatore apre un link condiviso, controlliamo il suo IP contro un servizio di geolocalizzazione che riporta se l'IP appartiene a un hosting provider. Se è così, la sessione viene segnalata come bot.

Questo cattura la maggioranza del traffico degli scanner di sicurezza email. Un visualizzatore che si connette da "Quincy, Washington" su un IP Microsoft Azure alle 2 di notte non è quasi certamente il tuo prospect che legge la tua proposta.

C'è una sottigliezza qui: non blocchiamo queste sessioni. Creiamo il record della visualizzazione ma lo segnaliamo come bot, lo escludiamo dagli analytics e non ti inviamo una notifica. Questo ci permette di verificare i falsi positivi e dà agli utenti la possibilità di ispezionare le sessioni bot se vogliono indagare.

E gli utenti VPN?

Gli utenti su VPN aziendali a volte transitano attraverso IP di datacenter, il che significa che il Livello 2 potrebbe segnalare un utente reale come bot. Per questo esiste il Livello 3 — dà agli umani un percorso per "dimostrare" che sono reali, anche se il loro IP sembra quello di un datacenter.

Livello 3: Conferma umana basata sui gesti

Questo è il livello critico. Si basa su un'osservazione semplice: gli umani reali interagiscono fisicamente con la pagina. I bot no — o quando lo fanno, le loro interazioni hanno una firma distintiva.

Quando una sessione viene inizialmente segnalata come bot (dal Livello 2), non la contiamo come visualizzazione reale. Invece, osserviamo input umani genuini:

Cosa monitoriamo: Movimento del mouse, eventi touch, input da tastiera e attività di scroll.

Cosa ignoriamo: Navigazione tra pagine, clic sui link e download. Questo è controintuitivo — sembrano segnali forti di comportamento umano. Ma SafeLinks naviga attraverso 6+ pagine di ogni deck che scansiona. Browser headless come Puppeteer possono cliccare pulsanti e avviare download programmaticamente. Queste azioni possono essere falsificate banalmente. Gli eventi di input a basso livello dei dispositivi sono molto più difficili da sintetizzare in modo convincente.

La finestra di 3 secondi: Ignoriamo tutti i gesti nei primi 3 secondi dopo il caricamento della pagina. SafeLinks e Proofpoint attivano i loro eventi sintetici quasi immediatamente — entro 500 millisecondi dal caricamento della pagina. Gli umani reali impiegano almeno 3 secondi per orientarsi e iniziare a interagire. Questa singola soglia temporale elimina la maggioranza del rumore degli eventi sintetici.

Analisi del movimento del mouse: Quando rileviamo un movimento del mouse dopo la finestra di 3 secondi, registriamo la traiettoria — coordinate e timestamp di fino a 20 eventi di movimento. I movimenti del mouse generati dai bot seguono percorsi geometrici (linee perfettamente dritte, cerchi esatti) o attivano un singolo evento. I movimenti del mouse umani hanno accelerazione e decelerazione organiche, leggere curve e micro-correzioni.

Quando un gesto genuino viene rilevato, la sessione viene "promossa" atomicamente da bot a reale. A quel punto — e solo a quel punto — il conteggio delle visualizzazioni si incrementa e ricevi una notifica.

Il timing conta

L'intero sistema è progettato attorno a una specifica race condition: cosa succede quando un utente reale apre un link, muove il mouse una volta e chiude immediatamente la scheda?

La richiesta di conferma potrebbe non completarsi prima che la scheda si chiuda. I browser cancellano le richieste fetch() in corso durante la navigazione. Quindi usiamo sendBeacon() — un'API del browser specificamente progettata per richieste fire-and-forget che sopravvivono alla chiusura della pagina — come backup. Il beacon finale trasporta i dati di conferma insieme alle metriche di engagement della sessione.

Lato server, la promozione è atomica: un singolo update SQL che ha successo solo se la sessione non è già stata promossa. Questo previene il conteggio doppio quando sia la conferma regolare che il beacon di backup arrivano.

Cosa significa per i tuoi analytics

L'impatto pratico è significativo. Nei nostri test su team commerciali focalizzati sull'enterprise, il 15-40% delle visualizzazioni apparenti dei deck erano sessioni bot — principalmente da SafeLinks e Proofpoint. Per i team che vendono a grandi enterprise con politiche di sicurezza email rigide, il numero era ancora più alto.

Senza filtraggio:

  • I conteggi delle visualizzazioni sono gonfiati del 15-40%
  • I prospect "più coinvolti" potrebbero essere quelli con la sicurezza email più aggressiva
  • Il timing delle visualizzazioni è inaffidabile — pensi che qualcuno abbia visualizzato il tuo deck alle 14:00 quando lo scanner di sicurezza l'ha aperto alle 13:58
  • I segnali di follow-up sono rumore

Con filtraggio:

  • Ogni visualizzazione rappresenta una persona reale che ha effettivamente guardato il tuo contenuto
  • Le metriche di engagement (tempo dedicato, pagine visualizzate, tasso di completamento) riflettono interesse genuino
  • Le notifiche delle visualizzazioni si attivano quando un umano è attivamente coinvolto, non quando un bot pre-scansiona

Verificare le sessioni bot in HummingDeck

Il feed Attività include un filtro "Mostra sessioni bot" che ti permette di ispezionare le sessioni filtrate. Usalo per verificare che il sistema funzioni correttamente per i tuoi prospect specifici — se vedi un visualizzatore legittimo segnalato come bot, il livello di conferma tramite gesti dovrebbe promuoverlo una volta che interagisce con la pagina. Se non succede, contatta il supporto.

Feed Attività di HummingDeck con sessioni bot visibili — righe sbiadite con icona robot indicano traffico bot filtrato da SafeLinks e Proofpoint
Esempio di feed Attività con "Mostra sessioni bot" abilitato. Le sessioni bot appaiono sbiadite con un'icona robot — nota le posizioni dei datacenter e i conteggi di pagine identici.

La lezione più ampia

La scansione di sicurezza email non sta scomparendo — sta diventando più approfondita. Microsoft e Google stanno espandendo la scansione automatizzata dei link man mano che gli attacchi di phishing diventano più sofisticati. Qualsiasi piattaforma di analytics che si basa sui caricamenti di pagina come proxy per le visualizzazioni umane diventerà sempre più inaccurata. Gli stessi bot che gonfiano le visualizzazioni dei deck falsificano anche i tassi di apertura email.

Il segnale di cui hai bisogno non è "il mio link è stato aperto". È "un umano ha interagito con il mio contenuto". Questo richiede rilevare la differenza — e la differenza sta nei gesti, non nel caricamento della pagina.