# Cobertura de datos del catálogo: qué es y cómo medirla

> Qué es la cobertura de datos de un catálogo, por qué se calcula sobre los campos que aplican a cada producto y cómo medirla para Google y ChatGPT.

URL: https://clione.ai/es/glosario/cobertura-datos-catalogo/
Lang: es

La cobertura de datos del catálogo responde a una pregunta que parece sencilla: **de los datos que tus productos deberían tener, ¿cuántos tienen de verdad?** No tiene nada que ver con la cobertura de [indexación](/es/glosario/indexacion/), la que mide cuántas páginas de tu web tiene Google en su índice; aquí se cuentan los campos de cada producto, los que luego alimentan su [ficha de producto](/es/glosario/ficha-de-producto/), su marcado y sus _feeds_, no URL. Te importa porque los sitios que leen tu [catálogo de productos](/es/glosario/catalogo-de-productos/), de [Google Merchant Center](/es/glosario/google-merchant-center/) al _feed_ de ChatGPT, trabajan con listas de campos, y un campo que falta puede bastar para que un producto no se muestre. Para este término no hay una norma publicada: lo que sigue es una forma de calcularlo, construida sobre cómo escalonan sus requisitos Google y OpenAI.

## Cómo se calcula

La fórmula es una división: **campos con un valor válido, entre campos aplicables**. Las dos palabras que importan son «válido» y «aplicable», y casi todos los errores de medición vienen de saltarse una de ellas.

**Aplicable: no todos los campos son para todos los productos.** La especificación de datos de producto de Merchant Center lo dice con tres niveles: obligatorio (si no lo envías, el producto no puede salir en anuncios ni en fichas gratuitas), «depende» (según el producto o los países donde se muestra) y opcional. Y muchos atributos cambian de nivel según el producto. El estado (`condition`) es obligatorio si el producto es usado o reacondicionado, y opcional si es nuevo. El color, el género y el grupo de edad son obligatorios para la ropa que se dirige a ciertos países y para las fichas gratuitas de toda la categoría de ropa y complementos, y opcionales para el resto. La marca es obligatoria en los productos nuevos, salvo películas, libros y música, y para un producto que de verdad no tiene marca Google pide **dejar el campo vacío**.[^mc-spec] Contar ese vacío como un hueco castiga a la tienda por hacer lo que Google pide.

**Válido: relleno no es lo mismo que cubierto.** OpenAI, en su especificación del _feed_ para ChatGPT, pide que un campo opcional sin dato se omita, que no se usen textos de relleno como `null`, `unknown` o `n/a` (salvo donde `unknown` está permitido) y aclara que un valor vacío no significa cero ni falso.[^openai-feed-spec] Merchant Center va en la misma línea: en la marca, nada de «N/A», «Genérico» o «Sin marca»; en el color, nada de «multicolor», «varios» o un código como `#fff000`.[^mc-spec] Un catálogo con todos los campos rellenos de «N/A» tiene una cobertura aparente del 100 % y una real mucho menor.

**Por destino: cada lector tiene su lista.** Las [fichas de comerciante](/es/glosario/fichas-de-comerciante/) de Google exigen en el marcado un nombre, una imagen y una oferta con un precio mayor que cero.[^google-merchant-listing] El _feed_ de OpenAI pide nueve campos obligatorios (identificador, título, descripción, URL, marca, nombre del vendedor, imagen, [precio y disponibilidad](/es/glosario/precio-y-disponibilidad/)), y rechaza la fila entera si la disponibilidad falta o no es uno de los valores admitidos.[^openai-feed-spec] Las variantes añaden sus propios campos, obligatorios solo cuando el producto tiene variantes.[^openai-feed-spec] Por eso **una cobertura sin destino no dice nada**: hay que decir para qué se mide.

## En una tienda

Cuatro productos de una tienda **ejemplo ficticio**, con ocho campos, medidos de dos maneras. La aplicabilidad sigue las reglas de Merchant Center que cita el apartado anterior: el color cuenta en la camiseta, que se vende en varios colores; el estado, en el móvil reacondicionado; la marca, en todos menos en la taza artesana, que no tiene.

| Producto (ejemplo ficticio)         | Campos aplicables                      | Con valor válido | Qué falla                                  |
| ----------------------------------- | -------------------------------------- | ---------------- | ------------------------------------------ |
| Camiseta de algodón, varios colores | 7 de 8 (el estado no aplica: es nueva) | 6                | El color dice «multicolor»                 |
| Cable USB-C, nuevo, un color        | 6 de 8                                 | 6                | Nada                                       |
| Móvil reacondicionado               | 7 de 8                                 | 6                | Falta el estado                            |
| Taza artesana sin marca             | 5 de 8                                 | 5                | Nada (la marca dice «N/A», pero no aplica) |
| **Total**                           | **25**                                 | **23**           |                                            |

**Medida sobre los campos aplicables, la cobertura es de 23 sobre 25, un 92 %**, y los dos huecos son justo los que importan: el color de la ropa y el estado del reacondicionado, que Merchant Center exige en esos casos.[^mc-spec] Medida de la forma ingenua (cualquier valor cuenta, sobre los ocho campos de cada producto) saldría 25 de 32, un 78 %: más baja, porque penaliza los campos que no aplican, y a la vez engañosa, porque cuenta como buenos el «multicolor» y el «N/A». **El número correcto es más alto y señala menos cosas, pero las que señala son las que bloquean.**


Leer la cobertura como un objetivo del 100 % de todo. En los datos de producto, el 100 % se mide sobre lo aplicable, no sobre todos los campos de la especificación. Google dice algo parecido de su propia «cobertura», la de indexación: no hay que esperar que todas las URL de un sitio estén indexadas, solo las canónicas.[^gsc-page-indexing] **En los dos casos, un número más bajo puede ser el correcto**, y forzarlo hacia arriba con relleno empeora el dato que se envía.[^openai-feed-spec]


## Cómo comprobarlo

1. **Exporta el catálogo** desde el panel de tu tienda, con todas las columnas de producto y de variante.
2. **Elige el destino y copia su lista de campos**: la especificación de Merchant Center, la del _feed_ de OpenAI o las propiedades de las fichas de comerciante de Google, cada una con su nivel de requisito.[^mc-spec][^openai-feed-spec][^google-merchant-listing]
3. **Marca qué campos aplican a cada producto** según su categoría, su estado y si tiene variantes, antes de contar nada.[^mc-spec]
4. **Cuenta solo los valores válidos**: descarta los vacíos, los «N/A», los «unknown» donde no están permitidos y los valores que la especificación prohíbe.[^openai-feed-spec]
5. **Informa por campo y por destino, con los obligatorios aparte**, y repite la medida después de cada importación o sincronización. Si envías el catálogo con Clione, los ajustes del _feed_ enseñan las cinco últimas versiones generadas, qué dejó fuera cada una y por qué.

## Concepto cercano: enriquecimiento de catálogo

La cobertura mide el hueco; el [enriquecimiento de catálogo](/es/glosario/enriquecimiento-de-catalogo/) lo rellena con datos que faltan o que no sirven tal como están. Van en ese orden: sin una medida de cobertura no se sabe qué enriquecer primero, y sin repetirla después no se sabe si el enriquecimiento funcionó. La [auditoría de catálogo](/es/glosario/auditoria-de-catalogo/) es el ejercicio más amplio, que además de contar campos revisa si sus valores son buenos. Y ninguna de las tres dice si el dato llega a la página pública: eso es la [verificación de publicación](/es/glosario/verificacion-de-publicacion/).

Para seguir, la guía para [auditar una ficha de producto](/es/guias/auditar-ficha-de-producto/) baja al detalle de una sola ficha, y la [ruta de lectura de medición y verificación](/es/aprender/medicion-y-verificacion/) ordena el resto de términos.