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_valuevindo 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. É exatamente assim que um feed de Google Shopping queima dinheiro sem que nada no painel indique problema.
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. Como montar essas faixas e os ROAS targets correspondentes está em custom labels no Google Shopping: como licitar mais nos produtos que dão mais lucro.
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:
- Exportar catálogo do Bling com custo por SKU (relatório de produtos ou API do Bling)
- Exportar catálogo da Nuvemshop para obter o ID do produto correspondente no Merchant Center
- Cruzar os dois exports por SKU ou referência de produto para garantir que os IDs batem
- Calcular margem bruta por produto:
(Preço − Custo) / Preço - Classificar cada produto na faixa de margem correspondente
- Criar ou atualizar o supplemental feed no Merchant Center com
idecustom_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.
Feed PRO e o Valor de Conversão por Pedido
Para lojas que também enviam o lucro real como conversion_value ao Google Ads, o Feed PRO complementa essa otimização por margem em dois níveis:
- Nível de campanha: quais produtos recebem quanto de budget, com qual ROAS target, baseado na faixa de margem do produto.
- 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 valor de conversão calibra depois do clique (valor por pedido). Juntos, o algoritmo do Google recebe a informação completa de rentabilidade — por produto, por pedido, em tempo real.
O Feed PRO lê custo do Bling como fonte primária, então o custo cadastrado no ERP alimenta diretamente a segmentação de campanha — a mesma fonte de dados que deve alimentar o conversion_value enviado ao Google, para uma única fonte de verdade em 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. O racional completo dessa estratégia está em otimizar o feed do Google Shopping por margem de lucro.
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.