¿Qué es la cobertura de datos de un catálogo de productos?

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, 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, su marcado y sus feeds, no URL. Te importa porque los sitios que leen tu catálogo de productos, de 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.⁠^{[1]Ayuda de Google Merchant Center. Product data specification} 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.⁠^{[2]OpenAI Developers. Products (Agentic Commerce, especificación de carga de archivos)} 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.⁠^{[1]Ayuda de Google Merchant Center. Product data specification} 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 de Google exigen en el marcado un nombre, una imagen y una oferta con un precio mayor que cero.⁠^{[3]Google Search Central. Merchant listing (Product, Offer) structured data} El feed de OpenAI pide nueve campos obligatorios (identificador, título, descripción, URL, marca, nombre del vendedor, imagen, precio y disponibilidad), y rechaza la fila entera si la disponibilidad falta o no es uno de los valores admitidos.⁠^{[2]OpenAI Developers. Products (Agentic Commerce, especificación de carga de archivos)} Las variantes añaden sus propios campos, obligatorios solo cuando el producto tiene variantes.⁠^{[2]OpenAI Developers. Products (Agentic Commerce, especificación de carga de archivos)} 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.

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.⁠^{[1]Ayuda de Google Merchant Center. Product data specification} 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.

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.⁠^{[1]Ayuda de Google Merchant Center. Product data specification}⁠^{[2]OpenAI Developers. Products (Agentic Commerce, especificación de carga de archivos)}⁠^{[3]Google Search Central. Merchant listing (Product, Offer) structured data}
3. Marca qué campos aplican a cada producto según su categoría, su estado y si tiene variantes, antes de contar nada.⁠^{[1]Ayuda de Google Merchant Center. Product data specification}
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.⁠^{[2]OpenAI Developers. Products (Agentic Commerce, especificación de carga de archivos)}
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 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 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.

Para seguir, la guía para auditar una ficha de producto baja al detalle de una sola ficha, y la ruta de lectura de medición y verificación ordena el resto de términos.