Compartes un enlace de propuesta con un prospecto. Dos minutos después, tu herramienta de seguimiento dice que lo abrió, navegó por seis páginas y pasó 30 segundos en cada una.
Envías un correo de seguimiento. No tienen idea de qué les hablas, todavía no lo han abierto.
Lo que pasó: el escáner de seguridad de correo de su empresa abrió tu enlace antes que ellos. La "vista" fue un bot. Y a menos que tu plataforma de analíticas maneje esto específicamente, no puedes distinguir la diferencia.
Esto no es un caso excepcional. Ocurre prácticamente en cada correo enviado a destinatarios empresariales que usan Microsoft 365 o Google Workspace. En el cold outbound específicamente, donde cada enlace se reescribe a través de SafeLinks o Proofpoint antes de la entrega, del 60 al 70% de los clics que tu CRM registra son escáneres, no humanos, dependiendo del stack de seguridad de correo del destinatario.
¿Poco tiempo?
Salta a cómo lo resolvemos con tres capas de detección de bots, o mira lo que esto significa para tus analíticas.
Los bots que inflan tus analíticas
Hay tres categorías de tráfico 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 página inmediatamente para generar una tarjeta de vista previa. Estas solicitudes provienen de user agents identificables: Slackbot-LinkExpanding, LinkedInBot, Twitterbot. Son fáciles de detectar y filtrar. La mayoría de las herramientas de seguimiento manejan esto correctamente.
Rastreadores de motores de búsqueda
Googlebot, Bingbot y sus variantes indexan rutinariamente el contenido público. Estos también se identifican abiertamente y son sencillos de filtrar. Si tus enlaces compartidos están detrás de autenticación o usan slugs únicos, los rastreadores rara vez los encuentran.
Escáneres de seguridad de correo electrónico
Esta es la categoría que rompe las analíticas.
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 páginas de phishing y malware. Lo hacen abriendo realmente el enlace, cargando la página 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 móviles como "itel A27 Android." Tu servidor ve lo que parece una visita legítima de navegador.
- Navegación de páginas. SafeLinks no solo carga la primera página. Navega por aproximadamente 6 páginas de tu presentación, independientemente de la longitud total. Proofpoint realiza un escaneo multipágina 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 navegación rápida.
- Eventos DOM sintéticos. Algunos escáneres disparan eventos de JavaScript: scrolls programáticos, toques simulados, incluso eventos de clic, para activar cualquier script malicioso que pueda estar oculto detrás de la interacción del usuario.
El efecto neto: cada vez que envías por correo un enlace de presentación a alguien en una empresa que usa Microsoft 365 (es decir, la mayoría 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.
Así es cómo una sesión de bot de SafeLinks se compara con un visor humano real lado a lado:
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 redirección a través 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 está abriendo tu URL original directamente. Está haciendo clic en la URL reescrita de SafeLinks, que pasa primero por el proxy de Microsoft, y el proxy de Microsoft abre tu página para re-escanearla en ese momento. Luego redirige el navegador del usuario a tu página real.
El resultado: el escaneo del bot y la visita real ocurren simultáneamente. El escáner de seguridad abre tu presentación 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 idénticas. Si tus analíticas no pueden distinguirlas, o cuentas ambas (inflado) o te arriesgas a filtrar la real (subcontado).
Este es el escenario más difícil de manejar correctamente. El escaneo previo a la entrega es fácil 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 sesión separada que se superpone con la legítima.
La trampa del seguimiento
Si usas notificaciones de vistas para cronometrar tus seguimientos, las vistas de bots son activamente dañinas. Llamas a un prospecto "mientras está mirando tu presentación" y todavía no ha abierto su correo. Pareces agresivo en lugar de atento. Y con la reescritura de URLs, incluso el momento es engañoso: la sesión del bot comienza en el mismo instante que la real.
Por qué la detección estándar de bots no funciona
El enfoque estándar, verificar user agents contra una lista de bots conocidos, detecta los bots de vista previa de enlaces y rastreadores, pero falla completamente con los escáneres de seguridad de correo. SafeLinks deliberadamente usa user agents de apariencia real específicamente para evitar ser identificado, porque las páginas de phishing que detectan bots sirven contenido diferente al que sirven a usuarios reales.
La limitación 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 dirección diferente. No puedes bloquear por IP sin bloquear a usuarios legítimos en VPNs corporativas.
El fingerprinting de navegador (canvas, WebGL, enumeración de fuentes) no funciona porque SafeLinks ejecuta un navegador completo basado en Chromium. Su fingerprint es indistinguible de una instalación real de Chrome.
Cómo lo resolvemos: tres capas de detección
Construimos un sistema de detección que captura escáneres de seguridad de correo sin bloquear usuarios legítimos, incluyendo aquellos en VPNs y proxies corporativos.
Así es cómo el tráfico fluye a través 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 más de 60 patrones de bots conocidos: bots de vista previa de enlaces, rastreadores de búsqueda, navegadores headless, librerías de cliente HTTP. Si una solicitud se identifica como Slackbot o python-requests, la rechazamos inmediatamente. No se crea ninguna sesión.
Esto captura aproximadamente el 40% del tráfico de bots. El 40% fácil.
Capa 2: Detección de IP de datacenter
Los escáneres de seguridad de correo falsifican su user agent, pero no pueden ocultar desde dónde 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 geolocalización que reporta si la IP pertenece a un proveedor de alojamiento. Si es así, la sesión se marca como bot.
Esto captura la mayoría del tráfico de escáneres de seguridad de correo. Un visor conectándose 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 aquí: no bloqueamos estas sesiones. Creamos el registro de vista pero lo marcamos como bot, lo excluimos de las analíticas y no te enviamos una notificación. Esto nos permite auditar falsos positivos y da a los usuarios la opción de inspeccionar sesiones de bots si quieren investigar.
¿Qué pasa con los usuarios de VPN?
Los usuarios de VPN corporativa a veces se enrutan a través de IPs de datacenter, lo que significa que la Capa 2 podría 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: Confirmación humana basada en gestos
Esta es la capa crítica. Se basa en una observación simple: los humanos reales interactúan físicamente con la página. Los bots no, o cuando lo hacen, sus interacciones tienen una firma distintiva.
Cuando una sesión 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 táctiles, entrada de teclado y actividad de scroll.
Lo que ignoramos: Navegación de páginas, clics en enlaces y descargas. Esto es contraintuitivo: parecen señales fuertes de comportamiento humano. Pero SafeLinks navega por más de 6 páginas de cada presentación que escanea. Navegadores headless como Puppeteer pueden hacer clic programáticamente en botones y activar descargas. Estas acciones se pueden falsificar trivialmente. Los eventos de dispositivos de entrada de bajo nivel son mucho más difíciles de sintetizar de manera convincente.
La ventana de 3 segundos: Ignoramos todos los gestos en los primeros 3 segundos después de la carga de la página. SafeLinks y Proofpoint disparan sus eventos sintéticos casi inmediatamente, dentro de los 500 milisegundos de carga de la página. Los humanos reales tardan al menos 3 segundos en orientarse y comenzar a interactuar. Este único umbral de tiempo elimina la mayoría del ruido de eventos sintéticos.
Análisis de movimiento del mouse: Cuando detectamos un movimiento del mouse después 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 geométricas (líneas perfectamente rectas, círculos exactos) o disparan un solo evento. Los movimientos del mouse humanos tienen aceleración y desaceleración orgánica, curvas leves y micro-correcciones.
Cuando se detecta un gesto genuino, la sesión se "promueve" atómicamente de bot a real. En ese punto, y solo en ese punto, el conteo de vistas se incrementa y recibes una notificación.
La importancia del timing
Todo el sistema está diseñado en torno a una condición de carrera específica: qué pasa cuando un usuario real abre un enlace, mueve el mouse una vez e inmediatamente cierra la pestaña?
La solicitud de confirmación podría no completarse antes de que se cierre la pestaña. Los navegadores cancelan las solicitudes fetch() en curso durante la navegación. Así que usamos sendBeacon(), una API del navegador diseñada específicamente para solicitudes de tipo disparar-y-olvidar que sobreviven la descarga de la página, como respaldo. El beacon final lleva los datos de confirmación junto con las métricas de engagement de la sesión.
En el lado del servidor, la promoción es atómica: una única actualización SQL que solo tiene éxito si la sesión no ha sido promovida previamente. Esto previene el conteo doble cuando tanto la confirmación regular como el beacon de respaldo llegan.
Lo que esto significa para tus analíticas
El impacto práctico 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 políticas estrictas de seguridad de correo, el número era aún mayor.
Sin filtrado:
- Los conteos de vistas están inflados entre un 15 y un 40%
- Los prospectos "más comprometidos" pueden ser los que tienen la seguridad de correo más agresiva
- El momento de las vistas no es confiable: crees que alguien vio tu presentación a las 2 PM cuando el escáner de seguridad la abrió a la 1:58 PM
- Las señales de seguimiento son ruido
Con filtrado:
- Cada vista representa una persona real que realmente miró tu contenido: puedes ver quién realmente vio tu propuesta
- Las métricas de engagement (tiempo invertido, páginas vistas, tasa de completado) reflejan interés genuino
- Las notificaciones de vistas se activan cuando un humano está 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. Úsalo para verificar que el sistema funciona correctamente para tus prospectos específicos. Si ves que un visor legítimo está siendo marcado, la capa de confirmación por gestos debería promoverlo una vez que interactúe con la página. Si no lo hace, contacta a soporte.
La lección más amplia
El escaneo de seguridad de correo no va a desaparecer, se está volviendo más exhaustivo. Microsoft y Google están expandiendo el escaneo automatizado de enlaces a medida que los ataques de phishing se vuelven más sofisticados. Cualquier plataforma de analíticas que dependa de las cargas de página como proxy de vistas humanas será cada vez más imprecisa. Al evaluar herramientas de seguimiento de propuestas, la detección de bots debería ser un requisito innegociable. Los mismos bots que inflan las vistas de presentaciones también falsifican las tasas de apertura de email.
La señal que necesitas no es "fue mi enlace abierto." Es "¿un humano interactuó con mi contenido?" Eso requiere detectar la diferencia, y la diferencia está en los gestos, no en la carga de la página. Si estás levantando una ronda y te apoyas en las analíticas de deck para priorizar los follow-ups, consulta nuestra guía sobre cómo saber si los inversores realmente leen tu pitch deck para ver los datos que lo respaldan.