EAN vs GTIN vs UPC/ISBN/MPN: qué necesita tu catálogo (y cuándo es obligatorio)
El código EAN es el identificador físico más común en el retail europeo y constituye la base técnica para la mayoría de reglas de calidad de catálogo en un entorno digital. Sin embargo, la confusión terminológica entre EAN, GTIN, UPC y MPN es la causa raíz de miles de errores de sincronización en feeds de datos.
En esta sección aclaramos la jerarquía técnica, las diferencias críticas con otros identificadores y por qué canales como Google Merchant Center exigen una precisión absoluta para evitar la suspensión de productos.
Qué es GTIN, EAN, UPC, ISBN y MPN
Para evitar errores de mapeo y conflictos de propiedad entre canales de venta, es vital distinguir entre el estándar, el formato y la referencia de fabricante.
GTIN (Global Trade Item Number) es el término paraguas para los identificadores globales de producto estandarizados por la organización GS1. Es el concepto abstracto que engloba a los formatos físicos que vemos en los códigos de barras:
- EAN (European Article Number): Es el formato estándar en Europa y la mayor parte del mundo. Técnicamente suele corresponder a un GTIN-13.
- UPC (Universal Product Code): Es el estándar predominante en Norteamérica. Corresponde a un GTIN-12.
- ISBN: Identificador específico para libros. Sigue reglas propias para ediciones y formatos, pero en el feed se mapea a su propio campo o se convierte a GTIN-13 (empezando por 978).
Por otro lado, el MPN (Manufacturer Part Number) es la referencia interna asignada por el fabricante. A diferencia del GTIN, el MPN no garantiza unicidad global (dos fabricantes distintos podrían usar la referencia "A-100").
Cómo abordarlo en tu catálogo:
Valida siempre la longitud y el checksum (dígito de control) antes de aceptar un código en tu base de datos. Un auricular con un código de 13 dígitos es un EAN (GTIN-13). Un libro debe mapearse al campo isbn en el feed. Nunca uses el MPN en el campo de GTIN; esto es un error crítico que confunde a los algoritmos de emparejamiento de productos en marketplaces.
Fuente: Información oficial sobre estándares en GS1.
Por qué Google Merchant Center pide GTIN y cuándo lo considera obligatorio
Google utiliza el GTIN para agrupar ofertas del mismo producto vendidas por distintos retailers. Conocer su política exacta evita rechazos masivos y la pérdida de impresiones en Shopping.
Google solicita GTIN obligatoriamente cuando el producto tiene un GTIN asignado por el fabricante y el feed proporciona la marca. Si el producto es artesanía, hecho a medida, o una antigüedad sin código, Google permite omitirlo usando el atributo identifier_exists (que veremos más adelante), pero requiere pruebas.
Ejemplo de impacto:
Un smartphone de marca reconocido (ej. Samsung Galaxy) listado sin su GTIN será marcado inmediatamente como "Información insuficiente de producto" y perderá elegibilidad para mostrarse en anuncios de Shopping, independientemente de tu puja.
Error típico:
Subir feeds que incluyen la brand (marca) y el mpn, pero dejan el campo gtin vacío cuando el producto realmente existe en el catálogo de GS1. Esto dispara una alerta de "GTIN faltante".
Fuente: Política oficial de identificadores en Google Merchant Center.
Dónde guardar identificadores en tu modelo de datos y por qué
Para reducir discrepancias entre tu e-commerce y los canales de marketing, necesitas un campo maestro (Source of Truth) a nivel de variante, no de producto padre.
Estrategia de almacenamiento:
- En un PIM (Product Information Management): Guarda un campo
gtin específico por cada variante. El PIM actúa como sistema centralizado que alimenta tanto a Shopify como a los feeds de marketing, asegurando que el dato sea idéntico en todos lados.
- En Shopify: Utiliza Product Metafields a nivel de variante para almacenar
gtin y mpn. Los metafields son campos personalizados que permiten guardar atributos adicionales estructurados, facilitando que las apps de feeds y ERPs lean el dato correcto sin tener que "escanear" la descripción o el título.
Ejemplo de implementación:
Crea en el PIM un atributo de texto gtin_text por variante. Mapéalo en la integración para que rellene el metafield shopify.metafields.product.gtin. Al exportar, el feed leerá este metafield.
Fuente: Guía de gestión de identificadores en Shopify.
Cómo mapear GTIN EAN en feeds y reglas de transformación
Un feed es el archivo (XML, CSV) o API que envía tus productos a canales externos. Normas claras de mapeo en esta etapa evitan errores automáticos.
Lógica de transformación recomendada:
En tu pipeline de exportación (feed management tool), prioriza siempre el campo gtin que viene del PIM/Metafield. Implementa una regla de "fallback" o respaldo:
- Si
gtin no está vacío → Usar gtin.
- Si
gtin está vacío Y mpn existe → Usar mpn y marcar identifier_exists = false (si aplica según la categoría).
- Normalización: Antes de enviar, aplica una función que elimine espacios en blanco, guiones y valide que solo hay caracteres numéricos.
Pseudoregla de transformación:
IF gtin IS NOT EMPTY THEN map_to 'gtin' ELSE IF mpn IS NOT EMPTY THEN map_to 'mpn' AND set 'identifier_exists' to 'false'.
Error típico:
Enviar GTINs "sucios" (ej: 123-456-789) que provocan el rechazo total del item en el feed por formato inválido.
Cómo construir tu sistema de identificadores: obtención, reglas y modelo de datos
El Código EAN es crítico no solo para Google, sino para mantener la coherencia operativa entre tu tienda, tu ERP y los marketplaces (Amazon, Zalando, etc.). Aquí profundizamos en la gobernanza: cómo obtenerlos, cómo decidir su herencia y cómo estructurar los datos.
Reglas clave iniciales para la gobernanza
Sin una política documentada, cada departamento (compras, logística, marketing) aplicará criterios distintos. Esto garantiza duplicidades.
La Política Mínima Viable:
Documenta cuándo es obligatorio usar un GTIN de GS1 y cuándo se permite un identificador interno.
- Regla: Si el producto se vende en marketplaces o feeds externos, exigir GTIN registrado en GS1.
- Regla: Productos de marca propia que nunca saldrán de la web propia pueden usar identificadores internos, pero deben etiquetarse internamente como
local_only para excluirlos de requerimientos de GTIN en los feeds.
Recurso: GS1 es la única fuente autorizada para generar códigos interoperables. Consulta sus estándares en GS1 Standards.
Reglas por variante y herencia del EAN
La decisión de aplicar el EAN al producto "padre" o a las variantes "hijo" es la fuente de mayor fricción en catálogos de moda y variantes complejas.
Framework de decisión:
- Producto Simple: El GTIN se asigna al producto.
- Variantes (Talla/Color): Cada variante vendida por separado debe tener su propio GTIN. Una zapatilla talla 40 y la misma en talla 41 son productos físicos distintos con códigos de barras distintos.
- Bundles / Multipacks: Si vendes un pack de 3 unidades, este necesita un GTIN nuevo (del pack), no puedes reutilizar el de la unidad individual.
Lógica de herencia en exportación:
Configura tu feed para que busque el valor en este orden: Variante > Producto. Si la variante tiene GTIN, úsalo. Si no, verifica si el producto padre tiene (solo válido para productos simples).
Error típico:
Usar el mismo GTIN para todas las tallas de una camiseta. Google detectará que el mismo identificador apunta a SKUs diferentes y rechazará todos por "GTIN duplicado".
Obtener EAN válidos y trazabilidad
Los marketplaces avanzados pueden auditar la propiedad del prefijo del GTIN.
Proceso de obtención:
Compra bloques de GTIN directamente en GS1 para los países donde operas. Evita revendedores de códigos baratos, ya que a menudo pertenecen a otras empresas y generarán conflictos de marca en Amazon o Google.
- En el PIM: Registra no solo el número, sino la fuente. Añade campos administrativos:
gtin_source, date_assigned, y validation_status.
Multipacks y casos especiales
Un multipack es una unidad de venta distinta a sus componentes.
Cómo gestionarlo:
Asigna un GTIN propio al pack. En el PIM, crea una relación de tipo "contiene" que vincule el SKU del pack con la cantidad del SKU base.
- En el feed: Marca el atributo
multipack como true (o indica la cantidad) y exporta el GTIN del pack.
- Ejemplo: Pack de 6 botellas de vino. Tiene su propio EAN-13 en la caja. No uses el EAN de la botella individual.
Auditoría y corrección a escala: checks automáticos y checklist de envío
Incluso con buenas políticas, los datos se degradan. Esta sección cubre cómo auditar tu catálogo masivamente antes de fechas críticas (Black Friday, Rebajas) para asegurar que ningún "top seller" sea rechazado por problemas de EAN.
Validación previa masiva del Código EAN
Los códigos incorrectos generan rechazos silenciosos: el producto se sube, pero no recibe impresiones.
Estrategia de validación por lotes:
Extrae un volcado completo de tu catálogo (CSV/Excel) con las columnas: sku, variant_id, gtin, mpn y identifier_exists. Ejecuta un script o utiliza fórmulas para validar:
- Longitud: ¿Tiene 8, 12, 13 o 14 dígitos? Cualquier otra cosa es error (a menos que sea ISBN).
- Tipo: ¿Es numérico?
- Integridad: Valida el dígito de control usando el algoritmo Módulo 10.
Produce un reporte con tres columnas: estado (Válido/Inválido), motivo (Checksum incorrecto/Longitud errónea) y acción (Corregir en PIM).
Error típico:
Aplicar correcciones manuales en el feed (por ejemplo, añadiendo un 0 delante para convertir UPC a EAN) sin corregir el dato en el PIM, lo que perpetúa el error en futuras sincronizaciones.
Uso correcto del atributo identifier_exists
Google y Meta permiten productos sin GTIN, pero solo si usas este atributo correctamente. Un uso indebido (marcar todo como false para evitar buscar los códigos) puede llevar a la suspensión de la cuenta.
Lógica de asignación:
- Si
gtin está presente y válido → Exporta gtin.
- Si
gtin está vacío Y el producto es "custom" (artesanía, marca propia sin GTIN, antigüedad) → Exporta identifier_exists = false.
- Asegúrate de que esta lógica aplica a nivel de variante. La variante A puede tener GTIN y la variante B (una edición limitada hecha a mano) no.
Más info: Consulta la especificación de datos de producto de Google y la documentación de catálogos de Meta.
Checklist operacional antes del envío a producción
Sigue este protocolo antes de conectar un nuevo feed o tras una actualización masiva de catálogo:
- Validación de Formato: ¿El 100% de los campos
gtin poblados pasan el test de longitud y checksum?
- Revisión de Familias: ¿Están los identificadores asignados a las variantes y no al padre en productos configurables?
- Mapa de Metafields: ¿Confirma que el feed está leyendo
shopify.metafields.namespace.key y no la descripción?
- Envío de Prueba: Sube el feed a un "Test Feed" en Merchant Center para ver errores sin afectar la cuenta real.
- Log de Cambios: Registra en el PIM quién modificó un GTIN y por qué, para mantener la trazabilidad.
Automatización de la gobernanza de catálogo con ButterflAI
Mantener la integridad de los identificadores EAN/GTIN manualmente en miles de SKUs es una tarea propensa al error humano y consume horas de gestión técnica.
ButterflAI audita tu catálogo en tiempo real detectando inconsistencias en identificadores, validando checksums y asegurando que la estructura de variantes cumple con los requisitos estrictos de Google Merchant Center y Meta. La plataforma permite corregir estos atributos masivamente y generar descripciones y metadatos optimizados, garantizando que tus productos no solo sean aprobados, sino que posicionen mejor.