Elegir entre arquitectura multitienda o entorno adicional
8 min de lectura
La plataforma VTEX permite crear diferentes arquitecturas para tu tienda, empezando por la creación de una cuenta principal, o account name. Puedes evolucionar tu cuenta principal con otras opciones de cuenta.
Este artículo presenta las diferencias entre arquitectura multitienda y entorno adicional para que identifiques cuál es el más adecuado para los distintos escenarios.
Para arquitecturas de marketplace, también se puede Elegir entre cuenta franquicia, Seller Portal o cuenta estándar, o utilizar la configuración Multilevel Omnichannel Inventory .
Arquitectura multitienda (store)
- El Admin VTEX será el mismo, pero con diferentes tiendas y, por tanto, distintos storefronts que se muestran al comprador final.
- Este recurso se utiliza generalmente cuando la tienda tiene otras marcas pero existe una similitud en la logística y medios de pago, o cuando la tienda necesita otro entorno, por ejemplo, para públicos diferentes.
- Todas las tiendas tienen acceso a los mismos componentes, como catálogo, promociones, mapa del sitio, precios, configuración de pagos, etc.; sin embargo, estos componentes pueden segmentarse para condiciones de venta diferentes utilizando políticas comerciales y bindings.
Entorno adicional (account)
- Dos entornos VTEX con accounts, o cuentas principales, totalmente separados entre sí, donde cada una tendrá configurados todos sus componentes de forma independiente, ampliando las posibilidades de configuración y segmentación de las condiciones de venta y experiencia de compra.
- Importante: el entorno adicional mencionado en este artículo no es lo mismo que una cuenta franquicia, que tiene un catálogo compartido con la cuenta principal, pero sin storefront propio, aunque la cuenta franquicia también funcione como un Admin VTEX independiente.
Comparación entre arquitectura multitienda y entorno adicional
La tabla siguiente muestra cómo se relacionan las distintas arquitecturas con los componentes y funcionalidades de la plataforma VTEX.
| Tema | Arquitectura multitienda (store) | Arquitectura de entornos adicionales |
|---|---|---|
| Arquitectura | Un solo Admin VTEX (account) con múltiples subcuentas (stores). | Dos entornos (accounts) del Admin VTEX separados. |
| Segmentación de las condiciones de venta | Posibilidad de segmentar aplicaciones del catálogo, precios, pagos, promociones y otros componentes utilizando políticas comerciales y bindings. | Al tratarse de dos entornos separados y con configuraciones independientes, el administrador de la tienda tiene mucho más control sobre las posibilidades de segmentar las condiciones de venta en diferentes escenarios. |
| Tipo de equipo | Recomendado cuando una misma empresa y un mismo equipo gestionan dos o más tiendas online con catálogos similares e ítems en común, pero que quieren ofrecer storefronts distintos para que sus compradores accedan a experiencias con marcas diferentes. | Recomendado cuando equipos diferentes de una misma empresa se ocupan de tiendas online distintas. |
| Storefront | Los storefronts son diferentes para cada tienda, pero se gestionan desde un mismo Admin VTEX.Si la intención es solamente cambiar el idioma del sitio web, pero el funcionamiento de la tienda es el mismo, se puede utilizar multibinding y la internacionalización de catálogo para la configuración en un mismo entorno VTEX. Esta arquitectura es diferente de una cuenta franquicia, ya que esta cuenta no tiene un sitio web propio. Los consumidores navegan directamente en el sitio web de la cuenta principal, que en este contexto actúa como un marketplace. | Cada account gestiona sus propios storefronts en Admins VTEX separados y pueden utilizar todas las opciones disponibles de segmentación de storefronts. |
| Desempeño del Admin VTEX | El desempeño del Admin VTEX puede verse afectado cuantas más políticas comerciales haya asociadas a una misma cuenta principal, ralentizando el uso de las funcionalidades de la plataforma, ya que es necesario actualizar la información en cada política comercial. También se prevén impactos en el desempeño del Admin si el catálogo de productos es muy extenso, con más de 2 millones de ítems, lo que aumenta el tiempo de indexación. | Es posible crear varias políticas comerciales, independientes para cada entorno. El desempeño del Admin VTEX puede verse afectado cuantas más políticas comerciales haya asociadas a una misma cuenta principal, ralentizando el uso de determinadas funcionalidades de la plataforma. Sin embargo, al tratarse de entornos separados, se reduce la necesidad de registrar varias políticas comerciales. |
| Costos | Aunque agregar una store no tiene costo adicional, es necesario contratar una política comercial adicional si se quiere diferenciar las reglas de negocio. Más información sobre las políticas comerciales y la segmentación de los ajustes disponibles en Cómo funciona una política comercial. | Es necesario contratar un entorno adicional, con costo adicional previsto en el contrato con VTEX. Si lo deseas, también puedes contratar una política comercial adicional, si quieres segmentar la configuración de cada entorno para condiciones diferentes. Más información sobre las políticas comerciales y la segmentación de las configuraciones disponibles en Cómo funciona una política comercial. |
| Operación | Cuando utilices este tipo de arquitectura, evalúa la complejidad de gestionar el catálogo, las promociones, los precios, el stock, los pedidos y los pagos pensando en diferentes stores, ya que todos los datos estarán en el mismo Admin. Es posible configurar la internacionalización del catálogo para vender en diferentes países. | Recomendamos esta arquitectura en los casos donde haya operaciones en dos países diferentes, cuando es necesaria la separación lingüística directamente en el catálogo, para facilitar el funcionamiento de equipos que se comunican también en idiomas distintos. |
| Master Data | Cada subcuenta tiene su propio Master Data configurado independientemente de la cuenta principal. Para guardar los datos de las entidades predeterminadas (CL, AD y OD) de la subcuenta en Master Data de la cuenta principal, puedes crear un apuntamiento abriendo un ticket con Soporte. El apuntamiento no es una migración de datos, ya que funciona como una redirección que permite almacenar los datos de las entidades predeterminadas de la subcuenta en la cuenta principal. Esta solución no se aplica a entidades personalizadas, que solo son visibles en la cuenta en que fueron creadas. Soporte no atiende migraciones de datos. Para migraciones recomendamos utilizar la API de Master Data o la interfaz de Master Data para extraer los datos de la cuenta principal e importarlos en la subcuenta. | Cada cuenta tendrá su propio Master Data. |
| Seguridad de la información | Todos los componentes se comparten entre las stores, como catálogo, promociones, precios y configuración de pagos. Es importante tener en cuenta este punto cuando diferentes equipos de una misma empresa tienen acceso al Admin VTEX. Por ejemplo, los empleados de la marca B podrán visualizar el catálogo, los precios y los pedidos de la marca A, aunque la marca A y la marca B sean dos stores distintas. | La separación de entornos significa que los empleados de equipos diferentes no tienen acceso a los datos y configuración del catálogo, promociones, precios y configuración de pagos, entre otros componentes. Por ejemplo, los empleados de la marca B no podrán visualizar el catálogo, los precios y los pedidos de la marca A, ya que la marca A y la marca B son entornos VTEX separados. |
| License Manager | El mismo License Manager gestiona todos los usuarios. | Cada Admin tendrá su propio Licence Manager, con gestión de usuarios independiente. |
| Tarjeta de regalo | Las subaccounts tendrán acceso a la misma gestión de tarjetas de regalo y se podrán utilizar en storefronts diferentes. | Cada Admin tendrá su gestión única de tarjetas de regalo, y las que se generan en un entorno no podrán utilizarse en el otro. |
| Estructura de marketplace | La estructura de marketplace no se aplica entre stores diferentes, puesto que ya comparten catálogo, precios y stock. | Es posible que un entorno sea seller en el otro y viceversa, poniendo todos sus productos en venta en ambos sitios web, con base en la relación seller-marketplace. Más información en Configurar marketplaces VTEX y Cómo configurar el seller para vender en un marketplace VTEX. También es posible crear cuentas franquicia, para que operen como sellers white label, ya que tienen precios, stock y logística diferentes. Más información en Elegir entre cuenta estándar, cuenta franquicia o Seller Portal. Esto puede hacerse contratando un entorno adicional (en caso de que tengan ítems del catálogo en común, pero no todos) o una cuenta franquicia (en caso de catálogos exactamente iguales). Más información en Elegir entre cuenta estándar, cuenta franquicia o Seller Portal. |
| Sitemap | Habrá un sitemap único para la account principal, que se compartirá entre las stores. | Cada account posee su sitemap independiente. |
| B2B: Catálogo | No es posible cambiar la unidad de medida registrada en el catálogo para cada política comercial. Por ejemplo, las tiendas B2B venden al por mayor, mientras que las B2C lo hacen al por menor. El storefront B2B con catálogo centralizado tendrá la página de producto con una sola unidad. Dependiendo del negocio, será necesario personalizar el storefront para permitir un mínimo de unidades de ese SKU. Es posible ampliar el catálogo creando kits, pero serían kits creados para la mayoría de los productos, generando un catálogo prácticamente duplicado. | Como los catálogos de cada entorno son independientes, no se aplican las restricciones presentes en el entorno multitienda.Es posible adaptar uno de los catálogos únicamente para ventas B2B. |
| B2B: configuración del orderForm | Al aplicarse una arquitectura multitienda, todas las stores compartirán la misma configuración del orderForm, en el checkout. Existen sistemas que pueden integrarse con el Admin VTEX y dependen de este tipo de configuración para realizar la integración, como es el caso de los proveedores de impuestos, por ejemplo. En la práctica, en la integración de un proveedor de impuestos, el orderform será llamado tanto en B2C como en B2B en un entorno multitienda, lo que perjudica a la operación del cliente. | Es posible crear una configuración independiente del orderForm para cada entorno, satisfaciendo las necesidades de las integraciones externas en el checkout de una tienda B2B. |