Un registro de producto, 20 activos para canales
Convierte un registro canónico de producto en títulos, viñetas, descripciones, feeds, anuncios, emails y activos sociales listos para cada canal, sin desviar los datos.
El mapeo de campos de datos de producto entre canales funciona mejor cuando se mantiene un único registro canónico de producto, se asigna cada campo a un contrato de canal, solo se transforma la presentación y se valida cada resultado antes de publicarlo. Los datos del producto permanecen fijos; los títulos, las viñetas, las descripciones, los feeds, los anuncios, los emails y los activos sociales cambian según el destino.
Un registro canónico debe servir para todos los canales
Un registro canónico es la versión gestionada de la identidad, los atributos, los datos comerciales, los recursos multimedia y las afirmaciones aprobadas de un producto. Debe contener los datos en su nivel reutilizable más preciso, sin incorporar las convenciones de un marketplace, una tienda, una plataforma publicitaria o una red social concretos.
No trate una descripción larga del producto como fuente de referencia. Un párrafo es difícil de validar, actualizar y reutilizar. Almacene el color, el material, las dimensiones, la compatibilidad, las características y los beneficios respaldados por pruebas en campos separados. Después, combínelos según los requisitos de cada canal.
Un proceso de mapeo fiable consta de cinco etapas:
- Origen: Valores sin procesar procedentes de su ERP, PIM, archivos de proveedores, DAM o plataforma de comercio electrónico.
- Registro canónico: Campos normalizados con definiciones y responsables claros.
- Contrato de canal: Campos obligatorios, valores permitidos, límites de longitud y tratamiento de valores nulos.
- Transformación: Concatenación, localización, conversión de unidades, formato y generación de textos.
- Validación: Comprobaciones automatizadas seguidas de una revisión humana cuando se requiere criterio.
Esta estructura hace que los mapeos sean explícitos. Como explica la guía de Catsy sobre el mapeo de datos de producto, el mapeo conecta campos entre sistemas teniendo en cuenta las diferencias de estructura y formato. Un valor de producto nunca debe llegar a un campo de destino mediante un proceso de copia y pega sin documentar.
Su tabla de mapeo debe contener, como mínimo, estas columnas:
| Columna de mapeo | Propósito |
|---|---|
source_field | Campo original en el sistema de origen |
canonical_field | Campo gestionado en el registro maestro del producto |
destination_field | Campo esperado por el canal |
scope | Producto, producto principal, variante, oferta, mercado o configuración regional |
transform_rule | Regla de formato, conversión, concatenación o generación |
required_when | Condición que hace obligatorio el campo |
null_policy | Omitir, heredar, bloquear o enviar un valor vacío explícito |
validation_rule | Comprobación de longitud, tipo, enumeración, relación o contenido |
owner | Equipo responsable de corregir el valor de origen |
schema_version | Especificación del canal utilizada al aprobar el mapeo |
Este contrato convierte «enviar los datos del producto» en una secuencia comprobable de decisiones.
¿Qué campos deben incluirse en el registro canónico de producto?
Su esquema canónico debe separar los datos de la presentación y los productos de las ofertas. Los nombres exactos de los campos pueden variar, pero sus significados deben permanecer estables.
| Grupo de campos | Campos canónicos recomendados | Directrices de mapeo |
|---|---|---|
| Identidad | product_id, parent_id, sku, gtin, mpn, brand | Almacene los identificadores como cadenas. Conserve los ceros iniciales. Nunca genere un GTIN o MPN a partir de un texto. |
| Clasificación | product_type, category_path, target_audience, use_case | Asigne las categorías internas a la taxonomía de cada canal mediante una tabla de consulta controlada. |
| Estructura de variantes | variant_axis_1, variant_value_1, variant_axis_2, variant_value_2 | Defina qué atributos crean una variante vendible, como el color o la talla. No mezcle valores del producto principal y de sus variantes. |
| Datos descriptivos | product_name, material, color, pattern, dimensions, weight, capacity, compatibility | Normalice las unidades y los valores enumerados antes de mapearlos a los canales. Conserve el valor original del proveedor para mantener la trazabilidad. |
| Beneficios y afirmaciones | feature_facts, approved_benefits, claim_evidence, prohibited_claims | Genere textos únicamente a partir de datos aprobados. Bloquee los superlativos, certificaciones y afirmaciones de rendimiento sin respaldo. |
| Comercio | regular_price, sale_price, currency, sale_start, sale_end, availability, condition | Mantenga separados los datos de oferta por mercado y vendedor. Valide las relaciones entre precios y fechas. |
| Recursos multimedia | primary_image_url, alternate_image_urls, video_url, image_alt | Indique expresamente el orden de los recursos y sus derechos de uso. Valide que los recursos obligatorios sean accesibles antes de exportarlos. |
| Cumplimiento | country_of_origin, warning_text, age_range, ingredients, care_instructions | Conserve la redacción obligatoria cuando corresponda. No reformule textos regulados sin aprobación. |
| Localización | locale, localized_name, localized_features, localized_description | Distinga los datos traducidos de los textos específicos para cada canal. Registre la configuración regional de origen y el estado de aprobación. |
| Gobernanza | source_system, source_record_id, updated_at, approved_at, content_status | Utilice estos campos para detectar exportaciones obsoletas, resolver conflictos y auditar cambios. |
Tres distinciones evitan muchos errores de mapeo.
En primer lugar, product_id y sku no son intercambiables. Un producto puede agrupar varias variantes vendibles, mientras que cada SKU identifica un artículo concreto. El texto del producto principal puede describir los elementos compartidos; los resultados de cada variante deben incluir los valores diferenciadores correctos.
En segundo lugar, un valor ausente no equivale a falso. Si se desconoce water_resistant, no lo asigne a «No». Manténgalo como nulo, envíelo para su enriquecimiento o bloquee la publicación cuando el canal exija una respuesta.
En tercer lugar, los valores normalizados y los valores de visualización cumplen funciones distintas. Almacene una dimensión en un campo numérico coherente con una unidad explícita. Aplique después el formato exigido por el destino y la configuración regional. No guarde «10 in / 25.4 cm» como un único valor de texto sin controlar.
La descripción general de Productrue sobre los datos de producto específicos para cada canal es una referencia útil para el problema central: distintos destinos necesitan selecciones y presentaciones diferentes de la misma información de producto subyacente.
Un registro puede generar estos 20 activos para canales
La siguiente matriz muestra cómo un registro gestionado puede servir para producir 20 resultados. Sustituya los nombres genéricos de restricciones, como max_title_chars, por los valores actuales del esquema oficial de cada canal. Los requisitos de los canales cambian, por lo que debe versionar las reglas en lugar de incorporar supuestos fijos en los datos del producto.
| # | Activo para el canal | Entradas principales | Reglas de transformación y rechazo |
|---|---|---|---|
| 1 | Título de producto de la tienda | brand, product_name, valores de variante | Aplique el orden de nombres de la tienda. Rechace un nombre vacío o un sufijo de variante no aprobado. |
| 2 | Descripción breve de la PDP | product_name, approved_benefits, target_audience | Seleccione un beneficio principal y el uso previsto. Rechace las afirmaciones sin datos que las respalden. |
| 3 | Viñetas de características de la PDP | feature_facts, materials, dimensions, compatibility | Ordene los datos útiles y aplíqueles un formato coherente. Rechace las viñetas duplicadas o contradictorias. |
| 4 | Descripción larga de la PDP | Datos aprobados, beneficios, casos de uso y datos de cuidado | Cree una narración legible sin modificar las especificaciones. Rechace el HTML no compatible o las afirmaciones prohibidas. |
| 5 | Tabla de especificaciones de la PDP | Dimensiones, peso, material, capacidad y datos del modelo | Presente las etiquetas y unidades según la configuración regional. Rechace los números incorrectos o las unidades ausentes. |
| 6 | Tarjeta de colección | product_name, primary_image_url, regular_price, sale_price | Acorte el título sin eliminar la distinción de la variante. Rechace la ausencia de imagen o moneda. |
| 7 | Registro de búsqueda interna | Nombre, identificadores, categoría, sinónimos y valores de variante | Indexe sinónimos controlados e identificadores exactos. Rechace el uso excesivo de palabras clave sin relación. |
| 8 | Fragmento de búsqueda orgánica | Nombre del producto, categoría, beneficio principal y marca | Genere un título y una descripción dentro de los límites configurados. Rechace un truncamiento que elimine la identidad del producto. |
| 9 | Título del marketplace | Marca, tipo de producto, atributos clave, cantidad y variante | Aplique el orden de título aprobado por ese marketplace. Rechace una longitud excesiva, términos repetidos o atributos obligatorios ausentes. |
| 10 | Viñetas del marketplace | Características, dimensiones, compatibilidad y contenido del paquete | Priorice los detalles esenciales para la compra. Rechace las afirmaciones promocionales que prohíba el destino. |
| 11 | Descripción del marketplace | Datos aprobados, beneficios, instrucciones y datos de cuidado | Elimine el marcado no compatible y el formato incompatible con el canal. Rechace los datos que contradigan las viñetas. |
| 12 | Brief de contenido mejorado para el marketplace | Beneficios, jerarquía de características, recursos multimedia y campos comparativos | Convierta el registro en módulos para un diseñador o una plantilla. Rechace los recursos no disponibles o las comparaciones sin fundamento. |
| 13 | Términos de búsqueda del marketplace | Vocabulario de la categoría, sinónimos e identificadores de modelo | Elimine duplicados y excluya la repetición del título visible cuando lo exija el contrato. Rechace los términos prohibidos de competidores. |
| 14 | Artículo del feed de Shopping | ID, título, descripción, URL, imagen, precio, disponibilidad e identificadores | Serialice los valores conforme al esquema del feed. Rechace los identificadores obligatorios ausentes o las incoherencias entre precio y moneda. |
| 15 | Ficha de comercio social | Nombre del producto, datos de variante, precio, inventario y recursos multimedia | Asigne el producto a la taxonomía y los valores permitidos por el destino. Rechace una categoría sin mapear o una variante huérfana. |
| 16 | Conjunto de anuncios de búsqueda de pago | Nombre del producto, beneficios aprobados, oferta y URL de la página de destino | Produzca varias combinaciones aprobadas. Rechace las ofertas vencidas o los textos que no coincidan con la página de destino. |
| 17 | Brief creativo para redes sociales de pago | Público, caso de uso, beneficios, imágenes y vídeo | Seleccione un enfoque y especifique los recursos necesarios. Rechace las afirmaciones sobre el público que no estén respaldadas por el registro del producto. |
| 18 | Bloque de producto para email | Nombre del producto, imagen, precio, beneficio y URL | Condense la oferta en un módulo reutilizable. Rechace las fechas de oferta obsoletas, las reglas de seguimiento ausentes o las URL rotas. |
| 19 | Promoción por SMS o notificación push | Nombre corto del producto, oferta, fecha límite y URL | Utilice únicamente la información esencial dentro del límite configurado. Rechace las fechas límite ambiguas o el inventario no disponible. |
| 20 | Guion para vídeo de formato corto | Caso de uso, datos de características, pasos de demostración y CTA aprobado | Cree un gancho, una demostración, una prueba y una acción. Rechace las demostraciones que el producto no pueda realizar. |
No todos los productos necesitan los 20 resultados al mismo tiempo. La matriz ofrece una referencia estable para decidir qué activos son posibles, qué entradas requieren y por qué debe bloquearse un resultado.
La dirección importante va del campo canónico al campo del canal. Si el título de un marketplace se convierte en la entrada de un email, los errores y las convenciones de formato se propagan entre destinos. Ambos activos deben recurrir en su lugar a los campos canónicos aprobados.
Los datos deben permanecer fijos mientras cambia la presentación
Clasifique cada campo en uno de estos tres tipos:
- Dato fijo: Identidad, dimensiones, material, cantidad del paquete, compatibilidad, precio, disponibilidad o texto de cumplimiento.
- Interpretación controlada: Un beneficio aprobado vinculado a una o varias características objetivas.
- Presentación del canal: Orden, tono, longitud, formato, énfasis de palabras clave y llamada a la acción.
Un canal puede destacar atributos diferentes, pero no debe crear datos distintos. El título de un marketplace puede priorizar la talla y la cantidad del paquete. Un texto para redes sociales puede empezar con un caso de uso. Un bloque de email puede empezar con una oferta activa. Los tres deben corresponder al mismo SKU, variante, contexto de precio y capacidades aprobadas del producto.
Mantenga la redacción persuasiva en una fase posterior a la aprobación de los datos. Las recomendaciones de 10 trucos para escribir descripciones de producto que vendan en 2026 pueden mejorar la presentación, mientras que las mejores prácticas para las descripciones de producto ayudan a decidir qué detalles deben destacarse. Ningún paso debe sobrescribir los datos de origen.
El lenguaje de cada canal también necesita límites. Una frase que funciona en un vídeo corto puede ser inadecuada para la ficha de un marketplace o una categoría regulada. Si utiliza expresiones específicas de una plataforma, manténgalas en el vocabulario del destino en lugar de incluirlas en el registro canónico. La guía sobre el lenguaje de TikTok y el significado de «nudge» muestra por qué la terminología de un canal necesita contexto.
Los datos estructurados serán importantes más allá de las fichas y los feeds habituales. Como se describe en El comercio agéntico está convirtiendo el contenido de producto en infraestructura de pago, los sistemas que seleccionan y compran productos necesitan contenido de producto que puedan interpretar de forma fiable. Los identificadores, atributos, datos de ofertas y relaciones claros son más reutilizables que una redacción pulida por sí sola.
Una auditoría de diez pasos establece una base fiable
Utilice la auditoría de contenido multicanal para documentar el estado actual antes de cambiar los mapeos o generar nuevos activos.
-
Exporte todos los destinos activos. Recopile los registros actuales de productos de su tienda, marketplaces, feeds, catálogos publicitarios y canales de comercio social. Conserve la hora de exportación y la cuenta del canal.
-
Capture una instantánea de los sistemas de origen. Registre los campos pertinentes del ERP, PIM, proveedor, DAM y plataforma de comercio electrónico. Incluya
source_record_id,updated_at, configuración regional, mercado y responsable. -
Elija la autoridad canónica para cada campo. Los precios pueden proceder de su sistema de comercio electrónico, las dimensiones del PIM y los recursos multimedia aprobados del DAM. Designe una autoridad por campo y documente cualquier alternativa.
-
Cree un diccionario de campos. Defina el tipo, alcance, unidad, valores permitidos, política de valores nulos y responsable de cada campo. Distinga los campos de producto principal, variante, oferta, configuración regional y mercado.
-
Cree un contrato de canal por destino. Registre
required_fields,max_title_chars,max_description_chars,allowed_values,allowed_html,image_requirementsy las reglas condicionales. Feche y versione el contrato. -
Mapee los campos existentes. Para cada campo de destino, especifique su origen canónico y su transformación. Marque los campos como directos, convertidos, concatenados, generados, heredados o sin mapear.
-
Genere únicamente campos de presentación. Una vez aprobados los datos, puede utilizar el Multichannel Product Description Generator de Kua.ai para crear títulos y descripciones específicos para cada canal a partir de las entradas gestionadas. Mantenga el texto generado en los campos de destino, no en la capa de datos canónicos.
-
Ejecute primero la validación determinista. Compruebe los tipos, longitudes, valores obligatorios, enumeraciones, identificadores, unidades, fechas, precios, relaciones entre variantes, URL y disponibilidad de recursos antes de la revisión editorial.
-
Compare los resultados con la base de referencia. Marque los datos modificados, campos ausentes, reasignaciones de categorías, títulos acortados, afirmaciones eliminadas, ofertas vencidas y valores de variante alterados. Revise los cambios de alto riesgo en lugar de aprobar toda la exportación como un único bloque.
-
Publique con una referencia de reversión. Guarde la instantánea de origen, la versión del mapeo, el resultado generado, el registro de aprobación y el archivo de exportación. Si un canal rechaza o representa incorrectamente un artículo, debe poder identificar la regla exacta y restaurar la versión anterior.
La disciplina general es la gestión del contenido de producto: gobernanza centralizada, enriquecimiento, localización y distribución. La guía de Shopify sobre gestión del contenido de producto ofrece contexto adicional para organizar este trabajo en distintos destinos comerciales.
Lista de comprobación de la auditoría de referencia
- Cada SKU activo tiene un
product_id, unskuy, cuando corresponde, una relación estable con el producto principal. - Los identificadores obligatorios están presentes o tienen una excepción documentada.
- Los campos del producto principal y de las variantes están separados.
- Los valores numéricos tienen unidades explícitas.
- Las categorías se asignan mediante taxonomías de canal controladas.
- Los beneficios aprobados están vinculados a datos que los respaldan.
- Se conserva la redacción relativa al cumplimiento.
- Los precios incluyen la moneda y el contexto del mercado.
- Las fechas de oferta son válidas y no han vencido.
- Las imágenes principales se cargan correctamente y corresponden a la variante adecuada.
- El contenido localizado identifica su configuración regional y su estado de aprobación.
- Cada contrato de canal tiene un responsable y una fecha de versión.
- Cada activo generado puede rastrearse hasta sus entradas canónicas.
Las puertas de validación evitan la publicación de mapeos incorrectos
La validación debe devolver códigos específicos en lugar de un mensaje general como «el feed ha fallado». Entre los motivos de rechazo útiles se incluyen:
| Código de rechazo | Condición | Responsable de la corrección |
|---|---|---|
MISSING_REQUIRED | Un campo de destino obligatorio de forma condicional o universal está vacío | Responsable del catálogo |
INVALID_ENUM | Un valor no figura en la lista aceptada por el canal | Responsable de taxonomía o del canal |
OVER_MAX_LENGTH | El contenido presentado supera el límite configurado del canal | Operaciones de contenido |
ORPHAN_VARIANT | Un SKU hace referencia a un producto principal ausente o no válido | Responsable del catálogo |
UNIT_MISSING | Una medida numérica no tiene unidad | Responsable de datos de producto |
IDENTIFIER_INVALID | Un identificador no supera el formato o la comprobación configurados | Responsable del catálogo o proveedor |
PRICE_RELATION_INVALID | El precio de oferta, el precio habitual, la moneda o los valores de mercado entran en conflicto | Responsable de comercio |
SALE_WINDOW_INVALID | La fecha de finalización es anterior a la de inicio o la oferta ha vencido | Responsable de comercio |
ASSET_UNAVAILABLE | No se puede recuperar una imagen obligatoria o una URL de destino | Responsable de medios o de la web |
CLAIM_UNSUPPORTED | El texto generado introduce una afirmación no aprobada | Responsable de aprobar el contenido |
LOCALE_MISMATCH | El idioma del contenido no coincide con la configuración regional de destino | Responsable de localización |
SCHEMA_VERSION_STALE | La exportación utiliza un contrato de canal obsoleto | Responsable de integración |
Separe los errores de las advertencias. La ausencia de un identificador obligatorio puede bloquear la publicación. Una descripción más corta que el intervalo editorial preferido puede requerir únicamente una advertencia. Documente esta diferencia para que los operadores no eludan fallos reales con el fin de despejar una cola saturada.
La revisión editorial debe centrarse en cuestiones que la automatización no puede resolver de forma fiable: claridad, énfasis engañoso, significado duplicado, tono y si un beneficio representa fielmente los datos del producto. Los revisores deben ver los campos de origen junto al activo generado.
La base de referencia está completa cuando cada resultado es trazable
Una base de referencia útil permite responder cinco preguntas sobre cualquier valor publicado:
- ¿Qué sistema de origen lo proporcionó?
- ¿Qué campo canónico lo almacenó?
- ¿Qué transformación lo modificó?
- ¿Qué regla del canal lo validó?
- ¿Quién aprobó el resultado final?
Si alguna respuesta depende de la memoria, de un comentario en una hoja de cálculo o de localizar a la persona que cargó el feed por última vez, el mapeo aún no está completo desde el punto de vista operativo.
Cree primero la matriz de campos para una familia de productos representativa. Incluya un producto sencillo, uno con múltiples variantes, una oferta, un registro localizado y un producto con texto de cumplimiento. Cuando esos casos superen las pruebas, aplique el mismo patrón gestionado al resto del catálogo.
Utilice Kua.ai para convertir los datos de producto aprobados en activos listos para cada destino una vez que haya establecido el diccionario de campos y los contratos de canal. Empiece con un registro auditado, valide los 20 resultados y mantenga cada campo generado conectado con su origen.
Preguntas frecuentes
¿Qué es el mapeo de campos de datos de producto entre canales?
El mapeo de campos de datos de producto es la conexión documentada entre un valor de origen, un campo canónico de producto y un campo de canal de destino. También define cualquier transformación, condición, regla de validación y tratamiento de valores nulos aplicado durante el proceso.
Por ejemplo, un número de artículo del ERP puede asignarse directamente al sku canónico y después al campo de SKU del vendedor de un marketplace. Un valor de material normalizado puede requerir una consulta controlada antes de introducirse en un atributo del canal. El mapeo debe hacer visibles ambas rutas.
¿Debe utilizar la misma descripción de producto en todos los canales?
Debe reutilizar los mismos datos aprobados, pero no debe obligar a todos los canales a utilizar una presentación idéntica. Los destinos difieren en la estructura de sus campos, la intención del público, el formato, el comportamiento de búsqueda y las reglas de contenido.
Genere cada descripción a partir del mismo nombre de producto, características, dimensiones, compatibilidad, beneficios y campos de cumplimiento. Cambie el orden, la longitud, el tono y el formato según el contrato del canal. No introduzca nuevas especificaciones o afirmaciones durante la adaptación.
¿Cómo deben mapearse los campos del producto principal y de las variantes?
Almacene la información compartida en el nivel del producto principal y las diferencias vendibles en el nivel de la variante. La marca, la familia de productos y la descripción general pueden pertenecer al producto principal. El SKU, el color, la talla, el código de barras, el precio, el inventario y la imagen de la variante suelen pertenecer a la variante vendible.
Defina explícitamente la herencia. Una variante puede heredar la descripción del producto principal cuando esté permitido, pero no debe heredar el color, el identificador, la imagen ni los datos de oferta de otra variante. Bloquee cualquier variante cuya relación con el producto principal no pueda resolverse.
¿Qué debe ocurrir cuando falta un campo obligatorio del canal?
No adivine ni genere un valor factual. Devuelva MISSING_REQUIRED, identifique el campo canónico y su responsable, y bloquee el artículo cuando el destino exija ese valor.
Si el campo es opcional, aplique la política documentada de valores nulos: omítalo, herede un valor aprobado del producto principal o envíe un valor vacío únicamente cuando el esquema espere uno expresamente. Registre las excepciones para que las soluciones temporales no se conviertan en mapeos permanentes.
¿Con qué frecuencia deben revisarse los mapeos de canales?
Revise un mapeo siempre que un canal cambie su esquema, taxonomía, valores aceptados, política de contenido o respuesta del feed. También debe revisarlo cuando añada un tipo de producto, mercado, configuración regional, modelo de variantes o sistema de origen.
Como control rutinario, compare las exportaciones actuales con la base de referencia guardada antes de las principales actualizaciones estacionales. Preste especial atención a los periodos de oferta, la disponibilidad, los mapeos de categorías, las URL de imágenes, los campos de cumplimiento y las afirmaciones generadas.
¿Puede la IA mapear y redactar automáticamente todos los campos?
La IA puede ayudar a clasificar campos de origen, sugerir mapeos y crear campos de presentación como títulos, viñetas, descripciones, anuncios y guiones. Las reglas deterministas deben seguir controlando los identificadores, precios, unidades, fechas, enumeraciones, relaciones entre variantes y textos de cumplimiento.
Exija aprobación humana para los mapeos ambiguos y las afirmaciones de alto riesgo. El flujo de trabajo más seguro combina datos de origen gestionados, contratos de canal versionados, validación automatizada y una revisión editorial específica.
