POAS na Nuvemshop: Como Parar de Otimizar por ROAS e Começar a Otimizar por Lucro Real

O Problema: ROAS Não Mede Lucro

ROAS (Return on Ad Spend) é uma razão entre receita bruta e investimento em mídia. Essa métrica ignora três variáveis que determinam se uma operação é lucrativa ou deficitária:

• CMV (Custo de Mercadoria Vendida) — margem bruta real do produto, geralmente vindo do ERP (Bling, Tiny, Omie).
• Impostos — ICMS, PIS/COFINS, Simples Nacional. Variam por UF e regime tributário.
• Frete — subsidiado ou não. Muitas operações absorvem frete grátis como custo de aquisição sem contabilizar no CAC.

Um cenário real:

ROAS 4.0x. Lucro zero. Esse é o cenário padrão de quem escala campanhas olhando exclusivamente para o painel do Google Ads ou Meta.

O Que é POAS e Por Que Ele Resolve

POAS (Profit on Ad Spend) substitui a receita bruta pelo lucro líquido como numerador da equação:

POAS = (Receita - CMV - Impostos - Frete) / Ad Spend

No cenário acima, o POAS seria 0 / 50 = 0.0. O algoritmo do Google Ads, ao receber esse valor como conversion_value, entenderia que aquele perfil de conversão não gera retorno — e redistribuiria budget para segmentos com margem real positiva.

O problema é operacional: como alimentar o algoritmo com dados de lucro em tempo real, por pedido, sem intervenção manual?

Arquitetura da Solução: Nexopath POAS na Nuvemshop

O pipeline tem três camadas:

Captura de Atribuição (Storefront)

O app roda nativamente via NubeSDK — o runtime de extensões da Nuvemshop. Não é um script externo injetado via GTM. Isso significa:

• Execução no contexto nativo da loja, sem conflito com checkout ou scripts de terceiros.
• Cookies 1st-party setados diretamente no domínio principal da loja (loja.com.br, não app.terceiro.com). Isso elimina perda de atribuição por bloqueio de cookies de terceiros (ITP/Safari, Firefox ETP).
• Captura de gclid e fbclid na primeira visita, persistidos em cookie 1st-party com TTL configurável.

A captura acontece automaticamente no carregamento da página. Não exige tag no GTM, não exige pixel adicional, não exige consentimento extra além do que a loja já gerencia.

Cruzamento com Dados de Custo (Backend)

Quando um pedido é criado na Nuvemshop, o webhook order/created dispara com o payload do pedido. O backend do Nexopath:

1. Extrai os IDs de clique (gclid, fbclid) do cookie 1st-party associado àquela sessão.
2. Consulta o CMV de cada SKU do pedido via integração com o ERP configurado (Bling, Tiny, ou API customizada).
3. Calcula impostos com base no regime tributário da loja (configurado uma vez no painel).
4. Subtrai frete real (não o frete cobrado do cliente — o custo logístico efetivo).

O resultado é um objeto de conversão enriquecido:

{
  "order_id": "NSH-48291",
  "gclid": "EAIaIQobChMI8d2x...",
  "fbclid": "fb.1.1714000000000.ABcDeFgHiJ",
  "gross_revenue": 200.0,
  "cogs": 110.0,
  "tax": 18.0,
  "shipping_cost": 22.0,
  "net_profit": 0.0,
  "poas_value": 0.0,
  "currency": "BRL",
  "timestamp": "2026-05-07T14:32:00-03:00"
}

Envio para Plataformas de Ads (Server-Side)

O poas_value calculado é enviado como conversion_value diretamente para:

• Google Ads API — via Enhanced Conversions (server-side), usando o gclid como chave de match.
• Meta Conversions API (CAPI) — usando o fbclid e dados hasheados (SHA-256) do comprador.

Esse envio é server-side. Não depende do navegador do usuário, não é afetado por ad blockers, e não sofre com limitações de cookies.

Por Que Cookies 1st-Party São Obrigatórios

A atribuição client-side padrão (via gtag.js ou pixel Meta) depende de cookies de terceiros ou de JavaScript executado no navegador. Três problemas operacionais:

1. ITP (Intelligent Tracking Prevention) — Safari limita cookies de JavaScript a 7 dias (ou 24h em alguns cenários com query parameters). Um ciclo de compra de 10 dias perde a atribuição.
2. Ad blockers — ~30% dos usuários brasileiros usam algum bloqueador. O gtag.js simplesmente não executa.
3. Subdomínios e redirects — lojas que usam domínios customizados com proxy reverso frequentemente perdem o gclid na transição.

Cookies 1st-party setados pelo NubeSDK no domínio raiz da loja (loja.com.br) não sofrem com ITP, não são bloqueados por ad blockers (são indistinguíveis de cookies funcionais), e persistem entre subdomínios.

Instalação e Configuração

O fluxo de setup tem três etapas, todas no painel do Nexopath:

Conexão com a Nuvemshop

Autenticação via OAuth2 padrão da Nuvemshop. O app solicita permissões de leitura de pedidos e produtos. Nenhum acesso ao checkout ou dados de pagamento — o app é PCI-compliant por design, pois nunca processa ou armazena dados de cartão.

Integração com ERP

Conecte o Bling, Tiny ou outra fonte de CMV. O Nexopath sincroniza a tabela de custos por SKU e mantém cache com invalidação por webhook (quando o preço de custo muda no ERP, o cache atualiza).

Conexão com Plataformas de Ads

Autentique Google Ads e/ou Meta Ads. O Nexopath configura automaticamente as ações de conversão no Google Ads com o label correto e habilita o envio server-side via CAPI para Meta.

Tempo médio de setup: ~5 minutos. Não exige GTM, não exige desenvolvedor, não exige alteração no tema da loja.

Leitura do Dashboard

Após a ativação, o dashboard exibe por campanha, ad group e ad:

• POAS — lucro real dividido por spend.
• Lucro bruto — receita menos CMV.
• Lucro líquido — após impostos e frete.
• CAC real — custo de aquisição considerando todos os custos, não apenas o spend.
• Margem por SKU — quais produtos geram margem e quais são deficitários mesmo com vendas altas.

A granularidade é por pedido. Cada conversão no Google Ads e Meta carrega o valor de lucro real, permitindo que o algoritmo otimize para margem, não para faturamento.

Limitações e Considerações

• Dependência do ERP: se o CMV não estiver atualizado no Bling/Tiny, o cálculo de POAS será impreciso. O Nexopath exibe alertas quando detecta SKUs sem custo cadastrado.
• Regime tributário: o cálculo de impostos é simplificado (alíquota fixa por regime). Operações com ICMS-ST ou regimes especiais devem validar os valores contra o ERP fiscal.
• Janela de atribuição: o cookie 1st-party tem TTL padrão de 30 dias. Ciclos de compra superiores a 30 dias exigem ajuste manual no painel.

Próximo Passo

O app está disponível na Nuvemshop App Store. A ativação é imediata e o free trial cobre os primeiros 14 dias com dados históricos retroativos a partir do primeiro pedido capturado.