{"id":12284,"date":"2020-05-26T09:21:18","date_gmt":"2020-05-26T09:21:18","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/2020\/05\/26\/supervision-de-la-experiencia-digital-una-vision-general\/"},"modified":"2026-08-26T18:39:23","modified_gmt":"2026-08-26T18:39:23","slug":"supervision-de-la-experiencia-digital-una-vision-general","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/es\/supervision-de-la-experiencia-digital-una-vision-general\/","title":{"rendered":"\u00bfQu\u00e9 es el Monitoreo de la Experiencia Digital? C\u00f3mo Observar los Viajes del Cliente desde Afuera Hacia Adentro"},"content":{"rendered":"<figure id=\"attachment_34540\" aria-describedby=\"caption-attachment-34540\" style=\"width: 1200px\" class=\"wp-caption alignnone\"><img fetchpriority=\"high\" decoding=\"async\" class=\"size-full wp-image-34540\" src=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2019\/11\/hero-digital-experience-monitoring.webp\" alt=\"Un panel de operaciones de comercio electr\u00f3nico que muestra un estado de tiempo de actividad verde junto a un paso de pago fallido\" width=\"1200\" height=\"800\" srcset=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2019\/11\/hero-digital-experience-monitoring.webp 1200w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2019\/11\/hero-digital-experience-monitoring-300x200.webp 300w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2019\/11\/hero-digital-experience-monitoring-1024x683.webp 1024w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2019\/11\/hero-digital-experience-monitoring-768x512.webp 768w\" sizes=\"(max-width: 1200px) 100vw, 1200px\" \/><figcaption id=\"caption-attachment-34540\" class=\"wp-caption-text\">Un panel de tiempo de actividad verde y un pago roto pueden ocurrir al mismo tiempo.<\/figcaption><\/figure>\n<p>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\u00f1ana.<\/p>\n<p>La monitorizaci\u00f3n de la experiencia digital (DEM) existe para esa situaci\u00f3n. Las m\u00e9tricas del lado del servidor confirman que tu infraestructura respondi\u00f3. 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\u00f3n de pagar.<\/p>\n<p>La mayor\u00eda de las gu\u00edas sobre este tema definen DEM para equipos de TI que supervisan laptops de empleados y t\u00faneles VPN. Esta cubre la otra versi\u00f3n: monitorizar los trayectos de cara al cliente que generan ingresos. Qu\u00e9 mide el DEM, d\u00f3nde cada fuente de datos se queda ciega, c\u00f3mo configurarlo en una tienda real y qu\u00e9 comprobaci\u00f3n de Dotcom-Monitor detecta cada fallo.<\/p>\n<p><strong>Qu\u00e9 encontrar\u00e1s en esta gu\u00eda<\/strong><\/p>\n<ul>\n<li><a href=\"#qu\u00e9-es-la-monitorizaci\u00f3n-de-la-experiencia-digital\">\u00bfQu\u00e9 es la monitorizaci\u00f3n de la experiencia digital?<\/a><\/li>\n<li><a href=\"#por-qu\u00e9-tus-paneles-se-ponen-verdes-mientras-el-pago-est\u00e1-roto\">Por qu\u00e9 tus paneles se ponen verdes mientras el pago est\u00e1 roto<\/a><\/li>\n<li><a href=\"#monitorizaci\u00f3n-sint\u00e9tica-vs-rum-vs-an\u00e1lisis-de-ruta-de-red\">Monitorizaci\u00f3n sint\u00e9tica vs. RUM vs. an\u00e1lisis de ruta de red<\/a><\/li>\n<li><a href=\"#qu\u00e9-medir-en-un-camino-de-ingresos\">Qu\u00e9 medir en un camino de ingresos<\/a><\/li>\n<li><a href=\"#cuatro-fallos-que-tu-chequeo-de-uptime-no-detectar\u00e1\">Cuatro fallos que tu chequeo de uptime no detectar\u00e1<\/a><\/li>\n<li><a href=\"#c\u00f3mo-configurar-la-monitorizaci\u00f3n-de-la-experiencia-digital\">C\u00f3mo configurar la monitorizaci\u00f3n de la experiencia digital<\/a><\/li>\n<li><a href=\"#c\u00f3mo-elegir-una-herramienta-de-monitorizaci\u00f3n-de-la-experiencia-digital\">C\u00f3mo elegir una herramienta de monitorizaci\u00f3n de la experiencia digital<\/a><\/li>\n<li><a href=\"#c\u00f3mo-dotcom-monitor-maneja-la-monitorizaci\u00f3n-de-la-experiencia-digital\">C\u00f3mo Dotcom-Monitor maneja la monitorizaci\u00f3n de la experiencia digital<\/a><\/li>\n<li><a href=\"#heading-faq\">Preguntas frecuentes sobre monitorizaci\u00f3n de la experiencia digital<\/a><\/li>\n<li><a href=\"#conclusi\u00f3n\">Conclusi\u00f3n<\/a><\/li>\n<\/ul>\n<h2 id='qu\u00e9-es-la-monitorizaci\u00f3n-de-la-experiencia-digital'  id=\"boomdevs_1\" id=\"what-is-digital-experience-monitoring\">\u00bfQu\u00e9 es la monitorizaci\u00f3n de la experiencia digital?<\/h2>\n<p>La monitorizaci\u00f3n de la experiencia digital es la pr\u00e1ctica de medir c\u00f3mo las personas experimentan tu sitio web o aplicaci\u00f3n de extremo a extremo, a trav\u00e9s de la red, navegador y dispositivo que usan para acceder a ti. En lugar de preguntar &#8220;\u00bfrespondi\u00f3 el servidor?&#8221;, pregunta &#8220;\u00bfalguien pudo completar lo que vino a hacer y cu\u00e1nto le tom\u00f3?&#8221;. Esa medici\u00f3n puede provenir de sesiones reales, de trayectos programados que se ejecutan a intervalos, o de ambos.<\/p>\n<p>El alcance es m\u00e1s amplio que el tiempo de actividad. Una configuraci\u00f3n de DEM supervisa el renderizado de p\u00e1ginas, transacciones de m\u00faltiples pasos como b\u00fasqueda y pago, las API detr\u00e1s de esos pasos, los scripts de terceros y c\u00f3mo todo cambia seg\u00fan la regi\u00f3n, navegador y velocidad de conexi\u00f3n. Ver\u00e1s esta pr\u00e1ctica tambi\u00e9n bajo nombres como monitorizaci\u00f3n de la experiencia del usuario final, monitorizaci\u00f3n de la experiencia de la aplicaci\u00f3n o gesti\u00f3n de la experiencia digital. Las etiquetas var\u00edan; lo que se mide mayormente no.<\/p>\n<h3 id='los-dos-tipos-de-dem-y-por-qu\u00e9-se-confunden'  id=\"boomdevs_2\" id=\"the-two-kinds-of-dem-and-why-they-get-confused\">Los dos tipos de DEM (y por qu\u00e9 se confunden)<\/h3>\n<p>Busca este t\u00e9rmino y la primera p\u00e1gina est\u00e1 dominada por proveedores de red y seguridad: Palo Alto Networks, Fortinet, Cloudflare, ThousandEyes, Tanium. La mayor\u00eda de lo que describen esas p\u00e1ginas es para empleados, monitoreando salud del endpoint, t\u00faneles SASE y la ruta entre el laptop de un trabajador remoto y Microsoft 365. Algunos tambi\u00e9n cubren tr\u00e1fico de clientes, pero las definiciones en los primeros resultados tienden hacia la fuerza laboral.<\/p>\n<p>Es una categor\u00eda real que resuelve un problema real. Simplemente no es el problema que tiene un equipo de operaciones de comercio electr\u00f3nico o digital.<\/p>\n<p>La versi\u00f3n para clientes apunta hacia afuera. Tus usuarios son extra\u00f1os en redes que no controlas, usan dispositivos que no aprovisionaste y se van sin abrir un ticket. Nadie escala un campo de c\u00f3digo promocional roto. Van a un competidor.<\/p>\n<blockquote><p>El DEM para empleados responde &#8220;por qu\u00e9 la llamada de Zoom de Sarah est\u00e1 entrecortada&#8221;. El DEM para clientes responde &#8220;por qu\u00e9 las finalizaciones de carrito bajaron un 18% en Brasil anoche&#8221;. Mismo acr\u00f3nimo, herramientas diferentes, propietarios diferentes.<\/p><\/blockquote>\n<p>El resto de esta gu\u00eda trata sobre el segundo.<\/p>\n<h2 id='por-qu\u00e9-tus-paneles-se-ponen-verdes-mientras-el-pago-est\u00e1-roto'  id=\"boomdevs_3\" id=\"why-your-dashboards-go-green-while-checkout-is-broken\">Por qu\u00e9 tus paneles se ponen verdes mientras el pago est\u00e1 roto<\/h2>\n<p>Tres configuraciones comunes fallan en la misma direcci\u00f3n y fallan en silencio.<\/p>\n<p><strong>Un ping de uptime verifica lo incorrecto.<\/strong> Un chequeo HTTP en tu p\u00e1gina de inicio confirma que una URL devolvi\u00f3 un 200. El pago puede devolver un 200 con &#8220;No pudimos procesar tu pago&#8221; mostrado dentro de la p\u00e1gina. El c\u00f3digo de estado no opina sobre el contenido.<\/p>\n<p><strong>Las m\u00e9tricas del lado del servidor se detienen en tu borde.<\/strong> El tiempo de respuesta de la aplicaci\u00f3n, CPU y tasas de error describen tu infraestructura. No incluyen resoluci\u00f3n DNS, handshakes TLS, comportamiento del CDN, ejecuci\u00f3n de etiquetas de terceros, ni los 2.8 segundos que un widget de chat bloquea el hilo principal en m\u00f3vil.<\/p>\n<p><strong>La monitorizaci\u00f3n de usuarios reales tiene un problema de supervivencia.<\/strong> <a href=\"https:\/\/www.dotcom-monitor.com\/es\/aprende-con-dotcom-monitor\/glosario\/que-es-la-monitorizacion-de-usuarios-reales-rum\/\">La monitorizaci\u00f3n de usuarios reales<\/a> recopila datos de un beacon JavaScript dentro de la p\u00e1gina. Eso significa que solo reporta sesiones donde la p\u00e1gina carg\u00f3 y el beacon se activ\u00f3. Los usuarios que sufren un fallo DNS, un 403 del CDN o un error TLS nunca cargan el beacon, as\u00ed que no reportan nada. Las peores ca\u00eddas producen los datos RUM menos, y el tr\u00e1fico que desaparece silenciosamente parece un d\u00eda lento en ventas.<\/p>\n<p>La velocidad de detecci\u00f3n agrava los tres. Muchas ca\u00eddas 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.<\/p>\n<p>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\u00e1gina en lugar de los c\u00f3digos de estado. Eso hace la <a href=\"https:\/\/www.dotcom-monitor.com\/es\/soluciones\/synthetic-monitoring\/\">monitorizaci\u00f3n sint\u00e9tica<\/a>, que es lo que esta gu\u00eda configura.<\/p>\n<h2 id='monitorizaci\u00f3n-sint\u00e9tica-vs-rum-vs-an\u00e1lisis-de-ruta-de-red'  id=\"boomdevs_4\" id=\"synthetic-monitoring-vs-rum-vs-network-path-analysis\">Monitorizaci\u00f3n sint\u00e9tica vs. RUM vs. an\u00e1lisis de ruta de red<\/h2>\n<p>Los analistas suelen dividir DEM en tres entradas. Se superponen y cada una est\u00e1 ciega donde las otras ven.<\/p>\n<figure id=\"attachment_34547\" aria-describedby=\"caption-attachment-34547\" style=\"width: 896px\" class=\"wp-caption alignnone\"><img decoding=\"async\" class=\"size-full wp-image-34547\" src=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2019\/11\/dem-data-sources-blind-spots.webp\" alt=\"Matriz de cobertura que muestra qu\u00e9 etapas cubren la monitorizaci\u00f3n sint\u00e9tica, la monitorizaci\u00f3n de usuarios reales y el an\u00e1lisis de ruta de red\" width=\"896\" height=\"406\" srcset=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2019\/11\/dem-data-sources-blind-spots.webp 896w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2019\/11\/dem-data-sources-blind-spots-300x136.webp 300w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2019\/11\/dem-data-sources-blind-spots-768x348.webp 768w\" sizes=\"(max-width: 896px) 100vw, 896px\" \/><figcaption id=\"caption-attachment-34547\" class=\"wp-caption-text\">Cada fuente de datos cubre un tramo diferente de la ruta entre un cliente y tu origen.<\/figcaption><\/figure>\n<div class=\"table-wrap\">\n<table>\n<thead>\n<tr>\n<th>Fuente<\/th>\n<th>Qu\u00e9 mide<\/th>\n<th>Qu\u00e9 detecta primero<\/th>\n<th>Punto ciego<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Monitorizaci\u00f3n sint\u00e9tica<\/td>\n<td>Trayectos programados que se ejecutan peri\u00f3dicamente desde ubicaciones fijas, en un navegador real<\/td>\n<td>Pasos rotos, fallos regionales, ralentizaciones de terceros, certificados expirados, ca\u00eddas fuera de horario pico<\/td>\n<td>Solo prueba los caminos que programaste, con los dispositivos y ubicaciones que elegiste<\/td>\n<\/tr>\n<tr>\n<td>Monitorizaci\u00f3n de usuarios reales<\/td>\n<td>Datos de campo de sesiones reales: Core Web Vitals, mezcla de dispositivos, mezcla de navegadores<\/td>\n<td>Problemas en dispositivos y navegadores poco comunes, distribuci\u00f3n real del tr\u00e1fico<\/td>\n<td>Sesgo de supervivencia: necesita tr\u00e1fico y una p\u00e1gina que carg\u00f3. Silenciosa en fallos graves y en p\u00e1ginas con bajo volumen<\/td>\n<\/tr>\n<tr>\n<td>An\u00e1lisis de ruta de red<\/td>\n<td>Ruteo hop a hop, latencia y p\u00e9rdida de paquetes entre puntos de vista y tu servicio<\/td>\n<td>Cambios en ruteo de ISP, problemas de emparejamiento (peering), problemas de BGP, latencia regional<\/td>\n<td>No dice nada sobre si la l\u00f3gica de la aplicaci\u00f3n funcion\u00f3<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<p>La monitorizaci\u00f3n sint\u00e9tica y RUM son la pareja que la mayor\u00eda de equipos de hecho usan. La sint\u00e9tica te da una se\u00f1al constante que no depende de que alguien est\u00e9 despierto y comprando. RUM te dice c\u00f3mo es tu audiencia real. Usa la sint\u00e9tica para detectar y alertar, RUM para priorizar qu\u00e9 corregir.<\/p>\n<p>Dotcom-Monitor cubre la fila uno y tres. <a href=\"https:\/\/www.dotcom-monitor.com\/es\/productos-de-monitoreo\/supervision-de-aplicaciones-web\/\">La monitorizaci\u00f3n de aplicaciones web<\/a> 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\u00ed que si quieres anal\u00edticas a nivel de sesi\u00f3n de compradores reales, usa una herramienta de RUM junto a ella.<\/p>\n<p>La sint\u00e9tica tiene un l\u00edmite propio: solo conoce los trayectos que programas. Si nadie programa el pago como invitado, ese pago puede estar roto por una semana.<\/p>\n<h2 id='qu\u00e9-medir-en-un-camino-de-ingresos'  id=\"boomdevs_5\" id=\"what-to-measure-on-a-revenue-path\">Qu\u00e9 medir en un camino de ingresos<\/h2>\n<p>Empieza por el trayecto, no por la lista de m\u00e9tricas. Para la mayor\u00eda de sitios de comercio electr\u00f3nico y SaaS, cuatro caminos llevan casi todo el riesgo: b\u00fasqueda, a\u00f1adir al carrito, pago y login.<\/p>\n<p>Para cada uno, sigue:<\/p>\n<ul>\n<li><strong>\u00c9xito a nivel de paso.<\/strong> \u00bfSe complet\u00f3 cada paso y tuvo la p\u00e1gina el texto que deb\u00eda tener? Un n\u00famero de confirmaci\u00f3n es mejor se\u00f1al que un c\u00f3digo de estado. En EveryStep, eso es una <a href=\"https:\/\/www.dotcom-monitor.com\/es\/funciones\/assertions-monitoring\/\">afirmaci\u00f3n de contenido<\/a> adjunta a cada paso, y puede verificar texto, elementos, estado HTTP, encabezados de respuesta o un payload JSON.<\/li>\n<li><strong>Duraci\u00f3n a nivel de paso.<\/strong> El tiempo total oculta el problema. Quieres ver que &#8220;aplicar c\u00f3digo promocional&#8221; pas\u00f3 de 400 ms a 9 segundos mientras todo lo dem\u00e1s se manten\u00eda estable. Los Script Time Watchers de EveryStep establecen un umbral por paso, para que un paso falle por s\u00ed solo en lugar de desaparecer dentro de un trayecto que a\u00fan pasa.<\/li>\n<li><strong>Core Web Vitals.<\/strong> Largest Contentful Paint, Interaction to Next Paint y Cumulative Layout Shift en las p\u00e1ginas que convierten, no solo la p\u00e1gina de inicio. <a href=\"https:\/\/www.dotcom-monitor.com\/es\/productos-de-monitoreo\/monitoreo-de-paginas-web-dotcom-monitor\/\">La monitorizaci\u00f3n de p\u00e1ginas web<\/a> reporta estas m\u00e9tricas por p\u00e1gina junto al gr\u00e1fico waterfall.<\/li>\n<li><strong>Tiempo hasta el primer byte.<\/strong> 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\u00e1gina lenta con TTFB r\u00e1pido es un problema del front-end.<\/li>\n<li><strong>Tiempo de elementos de terceros.<\/strong> Proveedores de pago, gestores de etiquetas, widgets de chat, plataformas de rese\u00f1as, p\u00edxeles publicitarios. <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/es\/3rd-party-content-monitoring\/\">La monitorizaci\u00f3n de contenido de terceros<\/a> importa porque son activos que no puedes parchear y solo puedes redirigir. El gr\u00e1fico waterfall lista cada solicitud de terceros como una l\u00ednea, para que veas qu\u00e9 proveedor a\u00f1adi\u00f3 900 ms este mes. Tambi\u00e9n vigila los dominios de terceros: un gateway de pago con certificado caducado lleva el pago abajo tan completamente como una ca\u00edda propia.<\/li>\n<li><strong>Tiempo de respuesta y correcci\u00f3n de la API.<\/strong> Inventario, precios, impuestos, env\u00edos y pagos est\u00e1n detr\u00e1s 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\u00e1gina.<\/li>\n<li><strong>Salud del certificado y DNS.<\/strong> Un certificado caducado en un subdominio de pago derriba el pago por completo, y es totalmente prevenible con <a href=\"https:\/\/www.dotcom-monitor.com\/es\/productos-de-monitoreo\/ssl-certificate-monitoring\/\">monitorizaci\u00f3n de certificados SSL<\/a> y <a href=\"https:\/\/www.dotcom-monitor.com\/es\/productos-de-monitoreo\/herramienta-de-supervision-de-dns-dotcom-monitor\/\">monitorizaci\u00f3n de DNS<\/a> funcionando bajo los chequeos de navegador.<\/li>\n<li><strong>Variaci\u00f3n geogr\u00e1fica.<\/strong> La misma p\u00e1gina desde Chicago, Londres y Singapur. La divergencia entre ubicaciones suele apuntar a CDN o DNS, no a tu aplicaci\u00f3n, por eso Dotcom-Monitor ejecuta el mismo script desde m\u00e1s de 30 ubicaciones globales en vez de una sola.<\/li>\n<\/ul>\n<h2 id='cuatro-fallos-que-tu-chequeo-de-uptime-no-detectar\u00e1'  id=\"boomdevs_6\" id=\"four-failures-your-uptime-check-will-miss\">Cuatro fallos que tu chequeo de uptime no detectar\u00e1<\/h2>\n<p>Cada uno de estos deja un panel de tiempo de actividad verde.<\/p>\n<h3 id='1-la-p\u00e1gina-de-error-200-ok'  id=\"boomdevs_7\" id=\"1-the-200-ok-error-page\">1. La p\u00e1gina de error 200 OK<\/h3>\n<p>Un procesador de tarjetas cambia un contrato API. Tu pago captura la excepci\u00f3n, muestra un mensaje amigable &#8220;Algo sali\u00f3 mal, por favor intenta de nuevo&#8221; y devuelve HTTP 200. Cada chequeo de uptime en internet dice que el sitio est\u00e1 bien. Los pedidos se detienen.<\/p>\n<p>La soluci\u00f3n es una afirmaci\u00f3n de contenido: el trayecto programado debe encontrar el n\u00famero de confirmaci\u00f3n de pedido o el paso falla.<\/p>\n<p><strong>Qu\u00e9 lo detecta:<\/strong> un chequeo de Aplicaciones Web (UserView) con una afirmaci\u00f3n en el paso de confirmaci\u00f3n. EveryStep valida el texto renderizado real, as\u00ed que &#8220;Algo sali\u00f3 mal&#8221; falla el chequeo aunque el servidor haya devuelto 200.<\/p>\n<h3 id='2-un-script-de-terceros-que-solo-perjudica-m\u00f3viles'  id=\"boomdevs_8\" id=\"2-a-third-party-script-that-only-hurts-mobile\">2. Un script de terceros que solo perjudica m\u00f3viles<\/h3>\n<p>Un equipo de marketing a\u00f1ade una etiqueta de personalizaci\u00f3n. Escritorio casi no lo nota. En una conexi\u00f3n m\u00f3vil limitada a\u00f1ade tres segundos antes de que el bot\u00f3n de pagar sea interactivo, as\u00ed que la conversi\u00f3n en m\u00f3vil 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\u00f3n.<\/p>\n<p>Correr el pago en perfiles de escritorio y m\u00f3vil limitado hace visible la divisi\u00f3n ese d\u00eda mismo. Por eso <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/es\/browser-monitoring-in-e-commerce-conversion-optimization\/\">la monitorizaci\u00f3n del navegador para optimizaci\u00f3n de conversi\u00f3n<\/a> aparece en an\u00e1lisis post-mortem de funnel.<\/p>\n<p><strong>Qu\u00e9 lo detecta:<\/strong> el mismo script de EveryStep reproducido en m\u00e1s de 40 navegadores y dispositivos m\u00f3viles adem\u00e1s de escritorio. Compara la duraci\u00f3n por paso entre ambos y la etiqueta aparece como un paso lent\u00edsimo, no como un vago &#8220;el sitio se siente lento en m\u00f3vil&#8221;.<\/p>\n<h3 id='3-una-falla-regional-de-cdn-o-dns'  id=\"boomdevs_9\" id=\"3-a-regional-cdn-or-dns-failure\">3. Una falla regional de CDN o DNS<\/h3>\n<p>Un empuje de configuraci\u00f3n de CDN rompe un punto de presencia. Clientes en S\u00e3o Paulo reciben un 403 del borde y nunca cargan tu JavaScript. Tus datos RUM no bajan, solo dejan de recibir sesiones brasile\u00f1as, que se lee como un d\u00eda suave de tr\u00e1fico.<\/p>\n<p>Una ubicaci\u00f3n de monitoreo en S\u00e3o Paulo falla en el primer chequeo. Esta es la raz\u00f3n para una <a href=\"https:\/\/www.dotcom-monitor.com\/es\/funciones\/funciones-red-de-vigilancia\/\">red de monitoreo global<\/a> en vez de chequeos desde una sola regi\u00f3n cloud.<\/p>\n<p><strong>Qu\u00e9 lo detecta:<\/strong> correr el trayecto desde 30+ ubicaciones, con grabaci\u00f3n de video sincronizada al gr\u00e1fico waterfall al fallar. Obtienes la p\u00e1gina 403 que vio el cliente brasile\u00f1o y la solicitud que la produjo, en vez de un ticket de soporte tres d\u00edas despu\u00e9s.<\/p>\n<h3 id='4-una-api-que-degrada-en-vez-de-fallar'  id=\"boomdevs_10\" id=\"4-an-api-that-degrades-instead-of-failing\">4. Una API que degrada en vez de fallar<\/h3>\n<p>Tu servicio de tarifa de env\u00edo comienza a responder en 11 segundos en vez de 300 ms. Nunca devuelve error, as\u00ed que las alertas de tasa de error permanecen silenciosas. Los clientes llegan al paso de env\u00edos, ven el spinner y abandonan.<\/p>\n<p><strong>Qu\u00e9 lo detecta:<\/strong> un chequeo de Servicios Web (WebView) al endpoint de tarifa de env\u00edo con un umbral de tiempo de respuesta y una afirmaci\u00f3n sobre el JSON que devuelve. Eso dispara en la API misma antes que el trayecto de navegador cruce el timeout en cascada.<\/p>\n<h2 id='c\u00f3mo-configurar-la-monitorizaci\u00f3n-de-la-experiencia-digital'  id=\"boomdevs_11\" id=\"how-to-set-up-digital-experience-monitoring\">C\u00f3mo configurar la monitorizaci\u00f3n de la experiencia digital<\/h2>\n<figure id=\"attachment_34554\" aria-describedby=\"caption-attachment-34554\" style=\"width: 2298px\" class=\"wp-caption alignnone\"><img decoding=\"async\" class=\"size-full wp-image-34554\" src=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2019\/11\/dem-setup-journey-map.webp\" alt=\"Diagrama de flujo de un trayecto scriptado de ecommerce desde la p\u00e1gina principal a b\u00fasqueda, p\u00e1gina de producto, carrito, pago y confirmaci\u00f3n, con afirmaciones y puntos de control de tiempo en cada paso\" width=\"2298\" height=\"568\" srcset=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2019\/11\/dem-setup-journey-map.webp 2298w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2019\/11\/dem-setup-journey-map-300x74.webp 300w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2019\/11\/dem-setup-journey-map-1024x253.webp 1024w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2019\/11\/dem-setup-journey-map-768x190.webp 768w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2019\/11\/dem-setup-journey-map-1536x380.webp 1536w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2019\/11\/dem-setup-journey-map-2048x506.webp 2048w\" sizes=\"(max-width: 2298px) 100vw, 2298px\" \/><figcaption id=\"caption-attachment-34554\" class=\"wp-caption-text\">Programa el trayecto como pasos, luego afirma qu\u00e9 debe contener cada paso.<\/figcaption><\/figure>\n<p>Este orden funciona si empiezas de cero o si a\u00f1ades profundidad a chequeos de uptime existentes.<\/p>\n<p><strong>Paso 1: Mapea los trayectos que generan dinero.<\/strong> Extrae el reporte de tu funnel y lista los tres a cinco caminos que los clientes realmente toman: b\u00fasqueda, a\u00f1adir al carrito, pago como invitado, pago con cuenta, login. Anota la condici\u00f3n exacta de \u00e9xito para cada uno.<\/p>\n<p><strong>Paso 2: Graba cada trayecto como una transacci\u00f3n scriptada.<\/strong> Haz los clics una vez en el EveryStep Web Recorder y captura clics, rellenado de formularios, navegaci\u00f3n y esperas, incluyendo desplegables, modales, contenido cargado con AJAX e iframes. No necesitas escribir selectores. Maneja las partes delicadas con intenci\u00f3n: banners de cookies, IDs din\u00e1micos, contrase\u00f1as de un solo uso y un m\u00e9todo 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\u00f3n nunca cree pedidos reales. Para eso sirve la <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/es\/guia-de-supervision-de-transacciones-web\/\">monitorizaci\u00f3n de transacciones web<\/a>.<\/p>\n<p><strong>Paso 3: A\u00f1ade una afirmaci\u00f3n a cada paso.<\/strong> Cada paso verifica texto o elemento que solo aparece si tuvo \u00e9xito: &#8220;Pedido confirmado&#8221;, un n\u00famero de confirmaci\u00f3n, subtotal de carrito que coincida con el precio del art\u00edculo. EveryStep tambi\u00e9n afirma sobre estado HTTP, encabezados y payload JSON, as\u00ed que un paso puede fallar por una mala respuesta API antes de que la p\u00e1gina se renderice mal. Sin afirmaciones vuelves a chequear c\u00f3digos de estado.<\/p>\n<p><strong>Paso 4: Elige ubicaciones y dispositivos que coincidan con tu tr\u00e1fico.<\/strong> Toma tus regiones principales de analytics y monitorea desde ellas, no desde donde est\u00e9n tus servidores. Dotcom-Monitor te da m\u00e1s de 30 ubicaciones y 40 navegadores y dispositivos m\u00f3viles, as\u00ed que elige las tres o cuatro que reflejen tu audiencia real y a\u00f1ade al menos un perfil m\u00f3vil limitado. La <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/es\/frecuencia-de-monitorizacion-sintetica\/\">frecuencia y ubicaciones de monitorizaci\u00f3n<\/a> deben reflejar tus clientes actuales.<\/p>\n<p><strong>Paso 5: Ajusta la frecuencia seg\u00fan impacto en ingresos.<\/strong> El pago merece un intervalo m\u00e1s apretado que una p\u00e1gina de empleos. Los scripts de transacci\u00f3n completos cuestan m\u00e1s que los chequeos de p\u00e1gina \u00fanica, as\u00ed que invierte donde est\u00e1n los pedidos.<\/p>\n<p><strong>Paso 6: Supervisa los servicios subyacentes.<\/strong> A\u00f1ade chequeos para las APIs en las que depende tu funnel, adem\u00e1s de DNS, certificados TLS y cualquier endpoint de socio en la ruta de pago. La <a href=\"https:\/\/www.dotcom-monitor.com\/es\/productos-de-monitoreo\/monitorizacion-de-api\/\">monitorizaci\u00f3n de API<\/a> con afirmaciones en la respuesta detecta degradaci\u00f3n que el trayecto de navegador solo muestra despu\u00e9s.<\/p>\n<p><strong>Paso 7: Dirige las alertas para que alguien act\u00fae.<\/strong> Confirma un fallo desde una segunda ubicaci\u00f3n antes de alertar a alguien, para eliminar falsas alarmas por ruido local. Usa una segunda ubicaci\u00f3n en la misma regi\u00f3n, eso s\u00ed. Chequear desde un nodo en otro continente suprime fallos regionales que este sistema busca detectar. Las <a href=\"https:\/\/www.dotcom-monitor.com\/es\/funciones\/funciones-alertas\/\">reglas de alerta<\/a> de Dotcom-Monitor gestionan los umbrales y l\u00f3gica de confirmaci\u00f3n 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.<\/p>\n<p><strong>Paso 8: Revisa los waterfalls seg\u00fan cronograma.<\/strong> Una vez a la semana, abre el gr\u00e1fico waterfall del trayecto m\u00e1s lento y observa qu\u00e9 cambi\u00f3. Los activos de terceros se infiltran gradualmente sin avisar. En una ejecuci\u00f3n fallida, el gr\u00e1fico viene acompa\u00f1ado con una grabaci\u00f3n de video de la sesi\u00f3n, que usualmente responde &#8220;qu\u00e9 vio realmente el cliente&#8221; en unos diez segundos. <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/es\/optimizacion-de-los-graficos-de-la-optimizacion-del-rendimiento-web-entendimiento-cascada\/\">Leer gr\u00e1ficos waterfall<\/a> transforma un n\u00famero lento en una petici\u00f3n espec\u00edfica de arreglo, y <a href=\"https:\/\/www.dotcom-monitor.com\/es\/funciones\/caracteristicas-informes\/\">los paneles p\u00fablicos y reportes por email<\/a> ponen esos mismos n\u00fameros frente a los responsables de preguntar sobre conversi\u00f3n.<\/p>\n<h2 id='c\u00f3mo-elegir-una-herramienta-de-monitorizaci\u00f3n-de-la-experiencia-digital'  id=\"boomdevs_12\" id=\"how-to-choose-a-digital-experience-monitoring-tool\">C\u00f3mo elegir una herramienta de monitorizaci\u00f3n de la experiencia digital<\/h2>\n<p>La mayor\u00eda de proveedores te mostrar\u00e1n un panel. Menos pasan estas preguntas.<\/p>\n<ul>\n<li><strong>\u00bfCorre en un navegador real?<\/strong> Los chequeos a nivel HTTP no pueden ejecutar JavaScript, as\u00ed que se pierden todo lo que hace un storefront moderno tras la respuesta inicial.<\/li>\n<li><strong>\u00bfQu\u00e9 tan dif\u00edcil es programar un trayecto de varios pasos?<\/strong> Si un script de pago toma dos d\u00edas de un desarrollador, nadie lo mantendr\u00e1 cuando redise\u00f1en la p\u00e1gina del carrito.<\/li>\n<li><strong>\u00bfDesde d\u00f3nde puede hacer pruebas?<\/strong> Cuenta las ubicaciones que coincidan con tus clientes, no el total. Veinte nodos en Norteam\u00e9rica no ayudan para un lanzamiento europeo.<\/li>\n<li><strong>\u00bfPuede afirmar sobre contenido, no solo estado?<\/strong> Esto separa la monitorizaci\u00f3n de transacciones de un ping simple.<\/li>\n<li><strong>\u00bfUna falla trae datos de causa ra\u00edz?<\/strong> Un waterfall, una captura en el momento de fallo, el elemento que fall\u00f3. Una alerta que solo dice &#8220;pago fall\u00f3&#8221; inicia tu investigaci\u00f3n desde cero.<\/li>\n<li><strong>\u00bfEncaja en tu flujo de incidentes?<\/strong> 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.<\/li>\n<li><strong>\u00bfPuede acceder entornos internos o en staging?<\/strong> Las apps preproducci\u00f3n y con firewall necesitan agentes privados dentro de la red.<\/li>\n<li><strong>\u00bfQu\u00e9 pasa con el precio cuando a\u00f1ades trayectos?<\/strong> El precio por paso o por ejecuci\u00f3n castiga la monitorizaci\u00f3n profunda de trayectos por la que lo compras.<\/li>\n<\/ul>\n<h2 id='c\u00f3mo-dotcom-monitor-maneja-la-monitorizaci\u00f3n-de-la-experiencia-digital'  id=\"boomdevs_13\" id=\"how-dotcom-monitor-handles-digital-experience-monitoring\">C\u00f3mo Dotcom-Monitor maneja la monitorizaci\u00f3n de la experiencia digital<\/h2>\n<p>Dotcom-Monitor cubre el lado sint\u00e9tico del DEM, que es la capa de detecci\u00f3n para todo lo anterior. Cuatro tipos de dispositivo mapean las capas de un trayecto de cliente, y la mayor\u00eda de tiendas usa los cuatro.<\/p>\n<div class=\"table-wrap\">\n<table>\n<thead>\n<tr>\n<th>Tipo de dispositivo<\/th>\n<th>Qu\u00e9 monitorea<\/th>\n<th>Qu\u00e9 te da en caso de fallo<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Aplicaciones Web<\/strong> (UserView)<\/td>\n<td>Trayectos con varios pasos scriptados en un navegador real: b\u00fasqueda, carrito, pago, login<\/td>\n<td>Grabaci\u00f3n de video sincronizada al gr\u00e1fico waterfall, m\u00e1s tiempos por paso<\/td>\n<\/tr>\n<tr>\n<td><strong>P\u00e1ginas Web<\/strong> (BrowserView)<\/td>\n<td>Renderizado de p\u00e1gina \u00fanica, Core Web Vitals, tiempo de elementos y terceros<\/td>\n<td>Gr\u00e1fico waterfall a nivel de elemento mostrando qu\u00e9 solicitud ralentiz\u00f3 la p\u00e1gina<\/td>\n<\/tr>\n<tr>\n<td><strong>Servicios Web<\/strong> (WebView)<\/td>\n<td>Llamadas REST, SOAP, GraphQL y Postman importadas a API detr\u00e1s del funnel<\/td>\n<td>Tiempo de respuesta, estado, encabezados y resultados de afirmaciones en el payload<\/td>\n<\/tr>\n<tr>\n<td><strong>Infraestructura de Internet<\/strong> (ServerView)<\/td>\n<td>DNS, certificados TLS, correo, FTP, TCP y chequeos a nivel ping<\/td>\n<td>Qu\u00e9 capa fall\u00f3, para dejar de depurar la app cuando es un registro DNS<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<p>Los trayectos se graban en el <a href=\"https:\/\/www.dotcom-monitor.com\/es\/funciones\/everystep\/\">EveryStep Web Recorder<\/a> como captura point-and-click en vez de selectores escritos a mano, luego se reproducen en m\u00e1s de 40 navegadores y dispositivos m\u00f3viles y desde 30+ ubicaciones en la red global de monitoreo. Los umbrales por paso detectan cu\u00e1l se volvi\u00f3 lento. Las afirmaciones de contenido detectan el paso que parece bien y no lo est\u00e1. <a href=\"https:\/\/www.dotcom-monitor.com\/es\/funciones\/funciones-agentes-privados\/\">Los agentes privados<\/a> corren los mismos chequeos contra staging o apps detr\u00e1s de firewall, lo que importa si quieres detectar un despliegue de pago malo antes de que salga.<\/p>\n<p>Dos advertencias honestas. Dotcom-Monitor es una plataforma sint\u00e9tica que no recopila datos RUM, as\u00ed que \u00fasala junto a una herramienta RUM si necesitas anal\u00edticas por sesi\u00f3n. Y no es un APM: te dice que un paso fall\u00f3 y d\u00f3nde, no qu\u00e9 l\u00ednea de tu c\u00f3digo lanz\u00f3 la excepci\u00f3n. Los equipos que necesitan ambos suelen ejecutar <a href=\"https:\/\/www.dotcom-monitor.com\/es\/soluciones\/retail-and-ecommerce-monitoring\/\">monitorizaci\u00f3n de retail y ecommerce<\/a> junto a un APM interno y tratan la capa sint\u00e9tica como la alerta temprana desde afuera.<\/p>\n<h2 id='conclusi\u00f3n'  id=\"boomdevs_14\" id=\"the-bottom-line\">Conclusi\u00f3n<\/h2>\n<p>La monitorizaci\u00f3n de la experiencia digital cierra la brecha entre &#8220;nuestros servidores est\u00e1n arriba&#8221; y &#8220;nuestros clientes pueden comprar&#8221;. La mayor\u00eda de los ingresos que pierdes por problemas de rendimiento desaparecen en esa brecha: p\u00e1ginas de error 200 OK, scripts de terceros que solo da\u00f1an m\u00f3viles, fallos regionales de CDN que tus datos RUM no ven y APIs que degradan sin error.<\/p>\n<p>No necesitas un programa grande para comenzar. Elige tu trayecto m\u00e1s valioso, gr\u00e1balo en EveryStep con una afirmaci\u00f3n en cada paso, ejec\u00fatalo desde las tres regiones donde est\u00e1n realmente tus clientes y dirige la alerta a quien pueda actuar. Ese chequeo detectar\u00e1 fallos que tu panel actual escondi\u00f3.<\/p>\n<p>Cuando corra limpio por una semana, programa el siguiente trayecto y repite. La mayor\u00eda de equipos cubren todo su funnel en tres o cuatro pasadas.<\/p>\n<section class=\"final-cta\">\n<h2 id='monitorea-los-trayectos-que-importan'  id=\"boomdevs_15\" id=\"see-what-external-checks-catch\">Monitorea los trayectos que importan<\/h2>\n<p>Graba tu ruta de pago en EveryStep, a\u00f1ade una afirmaci\u00f3n al paso de confirmaci\u00f3n y ejec\u00fatalo desde 30+ ubicaciones en navegadores reales. Comienza un <a href=\"https:\/\/userauth.dotcom-monitor.com\/Account\/FreeTrialSignUp?SolutionType=Monitoring\">trial gratuito de Dotcom-Monitor<\/a> y descubre qu\u00e9 ha estado ocultando tu panel de uptime.<\/p>\n<\/section>\n","protected":false},"excerpt":{"rendered":"<p>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\u00f1ana. La monitorizaci\u00f3n de la experiencia digital (DEM) existe para esa situaci\u00f3n. Las m\u00e9tricas del lado del servidor confirman que tu infraestructura respondi\u00f3. No dicen nada sobre si un [&hellip;]<\/p>\n","protected":false},"author":21,"featured_media":34546,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[875],"tags":[],"class_list":["post-12284","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sin-categorizar"],"_links":{"self":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/posts\/12284","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/comments?post=12284"}],"version-history":[{"count":0,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/posts\/12284\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/media\/34546"}],"wp:attachment":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/media?parent=12284"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/categories?post=12284"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/tags?post=12284"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}