Tu monitor de tiempo de actividad informa 100%. Tus servidores responden en 180 ms. Y los pedidos han bajado un 30% desde el martes por la mañana.
La monitorización de la experiencia digital (DEM) existe para esa situación. Las métricas del lado del servidor confirman que tu infraestructura respondió. No dicen nada sobre si un comprador en Frankfurt pudo realmente completar el pago en un Android de gama media con un script de pago lento delante del botón de pagar.
La mayoría de las guías sobre este tema definen DEM para equipos de TI que supervisan laptops de empleados y túneles VPN. Esta cubre la otra versión: monitorizar los trayectos de cara al cliente que generan ingresos. Qué mide el DEM, dónde cada fuente de datos se queda ciega, cómo configurarlo en una tienda real y qué comprobación de Dotcom-Monitor detecta cada fallo.
Qué encontrarás en esta guía
- ¿Qué es la monitorización de la experiencia digital?
- Por qué tus paneles se ponen verdes mientras el pago está roto
- Monitorización sintética vs. RUM vs. análisis de ruta de red
- Qué medir en un camino de ingresos
- Cuatro fallos que tu chequeo de uptime no detectará
- Cómo configurar la monitorización de la experiencia digital
- Cómo elegir una herramienta de monitorización de la experiencia digital
- Cómo Dotcom-Monitor maneja la monitorización de la experiencia digital
- Preguntas frecuentes sobre monitorización de la experiencia digital
- Conclusión
¿Qué es la monitorización de la experiencia digital?
La monitorización de la experiencia digital es la práctica de medir cómo las personas experimentan tu sitio web o aplicación de extremo a extremo, a través de la red, navegador y dispositivo que usan para acceder a ti. En lugar de preguntar “¿respondió el servidor?”, pregunta “¿alguien pudo completar lo que vino a hacer y cuánto le tomó?”. Esa medición puede provenir de sesiones reales, de trayectos programados que se ejecutan a intervalos, o de ambos.
El alcance es más amplio que el tiempo de actividad. Una configuración de DEM supervisa el renderizado de páginas, transacciones de múltiples pasos como búsqueda y pago, las API detrás de esos pasos, los scripts de terceros y cómo todo cambia según la región, navegador y velocidad de conexión. Verás esta práctica también bajo nombres como monitorización de la experiencia del usuario final, monitorización de la experiencia de la aplicación o gestión de la experiencia digital. Las etiquetas varían; lo que se mide mayormente no.
Los dos tipos de DEM (y por qué se confunden)
Busca este término y la primera página está dominada por proveedores de red y seguridad: Palo Alto Networks, Fortinet, Cloudflare, ThousandEyes, Tanium. La mayoría de lo que describen esas páginas es para empleados, monitoreando salud del endpoint, túneles SASE y la ruta entre el laptop de un trabajador remoto y Microsoft 365. Algunos también cubren tráfico de clientes, pero las definiciones en los primeros resultados tienden hacia la fuerza laboral.
Es una categoría real que resuelve un problema real. Simplemente no es el problema que tiene un equipo de operaciones de comercio electrónico o digital.
La versión para clientes apunta hacia afuera. Tus usuarios son extraños en redes que no controlas, usan dispositivos que no aprovisionaste y se van sin abrir un ticket. Nadie escala un campo de código promocional roto. Van a un competidor.
El DEM para empleados responde “por qué la llamada de Zoom de Sarah está entrecortada”. El DEM para clientes responde “por qué las finalizaciones de carrito bajaron un 18% en Brasil anoche”. Mismo acrónimo, herramientas diferentes, propietarios diferentes.
El resto de esta guía trata sobre el segundo.
Por qué tus paneles se ponen verdes mientras el pago está roto
Tres configuraciones comunes fallan en la misma dirección y fallan en silencio.
Un ping de uptime verifica lo incorrecto. Un chequeo HTTP en tu página de inicio confirma que una URL devolvió un 200. El pago puede devolver un 200 con “No pudimos procesar tu pago” mostrado dentro de la página. El código de estado no opina sobre el contenido.
Las métricas del lado del servidor se detienen en tu borde. El tiempo de respuesta de la aplicación, CPU y tasas de error describen tu infraestructura. No incluyen resolución DNS, handshakes TLS, comportamiento del CDN, ejecución de etiquetas de terceros, ni los 2.8 segundos que un widget de chat bloquea el hilo principal en móvil.
La monitorización de usuarios reales tiene un problema de supervivencia. La monitorización de usuarios reales recopila datos de un beacon JavaScript dentro de la página. Eso significa que solo reporta sesiones donde la página cargó y el beacon se activó. Los usuarios que sufren un fallo DNS, un 403 del CDN o un error TLS nunca cargan el beacon, así que no reportan nada. Las peores caídas producen los datos RUM menos, y el tráfico que desaparece silenciosamente parece un día lento en ventas.
La velocidad de detección agrava los tres. Muchas caídas reales son breves, y las breves son las que nadie detecta vigilando un panel. Si tus chequeos corren cada cinco minutos, una falla de cuatro minutos puede empezar y terminar entre chequeos y no dejar evidencia salvo los pedidos que no recibiste.
Cerrar los tres huecos toma tres cosas iguales: chequear fuera de tu propia infraestructura, renderizar en un navegador real y juzgar el resultado por el contenido de la página en lugar de los códigos de estado. Eso hace la monitorización sintética, que es lo que esta guía configura.
Monitorización sintética vs. RUM vs. análisis de ruta de red
Los analistas suelen dividir DEM en tres entradas. Se superponen y cada una está ciega donde las otras ven.
| Fuente | Qué mide | Qué detecta primero | Punto ciego |
|---|---|---|---|
| Monitorización sintética | Trayectos programados que se ejecutan periódicamente desde ubicaciones fijas, en un navegador real | Pasos rotos, fallos regionales, ralentizaciones de terceros, certificados expirados, caídas fuera de horario pico | Solo prueba los caminos que programaste, con los dispositivos y ubicaciones que elegiste |
| Monitorización de usuarios reales | Datos de campo de sesiones reales: Core Web Vitals, mezcla de dispositivos, mezcla de navegadores | Problemas en dispositivos y navegadores poco comunes, distribución real del tráfico | Sesgo de supervivencia: necesita tráfico y una página que cargó. Silenciosa en fallos graves y en páginas con bajo volumen |
| Análisis de ruta de red | Ruteo hop a hop, latencia y pérdida de paquetes entre puntos de vista y tu servicio | Cambios en ruteo de ISP, problemas de emparejamiento (peering), problemas de BGP, latencia regional | No dice nada sobre si la lógica de la aplicación funcionó |
La monitorización sintética y RUM son la pareja que la mayoría de equipos de hecho usan. La sintética te da una señal constante que no depende de que alguien esté despierto y comprando. RUM te dice cómo es tu audiencia real. Usa la sintética para detectar y alertar, RUM para priorizar qué corregir.
Dotcom-Monitor cubre la fila uno y tres. La monitorización de aplicaciones web ejecuta los trayectos de navegador programados, y los chequeos de Infraestructura de Internet se encargan de DNS, TLS y la capa de red por debajo. No recopila datos RUM, así que si quieres analíticas a nivel de sesión de compradores reales, usa una herramienta de RUM junto a ella.
La sintética tiene un límite propio: solo conoce los trayectos que programas. Si nadie programa el pago como invitado, ese pago puede estar roto por una semana.
Qué medir en un camino de ingresos
Empieza por el trayecto, no por la lista de métricas. Para la mayoría de sitios de comercio electrónico y SaaS, cuatro caminos llevan casi todo el riesgo: búsqueda, añadir al carrito, pago y login.
Para cada uno, sigue:
- Éxito a nivel de paso. ¿Se completó cada paso y tuvo la página el texto que debía tener? Un número de confirmación es mejor señal que un código de estado. En EveryStep, eso es una afirmación de contenido adjunta a cada paso, y puede verificar texto, elementos, estado HTTP, encabezados de respuesta o un payload JSON.
- Duración a nivel de paso. El tiempo total oculta el problema. Quieres ver que “aplicar código promocional” pasó de 400 ms a 9 segundos mientras todo lo demás se mantenía estable. Los Script Time Watchers de EveryStep establecen un umbral por paso, para que un paso falle por sí solo en lugar de desaparecer dentro de un trayecto que aún pasa.
- Core Web Vitals. Largest Contentful Paint, Interaction to Next Paint y Cumulative Layout Shift en las páginas que convierten, no solo la página de inicio. La monitorización de páginas web reporta estas métricas por página junto al gráfico waterfall.
- Tiempo hasta el primer byte. Separa el retraso en obtener una primera respuesta, que incluye DNS, TLS, redirecciones, comportamiento de la CDN y latencia de origen, del trabajo de renderizado posterior. Una página lenta con TTFB rápido es un problema del front-end.
- Tiempo de elementos de terceros. Proveedores de pago, gestores de etiquetas, widgets de chat, plataformas de reseñas, píxeles publicitarios. La monitorización de contenido de terceros importa porque son activos que no puedes parchear y solo puedes redirigir. El gráfico waterfall lista cada solicitud de terceros como una línea, para que veas qué proveedor añadió 900 ms este mes. También vigila los dominios de terceros: un gateway de pago con certificado caducado lleva el pago abajo tan completamente como una caída propia.
- Tiempo de respuesta y corrección de la API. Inventario, precios, impuestos, envíos y pagos están detrás de cada paso en el funnel. Los chequeos de servicios web alcanzan esos endpoints directamente y afirman sobre el cuerpo de la respuesta, para que captures un payload malo antes de que llegue a la página.
- Salud del certificado y DNS. Un certificado caducado en un subdominio de pago derriba el pago por completo, y es totalmente prevenible con monitorización de certificados SSL y monitorización de DNS funcionando bajo los chequeos de navegador.
- Variación geográfica. La misma página desde Chicago, Londres y Singapur. La divergencia entre ubicaciones suele apuntar a CDN o DNS, no a tu aplicación, por eso Dotcom-Monitor ejecuta el mismo script desde más de 30 ubicaciones globales en vez de una sola.
Cuatro fallos que tu chequeo de uptime no detectará
Cada uno de estos deja un panel de tiempo de actividad verde.
1. La página de error 200 OK
Un procesador de tarjetas cambia un contrato API. Tu pago captura la excepción, muestra un mensaje amigable “Algo salió mal, por favor intenta de nuevo” y devuelve HTTP 200. Cada chequeo de uptime en internet dice que el sitio está bien. Los pedidos se detienen.
La solución es una afirmación de contenido: el trayecto programado debe encontrar el número de confirmación de pedido o el paso falla.
Qué lo detecta: un chequeo de Aplicaciones Web (UserView) con una afirmación en el paso de confirmación. EveryStep valida el texto renderizado real, así que “Algo salió mal” falla el chequeo aunque el servidor haya devuelto 200.
2. Un script de terceros que solo perjudica móviles
Un equipo de marketing añade una etiqueta de personalización. Escritorio casi no lo nota. En una conexión móvil limitada añade tres segundos antes de que el botón de pagar sea interactivo, así que la conversión en móvil baja mientras escritorio parece normal. Nadie conecta los dos casos por una semana, porque el despliegue vino de un gestor de etiquetas y no de una versión.
Correr el pago en perfiles de escritorio y móvil limitado hace visible la división ese día mismo. Por eso la monitorización del navegador para optimización de conversión aparece en análisis post-mortem de funnel.
Qué lo detecta: el mismo script de EveryStep reproducido en más de 40 navegadores y dispositivos móviles además de escritorio. Compara la duración por paso entre ambos y la etiqueta aparece como un paso lentísimo, no como un vago “el sitio se siente lento en móvil”.
3. Una falla regional de CDN o DNS
Un empuje de configuración de CDN rompe un punto de presencia. Clientes en São Paulo reciben un 403 del borde y nunca cargan tu JavaScript. Tus datos RUM no bajan, solo dejan de recibir sesiones brasileñas, que se lee como un día suave de tráfico.
Una ubicación de monitoreo en São Paulo falla en el primer chequeo. Esta es la razón para una red de monitoreo global en vez de chequeos desde una sola región cloud.
Qué lo detecta: correr el trayecto desde 30+ ubicaciones, con grabación de video sincronizada al gráfico waterfall al fallar. Obtienes la página 403 que vio el cliente brasileño y la solicitud que la produjo, en vez de un ticket de soporte tres días después.
4. Una API que degrada en vez de fallar
Tu servicio de tarifa de envío comienza a responder en 11 segundos en vez de 300 ms. Nunca devuelve error, así que las alertas de tasa de error permanecen silenciosas. Los clientes llegan al paso de envíos, ven el spinner y abandonan.
Qué lo detecta: un chequeo de Servicios Web (WebView) al endpoint de tarifa de envío con un umbral de tiempo de respuesta y una afirmación sobre el JSON que devuelve. Eso dispara en la API misma antes que el trayecto de navegador cruce el timeout en cascada.
Cómo configurar la monitorización de la experiencia digital
Este orden funciona si empiezas de cero o si añades profundidad a chequeos de uptime existentes.
Paso 1: Mapea los trayectos que generan dinero. Extrae el reporte de tu funnel y lista los tres a cinco caminos que los clientes realmente toman: búsqueda, añadir al carrito, pago como invitado, pago con cuenta, login. Anota la condición exacta de éxito para cada uno.
Paso 2: Graba cada trayecto como una transacción scriptada. Haz los clics una vez en el EveryStep Web Recorder y captura clics, rellenado de formularios, navegación y esperas, incluyendo desplegables, modales, contenido cargado con AJAX e iframes. No necesitas escribir selectores. Maneja las partes delicadas con intención: banners de cookies, IDs dinámicos, contraseñas de un solo uso y un método de pago de prueba que no cobre a nadie. Dale al script su propia cuenta de prueba y un SKU seguro para inventario para que la monitorización nunca cree pedidos reales. Para eso sirve la monitorización de transacciones web.
Paso 3: Añade una afirmación a cada paso. Cada paso verifica texto o elemento que solo aparece si tuvo éxito: “Pedido confirmado”, un número de confirmación, subtotal de carrito que coincida con el precio del artículo. EveryStep también afirma sobre estado HTTP, encabezados y payload JSON, así que un paso puede fallar por una mala respuesta API antes de que la página se renderice mal. Sin afirmaciones vuelves a chequear códigos de estado.
Paso 4: Elige ubicaciones y dispositivos que coincidan con tu tráfico. Toma tus regiones principales de analytics y monitorea desde ellas, no desde donde estén tus servidores. Dotcom-Monitor te da más de 30 ubicaciones y 40 navegadores y dispositivos móviles, así que elige las tres o cuatro que reflejen tu audiencia real y añade al menos un perfil móvil limitado. La frecuencia y ubicaciones de monitorización deben reflejar tus clientes actuales.
Paso 5: Ajusta la frecuencia según impacto en ingresos. El pago merece un intervalo más apretado que una página de empleos. Los scripts de transacción completos cuestan más que los chequeos de página única, así que invierte donde están los pedidos.
Paso 6: Supervisa los servicios subyacentes. Añade chequeos para las APIs en las que depende tu funnel, además de DNS, certificados TLS y cualquier endpoint de socio en la ruta de pago. La monitorización de API con afirmaciones en la respuesta detecta degradación que el trayecto de navegador solo muestra después.
Paso 7: Dirige las alertas para que alguien actúe. Confirma un fallo desde una segunda ubicación antes de alertar a alguien, para eliminar falsas alarmas por ruido local. Usa una segunda ubicación en la misma región, eso sí. Chequear desde un nodo en otro continente suprime fallos regionales que este sistema busca detectar. Las reglas de alerta de Dotcom-Monitor gestionan los umbrales y lógica de confirmación y se integran nativamente con PagerDuty, Slack y Teams, para que las fallas en el pago lleguen donde quien puede revertir un despliegue las vea.
Paso 8: Revisa los waterfalls según cronograma. Una vez a la semana, abre el gráfico waterfall del trayecto más lento y observa qué cambió. Los activos de terceros se infiltran gradualmente sin avisar. En una ejecución fallida, el gráfico viene acompañado con una grabación de video de la sesión, que usualmente responde “qué vio realmente el cliente” en unos diez segundos. Leer gráficos waterfall transforma un número lento en una petición específica de arreglo, y los paneles públicos y reportes por email ponen esos mismos números frente a los responsables de preguntar sobre conversión.
Cómo elegir una herramienta de monitorización de la experiencia digital
La mayoría de proveedores te mostrarán un panel. Menos pasan estas preguntas.
- ¿Corre en un navegador real? Los chequeos a nivel HTTP no pueden ejecutar JavaScript, así que se pierden todo lo que hace un storefront moderno tras la respuesta inicial.
- ¿Qué tan difícil es programar un trayecto de varios pasos? Si un script de pago toma dos días de un desarrollador, nadie lo mantendrá cuando rediseñen la página del carrito.
- ¿Desde dónde puede hacer pruebas? Cuenta las ubicaciones que coincidan con tus clientes, no el total. Veinte nodos en Norteamérica no ayudan para un lanzamiento europeo.
- ¿Puede afirmar sobre contenido, no solo estado? Esto separa la monitorización de transacciones de un ping simple.
- ¿Una falla trae datos de causa raíz? Un waterfall, una captura en el momento de fallo, el elemento que falló. Una alerta que solo dice “pago falló” inicia tu investigación desde cero.
- ¿Encaja en tu flujo de incidentes? Las alertas que llegan a PagerDuty, Slack, Teams, SMS o un webhook se atienden. Las alertas que quedan en un panel que nadie tiene abierto no.
- ¿Puede acceder entornos internos o en staging? Las apps preproducción y con firewall necesitan agentes privados dentro de la red.
- ¿Qué pasa con el precio cuando añades trayectos? El precio por paso o por ejecución castiga la monitorización profunda de trayectos por la que lo compras.
Cómo Dotcom-Monitor maneja la monitorización de la experiencia digital
Dotcom-Monitor cubre el lado sintético del DEM, que es la capa de detección para todo lo anterior. Cuatro tipos de dispositivo mapean las capas de un trayecto de cliente, y la mayoría de tiendas usa los cuatro.
| Tipo de dispositivo | Qué monitorea | Qué te da en caso de fallo |
|---|---|---|
| Aplicaciones Web (UserView) | Trayectos con varios pasos scriptados en un navegador real: búsqueda, carrito, pago, login | Grabación de video sincronizada al gráfico waterfall, más tiempos por paso |
| Páginas Web (BrowserView) | Renderizado de página única, Core Web Vitals, tiempo de elementos y terceros | Gráfico waterfall a nivel de elemento mostrando qué solicitud ralentizó la página |
| Servicios Web (WebView) | Llamadas REST, SOAP, GraphQL y Postman importadas a API detrás del funnel | Tiempo de respuesta, estado, encabezados y resultados de afirmaciones en el payload |
| Infraestructura de Internet (ServerView) | DNS, certificados TLS, correo, FTP, TCP y chequeos a nivel ping | Qué capa falló, para dejar de depurar la app cuando es un registro DNS |
Los trayectos se graban en el EveryStep Web Recorder como captura point-and-click en vez de selectores escritos a mano, luego se reproducen en más de 40 navegadores y dispositivos móviles y desde 30+ ubicaciones en la red global de monitoreo. Los umbrales por paso detectan cuál se volvió lento. Las afirmaciones de contenido detectan el paso que parece bien y no lo está. Los agentes privados corren los mismos chequeos contra staging o apps detrás de firewall, lo que importa si quieres detectar un despliegue de pago malo antes de que salga.
Dos advertencias honestas. Dotcom-Monitor es una plataforma sintética que no recopila datos RUM, así que úsala junto a una herramienta RUM si necesitas analíticas por sesión. Y no es un APM: te dice que un paso falló y dónde, no qué línea de tu código lanzó la excepción. Los equipos que necesitan ambos suelen ejecutar monitorización de retail y ecommerce junto a un APM interno y tratan la capa sintética como la alerta temprana desde afuera.
Conclusión
La monitorización de la experiencia digital cierra la brecha entre “nuestros servidores están arriba” y “nuestros clientes pueden comprar”. La mayoría de los ingresos que pierdes por problemas de rendimiento desaparecen en esa brecha: páginas de error 200 OK, scripts de terceros que solo dañan móviles, fallos regionales de CDN que tus datos RUM no ven y APIs que degradan sin error.
No necesitas un programa grande para comenzar. Elige tu trayecto más valioso, grábalo en EveryStep con una afirmación en cada paso, ejecútalo desde las tres regiones donde están realmente tus clientes y dirige la alerta a quien pueda actuar. Ese chequeo detectará fallos que tu panel actual escondió.
Cuando corra limpio por una semana, programa el siguiente trayecto y repite. La mayoría de equipos cubren todo su funnel en tres o cuatro pasadas.
Monitorea los trayectos que importan
Graba tu ruta de pago en EveryStep, añade una afirmación al paso de confirmación y ejecútalo desde 30+ ubicaciones en navegadores reales. Comienza un trial gratuito de Dotcom-Monitor y descubre qué ha estado ocultando tu panel de uptime.
