Integrar o Sales Layer com o BigCommerce é ligar um PIM, onde o catálogo é preparado e validado, à loja onde o produto se vende. Segundo a documentação do Sales Layer, o conector envia os dados do catálogo para o BigCommerce através da API da plataforma e funciona num único sentido: do PIM para a loja.
Para uma marca ou distribuidora, o ganho está em deixar de editar produtos em dois sítios. Mas o conector só ajuda se os dados chegarem limpos e o mapeamento estiver bem pensado. Na Avafa tratamos estes projetos dentro da nossa área de integração de PIM com ecommerce, e este guia resume o que decidir antes de ligar o canal.
Vai ver o que o conector faz, como preparar o catálogo, como mapear atributos, preços, imagens e variantes, e que erros evitar. No fim tem uma lista de verificação para validar a primeira sincronização.
O que faz o conector Sales Layer para BigCommerce?
Envia produtos, variantes, categorias e imagens do Sales Layer para o BigCommerce e atualiza a loja sempre que o catálogo muda no PIM. Segundo a página do conector, pode escolher o que sincronizar e importar só categorias e árvores de atributos selecionadas.
Também permite ligar portes e inventário, converter os SKU do PIM em SKU do BigCommerce e enviar dados para várias lojas, por exemplo uma por marca, região ou segmento de clientes. O Sales Layer calcula ainda um indicador de qualidade da ficha e regista a atividade de atualizações e edições.
Um requisito que convém confirmar logo: a documentação indica que as contas novas do BigCommerce têm de estar na versão Multi-Storefront, a única que hoje se pode criar. Quem tem uma conta mais antiga deve validar a situação com o Sales Layer antes de começar.
Quando compensa ligar o PIM ao BigCommerce?
Compensa quando o catálogo muda com frequência ou tem muitos atributos, e a edição manual na loja já gera erros ou atrasos. Não compensa, por agora, com poucas referências estáveis, onde uma folha de cálculo bem organizada resolve.
Os sinais de que está na hora de avançar são estes:
- as mesmas descrições, medidas e imagens são copiadas à mão para mais do que um canal;
- as variantes (tamanho, cor, acabamento) estão inconsistentes entre produtos;
- lançamentos e descontinuações demoram dias a chegar à loja;
- há várias lojas ou marcas a partilhar o mesmo catálogo base.
Se o problema for a origem do dado, a ligação ao ERP vem antes do PIM. Veja como fazemos esse passo na ligação do SAP S/4HANA ao BigCommerce.
Como preparar o catálogo antes de ligar o canal?
Comece pela base de dados: uma referência única por produto, atributos com nomes e unidades coerentes e categorias definidas antes do primeiro envio. O conector converte o que o PIM tem; não corrige o que está mal estruturado.
O passo a passo que seguimos:
- Definir a referência (SKU) única de cada produto e de cada variante.
- Normalizar atributos: um nome, uma unidade, um formato de valor.
- Fechar a árvore de categorias que vai existir no BigCommerce.
- Decidir que campos são do PIM e quais continuam a ser geridos na loja.
- Escolher um grupo pequeno de produtos para o primeiro teste.
A decisão do ponto 4 é a mais importante. O conector só trabalha num sentido, por isso o que for editado diretamente no BigCommerce pode ser sobrescrito na sincronização seguinte.
Como mapear atributos e campos no conector?
Os campos pré-configurados do conector costumam mapear-se de forma intuitiva; os restantes precisam de regras. A documentação do Sales Layer dá instruções concretas para vários campos de produto do BigCommerce.
| Campo | Regra a respeitar |
|---|---|
| — | — |
| Preço promocional | Enviar valor; para limpar, enviar 0 |
| Marca | Número é lido como ID; texto cria ou associa |
| Disponibilidade | available, disabled ou preorder |
| Tipo | Digital ou Physical |
| Método de controlo | product ou variant |
A regra do preço promocional apanha muita gente: um campo vazio é ignorado e o valor antigo fica na loja. Para o apagar tem de enviar 0. Nos preços por quantidade, cada regra precisa de quatro campos com o mesmo número: quantidade mínima, quantidade máxima, tipo (preço, fixo ou percentagem) e valor.
O aviso mais útil da documentação é este: não mapeie campos que não usa. Mesmo vazios, podem substituir dados já existentes no BigCommerce. Num exemplo da própria documentação, um campo personalizado de especificação técnica preenchido na loja é apagado porque o canal o enviava vazio.
Como tratar imagens e URL?
As imagens seguem a ordem configurada no conector: a imagem principal vem primeiro e as adicionais depois, pela ordem dos campos. Esta ordenação aplica-se à versão 1.1 ou posterior do conector, segundo a documentação.
Para as descrições das imagens, use um campo de tabela em que a primeira coluna é o nome da imagem e a segunda a descrição. Para remover uma descrição, envie o nome da imagem com a segunda coluna vazia. Se enviar duas descrições diferentes para a mesma imagem, só conta a primeira, e imagens que não estejam na tabela ficam sem descrição.
No URL, defina o formato no separador de parâmetros do conector para coincidir com a estrutura configurada nas definições da loja, ou mapeie o campo URL nas tabelas de categoria e produto. O mapeamento por tabela tem prioridade; se o campo estiver vazio, volta à estrutura inicial. Este ponto toca diretamente no SEO, porque um URL que muda sem controlo gera redirecionamentos e quebras de ligações.
Como funcionam as variantes no BigCommerce?
Os campos do separador de variantes definem as opções do produto no BigCommerce, e todas as variantes do mesmo produto têm de usar os mesmos atributos, com valores únicos. Só os atributos mapeados são exportados, e um atributo só é criado quando uma variante tem valor para ele.
O tipo de opção depende do campo mapeado:
- lista pendente: campo de texto, por exemplo o tamanho;
- amostra de cor: campo de cor com até três cores, no formato nome#código1#código2#código3, com códigos hexadecimais de 6 caracteres;
- lista de retângulos: acrescentar type_rectangle ao nome do atributo da variante.
Cuidado com a cor. Sem códigos hexadecimais, o atributo passa a lista pendente. E uma variante a que falte o código não é criada; se já existir na loja, fica a branco. Para escolher a variante por defeito, comece o conteúdo do campo por #default.
Há ainda uma armadilha na alteração de atributos: se mudar os atributos no Sales Layer, os valores antigos de opção permanecem no BigCommerce, embora as variantes sejam substituídas. E renomear um valor cria uma opção nova, sem ligação à anterior.
Que campos personalizados são suportados?
Os campos personalizados funcionam em produtos e variantes, mas não em categorias. Adicione-os como campos adicionais nos separadores de produtos e variantes. Se o campo não existir no BigCommerce, é criado; se existir, é atualizado; se for apagado no Sales Layer, é apagado na loja.
Esta lógica de criar, atualizar e apagar é prática, mas obriga a disciplina. Apagar um campo no PIM por engano apaga-o na loja na sincronização seguinte.
Lista de verificação para a primeira sincronização
Antes de ligar o canal à loja de produção, confirme:
- A conta do BigCommerce é Multi-Storefront.
- Os campos não usados estão desativados ou sem mapear.
- O preço promocional e os preços por quantidade têm regras testadas.
- Todas as variantes do mesmo produto usam os mesmos atributos.
- As cores têm códigos hexadecimais completos.
- O formato do URL coincide com o da loja.
- O teste foi feito com um grupo pequeno de produtos.
- Existe cópia de segurança do catálogo atual.
A cópia de segurança e o teste em ambiente separado são boas práticas nossas; a documentação do Sales Layer para outras plataformas recomenda precisamente começar com uma amostra pequena de dados e testar antes de ligar à produção.
Como trabalhamos na Avafa
Começamos por auditar o catálogo e o mapeamento: quais os atributos, de onde vêm e para onde vão. Depois configuramos o canal num grupo reduzido de produtos, validamos preços, variantes, imagens e URL, e só então alargamos. O trabalho encaixa na nossa integração de PIM com ecommerce e, do lado da loja, na agência de SEO para BigCommerce.
Se o seu PIM não for o Sales Layer, a lógica é a mesma. Veja a ligação do Plytix ao BigCommerce, do Akeneo ao BigCommerce ou do Brandfolder ao BigCommerce.
Perguntas frequentes
O Sales Layer sincroniza nos dois sentidos com o BigCommerce?
Não. Segundo a documentação, as sincronizações correm num único sentido, do Sales Layer para o BigCommerce. Por isso o catálogo deve ser editado no PIM.
Posso enviar dados para mais do que uma loja?
Sim. O conector suporta o envio para várias lojas, que podem servir marcas, regiões ou segmentos de clientes diferentes. A conta tem de ser Multi-Storefront.
Como limpo um preço promocional?
Envie o valor 0. Um campo vazio é ignorado e o preço antigo mantém-se na loja.
O que acontece se mapear um campo que não uso?
Pode apagar dados que já existem no BigCommerce. Deixe esses campos sem mapear ou desativados.
Os campos personalizados funcionam nas categorias?
Não. Funcionam em produtos e variantes, mas não em categorias, nem no BigCommerce nem neste conector.
Porque é que uma variante de cor não foi criada?
Provavelmente falta um código hexadecimal na amostra de cor. Uma variante sem esse código não é criada, e uma já existente fica a branco.
Quanto tempo demora o projeto?
Depende da qualidade dos dados, do número de variantes e das regras de preço. Só se estima depois de ver o catálogo e o mapeamento; por isso evitamos prazos genéricos.