En resumen
Qué se mide
la estructura de la capa de datos que publica tu página y la validez de los nombres de sus eventos.
Cuándo salta
cuando la estructura tiene defectos, o cuando los eventos estándar no son válidos.
Por qué importa
los datos siguen llegando, así que nadie se da cuenta hasta que hace falta una respuesta que no está.
Severidad en Wakaris
Mejora. Solo aplica donde hay medición instalada: sin ella, no hay nada que revisar.
Qué es y qué mide este hallazgo
Tener medición instalada y tener medición aprovechable son dos cosas distintas, y este hallazgo va de la segunda. No pregunta si mides, sino si lo que mides llega en una forma que alguien pueda usar después.
Revisa dos cosas. La primera es la capa de datos: el objeto que tu página publica para que las etiquetas de medición lean de ahí en lugar de deducir la información de la pantalla. Está documentada como una estructura de tipo JSON, una única lista global a la que la página va añadiendo valores y avisos de que algo ha pasado.
La segunda son los nombres de los eventos. Las plataformas de analítica distinguen tres clases: los que recogen por su cuenta, los recomendados —que ya saben interpretar y para los que tienen informes hechos— y los que te inventas tú. Este hallazgo comprueba si los eventos estándar que declaras son válidos, y válido tiene una definición publicada: el nombre no puede pasar de 40 caracteres, solo admite caracteres alfanuméricos y guiones bajos, tiene que empezar por letra, y hay nombres reservados que no se pueden usar.
Cómo se mide
Wakaris analiza la URL que le indiques, lee la capa de datos que publica esa página y los eventos que declara, y te devuelve cuál de las dos evidencias falla, con la severidad del hallazgo y sin instalar nada. Esa es la vía directa para saber en qué punto estás.
El alcance importa mucho aquí, más que en otros hallazgos. Se observa una sola página, en una sola carga y sin que nadie interactúe. Todo lo que solo ocurre cuando alguien compra, envía un formulario o pulsa un botón queda fuera: lo que se ve es lo que la página declara al cargarse. Así que un resultado limpio no significa que toda tu medición esté bien montada, significa que lo que se declara en la carga de esa página lo está.
Y hay un segundo límite, de naturaleza: la comprobación mira la forma, no la verdad. Una capa de datos impecablemente estructurada puede estar publicando un precio equivocado o una categoría que no corresponde, y eso ninguna revisión automática lo puede saber. Para eso hace falta que alguien conozca el negocio y compare.
Por qué importa
Lo característico de este hallazgo es que el coste es invisible y llega tarde. Los datos siguen entrando, los paneles se rellenan, nadie ve un error. El problema aparece meses después, cuando alguien hace una pregunta concreta y la respuesta no está en ninguna parte.
Los nombres son la mitad del asunto. Usar los nombres recomendados es lo que te da los informes que la plataforma ya tiene construidos; un nombre inventado obliga a levantar cada informe a mano, y la propia documentación advierte de que los eventos recomendados hay que configurarlos precisamente porque la plataforma no puede enviarlos sola.
La estructura es la otra mitad, y ahí las reglas son estrictas. La documentación es explícita en tres puntos: solo se admite una capa de datos por página, su nombre distingue mayúsculas de minúsculas, y asignarle valores directamente en lugar de añadirlos sobrescribe todo lo que hubiera antes. Cualquiera de los tres convierte la medición en datos que llegan a medias.
Y lo peor: el histórico no se arregla. Lo que no se midió bien en marzo no se recupera en junio.
Causas comunes
La causa más frecuente es de orden. La capa de datos se crea después del código de medición, cuando la documentación pide crearla lo más arriba posible del código fuente, por encima de él, y con la forma defensiva que la reutiliza si ya existe. Puesta después, las etiquetas que se disparan al principio no encuentran nada.
La segunda es asignar en lugar de añadir. Usar la capa de datos directamente sobrescribe cualquier valor que ya hubiera, y eso borra en silencio lo que otro trozo de código acababa de dejar ahí.
La tercera es la duplicidad: dos capas de datos, o una con el nombre cambiado de mayúsculas, cuando solo se admite una por página y el nombre es sensible a mayúsculas.
Y la cuarta es de nomenclatura, casi siempre por manos distintas en momentos distintos. Cada uno nombra el mismo concepto a su manera, y la documentación insiste justo en lo contrario: si en una página llamas de una forma a la categoría, en las demás tiene que llamarse igual.
Cómo solucionarlo
Wakaris te dice cuál de las dos evidencias falla, y el orden de arreglo sale de ahí.
Si falla la estructura, empieza por el sitio: crea la capa de datos lo más arriba posible, por encima del código de medición, reaprovechándola si ya existe. Añade siempre los valores en lugar de asignarlos. Y deja una sola capa de datos por página, con su nombre escrito exactamente, mayúsculas incluidas.
Si fallan los nombres, renombra los eventos a los que tu plataforma reconoce, y hazlo antes de construir nada encima: cambiarlos después obliga a rehacer todo lo que se apoyaba en los anteriores. Usa el mismo nombre para el mismo concepto en todas las páginas.
Y por último, lo que más aguanta y no es técnico: escribe el plan de nombres y déjalo donde lo encuentre quien monte la próxima página. Es el arreglo que se degrada más rápido, porque cada página nueva lo vuelve a abrir. Cuando termines, vuelve a pasar la página por Wakaris.
Tabla que compara una capa de datos bien construida con los cuatro defectos habituales y su corrección
Brief para generar la imagen
Ilustración editorial para una guía técnica de Wakaris. Tema: Tabla que compara una capa de datos bien construida con los cuatro defectos habituales y su corrección. 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: calidad, instrumentación, tabla, compara, capa, datos, bien, construida
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: Calidad de la instrumentación. Revisa si la capa de datos que publica mi página tiene la estructura esperada y si los eventos estándar que declara son válidos. Referencia: el hallazgo salta cuando la estructura tiene defectos o cuando los eventos estándar no son válidos. Pega aquí el resultado de Wakaris: cuál de las dos evidencias falla, en qué página y, si lo indica, en qué evento o en qué parte de la estructura. 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 y cómo se instaló la medición: con un complemento, con código a mano, o las dos cosas? b) ¿Quién montó la medición y cuándo? ¿Ha pasado por más de una persona o agencia? c) ¿Qué acciones te importa medir de verdad? (contactos, compras, altas, descargas, llamadas) d) ¿Sabes si tu web publica una capa de datos, o no te consta? e) ¿Los nombres de tus eventos están escritos en algún documento, o cada uno se puso cuando hizo falta? f) ¿Tomas decisiones con esos datos ahora mismo, o todavía no los usas? g) Si hay que tocar el código, ¿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 comprobar, dilo: tú no ves mi web, razonas sobre lo que yo te cuento. 5. No me propongas cambios técnicos irreversibles o de riesgo (renombrar eventos que ya alimentan informes, tocar la medición en producción) sin avisarme antes del riesgo, de que el histórico anterior no se recupera y de que conviene un entorno de prueba. 6. Avísame expresamente si un cambio que me propones rompe la continuidad de mis datos: prefiero saberlo antes que descubrirlo en el panel del mes siguiente. 7. Si necesitas un dato que solo se obtiene analizando la web (confirmar qué evidencia falla, 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/calidad-de-la-instrumentacion 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: Calidad de la instrumentación. Se trata de si la capa de datos que publica mi página tiene la estructura esperada y de si los nombres de mis eventos son los estándar. Referencia: el problema existe cuando la estructura tiene defectos o cuando los eventos estándar no son válidos. 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 leyendo el código de mi página, y tú no puedes hacerlo 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) ¿Tu web tiene medición instalada? ¿La pusiste tú, un complemento o una agencia? b) ¿Ha pasado la medición por más de una persona o empresa desde que se montó? c) ¿Sabes si tu web publica una capa de datos o no te consta? d) ¿Tienes escrito en algún sitio cómo se llaman tus eventos y qué mide cada uno? e) ¿Te ha pasado alguna vez que un informe no cuadre, que falten conversiones o que un mismo hecho aparezca contado dos veces? f) ¿Se rediseñó la web o se cambió de plantilla sin revisar la medición? 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 dos cosas 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á qué evidencia falla 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. 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, y recuérdame que el histórico ya recogido no se arregla hacia atrás. 7. 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/calidad-de-la-instrumentacion 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
Si los datos me llegan, ¿está bien instrumentado? +
No necesariamente. Que lleguen datos y que sirvan para responder preguntas son cosas distintas. Este hallazgo va justo de la diferencia: la medición está puesta, entra información, y aun así falta la estructura o los nombres que permiten aprovecharla después.
¿Da igual cómo llame a mis eventos? +
No. Las plataformas distinguen los eventos que recogen solas, los recomendados que ya saben interpretar y los que te inventas. Usar los nombres recomendados te da informes ya construidos; inventarte el nombre obliga a levantar cada informe a mano, y algunas cosas no se pueden recuperar.
¿Puedo tener dos capas de datos en la misma página? +
La documentación es explícita: solo se admite una por página, y su nombre distingue mayúsculas de minúsculas. Dos capas, o una con el nombre mal escrito, es una de las formas más habituales de que la información se pierda sin que nadie vea ningún error.
¿Puedo arreglar los datos que ya recogí mal? +
No hacia atrás. La instrumentación decide qué se guarda en el momento en que ocurre, así que lo que se midió mal queda así. Se arregla desde hoy, y por eso conviene revisarlo antes de construir informes o decisiones encima.
Fuentes citadas
- developers.google.comThe data layer, Google for Developers: la capa de datos como estructura de tipo JSON, la creación lo más arriba posible del código fuente y en forma reutilizable, la adición de valores frente a la asignación directa que sobrescribe, la sensibilidad a mayúsculas del nombre, el límite de una sola capa por página y la coherencia de nombres entre páginas.
- developers.google.comSend events, Google for Developers: los nombres de evento no pueden pasar de 40 caracteres, solo admiten caracteres alfanuméricos y guiones bajos, deben empezar por letra, y cada evento admite 25 parámetros como máximo.
- developers.google.comRecommended events, Google for Developers: las tres clases de evento, y que los recomendados hay que configurarlos porque la plataforma no puede enviarlos por su cuenta.
Actualizado: 8 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.