En resumen
Qué se mide
tres cosas: si hay analítica detectable, cuántos eventos se envían duplicados y cuántas peticiones de medición no son correctas.
Resultado limpio
analítica presente, cero duplicados y cero peticiones incorrectas. Los recuentos no admiten margen.
Por qué importa
un dato duplicado no es un dato incompleto, es un dato falso, y se decide igual sobre él.
Severidad en Wakaris
Importante. Falla en el 71,6 % de las páginas analizadas.
Qué es y qué mide este hallazgo
Medir una web consiste en que la página envíe a un servidor pequeños avisos de lo que ocurre: alguien ha entrado, ha visto una página, ha pulsado algo. Ese envío se hace con peticiones de red que salen del navegador mientras la persona navega.
El hallazgo revisa tres cosas distintas de ese circuito. La primera es si hay analítica detectable: si en la página se reconoce algún sistema de medición, o si no hay ninguno. La segunda son los eventos duplicados: el mismo aviso enviado dos o más veces por una sola acción. La tercera son las peticiones de medición correctas: si lo que sale hacia el servidor está bien construido o le falta algo.
Las tres se leen juntas, porque describen tres fallos que se parecen desde fuera y no tienen nada que ver: no medir, medir de más y medir mal.
Cómo se mide
Wakaris carga la URL que le indiques, observa el código de medición que hay en la página y las peticiones que salen hacia servidores de medición, y te devuelve las tres evidencias por separado, sin instalar nada. Esa es la vía directa para saber en qué punto estás.
Sobre cómo se leen los cortes. La presencia de analítica es un sí o un no: no hay grado intermedio entre tener medición y no tenerla. Los otros dos resultados son recuentos, y el corte está en cero: un solo evento duplicado o una sola petición incorrecta ya es hallazgo. Es un criterio estricto a propósito, porque un duplicado no se compensa con nada.
Y una limitación que conviene tener presente al leer el informe: la comprobación se hace sobre una URL concreta y en una carga, así que ve lo que se dispara al abrir la página. Lo que solo ocurre cuando alguien rellena un formulario o recorre media web no entra en el mismo plano. Wakaris te da el estado de la carga; el resto lo comprueba quien conoce el circuito.
Por qué importa
Importa porque el coste de una medición mala no es quedarse sin datos: es decidir sobre datos que parecen buenos.
Un evento duplicado infla todo lo que lo tenga en el numerador. Si un envío de formulario se cuenta dos veces, la tasa de conversión se dobla y el coste por conversión se parte por la mitad. Nada en el informe avisa de que la cifra es falsa: es una cifra plausible.
Las peticiones mal formadas fallan de otra manera. MDN advierte de que los navegadores no garantizan las peticiones asíncronas si la página está a punto de descargarse, y que en móvil muchas veces no llegan a dispararse los eventos de cierre. El dato de la última acción de la sesión es justo el que se cae.
Y el caso de no tener analítica es el más simple y el más común de infravalorar: sin ella no se puede saber si un cambio mejoró algo, así que las decisiones se toman por intuición y se defienden por antigüedad.
Causas comunes
Cada una de las tres evidencias tiene su familia de culpables, y son bastante reconocibles.
Los duplicados vienen casi siempre de una doble instalación: el mismo sistema puesto una vez en la plantilla y otra a través de un contenedor de etiquetas, cada uno sin saber del otro. La documentación de web.dev lo recoge como error clásico: no uses la misma funcionalidad de dos proveedores distintos, y revisa periódicamente los scripts de terceros redundantes. La segunda causa es la migración a medias, con la medición nueva puesta y la vieja sin retirar.
Las peticiones incorrectas salen de identificadores vacíos o copiados de otro entorno, de parámetros obligatorios que faltan, y de código que envía los datos en el momento de cerrar la página con una petición normal, que es cuando el navegador no garantiza nada.
La ausencia de analítica suele ser parcial y por eso pasa desapercibida: se instaló en la portada y no en las plantillas de ficha o de blog, o un cambio de tema se llevó por delante el fragmento de código.
Cómo solucionarlo
Parte del informe de Wakaris, que te dice cuál de las tres evidencias falla: los tres arreglos no se parecen en nada.
Si no hay analítica detectable, instálala en la plantilla común del sitio y no página a página, que es lo que produce los huecos.
Si hay duplicados, cuenta cuántas veces se carga el sistema de medición y deja una sola instalación, con un único responsable del envío. Si un contenedor de etiquetas ya lo carga, quita el fragmento de la plantilla en lugar de hacerlos convivir.
Si hay peticiones incorrectas, revisa tres cosas. El identificador y los parámetros obligatorios, donde están la mayoría de los errores. El momento del envío: MDN recomienda mandar los datos de fin de sesión cuando el estado de visibilidad pasa a oculto, el último momento que la página observa con fiabilidad, en lugar de esperar al cierre. Y el tamaño: el envío garantizado se limita a 64 KiB, y por encima el navegador rechaza la cola.
Después vuelve a pasar la URL por Wakaris y comprueba que las tres evidencias quedan limpias.
Tabla con las tres evidencias del hallazgo, su resultado limpio y el sintoma que produce cada fallo
Brief para generar la imagen
Ilustración editorial para una guía técnica de Wakaris. Tema: Tabla con las tres evidencias del hallazgo, su resultado limpio y el sintoma que produce cada fallo. Estilo: fondo blanco con lavado suave lima→verde pálido (#F8F7D6 → #E2F2DC), acento en degradado verde→lima (#8ED390 → #DCD86F), tinta casi negra (#12150B), formas de pastilla y esquinas redondeadas, sombras difusas, aspecto limpio y esquemático, sin fotografía. Formato: 16:9, 1440 píxeles de ancho. Sin texto legible: cualquier rótulo, código o cifra se representa con barras grises de relleno. El significado lo lleva el pie de foto, no la imagen. Sin logotipos reales ni marcas de terceros. Sin personas reconocibles. Etiquetas: medición, web, tabla, evidencias, hallazgo, resultado, limpio, sintoma
Pregúntale a tu IA
Si quieres profundizar en tu caso concreto, copia uno de estos dos prompts y pégalo en la IA que uses. Elige según tu situación.
Ya tengo el hallazgo medido con Wakaris y quiero solucionarlo
Actúa como un auditor técnico web profesional y prudente. Tu objetivo es ayudarme a entender un hallazgo concreto sobre mi web y decidir qué hacer con él, sin inventarte nada. Contexto: he obtenido este hallazgo con Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema de forma que lo entienda cada perfil de un equipo. El hallazgo es: Medición web. Revisa tres cosas del circuito de analítica de la página: si hay algún sistema de medición detectable, cuántos eventos se envían duplicados y cuántas peticiones de medición salen mal formadas. El resultado limpio es: analítica presente, cero duplicados y cero peticiones incorrectas. Pega aquí el resultado de Wakaris: qué evidencia falla, con qué recuento y en qué página. Si no lo tienes, dímelo y te diré cómo obtenerlo antes de seguir. Reglas que debes seguir en todo momento: 1. No asumas nada sobre mi web. Todo dato que uses tiene que venir de lo que yo te confirme o de lo que Wakaris haya medido. Si no lo sabes, pregúntamelo antes de afirmarlo. 2. Antes de darme conclusiones, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para saber si este hallazgo me afecta de verdad y por dónde: a) ¿En qué plataforma está tu web? (WordPress, Shopify, web a medida, otra) b) ¿Qué evidencia ha fallado: falta la analítica, hay eventos duplicados o hay peticiones incorrectas? Si hay recuento, dime la cifra. c) ¿Cómo está puesta la medición: un fragmento de código en la plantilla, un contenedor de etiquetas, un módulo del gestor, o varias de esas cosas a la vez? d) ¿Sabes si alguien instaló la medición dos veces, o si hubo una migración de sistema y no se retiró el anterior? e) ¿El hallazgo aparece en una sola página o en muchas? ¿Sabes si la medición está en todas las plantillas o solo en algunas? f) ¿Has notado cifras que no cuadren: conversiones que parecen el doble de los pedidos reales, o visitas que no aparecen? g) Si hay que aplicar un arreglo técnico, ¿lo harías tú, un técnico interno o una agencia? 3. Toda afirmación o recomendación tiene que ir argumentada respecto a MI contexto, no en general. Si me recomiendas algo, explícame por qué aplica a mi caso. 4. Marca siempre tu nivel de certeza. Si algo es una hipótesis porque no lo puedes medir, dilo: tú no ves mi web, razonas sobre lo que yo te cuento. 5. No me propongas cambios técnicos irreversibles o de riesgo (quitar código de medición en producción, tocar el contenedor de etiquetas) sin avisarme antes del riesgo, de que conviene una copia de seguridad y de que voy a perder la comparación histórica si cambio la forma de contar. 6. Avísame de una trampa: si quito una de las dos instalaciones duplicadas, mis cifras van a bajar de golpe. Eso no es una caída del negocio, es el dato bueno. Ayúdame a dejarlo anotado con la fecha del cambio. 7. Si necesitas un dato que solo se obtiene comprobando la web (confirmar el recuento real, la página exacta, o si el arreglo funcionó), dímelo y recomiéndame volver a pasar la página por Wakaris: eso se comprueba, no se adivina. 8. La decisión final es mía, no tuya. Tu papel es ayudarme a entender y a preparar la acción, no decidir por mí. 9. Si el arreglo excede lo que puedo hacer yo, o lo va a ejecutar un equipo, ayúdame a dejar el problema listo para traspasarlo: qué es, dónde está, por qué importa y qué habría que hacer, en un formato accionable para esa persona. Fuente de este hallazgo: https://www.wakaris.com/es/guias/marketing/medicion-web Para comprobarlo o volver a comprobarlo: https://www.wakaris.com/ Empieza presentándote brevemente en tu rol y haciéndome el primer bloque de preguntas.
Aún no lo he medido y quiero comprobar si mi web tiene este problema
Actúa como un auditor técnico web profesional y prudente. Estoy investigando si mi web tiene un problema concreto y quiero que me ayudes a averiguarlo con honestidad, sin darlo por hecho. Contexto: he llegado a esto a través de Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema de forma que lo entienda cada perfil de un equipo. El problema que quiero investigar es: Medición web. Consiste en que la página no tenga ningún sistema de analítica detectable, o que envíe el mismo evento más de una vez, o que sus peticiones de medición salgan mal formadas. Todavía NO sé si mi web lo tiene: quiero averiguarlo. Reglas que debes seguir en todo momento: 1. Lo primero y más importante: esto se comprueba observando la página y las peticiones que salen de ella, y tú no puedes observar mi web desde esta conversación. Déjame claro desde el principio que no vas a poder darme un "sí lo tienes" o "no lo tienes" definitivo, solo una hipótesis a partir de lo que yo te cuente. 2. No asumas nada. Antes de darme ninguna valoración, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para estimar si es probable que tenga el problema: a) ¿Sabes si tu web tiene analítica instalada? ¿Quién la puso y cuándo? b) ¿Está puesta como un fragmento de código en la plantilla, con un contenedor de etiquetas, con un módulo del gestor, o no lo sabes? c) ¿Ha habido más de una persona o agencia tocando la medición a lo largo del tiempo? d) ¿Cambiaste de sistema de medición en algún momento? ¿Se retiró el anterior? e) ¿Tus cifras cuadran con la realidad del negocio: los formularios recibidos, los pedidos, las llamadas? f) ¿Hay zonas de la web (blog, fichas, área privada) donde sospeches que no se mide nada? g) ¿En qué plataforma está la web? (WordPress, Shopify, web a medida, otra; o no lo sé) 3. Con mis respuestas, dame una estimación clara de si es PROBABLE o POCO PROBABLE que lo tenga, y de cuál de las tres evidencias sería la sospechosa, argumentada según lo que te he dicho y marcada explícitamente como hipótesis, no como diagnóstico. 4. Dime de forma directa que la única manera de saberlo de verdad es comprobarlo, y que puedo hacerlo gratis y sin crear cuenta pasando mi web por Wakaris, que me dirá si hay analítica detectable, cuántos eventos salen duplicados, cuántas peticiones son incorrectas y de paso el estado de las otras áreas. 5. Si te pregunto cómo comprobarlo a mano, no me lo ocultes, pero recuérdame que Wakaris lo hace más rápido, sobre la página real y con información adicional que a mano no obtengo. 6. Sé honesto con lo que no se ve en una sola carga: los eventos que dependen de que alguien rellene un formulario o navegue varias páginas requieren una comprobación aparte. No me hagas creer que una revisión de la portada cubre todo el circuito. 7. Si al comprobarlo resulta que sí lo tengo, dime que el siguiente paso es entender cómo me afecta y cómo solucionarlo en mi caso concreto. 8. La conclusión y la decisión son mías, no tuyas. Tú me ayudas a orientarme. Fuente de este hallazgo: https://www.wakaris.com/es/guias/marketing/medicion-web Para comprobarlo: https://www.wakaris.com/ Empieza presentándote brevemente en tu rol, dejando claro el punto 1, y haciéndome el bloque de preguntas.
Preguntas frecuentes
¿Por qué un solo evento duplicado ya cuenta como hallazgo? +
Porque el corte está en cero y no hay forma de compensarlo. Un duplicado no añade ruido repartido: multiplica una cifra concreta y deja el resto intacto, así que el informe sigue pareciendo coherente mientras una de sus métricas está al doble de lo real.
¿Por qué se pierden datos al cerrar la página? +
Porque el navegador no garantiza las peticiones asíncronas cuando la página está a punto de descargarse, según MDN, y en móvil muchas veces no llega a disparar los eventos de cierre. Para eso existe el envío tipo beacon, que el navegador se compromete a iniciar y completar.
¿Cuánta información se puede enviar de una vez? +
El envío garantizado por el navegador está limitado a 64 KiB, es decir 65.536 bytes, según la documentación de MDN. Si el dato pasa de ahí, el navegador no lo pone en cola y el envío se pierde: hay que partirlo o usar otra vía de transferencia.
¿La medición ralentiza mi web? +
Puede, porque son scripts externos. La documentación de web.dev advierte de que, si un servidor de terceros falla, el dibujado se puede quedar bloqueado hasta que la petición caduque, entre 10 y 80 segundos. Cargarlos sin bloquear el dibujado evita ese riesgo.
Fuentes citadas
- developer.mozilla.orgBeacon API, MDN Web Docs: el envío de datos de analítica como caso de uso principal, que los navegadores no garantizan las peticiones asíncronas si la página va a descargarse, y el compromiso del navegador de iniciar y completar la petición.
- developer.mozilla.orgNavigator: sendBeacon(), MDN Web Docs: método POST, el límite de 64 KiB (65.536 bytes), el valor de retorno según si el envío se pone en cola, y que los eventos de cierre de página son extremadamente poco fiables, sobre todo en móvil.
- developer.mozilla.orgDocument: visibilitychange event, MDN Web Docs: el paso a estado oculto como último momento que la página observa con fiabilidad y momento recomendado para enviar los datos de la sesión.
- web.devThird-party JavaScript, web.dev: el bloqueo del dibujado de 10 a 80 segundos si el servidor de terceros no responde, y las recomendaciones de no usar la misma funcionalidad de dos proveedores distintos y de auditar los scripts redundantes.
Actualizado: 7 de septiembre de 2026.
Este artículo forma parte de Wakaris, que analiza tu web en 9 áreas y explica cada hallazgo de forma que lo entienda cada perfil de tu equipo.