La planificación del modelo de datos de VTEX debe comenzar con una pregunta de traducción de significado: ¿qué registros del origen se convertirán en estructuras comerciales utilizables de VTEX y cuáles pertenecen a otro dominio de VTEX, a la implementación de Storefront, a una integración o a un sistema externo? VTEX es un entorno de comercio modular, por lo que el significado de los datos se distribuye entre Catalog, SKUs, specifications, Pricing, Promotions, Checkout, Orders, Logistics, sellers, contexto de marketplace, Master Data, Search, implementación de Storefront y sistemas externos.
Esto hace que VTEX sea diferente de plataformas donde los datos de Product, Customer, Order, página y URL pueden revisarse principalmente como registros aislados. Una opción de Product del origen puede convertirse en un SKU, una specification, una selección de Storefront, un campo personalizado o un requisito de reconstrucción. Un campo de Customer del origen puede ser contexto ordinario de perfil, Master Data, información B2B, identidad propiedad de CRM o metadatos de integración. Un Order del origen puede conservar valor para atención y elaboración de informes, pero no configura automáticamente Checkout, Payments, preparación de pedidos, marketplace o Logistics en VTEX.
El alcance más sólido para una migración hacia VTEX no es el que transfiere más datos. Es el que conserva significado útil y separa registros migrados de configuración de VTEX, implementación frontend, responsabilidad de integraciones, correspondencia estructurada o tratamiento dedicado en destino y necesidades de reestructuración o correspondencia específica.
El significado de los datos de VTEX se distribuye entre servicios comerciales
Los datos de VTEX deben interpretarse según el dominio de plataforma que será responsable de ellos después de la migración. Los datos de Catalog pueden afectar presentación de Products, Search, Pricing, Promotions, disponibilidad de SKUs, Logistics y funcionamiento de marketplace. El historial de Orders puede ser importante para atención y informes, pero el procesamiento activo de Orders depende de Checkout, Payments, preparación de pedidos, Logistics y configuración operativa. Los datos de Customer pueden parecer sencillos al principio, mientras Master Data, segmentación, contexto B2B, identificadores de CRM o formularios personalizados crean decisiones independientes.
Este modelo distribuido cambia la revisión de la migración. Un campo que parecía un atributo ordinario de Product en la Store de origen puede ser una specification en VTEX. Una variante del origen puede necesitar estructura a nivel de SKU. Un precio de canal puede pertenecer a reglas o tablas de Pricing en lugar del propio Product. Una referencia de seller de marketplace puede no ser dato ordinario de Catalog. Una página de contenido puede requerir implementación de Storefront o planificación de redirecciones en lugar de una migración directa uno a uno.
| Registro o comportamiento de origen | Pregunta de interpretación en VTEX | Implicación para la migración |
|---|---|---|
| Opción o variante de Product | ¿Define un SKU vendible, una Product specification o comportamiento de selección en Storefront? | La relación Product-SKU-specification debe ser explícita en el alcance. |
| Atributo o campo personalizado | ¿Se usa para filtrado, detalle de Product, operaciones, integración o flujo de Customer? | La correspondencia depende del uso comercial, no solo de la similitud de nombres. |
| Precio de canal o promoción | ¿Es precio base, tabla de precios, condición de canal de ventas, Coupon o regla activa de Promotion? | El comportamiento comercial debe separarse de datos históricos de precios. |
| Campo adicional de Customer | ¿Es dato de perfil, Master Data, contexto B2B, metadato de CRM o información propiedad de integración? | Algunos valores pueden necesitar correspondencia o filtrado acotado, reestructuración específica o tratamiento desde sistemas externos. |
| Estado de Order o nota de preparación | ¿Es contexto histórico de atención o comportamiento activo de OMS/Logistics? | La migración de Orders no debe tratarse como configuración de flujo de trabajo del destino. |
VTEX requiere, por tanto, correspondencia basado en significado. Cada área de datos necesita un responsable futuro y una finalidad declarados; esa responsabilidad determina si un campo pertenece a registros migrados, configuración de VTEX, implementación de Storefront, datos de integración, un modelo reestructurado de destino o exclusión deliberada.
La traducción de Catalog empieza con relaciones entre Category, Brand, Product, SKU y specification
VTEX Catalog no es una tabla plana de Products. Su estructura central conecta Categories, Brands, Products, SKUs y specifications. Un Product representa la definición comercial genérica y cada SKU la variación o unidad física que puede mantenerse en stock y comprarse. Los grupos de specifications vinculados a Categories definen qué propiedades de Product y SKU se aplican y pueden heredarse entre niveles de Category.
| Estructura de origen | Interpretación en VTEX | Consecuencia para la relación |
|---|---|---|
| Product padre con variantes hijas | Product con uno o más SKUs | La identidad vendible, imágenes, inventario y líneas de Order pertenecen al nivel de SKU cuando corresponda. |
| Atributo de Product | Product specification | Conserva campo y valor vinculados a Category en lugar de copiar texto libre. |
| Atributo de variante, como talla o voltaje | SKU specification | Mantenlo unido al SKU que representa la variación física. |
| Brand o Manufacturer | Relación de Brand | No aplanes el valor cuando navegación o descubrimiento dependan de la entidad Brand. |
| Árbol de Categories | Clasificación de Catalog | La posición en Categories determina herencia de specifications y organización de Products. |
| Conjunto de imágenes de Product | Relación multimedia con SKU | VTEX asocia disponibilidad vendible e imágenes con SKUs activos. |
| Conjunto, kit o estructura configurable | Kit, attachment, assembly opción, service o lógica externa | Determina qué estructura de VTEX posee realmente la relación de componentes y precios. |
Una migración puede conservar todos los nombres de Products del origen y seguir produciendo un Catalog débil en VTEX si SKUs, specifications, imágenes, Categories y Brands ya no describen el mismo artículo vendible.
Specifications, attachments y assembly opciones conservan significados distintos
Las specifications de VTEX son propiedades estructuradas asociadas con Categories y aplicadas a Products o SKUs. Pueden sostener navegación, comparación, selección, integración o presentación. Por ello, su finalidad es tan importante como el valor. Un campo "color" usado para filtrado no equivale automáticamente a una nota de color en texto libre; una talla que distingue SKUs no es igual a una specification dimensional del Product.
VTEX también separa specifications de estructuras opcionales de personalización de Products. Attachments pueden recopilar información vinculada a un SKU. Assembly opciones pueden representar combinaciones más complejas, cantidades, artículos adicionales, costes y relaciones de inventario. Kits agrupan SKUs que se venden juntos, mientras los extras de pago pueden representarse mediante relaciones de SKU service. Estos conceptos no deberían colapsarse en una única columna genérica de "opción".
| Significado en origen | Concepto de destino en VTEX | Distinción clave |
|---|---|---|
| Característica descriptiva | Product specification | Describe el Product genérico. |
| Característica que define una variación | SKU specification | Distingue la unidad vendible. |
| Información aportada por el comprador | Attachment | Añade información a un SKU sin crear necesariamente otro SKU. |
| Componente o combinación configurable | Assembly opción | Representa artículos adicionales, cantidades, costes o relaciones de inventario. |
| Grupo de unidades vendibles | Kit | Conserva una composición de SKUs vendidos juntos. |
| Extra de pago asociado a un artículo | Relación de SKU service | Mantiene el extra separado de la identidad base del SKU. |
El modelo de destino debe conservar la estructura que determina identidad de Product, selección del comprador, inventario e interpretación de líneas de Order, no limitarse a conservar etiquetas y valores.
Pricing, Promotions, trade policies y offers forman capas comerciales separadas
Una exportación de origen puede colocar precio, sale precio, channel, marketplace y disponibilidad junto al registro de Product. VTEX separa estos significados entre Catalog, Pricing, Promotions, trade policies, Logistics, Inventory y offer del sellers. Un mismo SKU puede participar en distintos contextos comerciales sin convertirse en varios Products.
| Registro comercial | Significado en VTEX | Consecuencia de responsabilidad |
|---|---|---|
| Precio base o de lista | Relación de Pricing para un SKU | El precio no es un atributo permanente del Product. |
| Resultado de Promotion o Coupon | Ajuste comercial basado en reglas | La evidencia histórica de descuento en Orders se separa de las reglas activas de Promotions. |
| Trade policy | Contexto de canal de ventas | Determina dónde están disponibles Products o SKUs y puede vincular condiciones comerciales. |
| Inventory y Logistics | Disponibilidad y promesa de preparación de pedidos | El significado de stock y entrega pertenece fuera del registro descriptivo de Catalog. |
| Seller offer | Oferta comercial de un seller para un artículo de Catalog | La identidad de marketplace y responsabilidad del seller permanecen separadas de la definición del Product. |
| Surtido específico de canal | Disponibilidad de Products por trade policy o seller | Conserva la relación en lugar de duplicar el Product. |
Este modelo por capas es especialmente importante cuando la Store de origen usa catálogos regionales, listas de precios B2B, ofertas de marketplace o precios dirigido por ERP. La migración debe conservar los identificadores que conectan el SKU con sus registros de precio, canal, seller, inventario y Logistics.
Customers, registros B2B y Master Data requieren identidad explícita
Los datos relacionados con Customers en VTEX pueden abarcar perfiles de comprador, direcciones, estructuras de organizaciones B2B, identificadores de CRM, registros de consentimiento, formularios personalizados y documentos de Master Data. Master Data es una base de datos nativa de documentos clave diseñada para almacenar, buscar, ampliar y personalizar datos, por lo que un registro personalizado puede representar un objeto operativo y no un simple campo adicional de Customer.
| Registro de origen | Posible responsable en VTEX | Pregunta de identidad |
|---|---|---|
| Perfil de comprador | Customer o datos de perfil | ¿Qué email, documento o clave externa representa a la persona? |
| Dirección | Registro de dirección relacionado con Customer | ¿Es dato reutilizable de cuenta, instantánea de Order o ambas cosas? |
| Empresa, organización, rol de comprador o centro de coste | Dominio B2B o modelo de datos personalizado | ¿Qué relaciones controlan acceso, aprobación, Catalog o contexto de precio? |
| Valor de loyalty, CRM o calificación | Master Data o CRM externo | ¿Qué sistema lo actualiza y qué clave lo vincula al Customer? |
| Envío de formulario personalizado | Documento de Master Data | ¿Es atributo de Customer, registro de flujo de trabajo o entidad independiente? |
| Consentimiento de marketing | Relación de Customer o sistema de marketing | Conserva finalidad, timestamp, origen y significado legal cuando sea necesario. |
Una disciplina clara de identidad evita que personas, empresas, direcciones y registros de flujo de trabajo sin relación se aplanen en un único perfil. El modelo de migración debe definir claves duraderas y cardinalidad de relaciones antes de seleccionar campos de destino.
Los Orders conservan historial comercial entre dominios operativos distintos
Un Order histórico de VTEX puede conectar identidad de Customer, seller, trade policy, líneas de SKU, precios, Promotions, impuestos, evidencia de pago, datos de envío, preparación de pedidos, estado y referencias externas. Estas relaciones explican la transacción pasada. No convierten configuración actual de Checkout, Payments, OMS, Logistics, inventario, carriers o warehouses en parte del registro de Order.
| Valor relacionado con Order | Significado histórico | Dominio activo separado |
|---|---|---|
| Línea de SKU y seller | Qué se compró y a quién | Catalog actual y offer del sellers pueden cambiar después. |
| Price y descuento | Instantánea comercial | Las reglas activas de Pricing y Promotions son independientes. |
| Referencia de transacción de pago | Evidencia de procesamiento de pago | La configuración activa de gateway y antifraude es independiente. |
| Método de envío, SLA y dirección | Promesa histórica de entrega | Logistics, docks, warehouses, carriers y puntos de recogida son independientes. |
| Estado y datos de preparación | Estado pasado de OMS | Nuevos Orders pueden seguir un flujo operativo diferente. |
| ID externo de Order | Linaje entre sistemas | Consérvalo cuando ERP, marketplace, atención al Customer o informes sigan utilizándolo. |
El límite relevante es el modelo de relaciones: qué valores históricos permanecen unidos al Order y qué dominios activos poseen el comportamiento futuro.
Catalogs de marketplace, sellers y offers necesitan responsabilidades separadas
VTEX puede actuar como marketplace, seller o parte de una red conectada de marketplaces. Por ello, los datos de marketplace abarcan más que Products y Orders. Pueden incluir identidades de sellers, seller SKUs, coincidencias de Catalog, offers, precios, inventario, comisiones, responsabilidad de preparación, correspondencias de Products y Categories y referencias externas de listados.
| Capa de marketplace | Significado | Relación que debe conservarse |
|---|---|---|
| Product y SKU canónicos | Identidad compartida de Catalog | Las offer del sellers deben referenciar el artículo previsto de Catalog. |
| Seller | Responsable comercial y operativo | Mantén la identidad del seller separada de Brand, proveedor o Manufacturer. |
| Offer | Contexto específico del seller para precio, inventario y preparación | No fusiones todas las offers dentro de la definición del Product. |
| Catalog correspondencia | Relación entre estructuras externas y VTEX de Product/Category | Conserva la clave de correspondencia cuando el conector continúe. |
| Origen de Order de marketplace | Historial de canal y seller | Consérvalo cuando atención, liquidación o informes dependan de él. |
| Referencia de comisión o liquidación | Contexto financiero de marketplace | Mantenla en el sistema responsable de la liquidación en lugar de forzarla en campos ordinarios de Order. |
Una migración hacia VTEX debe definir si cada registro de marketplace del origen se convierte en relación de Catalog de VTEX, offer del seller, registro de conector externo, atributo histórico de Order u objeto retenido en un sistema externo.
Storefront, CMS Pages, Blog Posts, Search y URLs deben separarse de la transferencia central de datos
La implementación de Storefront en VTEX puede incluir frontends headless, componentes CMS, comportamiento de Search, merchandising, redirecciones y continuidad SEO. Un Product puede migrar a VTEX y la experiencia de Storefront seguir incompleta. Una CMS Page puede aportar valor de contenido y no tener una relación uno a uno directa con la implementación de Storefront de destino. Blog Posts pueden ser importantes para tráfico orgánico, pero su tratamiento depende del alcance y de la configuración de plataforma.
Para planificar el modelo de datos, los registros de contenido y URLs deben evaluarse por función comercial y no solo por tipo de registro. Una URL de Category del origen puede ser una ruta de Catalog, página de destino de Search, página de merchandising o activo SEO. Una página de contenido puede ser una página de políticas, guía de compra, página de destino de campaña o diseño personalizado. Una regla de Search puede pertenecer a la plataforma, a una aplicación o a una implementación personalizada.
| Activo de origen | Pregunta de planificación para VTEX |
|---|---|
| URL de Product | ¿Debe redirigir, mantenerse equivalente o reconstruirse mediante el enrutamiento de Storefront? |
| Página de Category o collection | ¿Es organización de Catalog, navegación, experiencia de Search, contenido SEO o merchandising? |
| CMS Page | ¿Debe migrar como contenido, recrearse en Storefront, redirigirse o retirarse? |
| Blog Post | ¿Está dentro del alcance de migración, alcance SEO, estrategia de contenido o una decisión CMS independiente? |
| Lógica de Search/filtros | ¿La impulsan specifications, configuración de Search, comportamiento de aplicación o implementación personalizada? |
Esta separación evita tratar los registros de Catalog como completos mientras siguen sin resolver descubrimiento orientado al Customer, contenido y relaciones de URLs.
Los sistemas externos y los datos personalizados determinan el límite real de la migración
Las migraciones a VTEX suelen implicar ERP, CRM, PIM, OMS, WMS, middleware de marketplace, proveedores de pago, sistemas de loyalty, sistemas fiscales, Analytics, herramientas de atención y aplicaciones personalizadas de Storefront. Estos sistemas pueden ser responsables de identificadores de Product, precios, inventario, atributos de Customer, referencias de Order, datos de sellers, información de preparación o registros personalizados.
El alcance debe identificar la responsabilidad de cada sistema. Si un ERP sobrescribirá un valor de origen, ese valor importa solo si se necesita como estado inicial, referencia histórica o clave de reconciliación. Si un ID externo debe seguir vinculando Orders, Customers o Products entre sistemas, conservarlo puede ser crítico. Si un registro personalizado sostiene un flujo de trabajo que VTEX no representa de forma nativa como dato comercial estándar, puede ser necesario correspondencia o reestructuración específica.
| Tipo de dato externo o personalizado | Decisión de alcance |
|---|---|
| ID de Product u Order en ERP | Conservar si se requiere para reconciliación o sincronización. |
| Conjunto de atributos de PIM | Mapear solo los valores necesarios para VTEX Catalog, specifications o Search. |
| Identificador de Customer en CRM | Conservar si los flujos de trabajo de atención o marketing dependen de él. |
| Referencia WMS o de preparación | Decidir si pertenece al historial, configuración de integración o tratamiento personalizado. |
| Datos de aplicación o middleware | Revisar comportamiento de migración compatible antes de asumir que puede transferirse. |
La correspondencia o el filtrado acotado puede ayudar cuando el requisito implica filtrado, correspondencia o configuración compatibles. Debe considerarse correspondencia o reestructuración específica cuando el requisito implica datos no admitidos, registros personalizados, transformación a medida, tratamiento de una plataforma de origen personalizada o ajuste de lógica de migración fuera del comportamiento compatible.
Los límites de responsabilidad definen el alcance de migración de VTEX
El alcance de VTEX está determinado por responsabilidades y relaciones, no por volumen de registros. Un catálogo pequeño puede ser estructuralmente complejo si depende de herencia de specifications, assembly opciones, varias trade policies, sellers, documentos de Master Data o identificadores externos. Un catálogo grande puede ser comparativamente sencillo cuando Products, SKUs, Categories, Brands y specifications siguen un modelo consistente.
| Patrón del origen | Pregunta central | Consecuencia de alcance |
|---|---|---|
| Product con varias variaciones comprables | ¿Qué objeto del origen se convierte en el SKU de VTEX? | Conserva Product padre, identidad de SKU, specifications, imágenes y referencias de inventario. |
| Surtido regional o B2B | ¿Qué trade policy, precio y relación de acceso se aplican? | Mantén contexto comercial separado de identidad de Product. |
| Tablas personalizadas de Customer o flujo de trabajo | ¿El registro es perfil, documento Master Data, entidad B2B u objeto de sistema externo? | Modela la entidad y su relación duradera en lugar de añadir campos arbitrarios de Customer. |
| Catalog de marketplace | ¿VTEX es marketplace, seller o ambos? | Separa registros canónicos de Catalog de offer del sellers y claves de correspondencia. |
| Contenido headless o de Storefront personalizada | ¿Qué CMS, aplicación o repositorio posee el contenido? | No trates la implementación de Storefront como datos ordinarios de Catalog. |
| Integración ERP/PIM/WMS/OMS | ¿Qué sistema es autoridad para cada valor? | Conserva IDs entre sistemas y reglas de responsabilidad sin duplicar modelos externos. |
Este límite mantiene coherente el modelo de VTEX entre dominios de Catalog, comercial, Customers, marketplace, contenido y operación.
Conclusión
VTEX distribuye el significado comercial entre dominios relacionados. Categories, Brands, Products, SKUs y specifications forman Catalog; Pricing, Promotions, trade policies, inventario, Logistics y offer del sellers añaden contexto comercial; los registros de Customers y B2B pueden extenderse hacia Master Data; Orders conserva relaciones históricas entre Checkout, Payments, OMS y preparación de pedidos; el contenido de Storefront y los sistemas externos mantienen su propia responsabilidad.
El modelo de migración debe conservar claves y relaciones en lugar de aplanar todos los valores en Products, Customers u Orders. La responsabilidad clara entre dominios de VTEX es lo que permite que un Product siga siendo localizable, un SKU siga vendible, un Order siga comprensible, una offer del seller siga atribuible y una integración externa siga referenciando el registro correcto.
Preguntas frecuentes
¿Por qué son tan importantes los SKUs en una migración a VTEX?
Los SKUs suelen controlar versiones vendibles, precio, inventario, disponibilidad, Logistics y opciones de Storefront. Si las opciones de Product del origen no se traducen a estructuras utilizables de SKU y specification en VTEX, los Products pueden migrar y aun así incumplir expectativas comerciales u operativas.
¿Todos los atributos del origen se convierten en specifications de VTEX?
No. Los atributos deben revisarse por finalidad. Algunos pertenecen como specifications, otros definen SKUs, otros corresponden a contenido o integraciones y algunos deberían excluirse porque ya no sostienen la operación de destino.
¿Pueden las Promotions y reglas de precio del origen migrarse como campos de Product?
Normalmente no. Promotions, Coupons, tablas de precios, condiciones de canal y lógica externa de Pricing deben revisarse por separado de los precios base de Products. Algunos valores pueden migrarse como referencias, mientras el comportamiento comercial activo puede requerir configuración o integración en VTEX.
¿Los Orders históricos equivalen a la configuración de OMS de VTEX?
No. Los Orders históricos conservan contexto de compra pasado cuando está admitido. El procesamiento activo pertenece a Checkout, Payments, OMS, Logistics, inventario y configuración de sellers actuales.
¿Cuándo necesitan los datos de VTEX un modelo de entidad separado?
Cuando un registro de origen no puede convertirse en registro de Catalog, Customer, Master Data, Order, CMS, seller o sistema externo sin perder identidad o relaciones. Define primero el responsable de la entidad, su clave y sus vínculos antes de asignar campos individuales.
¿Cómo afectan las trade policies y las relaciones de SKU a una migración hacia VTEX?
El Product aporta significado descriptivo compartido, mientras los SKUs representan variaciones vendibles y las trade policies pueden cambiar surtido, precio, Logistics o contexto comercial. La correspondencia debe conservar estas relaciones para que un registro no se considere completo solo porque existe la carcasa del Product.