Sistemas de Datos de Producto que Realmente Funcionan: Del ERP al Canal

El Problema de Datos de Producto del que Nadie Habla

Los datos de producto parecen simples en una hoja de cálculo. Nombre, descripción, precio, imagen. Luego la realidad te golpea. Tienes 50.000 productos con 200 atributos cada uno, en 12 idiomas, provenientes de 3 sistemas fuente, distribuidos a 5 canales de salida, y la calidad de los datos es inconsistente en todos ellos.

El problema real no es almacenar datos de producto. Cualquier base de datos hace eso. El problema real es el pipeline: cómo los datos fluyen desde los sistemas fuente a través del enriquecimiento hasta los canales de salida, con validación en cada etapa y formatos diferentes para cada destino.

Hemos diseñado sistemas de datos de producto para fabricantes B2B con jerarquías de clasificación complejas, contenido multi-locale, integración ERP y salida multicanal (web, búsqueda, marketplace, exportación). Este artículo cubre los patrones de arquitectura. Para la implementación PIM específicamente, consulta nuestra guía de implementación PIM. Para patrones de workflow en Pimcore, consulta nuestra guía de workflow Pimcore.

El Pipeline: De la Fuente al Canal

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│   FUENTES     │     │   MASTER      │     │   CANALES     │
│               │     │               │     │               │
│  ERP/SAP     │────▶│  Sistema PIM  │────▶│  Sitio web     │
│  Proveedores │     │  (Pimcore,    │     │  Índice búsqueda│
│  Hojas cálc. │     │   Akeneo)     │     │  Marketplace   │
│  Entrada man.│     │               │     │  Print/PDF     │
│              │     │  Enriquecer   │     │  API socios    │
│              │     │  Validar      │     │  Feed de datos │
│              │     │  Aprobar      │     │               │
└──────────────┘     └──────────────┘     └──────────────┘

Capa de Fuentes

Los productos entran al sistema desde múltiples fuentes. Cada fuente tiene diferente calidad de datos, diferentes formatos y diferentes frecuencias de actualización.

La capa de importación debe manejar: mapeo de campos (el proveedor lo llama "item_name", el ERP lo llama "MATNR"), transformación de datos (precio en EUR a centavos), deduplicación (mismo producto desde dos fuentes) y resolución de conflictos (qué fuente gana para qué campo).

Este es exactamente el problema que nuestro Vendure Data Hub Plugin resuelve con 9 extractores, 61 operadores de transformación y mapeo de campos configurable.

Capa Master (PIM)

El PIM es la fuente única de verdad para los datos de producto. Cada campo tiene un valor autoritativo. Cada cambio está versionado. Cada producto pasa por un workflow editorial antes de su publicación.

Responsabilidades clave del PIM:

• Enriquecimiento de datos: agregar descripciones, imágenes y traducciones que no vienen del ERP
• Clasificación: asignar productos a categorías jerárquicas con atributos tipados
• Validación: asegurar que los campos obligatorios estén completos antes de la publicación
• Workflow: revisión editorial y aprobación antes de que los datos lleguen a los canales de salida
• Versionado: rastrear cada cambio, permitir edición de borradores sin afectar los datos en producción

Capa de Canales

Cada canal de salida necesita los datos de producto en un formato diferente:

Los mismos datos de producto, transformados de manera diferente para cada canal. El PIM almacena los datos master. La capa de distribución transforma y entrega.

Sistemas de Clasificación

Los productos tienen atributos. Un zapato tiene talla, color, material y tipo de suela. Un grifo tiene caudal, tipo de conexión, acabado y certificación. Un servidor tiene CPU, RAM, almacenamiento y unidades de rack.

Atributos Planos vs Classification Store

Los atributos planos (columnas en la tabla de productos) funcionan para catálogos simples con productos uniformes. Cada producto tiene los mismos campos.

Los classification stores (clave-valor dinámico con grupos) funcionan para catálogos diversos donde diferentes tipos de productos tienen diferentes atributos.

Classification Store:
├── Grupo: Dimensiones
│   ├── Clave: width (float, unidad: mm)
│   ├── Clave: height (float, unidad: mm)
│   └── Clave: depth (float, unidad: mm)
├── Grupo: Técnico
│   ├── Clave: flow_rate (float, unidad: l/min)
│   ├── Clave: pressure (float, unidad: bar)
│   └── Clave: connection_type (select: 3/8", 1/2", 3/4")
├── Grupo: Certificaciones
│   ├── Clave: ce_mark (boolean)
│   ├── Clave: tuv (boolean)
│   └── Clave: energy_label (select: A-G)

Los classification stores escalan a miles de atributos sin cambios de esquema. Nuevos atributos son configuración, no migración. Pero son más difíciles de consultar (lookups clave-valor en lugar de acceso por columna) y más difíciles de validar (el esquema es dinámico).

En Pimcore, el Classification Store proporciona esta capacidad de forma nativa con valores localizados, organización por grupos e integración con la UI de admin.

Gestión de Variantes

Los productos con variantes (talla, color, configuración) son la fuente de la mayor parte de la complejidad en los datos.

Arquitectura de Variantes

Product (parent)
├── name: "Running Shoe Pro"
├── description: "..."
├── brand: "..."
├── images: [hero.jpg, detail.jpg]
│
├── Variant: Talla 40, Negro
│   ├── sku: "RSP-40-BLK"
│   ├── price: 12900  (centavos)
│   ├── stock: 15
│   └── ean: "4012345678901"
│
├── Variant: Talla 40, Blanco
│   ├── sku: "RSP-40-WHT"
│   ├── price: 12900
│   ├── stock: 8
│   └── ean: "4012345678902"
│
└── Variant: Talla 42, Negro
    ├── sku: "RSP-42-BLK"
    ├── price: 12900
    ├── stock: 0  (agotado)
    └── ean: "4012345678903"

Datos heredados vs específicos de la variante:

• Heredados (del padre): nombre, descripción, marca, categoría, imágenes compartidas
• Específicos de la variante: SKU, precio, stock, EAN, talla, color, imágenes específicas de la variante

El modelo de herencia reduce la duplicación. Cambias la descripción del producto una vez y se actualiza para todas las variantes. Pero los overrides específicos de la variante deben ser posibles (precio diferente por talla, imagen diferente por color).

La Explosión Combinatoria

Un producto con 5 tallas y 8 colores tiene 40 variantes. Agrega 3 materiales y tienes 120. Agrega 2 anchos y tienes 240. La mayoría de estas combinaciones no existen como productos reales.

Soluciones:

• Solo variantes explícitas: crear únicamente las combinaciones que existen. Sin generación automática.
• Matriz de disponibilidad: definir qué combinaciones son válidas. Generar automáticamente solo las válidas.
• Variantes virtuales: calcular en tiempo de consulta a partir de conjuntos de atributos. No almacenar registros individuales.

Pipeline de Assets

Las imágenes de producto, dibujos técnicos, PDFs y modelos 3D necesitan su propio pipeline.

Upload/Import
  │
  ├── Validación de formato (tipo, tamaño, resolución)
  ├── Extracción de metadatos (EXIF, dimensiones)
  ├── Generación de miniaturas (múltiples tamaños)
  ├── Distribución CDN
  └── Asociación al producto/variante

Desafíos de Assets

Para Pimcore específicamente, documentamos un bug de rendimiento donde los lookups de dimensiones de assets disparan I/O al almacenamiento remoto en cada renderizado de página. La solución está descrita en nuestra guía de actualización de Pimcore.

Distribución Multicanal

Distribución Event-Driven

Cuando un producto se publica en el PIM, los eventos disparan la distribución a cada canal:

// El PIM publica el producto -> los eventos disparan las actualizaciones de canales
eventBus.on('product.published', async (product) => {
    await Promise.allSettled([
        searchIndexer.index(product),           // Actualizar la búsqueda
        feedGenerator.queue(product),            // Encolar para feeds de marketplace
        cacheInvalidator.invalidate(product.id), // Invalidar caché del sitio web
        partnerApi.notify(product.id),           // Notificar sistemas de socios
    ]);
});

Cada transformador de canal convierte los datos master al formato específico del canal:

// Sitio web: datos completos con campos SEO
function toWebProduct(product: PimProduct): WebProduct {
    return {
        slug: product.slug,
        name: product.name,
        description: product.description,
        seoTitle: product.seoTitle || product.name,
        seoDescription: product.seoDescription || truncate(product.description, 160),
        images: product.images.map(img => ({
            url: cdn.getUrl(img, 'large'),
            alt: img.alt || product.name,
        })),
        variants: product.variants.filter(v => v.active),
        // ... datos completos del producto
    };
}

// Feed de marketplace: formato específico de la plataforma
function toGoogleMerchantItem(product: PimProduct, variant: PimVariant): MerchantItem {
    return {
        id: variant.sku,
        title: `${product.name} - ${variant.size} ${variant.color}`,
        description: stripHtml(product.description),
        link: `https://shop.example.com/p/${product.slug}`,
        image_link: cdn.getUrl(product.images[0], 'large'),
        price: `${(variant.price / 100).toFixed(2)} EUR`,
        availability: variant.stock > 0 ? 'in_stock' : 'out_of_stock',
        brand: product.brand,
        gtin: variant.ean,
        condition: 'new',
    };
}

Calidad de los Datos

Validación Automatizada

interface ValidationRule {
    field: string;
    check: (value: any, product: Product) => boolean;
    message: string;
    severity: 'error' | 'warning';
}

const VALIDATION_RULES: ValidationRule[] = [
    { field: 'name', check: (v) => v && v.length > 3, message: 'El nombre debe tener al menos 3 caracteres', severity: 'error' },
    { field: 'description', check: (v) => v && v.length > 50, message: 'La descripción debería tener al menos 50 caracteres', severity: 'warning' },
    { field: 'images', check: (v) => v && v.length > 0, message: 'Se requiere al menos una imagen', severity: 'error' },
    { field: 'price', check: (v) => v && v > 0, message: 'El precio debe ser positivo', severity: 'error' },
    { field: 'ean', check: (v) => !v || isValidEan(v), message: 'Formato EAN inválido', severity: 'error' },
    { field: 'categories', check: (v) => v && v.length > 0, message: 'Se requiere al menos una categoría', severity: 'error' },
];

Ejecuta la validación antes de la publicación. Bloquea la publicación en caso de errores. Muestra advertencias pero permite la publicación. Rastrea los puntajes de calidad de datos por producto, por categoría, por proveedor.

Errores Comunes

1. Sin fuente única de verdad. Si los mismos datos de producto viven en el ERP, el PIM y el sistema de comercio sin un master claramente definido, los conflictos son inevitables.

2. El ERP como PIM. Los ERPs almacenan datos operativos (SKU, precio, stock). No manejan contenido enriquecido (descripciones, imágenes, traducciones). No intentes forzarlos a hacerlo.

3. Sin propiedad de campos. Sin reglas claras sobre qué fuente es dueña de qué campo, las importaciones sobrescriben el enriquecimiento manual. Consulta nuestra guía de workflow Pimcore para el patrón de propiedad de campos.

4. Mismo formato para todos los canales. Cada canal necesita datos diferentes. Un feed de Google Merchant y una API de sitio web tienen campos, formatos y frecuencias de actualización diferentes.

5. Sin validación antes de la publicación. Los productos se publican con imágenes faltantes, descripciones vacías o EANs inválidos. La validación automatizada previene esto.

6. Ignorar la complejidad de las variantes. Generar automáticamente todas las combinaciones posibles crea miles de variantes fantasma. Solo crea las combinaciones reales y disponibles.

Puntos Clave

• El pipeline es la arquitectura. Fuente a master a canal. Cada etapa tiene diferentes responsabilidades, diferentes formatos de datos y diferentes requisitos de calidad.

• El PIM es la fuente única de verdad. No el ERP, no el sistema de comercio, no la hoja de cálculo. Un master autoritativo con versionado y workflow.

• Los classification stores manejan la diversidad de atributos. Cuando diferentes tipos de productos tienen diferentes atributos, el clave-valor dinámico con grupos escala mejor que las columnas fijas.

• Cada canal tiene su propia transformación. Sitio web, búsqueda, marketplace, print y API de socios necesitan formatos diferentes a partir de los mismos datos master.

• La calidad de datos es un sistema, no un paso. Validación automatizada, puntajes de calidad, reglas de bloqueo en la publicación. Continuo, no de una sola vez.

Diseñamos sistemas de datos de producto como parte de nuestras prácticas de ecommerce e ingeniería de datos. Si necesitas ayuda con arquitectura PIM o pipelines de datos de producto, habla con nuestro equipo o solicita un presupuesto.