Escolher entre arquitetura multiloja ou ambiente adicional
8 min de leitura
A plataforma VTEX permite a criação de arquiteturas diferentes para a sua loja, começando com a criação de uma conta principal, ou account name. É possível evoluir sua conta principal com outras opções de conta.
Este artigo apresenta as diferenças entre arquitetura multiloja e ambiente adicional para que você identifique qual a mais adequada para diferentes cenários.
Para arquiteturas de marketplace, também é possível Escolher entre Conta Franquia, Seller Portal ou Conta Padrão, ou utilizar a configuração de Multilevel Omnichannel Inventory .
Arquitetura multiloja (subconta / store)
- O Admin VTEX será o mesmo, mas com stores diferentes, e portanto com frentes de loja distintas na visão do comprador final.
- Esse recurso geralmente é utilizado quando a loja tem outras marcas mas existe uma similaridade de logística e métodos de pagamento ou quando a loja precisa de outro ambiente, por exemplo para diferentes públicos.
- Todos os módulos são compartilhados entre as stores, desde catálogo, promoções, sitemap, preços, configurações de pagamento e outros módulos, porém podem ser segmentados para condições de venda diferentes usando políticas comerciais e bindings.
Ambiente adicional (account)
- Dois ambientes VTEX com accounts, ou contas principais, totalmente separadas entre si, onde cada um deles terá todos os seus módulos configurados de forma independente, expandindo as possibilidades de configuração e segmentação de condições de venda e experiência de compra.
- Note que o ambiente adicional mencionado neste artigo não é o mesmo que conta franquia, que possui catálogo compartilhado com a conta principal mas não tem storefront próprio, por mais que a conta franquia também opere como um Admin VTEX à parte.
Comparação entre arquitetura multiloja e ambiente adicional
A tabela abaixo apresenta como as diferentes arquiteturas se relacionam com módulos e funcionalidades da plataforma VTEX.
| Aspecto | Arquitetura multiloja (store) | Arquitetura de ambientes adicionais |
|---|---|---|
| Arquitetura | Um único Admin VTEX (account), com múltiplas subcontas (stores). | Dois ambientes (accounts) separados do Admin VTEX. |
| Segmentação de condições de venda | É possível segmentar as aplicações de catálogo, preços, pagamentos, promoções, entre outros módulos, usando políticas comerciais e bindings. | Pelo fato de serem dois ambientes separados, com configurações independentes, o lojista tem muito mais controle sobre as possibilidades de segmentação de condições de venda em diferentes cenários. |
| Tipo de equipe | Recomendado quando uma mesma empresa e mesma equipe gerencia dois ou mais ecommerces com catálogos similares e itens em comum, mas que desejam oferecer storefronts diferentes para seus compradores acessarem experiências com marcas diferentes. | Recomendado quando equipes distintas da mesma empresa lidam com ecommerces diferentes. |
| Storefront | Storefronts são diferentes para cada store, mas gerenciado por um mesmo Admin VTEX.Caso a intenção seja somente mudar o idioma do site, mas a operação da loja for a mesma, é possível utilizar o multibinding e internacionalização do catálogo para configuração em um mesmo ambiente VTEX. Note que essa arquitetura é diferente de uma conta-franquia, pois essa conta não possui um site próprio. Os consumidores navegam diretamente no site da conta principal, que atua como marketplace nessa situação. | Cada account gerencia seus próprios storefronts em Admins VTEX separados, podendo utilizar todas as opções disponíveis de segmentação de storefronts. |
| Performance do Admin VTEX | A performance do Admin VTEX pode ser afetada quanto mais políticas comerciais forem associadas a uma mesma conta principal, ficando mais lento o uso das funcionalidades na plataforma, uma vez que a informação precisa ser atualizada em cada política comercial. Impactos na performance do Admin também são esperadas se o catálogo de produtos for muito extenso, com mais de 2 milhões de produtos, aumentando o tempo de indexação. | É possível criar múltiplas políticas comerciais, separadas para cada ambiente. A performance do Admin VTEX pode ser afetada quanto mais políticas comerciais forem associadas a uma mesma conta principal, ficando mais lento o uso de certas funcionalidades na plataforma. Porém, dado que são ambientes separados, a necessidade de cadastrar múltiplas políticas comerciais diminui. |
| Custos | Apesar da adição de uma store não ter custo adicional, é necessário contratar uma política comercial adicional, caso deseje diferenciar as regras de negócio. Saiba mais sobre políticas comerciais e segmentação das configurações disponíveis em Como funciona uma política comercial. | É necessário contratar um ambiente adicional com custo adicional previsto no contrato com a VTEX. Caso deseje, também é possível contratar uma política comercial adicional, caso deseje segmentar as configurações de cada ambiente para condições diferentes. Saiba mais sobre políticas comerciais e segmentação das configurações disponíveis em Como funciona uma política comercial. |
| Operação | Ao utilizar esse tipo de arquitetura, avalie a complexidade de gestão de catálogo, promoções, preços, estoque, pedidos e pagamentos pensando em diferentes stores, uma vez que todos os dados estarão no mesmo Admin. É possível configurar internacionalização do catálogo, para a venda em países diferentes. | Recomendamos essa arquitetura em casos de operações em dois países distintos, quando há necessidade de separação de idiomas diretamente no catálogo, para facilitar a operação de equipes que se comunicam em idiomas diferentes também. |
| Master Data | Cada subconta possui seu próprio Master Data, configurado de forma independente da conta principal. É possível realizar um apontamento para que os dados das entidades padrão (CL, AD e OD) da subconta sejam salvos no Master Data da conta principal, mediante solicitação ao Suporte. O apontamento não é uma migração de dados, pois funciona somente como um redirecionamento para que os dados das entidades padrão da subconta possam ser armazenados na conta principal. Essa solução não se aplica a entidades customizadas — elas permanecem visíveis apenas na conta em que foram criadas. O Suporte não atua em cenários de migração de dados. Para esses casos, recomendamos utilizar a Master Data API ou a interface do Master Data para extrair os dados da conta principal e importá-los para a subconta. | Cada conta terá seu Master Data independente. |
| Segurança da informação | Todos os módulos são compartilhados entre as stores, como catálogo, promoções, preços, configurações de pagamento, etc. É importante levar esse ponto em consideração ao lidar com diferentes times de uma mesma empresa tendo acesso ao Admin VTEX. Por exemplo, funcionários da Marca B poderão visualizar catálogo, preços e pedidos da Marca A - sendo Marca A e Marca B duas stores separadas. | A separação de ambientes faz com que os dados e configurações de catálogo, promoções, preços, configurações de pagamento, entre outros módulos, não sejam acessados por funcionários de times diferentes. Por exemplo, funcionários da Marca B não poderão visualizar catálogo, preços e pedidos da Marca A - sendo Marca A e Marca B ambientes VTEX separados. |
| License Manager | O mesmo License Manager gerencia todos os usuários. | Cada Admin terá o seu próprio License Manager, com gerenciamento de usuários separados. |
| Giftcard | As subaccounts terão acesso ao mesmo gerenciamento de giftcards, sendo possível usar os giftcards em storefronts diferentes. | Cada Admin terá o seu gerenciamento de Giftcard único, não sendo possível usar o giftcard gerado em um ambiente, no outro ambiente. |
| Estrutura de marketplace | Uma estrutura de marketplace não se aplica entre as stores diferentes, uma vez que que já compartilham catálogo, preços e estoque. | É possível que um ambiente seja seller no outro ambiente e vice e versa, tendo os produtos sendo vendidos nos dois sites baseados na relação seller-marketplace. Saiba mais em Configurar marketplace VTEX e Configurar seller para vender em marketplace VTEX. Também é possível criar contas-franquia, para que operem como sellers white label, já que possuem preços, estoques e logística diferentes. Saiba mais em Escolher entre Conta Franquia, Seller Portal ou Conta Padrão. Isso pode ser feito contratando ambiente adicional (caso tenham itens no catálogo em comum, mas não todos) ou conta-franquia (em casos de catálogos exatamente iguais). Saiba mais em Escolher entre Conta Franquia, Seller Portal ou Conta Padrão. |
| Sitemap | Haverá um sitemap único para a account principal, que será compartilhado entre as stores. | Cada account possui seu sitemap independente. |
| B2B: Catálogo | Não é possível mudar a unidade de medida registrada no catálogo para cada política comercial. Ex: lojas B2B vendem em atacado, enquanto B2Cs vendem por pequenas quantidades. O storefront B2B com catálogo centralizado terá a página de produto com uma unidade apenas. Dependendo do negócio, será preciso customizar o storefront para permitir um mínimo de unidades daquele SKU. É possível ampliar o catálogo com a criação de kits, mas seriam kits criados para a maioria dos produtos, gerando um catálogo praticamente duplicado. | Como os catálogos de cada ambiente são independentes, as restrições presentes no ambiente multiloja não se aplicam.É possível adaptar um dos catálogos somente para vendas B2B. |
| B2B: configurações do orderForm | Ao seguir por uma arquitetura multiloja, todas as stores compartilharão o mesmo orderForm configuration, no Checkout. Existem sistemas que podem ser integrados ao Admin da VTEX e dependem deste tipo de configuração para realizar a integração, como é o caso de Tax Providers por exemplo. Na prática, na integração de um Tax provider, ele será chamado tanto no B2C quanto no B2B em um ambiente multiloja, o que é danoso para a operação do cliente. | É possível criar uma configuração distinta do orderForm para cada ambiente, suprindo as necessidades de integrações externas no checkout de uma loja B2B. |