Integração Bling + Google Shopping: Como Usar Dados de Custo Para Campanhas Mais Lucrativas

Você sabe o custo de cada produto que vende. Esse dado está no Bling, atualizado por remessa, por fornecedor, por variação de câmbio quando aplicável. O problema é que esse dado fica no Bling — e nunca chega ao Google Shopping.

O Google Shopping vê apenas o preço de venda, a disponibilidade, o título, a imagem. Não sabe quanto custa o produto para a loja. Não sabe se a margem é 8% ou 68%. Quando o algoritmo do Shopping aloca budget, ele faz isso com metade das informações que uma decisão de negócio minimamente racional exigiria.

Esse isolamento entre ERP, plataforma de e-commerce e ferramenta de anúncio é o problema central de otimização de feed. Não é um problema do Google, nem da Nuvemshop, nem do Bling — é estrutural. Cada sistema foi projetado para fazer bem a sua parte, e a integração entre eles fica por conta da operação.

Os Três Silos e o Que Vive em Cada Um

Bling armazena:

  • Custo de aquisição ou produção por SKU
  • Histórico de remessas e variação de custo por fornecedor
  • Custo médio ponderado quando há múltiplas remessas com preços diferentes
  • NF-e de entrada, com impostos pagos na compra (para quem controla custo real com tributos)

Nuvemshop armazena:

  • Catálogo de produtos com preço de venda, estoque, variações
  • Pedidos com linha de produto, receita, dados do comprador
  • Feed de produtos exportado para o Google Merchant Center (sem custo)

Google Ads / Merchant Center opera com:

  • Feed de produtos vindo da Nuvemshop (sem dados de custo)
  • conversion_value vindo do pixel ou de API (por padrão, receita bruta do pedido)
  • Custom labels no feed (por padrão, vazios)
  • Algoritmo de lance que usa esses dados para distribuir budget

O custo que determina a margem e, portanto, o quanto faz sentido investir em cada produto, existe apenas no primeiro silo. Nunca chega ao terceiro.

Como Isso Afeta a Alocação de Budget na Prática

Uma loja de artigos de papelaria vende dois produtos no Google Shopping:

Caderno artesanal próprio: preço de venda R$ 85, custo de produção R$ 18 (margem bruta 79%).

Caderno de revenda importado: preço de venda R$ 79, custo de aquisição R$ 61 (margem bruta 23%).

Ambos aparecem no Shopping. O caderno importado tem ticket ligeiramente menor, mas historicamente converte bem — o preço competitivo atrai cliques. O algoritmo do Shopping, sem saber nada sobre custo, começa a aumentar lances para o importado porque ele converte.

Resultado: o produto com margem de 23% recebe budget crescente. O produto com margem de 79% fica com budget residual. A receita no Google Ads parece saudável. O lucro da operação, não.

Com os dados de custo do Bling integrados ao feed como custom labels:

  • Caderno artesanal: custom_label_0 = alta-margem → campanha com ROAS target 2.0x, budget generoso
  • Caderno importado: custom_label_0 = baixa-margem → campanha com ROAS target 6.5x, budget controlado

O algoritmo agora opera com a restrição correta para cada produto.

O Que Seria Necessário Para Fazer Isso Manualmente

O pipeline manual para colocar custo do Bling como custom labels no Google Shopping tem exatamente seis etapas:

  1. Exportar catálogo do Bling com custo por SKU (relatório de produtos ou API do Bling)
  2. Exportar catálogo da Nuvemshop para obter o ID do produto correspondente no Merchant Center
  3. Cruzar os dois exports por SKU ou referência de produto para garantir que os IDs batem
  4. Calcular margem bruta por produto: (Preço − Custo) / Preço
  5. Classificar cada produto na faixa de margem correspondente
  6. Criar ou atualizar o supplemental feed no Merchant Center com id e custom_label_0

Para 200 SKUs com custos estáveis e atualização mensal, esse processo leva 3-4 horas de trabalho de alguém com Excel razoável. O resultado dura até o primeiro fornecedor reajustar preço — o que invalida a classificação de qualquer produto afetado. Para uma operação com 500+ SKUs e múltiplos fornecedores, isso se torna inviável como processo recorrente.

O outro problema do processo manual é o delay. Um reajuste de custo que transforma um produto de media-margem para baixa-margem pode ficar com a classificação errada por semanas até a próxima atualização do feed. Em uma conta com R$ 15.000 de budget mensal em Shopping, duas semanas de classificação errada representa R$ 7.500 de spend potencialmente mal direcionado.

O Pipeline Automatizado: Bling → Nuvemshop → Google

O Feed PRO resolve os três silos com um pipeline contínuo:

Leitura de custo no Bling: o Feed PRO se conecta à API do Bling e lê o custo de produto cadastrado para cada SKU. Quando há múltiplas remessas com custos diferentes, usa o custo médio ponderado — o mesmo critério que o Bling aplica internamente no estoque.

Catálogo da Nuvemshop: os produtos da loja, com seus IDs do Merchant Center, são lidos da Nuvemshop para garantir que o mapeamento entre SKU e ID de produto esteja correto e atualizado.

Cálculo de margem e custom labels: com custo (Bling) e preço de venda (Nuvemshop), o Feed PRO calcula a margem bruta de cada produto e aplica o custom label correspondente à faixa que você configurou: alta, média, baixa, ou qualquer outra segmentação que faça sentido para a operação.

Feed atualizado no Merchant Center: o feed com os custom labels é enviado ao Google Merchant Center automaticamente. Quando qualquer custo muda no Bling — nova remessa, reajuste manual, atualização de fornecedor —, o custom label é recalculado e o feed é atualizado sem intervenção manual.

Quando o Feed PRO e o POAS Dashboard Trabalham Juntos

Para lojas que também usam o POAS Dashboard para enviar o lucro real como conversion_value ao Google Ads, o Feed PRO e o POAS formam um sistema coerente de otimização por margem:

  • Feed PRO atua no nível de campanha: quais produtos recebem quanto de budget, com qual ROAS target, baseado na faixa de margem do produto.
  • POAS Dashboard atua no nível de conversão: qual valor de lucro o Google Ads recebe por pedido, substituindo receita bruta por lucro real no conversion_value.

Os dois se complementam sem sobreposição. O Feed PRO segmenta antes do clique (estrutura de campanha por margem). O POAS calibra depois do clique (valor de conversão por pedido). Juntos, o algoritmo do Google recebe a informação completa de rentabilidade — por produto, por pedido, em tempo real.

Ambos os apps leem custo do Bling como fonte primária, então o custo cadastrado no ERP alimenta tanto a segmentação de campanha quanto o conversion_value enviado ao Google. Uma única fonte de verdade para todas as decisões de bid.

Qual Operação Se Beneficia Mais Dessa Integração

A integração Bling → custom labels → Google Shopping gera retorno mensurável em operações com:

  • Custo de produto cadastrado por SKU no Bling (necessário para o cálculo)
  • Pelo menos duas categorias de produto com diferença de margem superior a 20pp
  • Budget mensal em Google Shopping acima de R$ 5.000
  • Mix de produtos próprios e revenda no mesmo catálogo (a diferença de margem entre os dois é frequentemente grande o suficiente para justificar campanhas separadas)

Para lojas mono-categoria com CMV estável — por exemplo, uma loja de suplementos que vende exclusivamente a marca própria —, a segmentação por custom labels de margem agrega menos porque os produtos têm margem similar. Outros critérios de custom labels (velocidade de estoque, sazonalidade, linha de produto) podem ser mais relevantes nesse caso.

Para lojas com mix amplo e custos variáveis — papelaria, presentes, pet, beleza com mix de marcas próprias e revendas —, a integração com Bling é o habilitador de qualquer estratégia de bid por margem.

Próximo Passo

O Feed PRO conecta Bling, Nuvemshop e Google Shopping num pipeline contínuo: lê custo do ERP, calcula margem, preenche custom labels, atualiza o feed automaticamente. Sem planilha, sem processo manual recorrente. Disponível em feed.nexopath.com. Free trial de 14 dias.