Como Integrar Bling e Nuvemshop Para Saber o Custo Real de Cada Pedido

Toda loja que usa Bling como ERP tem o mesmo problema: o CMV está no Bling, os pedidos estão na Nuvemshop, e os gastos com mídia estão no Google Ads ou Meta. Três sistemas. Três bases de dados. Nenhuma integração nativa entre eles.

O resultado prático é imediato: você não sabe quanto lucrou por pedido. Sabe quanto faturou (Nuvemshop), quanto gastou em mídia (Google/Meta), e quanto os produtos custaram (Bling) — mas esses três números nunca são somados no mesmo lugar, em tempo real, atribuídos à campanha que originou a venda.

Esse gap faz com que a maioria das lojas gerencie tráfego pago com informação incompleta por padrão. Não por falta de vontade — por falta de pipeline.

Por Que o Custo de Produto Fica Preso no Bling

O Bling é um ERP: seu propósito é rastrear estoque, emitir NF-e, controlar contas a pagar e a receber. O preço de custo de cada produto fica no cadastro de produtos — atualizado quando chega nova remessa do fornecedor, quando há reajuste de tabela, quando a composição do produto muda.

Esse dado é preciso e atualizado. O problema é que ele foi projetado para a operação financeira e fiscal da loja, não para o media buyer que precisa saber se a campanha de Google Shopping está gerando lucro.

A Nuvemshop, por outro lado, conhece os pedidos: quais produtos foram vendidos, a qual preço, para qual cliente. Mas não tem o CMV — esse dado nunca foi importado, porque não há motivo operacional para a plataforma de e-commerce armazenar o custo de aquisição.

E o Google Ads conhece o spend por campanha e o valor de conversão que você enviou — que por padrão é a receita bruta do pedido, não o lucro.

O Fluxo Sem Integração: Reconciliação Mensal Em Planilha

A solução adotada pela maioria das operações é a planilha de reconciliação mensal:

1. Exportar relatório de pedidos da Nuvemshop (CSV com SKU, quantidade, valor)
2. Exportar tabela de custos do Bling (CSV com SKU e preço de custo)
3. VLOOKUP: cruzar pedidos com custos por código de produto
4. Calcular margem bruta por linha de pedido
5. Exportar relatório de campanhas do Google Ads / Meta
6. Tentar cruzar pedidos com campanhas (na prática, sem rastreamento de UTMs, isso falha)

Esse processo tem um problema estrutural: quando você termina, o mês já acabou. As campanhas que geraram prejuízo rodaram o período inteiro. O insight chega tarde demais para mudar qualquer coisa.

Uma loja com 600 pedidos/mês e ticket médio de R$ 260 que descobre no dia 30 que três ad sets estavam com POAS negativo perdeu 30 dias de oportunidade de correção — e o budget queimado não volta.

Como Funciona a Integração Automática Entre Bling, Nuvemshop e Ads

A integração que conecta os três sistemas opera em três camadas:

Camada 1 — Sincronização de CMV: o Bling é a fonte de verdade do preço de custo. A integração mantém uma tabela sincronizada de CMV por SKU, atualizada via webhook sempre que o preço de custo muda no ERP. Se o fornecedor reajustar o preço, o cálculo de margem dos pedidos seguintes já usa o valor novo — sem reconfiguração manual.

Camada 2 — Cálculo de Lucro Por Pedido: quando um pedido é criado na Nuvemshop, a integração consulta automaticamente o CMV de cada SKU, calcula impostos com base no regime tributário configurado, e aplica o custo logístico real (não o valor cobrado do cliente — o custo efetivo de envio). O resultado:

Pedido #31847
├── Receita: R$ 340,00
├── CMV (do Bling): R$ 119,00
├── Impostos (Simples Nacional 7%): R$ 23,80
├── Frete real: R$ 19,50
└── Lucro líquido: R$ 177,70

Camada 3 — Atribuição à Campanha: para que o lucro do pedido seja atribuído à campanha que originou a venda, o rastreamento precisa preservar o parâmetro de clique (gclid para Google, fbclid para Meta) desde o primeiro acesso até o checkout — via cookies first-party. Para os detalhes técnicos desse pipeline, veja Atribuição First-Party: Como Cruzar GCLID com o Webhook do ERP.

Com as três camadas funcionando, cada pedido carrega: qual campanha originou a venda + qual foi o lucro real. Esse valor é enviado como conversion_value para o Google Ads — e o algoritmo passa a otimizar para margem, não para receita.

Exemplo: Uma Loja Com Duas Categorias de CMV

Uma loja que vende R$ 60.000/mês — metade em eletrônicos (CMV 75%), metade em acessórios (CMV 32%) — com a mesma conta Google Ads ilustra o que acontece sem integração:

O Google Ads sem dados de CMV vê o ROAS de eletrônicos (4.2x) como saudável e potencialmente escalável. Com POAS, fica claro que cada real investido em eletrônicos gera R$ 1,15 de prejuízo.

A loja que tem essa integração funcionando redistribui o budget antes de terminar a semana. A loja sem integração descobre no relatório do mês — e quando vai corrigir, já perdeu R$ 8.300.

O Que Precisa Estar Configurado Para a Integração Funcionar

No Bling: todos os produtos ativos com preço de custo cadastrado. SKUs sem custo resultam em POAS indefinido para os pedidos que os incluem. Uma revisão rápida do cadastro antes de ativar a integração evita esse problema.

Na Nuvemshop: acesso aos webhooks de pedido (order/created e order/paid). Essa permissão é concedida via OAuth2 no momento da instalação do app.

Regime tributário: configurado uma vez no painel da integração — Simples Nacional, Lucro Presumido ou Lucro Real. Esse parâmetro define a alíquota aplicada a cada pedido.

Política de frete: custo logístico médio por pedido, ou por faixa de CEP se houver variação regional relevante.

Após essa configuração inicial, o pipeline opera autonomamente. Novos pedidos, novos SKUs, novas campanhas são capturados automaticamente via webhooks. Para o passo a passo completo do setup, veja POAS na Nuvemshop: Como Parar de Otimizar por ROAS e Começar a Otimizar por Lucro Real.

Por Que Não Basta Separar Campanhas Por Categoria

Uma alternativa comum é separar campanhas por categoria de produto — “eletrônicos” em uma campanha, “acessórios” em outra — e definir ROAS targets diferentes para cada uma. É melhor do que uma campanha única, mas tem limitações:

O ROAS target precisa ser recalibrado manualmente quando o CMV muda. Quando o fornecedor reajusta o preço, a meta desatualizada faz o algoritmo otimizar com o target errado. E dentro de uma mesma categoria, variações de CMV entre SKUs continuam invisíveis.

A integração com Bling resolve isso na raiz: o valor de lucro real enviado por pedido já reflete o CMV atual de cada SKU, sem recalibração manual. Para a rotina de decisão que isso habilita — pausar ad sets deficitários no mesmo dia, não no fechamento do mês — veja Otimização Orientada a Lucro: Como Integrar CMV do Bling à Tomada de Decisão no Google e Meta Ads.

Próximo Passo

O POAS Dashboard integra Bling, Nuvemshop e plataformas de ads automaticamente, calculando o lucro real por pedido e atribuindo à campanha de origem. O setup leva menos de 10 minutos. Disponível em poas.nexopath.com. Free trial de 14 dias.