Você compartilha um link de proposta com um prospect. Dois minutos depois, sua ferramenta de rastreamento diz que ele abriu, navegou por seis páginas e passou 30 segundos em cada uma.
Você dispara um email de follow-up. O prospect não faz ideia do que você está falando — ele ainda nem abriu o link.
O que aconteceu: o scanner de segurança de email da empresa dele abriu seu link antes dele. A "visualização" foi um bot. E a menos que sua plataforma de analítica trate isso especificamente, você não consegue distinguir um do outro.
Isso não é um caso raro. Acontece em praticamente todo email enviado para destinatários corporativos que usam Microsoft 365 ou Google Workspace.
Os bots que inflam sua analítica
Existem três categorias de tráfego automatizado que acessam links compartilhados de apresentações:
Bots de pré-visualização de links
Quando você cola um link no Slack, LinkedIn, Twitter ou iMessage, um bot imediatamente busca a página para gerar um cartão de pré-visualização. Essas requisições vêm com user agents identificáveis — Slackbot-LinkExpanding, LinkedInBot, Twitterbot. São fáceis de detectar e filtrar. A maioria das ferramentas de rastreamento lida com eles corretamente.
Crawlers de mecanismos de busca
Googlebot, Bingbot e suas variantes indexam rotineiramente conteúdo público. Eles também se identificam abertamente e são simples de filtrar. Se seus links compartilhados estão atrás de autenticação ou usam slugs únicos, crawlers raramente os encontram.
Scanners de segurança de email
Esta é a categoria que quebra a analítica.
Microsoft Defender SafeLinks, Proofpoint URL Defense, Mimecast e Google Safe Browsing escaneiam cada link em emails recebidos antes que o destinatário os veja. Sua função é detectar páginas de phishing e malware. Fazem isso abrindo efetivamente o link, carregando a página e, em muitos casos, navegando pelo seu conteúdo.
O que os torna quase impossíveis de distinguir de usuários reais:
- User agents falsificados. SafeLinks não se anuncia como bot. Ele usa user agents reais de navegadores — coisas como "Chrome 120 on Windows 11" ou até strings de dispositivos móveis como "itel A27 Android." Seu servidor vê o que parece uma visita legítima de navegador.
- Navegação entre páginas. SafeLinks não carrega apenas a primeira página. Ele navega por aproximadamente 6 páginas da sua apresentação, independentemente do total. Proofpoint faz um escaneamento multi-página semelhante.
- Timing realista. Essas sessões duram de 22 a 48 segundos. Não passam voando instantaneamente como um scraper grosseiro — o timing parece plausível para uma navegação rápida.
- Eventos DOM sintéticos. Alguns scanners disparam eventos JavaScript — scrolls programáticos, toques simulados, até eventos de clique — para acionar scripts maliciosos que possam estar escondidos atrás de interação do usuário.
O efeito final: toda vez que você envia um link de apresentação por email para alguém em uma empresa que usa Microsoft 365 (ou seja, a maioria dos seus prospects corporativos), você recebe uma "visualização" falsa que parece real. Às vezes duas — uma do stack de segurança do remetente e outra do destinatário.
Veja como uma sessão de bot SafeLinks se compara a um visualizador humano real, lado a lado:
A reescrita de URL piora tudo
Algumas ferramentas de segurança não apenas pré-escaneiam links — elas os reescrevem completamente. SafeLinks substitui cada URL no corpo do email por um redirecionamento através dos próprios servidores da Microsoft (https://nam02.safelinks.protection.outlook.com/...). Proofpoint faz o mesmo com suas reescritas de URL Defense (https://urldefense.proofpoint.com/v2/...).
Quando o destinatário finalmente clica no link do email, ele não está abrindo sua URL original diretamente. Ele está clicando na URL reescrita do SafeLinks, que passa pelo proxy da Microsoft primeiro — e o proxy da Microsoft abre sua página para reescaneá-la naquele momento. Depois redireciona o navegador do usuário para sua página real.
O resultado: o escaneamento do bot e a visita real acontecem simultaneamente. O scanner de segurança abre sua apresentação a partir de um IP de datacenter no exato mesmo segundo em que o usuário real abre a partir do escritório. Você recebe duas sessões simultâneas — uma bot, uma humana — com timestamps quase idênticos. Se sua analítica não consegue diferenciá-las, você ou conta ambas (inflado) ou corre o risco de filtrar a real (subcontado).
Este é o cenário mais difícil de tratar corretamente. O escaneamento pré-entrega é fácil de identificar isoladamente — chega minutos antes de alguém clicar. Mas o re-escaneamento no momento do clique chega junto com o usuário real, de um IP diferente, com um user agent diferente, criando uma sessão separada que se sobrepõe à legítima.
A armadilha do follow-up
Se você está usando notificações de visualização para cronometrar seus follow-ups, visualizações de bots são ativamente prejudiciais. Você liga para um prospect "enquanto ele está olhando sua apresentação" e ele sequer abriu o email ainda. Você parece agressivo em vez de atencioso. E com a reescrita de URL, até o timing é enganoso — a sessão do bot começa no mesmo momento que a real.
Por que a detecção padrão de bots não funciona
A abordagem padrão — verificar user agents contra uma lista de bots conhecidos — pega bots de pré-visualização e crawlers, mas falha completamente com scanners de segurança de email. SafeLinks deliberadamente usa user agents realistas especificamente para evitar ser identificado, porque páginas de phishing que detectam bots servem conteúdo diferente do que servem para usuários reais.
Limitação por IP também não ajuda. SafeLinks rotaciona entre um pool de IPs de datacenters Azure, então cada escaneamento vem de um endereço diferente. Você não pode bloquear por IP sem bloquear usuários legítimos em VPNs corporativas.
Fingerprinting de navegador (canvas, WebGL, enumeração de fontes) não funciona porque SafeLinks roda um navegador completo baseado em Chromium. Seu fingerprint é indistinguível de uma instalação real do Chrome.
Como resolvemos: três camadas de detecção
Construímos um sistema de detecção que captura scanners de segurança de email sem bloquear usuários legítimos — incluindo aqueles em VPNs corporativas e proxies.
Veja como o tráfego flui pelas três camadas. Passe o mouse sobre qualquer nó para rastrear seu caminho:
Camada 1: Correspondência de user agent
A parte direta. Verificamos requisições recebidas contra 60+ padrões conhecidos de bots — bots de pré-visualização, crawlers de busca, headless browsers, bibliotecas de cliente HTTP. Se uma requisição se identifica como Slackbot ou python-requests, rejeitamos imediatamente. Nenhuma sessão é criada.
Isso captura cerca de 40% do tráfego de bots. Os 40% fáceis.
Camada 2: Detecção de IP de datacenter
Scanners de segurança de email falsificam seu user agent, mas não podem esconder de onde estão rodando. SafeLinks opera a partir de datacenters Azure. Proofpoint roda na AWS. Esses são intervalos de IP de provedores de hospedagem conhecidos.
Quando um visualizador abre um link compartilhado, verificamos seu IP contra um serviço de geolocalização que informa se o IP pertence a um provedor de hospedagem. Se pertence, a sessão é marcada como bot.
Isso captura a maioria do tráfego de scanners de segurança de email. Um visualizador conectando a partir de "Quincy, Washington" em um IP Microsoft Azure às 2 da manhã quase certamente não é seu prospect lendo sua proposta.
Há uma sutileza aqui: nós não bloqueamos essas sessões. Criamos o registro de visualização, mas marcamos como bot, excluímos da analítica e não enviamos notificação. Isso nos permite auditar falsos positivos e dá aos usuários a opção de inspecionar sessões de bots se quiserem investigar.
E os usuários de VPN?
Usuários de VPN corporativa às vezes roteiam através de IPs de datacenter, o que significa que a Camada 2 pode marcar um usuário real como bot. Por isso a Camada 3 existe — ela dá aos humanos um caminho para "provar" que são reais, mesmo que seu IP pareça ser de um datacenter.
Camada 3: Confirmação humana baseada em gestos
Esta é a camada crítica. Ela se baseia em uma observação simples: humanos reais interagem fisicamente com a página. Bots não — ou quando interagem, suas interações têm uma assinatura distinta.
Quando uma sessão é inicialmente marcada como bot (pela Camada 2), nós não a contamos como uma visualização real. Em vez disso, observamos input humano genuíno:
O que monitoramos: Movimento do mouse, eventos de toque, entrada de teclado e atividade de scroll.
O que ignoramos: Navegação entre páginas, cliques em links e downloads. Isso é contraintuitivo — parecem sinais fortes de comportamento humano. Mas SafeLinks navega por 6+ páginas de cada apresentação que escaneia. Headless browsers como Puppeteer podem clicar botões e acionar downloads programaticamente. Essas ações podem ser falsificadas trivialmente. Eventos de dispositivos de entrada de baixo nível são muito mais difíceis de sintetizar de forma convincente.
A janela de 3 segundos: Ignoramos todos os gestos nos primeiros 3 segundos após o carregamento da página. SafeLinks e Proofpoint disparam seus eventos sintéticos quase imediatamente — dentro de 500 milissegundos do carregamento da página. Humanos reais levam pelo menos 3 segundos para se orientar e começar a interagir. Esse único limiar de tempo elimina a maioria do ruído de eventos sintéticos.
Análise de movimento do mouse: Quando detectamos um movimento de mouse após a janela de 3 segundos, registramos a trajetória — coordenadas e timestamps de até 20 eventos de movimento. Movimentos de mouse gerados por bots seguem caminhos geométricos (linhas perfeitamente retas, círculos exatos) ou disparam um único evento. Movimentos humanos de mouse têm aceleração e desaceleração orgânicas, curvas suaves e microcorreções.
Quando um gesto genuíno é detectado, a sessão é atomicamente "promovida" de bot para real. Nesse ponto — e somente nesse ponto — o contador de visualizações incrementa e você recebe uma notificação.
O timing importa
Todo o sistema é projetado em torno de uma condição de corrida específica: o que acontece quando um usuário real abre um link, move o mouse uma vez e fecha a aba imediatamente?
A requisição de confirmação pode não ser concluída antes do fechamento da aba. Navegadores cancelam requisições fetch() em andamento durante a navegação. Por isso usamos sendBeacon() — uma API de navegador projetada especificamente para requisições do tipo "disparar e esquecer" que sobrevivem ao descarregamento da página — como backup. O beacon final carrega os dados de confirmação junto com as métricas de engajamento da sessão.
No lado do servidor, a promoção é atômica: um único update SQL que só é bem-sucedido se a sessão ainda não foi promovida. Isso previne contagem dupla quando tanto a confirmação regular quanto o beacon de backup chegam.
O que isso significa para sua analítica
O impacto prático é significativo. Em nossos testes com equipes de vendas focadas no mercado corporativo, 15–40% das visualizações aparentes de apresentações eram sessões de bots — principalmente de SafeLinks e Proofpoint. Para equipes que vendem para grandes empresas com políticas rigorosas de segurança de email, o número era ainda maior.
Sem filtragem:
- Contagens de visualização são infladas em 15–40%
- Os prospects "mais engajados" podem ser aqueles com a segurança de email mais agressiva
- O timing de visualização não é confiável — você acha que alguém viu sua apresentação às 14h quando o scanner de segurança abriu às 13:58
- Sinais de follow-up são ruído
Com filtragem:
- Cada visualização representa uma pessoa real que efetivamente olhou seu conteúdo
- Métricas de engajamento (tempo gasto, páginas visualizadas, taxa de conclusão) refletem interesse genuíno
- Notificações de visualização disparam quando um humano está ativamente engajado, não quando um bot pré-escaneia
Verificando sessões de bots no HummingDeck
O feed de Atividade inclui um filtro "Mostrar sessões de bots" que permite inspecionar sessões filtradas. Use-o para verificar se o sistema está funcionando corretamente para seus prospects específicos — se você vir um visualizador legítimo sendo marcado, a camada de confirmação por gestos deve promovê-lo assim que ele interagir com a página. Se isso não acontecer, entre em contato com o suporte.
A lição mais ampla
O escaneamento de segurança de email não vai desaparecer — está ficando mais minucioso. Microsoft e Google estão expandindo o escaneamento automatizado de links à medida que ataques de phishing se tornam mais sofisticados. Qualquer plataforma de analítica que dependa de carregamentos de página como proxy para visualizações humanas vai se tornar cada vez mais imprecisa.
O sinal que você precisa não é "meu link foi aberto." É "um humano interagiu com meu conteúdo." Isso requer detectar a diferença — e a diferença está nos gestos, não no carregamento da página.