Por que tus analiticas de presentaciones estan mal: como los bots de seguridad de correo inflan tus conteos de vistas

HummingDeck Team··11 min de lectura

Compartes un enlace de propuesta con un prospecto. Dos minutos despues, tu herramienta de seguimiento dice que lo abrio, navego por seis paginas y paso 30 segundos en cada una.

Envias un correo de seguimiento. No tienen idea de que les hablas — todavia no lo han abierto.

Lo que paso: el escaner de seguridad de correo de su empresa abrio tu enlace antes que ellos. La "vista" fue un bot. Y a menos que tu plataforma de analiticas maneje esto especificamente, no puedes distinguir la diferencia.

Esto no es un caso excepcional. Ocurre practicamente en cada correo enviado a destinatarios empresariales que usan 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

Los bots que inflan tus analiticas

Hay tres categorias de trafico automatizado que llega a los enlaces compartidos de presentaciones:

Bots de vista previa de enlaces

Cuando pegas un enlace en Slack, LinkedIn, Twitter o iMessage, un bot obtiene la pagina inmediatamente para generar una tarjeta de vista previa. Estas solicitudes provienen de user agents identificables — Slackbot-LinkExpanding, LinkedInBot, Twitterbot. Son faciles de detectar y filtrar. La mayoria de las herramientas de seguimiento manejan esto correctamente.

Rastreadores de motores de busqueda

Googlebot, Bingbot y sus variantes indexan rutinariamente el contenido publico. Estos tambien se identifican abiertamente y son sencillos de filtrar. Si tus enlaces compartidos estan detras de autenticacion o usan slugs unicos, los rastreadores rara vez los encuentran.

Escaneres de seguridad de correo electronico

Esta es la categoria que rompe las analiticas.

Microsoft Defender SafeLinks, Proofpoint URL Defense, Mimecast y Google Safe Browsing escanean cada enlace en los correos entrantes antes de que el destinatario los vea. Su trabajo es detectar paginas de phishing y malware. Lo hacen abriendo realmente el enlace, cargando la pagina y, en muchos casos, navegando por su contenido.

Lo que los hace casi imposibles de distinguir de usuarios reales:

  • User agents falsificados. SafeLinks no se anuncia como un bot. Usa user agents de navegadores reales — cosas como "Chrome 120 on Windows 11" o incluso cadenas de dispositivos moviles como "itel A27 Android." Tu servidor ve lo que parece una visita legitima de navegador.
  • Navegacion de paginas. SafeLinks no solo carga la primera pagina. Navega por aproximadamente 6 paginas de tu presentacion, independientemente de la longitud total. Proofpoint realiza un escaneo multipagina similar.
  • Tiempos realistas. Estas sesiones duran entre 22 y 48 segundos. No pasan a toda velocidad como un scraper tosco — los tiempos parecen plausibles para una navegacion rapida.
  • Eventos DOM sinteticos. Algunos escaneres disparan eventos de JavaScript — scrolls programaticos, toques simulados, incluso eventos de clic — para activar cualquier script malicioso que pueda estar oculto detras de la interaccion del usuario.

El efecto neto: cada vez que envias por correo un enlace de presentacion a alguien en una empresa que usa Microsoft 365 (es decir, la mayoria de tus prospectos empresariales), obtienes una "vista" falsa que parece real. A veces dos — una del stack de seguridad del remitente y otra del destinatario.

Asi es como una sesion de bot de SafeLinks se compara con un visor humano real lado a lado:

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 reescritura de URLs lo empeora

Algunas herramientas de seguridad no solo pre-escanean enlaces — los reescriben completamente. SafeLinks reemplaza cada URL en el cuerpo del correo con una redireccion a traves de los propios servidores de Microsoft (https://nam02.safelinks.protection.outlook.com/...). Proofpoint hace lo mismo con sus reescrituras de URL Defense (https://urldefense.proofpoint.com/v2/...).

Cuando el destinatario finalmente hace clic en el enlace de su correo, no esta abriendo tu URL original directamente. Esta haciendo clic en la URL reescrita de SafeLinks, que pasa primero por el proxy de Microsoft — y el proxy de Microsoft abre tu pagina para re-escanearla en ese momento. Luego redirige el navegador del usuario a tu pagina real.

El resultado: el escaneo del bot y la visita real ocurren simultaneamente. El escaner de seguridad abre tu presentacion desde una IP de datacenter en el mismo segundo exacto en que el usuario real la abre desde su oficina. Obtienes dos sesiones concurrentes — una de bot, una humana — con marcas de tiempo casi identicas. Si tus analiticas no pueden distinguirlas, o cuentas ambas (inflado) o te arriesgas a filtrar la real (subcontado).

Este es el escenario mas dificil de manejar correctamente. El escaneo previo a la entrega es facil de identificar de forma aislada — llega minutos antes de que alguien haga clic. Pero el re-escaneo al momento del clic llega junto con el usuario real, desde una IP diferente, con un user agent diferente, creando una sesion separada que se superpone con la legitima.

La trampa del seguimiento

Si usas notificaciones de vistas para cronometrar tus seguimientos, las vistas de bots son activamente daninas. Llamas a un prospecto "mientras esta mirando tu presentacion" y todavia no ha abierto su correo. Pareces agresivo en lugar de atento. Y con la reescritura de URLs, incluso el momento es enganoso — la sesion del bot comienza en el mismo instante que la real.

Por que la deteccion estandar de bots no funciona

El enfoque estandar — verificar user agents contra una lista de bots conocidos — detecta los bots de vista previa de enlaces y rastreadores, pero falla completamente con los escaneres de seguridad de correo. SafeLinks deliberadamente usa user agents de apariencia real especificamente para evitar ser identificado, porque las paginas de phishing que detectan bots sirven contenido diferente al que sirven a usuarios reales.

La limitacion de tasa basada en IP tampoco ayuda. SafeLinks rota entre un conjunto de IPs de datacenters de Azure, por lo que cada escaneo viene de una direccion diferente. No puedes bloquear por IP sin bloquear a usuarios legitimos en VPNs corporativas.

El fingerprinting de navegador (canvas, WebGL, enumeracion de fuentes) no funciona porque SafeLinks ejecuta un navegador completo basado en Chromium. Su fingerprint es indistinguible de una instalacion real de Chrome.

Como lo resolvemos: tres capas de deteccion

Construimos un sistema de deteccion que captura escaneres de seguridad de correo sin bloquear usuarios legitimos — incluyendo aquellos en VPNs y proxies corporativos.

Asi es como el trafico fluye a traves de las tres capas. Pasa el cursor sobre cualquier nodo para trazar su ruta:

Capa 1: Coincidencia de user agent

La parte sencilla. Verificamos las solicitudes entrantes contra mas de 60 patrones de bots conocidos — bots de vista previa de enlaces, rastreadores de busqueda, navegadores headless, librerias de cliente HTTP. Si una solicitud se identifica como Slackbot o python-requests, la rechazamos inmediatamente. No se crea ninguna sesion.

Esto captura aproximadamente el 40% del trafico de bots. El 40% facil.

Capa 2: Deteccion de IP de datacenter

Los escaneres de seguridad de correo falsifican su user agent, pero no pueden ocultar desde donde se ejecutan. SafeLinks opera desde datacenters de Azure. Proofpoint se ejecuta en AWS. Estos son rangos de IP de proveedores de alojamiento conocidos.

Cuando un visor abre un enlace compartido, verificamos su IP contra un servicio de geolocalizacion que reporta si la IP pertenece a un proveedor de alojamiento. Si es asi, la sesion se marca como bot.

Esto captura la mayoria del trafico de escaneres de seguridad de correo. Un visor conectandose desde "Quincy, Washington" en una IP de Microsoft Azure a las 2 AM casi con certeza no es tu prospecto leyendo tu propuesta.

Hay una sutileza aqui: no bloqueamos estas sesiones. Creamos el registro de vista pero lo marcamos como bot, lo excluimos de las analiticas y no te enviamos una notificacion. Esto nos permite auditar falsos positivos y da a los usuarios la opcion de inspeccionar sesiones de bots si quieren investigar.

Que pasa con los usuarios de VPN?

Los usuarios de VPN corporativa a veces se enrutan a traves de IPs de datacenter, lo que significa que la Capa 2 podria marcar a un usuario real como bot. Por eso existe la Capa 3 — les da a los humanos una forma de "demostrar" que son reales, incluso si su IP parece de un datacenter.

Capa 3: Confirmacion humana basada en gestos

Esta es la capa critica. Se basa en una observacion simple: los humanos reales interactuan fisicamente con la pagina. Los bots no — o cuando lo hacen, sus interacciones tienen una firma distintiva.

Cuando una sesion se marca inicialmente como bot (desde la Capa 2), no la contamos como una vista real. En su lugar, observamos la entrada humana genuina:

Lo que monitoreamos: Movimiento del mouse, eventos tactiles, entrada de teclado y actividad de scroll.

Lo que ignoramos: Navegacion de paginas, clics en enlaces y descargas. Esto es contraintuitivo — parecen senales fuertes de comportamiento humano. Pero SafeLinks navega por mas de 6 paginas de cada presentacion que escanea. Navegadores headless como Puppeteer pueden hacer clic programaticamente en botones y activar descargas. Estas acciones se pueden falsificar trivialmente. Los eventos de dispositivos de entrada de bajo nivel son mucho mas dificiles de sintetizar de manera convincente.

La ventana de 3 segundos: Ignoramos todos los gestos en los primeros 3 segundos despues de la carga de la pagina. SafeLinks y Proofpoint disparan sus eventos sinteticos casi inmediatamente — dentro de los 500 milisegundos de carga de la pagina. Los humanos reales tardan al menos 3 segundos en orientarse y comenzar a interactuar. Este unico umbral de tiempo elimina la mayoria del ruido de eventos sinteticos.

Analisis de movimiento del mouse: Cuando detectamos un movimiento del mouse despues de la ventana de 3 segundos, registramos la trayectoria — coordenadas y marcas de tiempo de hasta 20 eventos de movimiento. Los movimientos del mouse generados por bots siguen trayectorias geometricas (lineas perfectamente rectas, circulos exactos) o disparan un solo evento. Los movimientos del mouse humanos tienen aceleracion y desaceleracion organica, curvas leves y micro-correcciones.

Cuando se detecta un gesto genuino, la sesion se "promueve" atomicamente de bot a real. En ese punto — y solo en ese punto — el conteo de vistas se incrementa y recibes una notificacion.

La importancia del timing

Todo el sistema esta disenado en torno a una condicion de carrera especifica: que pasa cuando un usuario real abre un enlace, mueve el mouse una vez e inmediatamente cierra la pestana?

La solicitud de confirmacion podria no completarse antes de que se cierre la pestana. Los navegadores cancelan las solicitudes fetch() en curso durante la navegacion. Asi que usamos sendBeacon() — una API del navegador disenada especificamente para solicitudes de tipo disparar-y-olvidar que sobreviven la descarga de la pagina — como respaldo. El beacon final lleva los datos de confirmacion junto con las metricas de engagement de la sesion.

En el lado del servidor, la promocion es atomica: una unica actualizacion SQL que solo tiene exito si la sesion no ha sido promovida previamente. Esto previene el conteo doble cuando tanto la confirmacion regular como el beacon de respaldo llegan.

Lo que esto significa para tus analiticas

El impacto practico es significativo. En nuestras pruebas con equipos de ventas enfocados en empresas, del 15 al 40% de las vistas aparentes de presentaciones eran sesiones de bots — principalmente de SafeLinks y Proofpoint. Para equipos que venden a grandes empresas con politicas estrictas de seguridad de correo, el numero era aun mayor.

Sin filtrado:

  • Los conteos de vistas estan inflados entre un 15 y un 40%
  • Los prospectos "mas comprometidos" pueden ser los que tienen la seguridad de correo mas agresiva
  • El momento de las vistas no es confiable — crees que alguien vio tu presentacion a las 2 PM cuando el escaner de seguridad la abrio a la 1:58 PM
  • Las senales de seguimiento son ruido

Con filtrado:

  • Cada vista representa una persona real que realmente miro tu contenido
  • Las metricas de engagement (tiempo invertido, paginas vistas, tasa de completado) reflejan interes genuino
  • Las notificaciones de vistas se activan cuando un humano esta activamente comprometido, no cuando un bot pre-escanea

Verificar sesiones de bots en HummingDeck

El feed de Actividad incluye un filtro "Mostrar sesiones de bots" que te permite inspeccionar las sesiones filtradas. Usalo para verificar que el sistema funciona correctamente para tus prospectos especificos — si ves que un visor legitimo esta siendo marcado, la capa de confirmacion por gestos deberia promoverlo una vez que interactue con la pagina. Si no lo hace, contacta a soporte.

HummingDeck Activity feed with bot sessions visible — dimmed rows with a robot icon indicate filtered bot traffic from SafeLinks and Proofpoint
Ejemplo de feed de Actividad con "Mostrar sesiones de bots" habilitado. Las sesiones de bots aparecen atenuadas con un icono de robot — observa las ubicaciones de datacenter y los conteos de paginas identicos.

La leccion mas amplia

El escaneo de seguridad de correo no va a desaparecer — se esta volviendo mas exhaustivo. Microsoft y Google estan expandiendo el escaneo automatizado de enlaces a medida que los ataques de phishing se vuelven mas sofisticados. Cualquier plataforma de analiticas que dependa de las cargas de pagina como proxy de vistas humanas sera cada vez mas imprecisa.

La senal que necesitas no es "fue mi enlace abierto." Es "un humano interactuo con mi contenido?" Eso requiere detectar la diferencia — y la diferencia esta en los gestos, no en la carga de la pagina.