Atribuição First-Party: Como Cruzar GCLID/FBCLID com o Webhook do ERP Sem Perda de Dados

Por Que o Pixel Frontend Está Fragmentando Seus Dados

O modelo padrão de rastreamento em e-commerce funciona assim: o usuário clica no anúncio, o gtag.js ou o pixel Meta lê o GCLID/FBCLID da URL, armazena em cookie, e dispara um evento de conversão quando o pedido é concluído. Simples em teoria. Fragmentado na prática.

Três forças sistêmicas estão degradando esse modelo:

Bloqueadores de anúncios — a taxa de uso de extensões como uBlock Origin, AdBlock Plus, e similares está entre 25-35% em usuários desktop no Brasil. Esses bloqueadores não apenas bloqueiam anúncios: eles bloqueiam os scripts de rastreamento que dependem dos mesmos servidores. O gtag.js não executa. O pixel Meta não dispara. A conversão acontece mas nunca é registrada.

ITP (Intelligent Tracking Prevention) do Safari — o Safari limita cookies criados via JavaScript (third-party scripts) a 7 dias. Em alguns cenários com query parameters, o limite cai para 24 horas. Ciclos de compra que duram mais de 7 dias — consultas, abandono de carrinho, retorno — perdem a atribuição no navegador mais usado em iOS.

Cookies de terceiros em extinção — o Chrome iniciou a deprecação gradual de third-party cookies. Scripts externos que tentam rastrear o usuário entre sites estão cada vez mais isolados. O FBCLID do Meta é especialmente afetado em cenários onde o usuário navega de domínios externos para a loja.

O resultado agregado: em operações típicas na Nuvemshop, 15-30% das conversões reais não aparecem nos painéis de ads por falhas de rastreamento client-side.

O Problema Específico do GCLID e do FBCLID

O gclid e o fbclid são parâmetros que as plataformas de ads adicionam à URL de destino no momento do clique. Eles carregam o identificador único do clique que originou aquela sessão.

https://loja.com.br/produto?gclid=EAIaIQobChMI8d2x...&utm_source=google

Para que a conversão seja atribuída corretamente ao clique que a originou, esse gclid precisa:

  1. Ser capturado no carregamento da página
  2. Persistir durante toda a sessão de navegação (mesmo em páginas sem o parâmetro na URL)
  3. Ser associado ao ID do pedido no momento da compra
  4. Ser transmitido ao Google Ads junto com os dados da conversão

Cada etapa é um ponto de falha potencial com rastreamento puramente client-side.

A Arquitetura de Rastreamento Bulletproof

A solução tem três camadas que trabalham em conjunto:

O parâmetro gclid (e fbclid) deve ser capturado via script que executa antes do GTM, antes de scripts externos, no contexto do próprio domínio da loja. Isso significa um cookie first-party em loja.com.br, não um cookie de terceiro em analytics.plataforma.com.

(function () {
  var params = new URLSearchParams(window.location.search);

  var ids = {
    gclid: params.get('gclid'),
    fbclid: params.get('fbclid'),
    utm_source: params.get('utm_source'),
    utm_campaign: params.get('utm_campaign'),
  };

  // Só sobrescreve se há novos parâmetros (clique novo)
  if (ids.gclid || ids.fbclid) {
    var cookieValue = JSON.stringify({
      ...ids,
      captured_at: Date.now(),
    });

    // Cookie first-party, TTL 30 dias, escopo de domínio raiz
    document.cookie =
      'nx_attribution=' + encodeURIComponent(cookieValue) +
      '; max-age=2592000; path=/; SameSite=Lax';
  }
})();

Diferença crítica para cookies third-party: este cookie é indistinguível de um cookie funcional da loja (sessão de usuário, carrinho). O ITP do Safari não o classifica como rastreamento de terceiro. Ad blockers não o bloqueiam porque o script executa no domínio da própria loja.

O TTL de 30 dias cobre a maioria dos ciclos de compra em e-commerce. Para ciclos mais longos (produtos de alto envolvimento, compras recorrentes programadas), o TTL é configurável.

Camada 2: Amarração ao ID do Pedido

Quando o pedido é criado, o checkout da Nuvemshop dispara um evento que o script do app captura antes da navegação para a página de confirmação. Nesse momento, o cookie nx_attribution ainda está acessível via document.cookie.

O fluxo:

  1. Usuário clica em “Finalizar compra”
  2. O script lê nx_attribution do cookie
  3. Adiciona os IDs de atribuição ao payload do pedido (via campo customizado ou parâmetro de sessão)
  4. A Nuvemshop cria o pedido com os dados de atribuição embutidos
// Pseudocódigo do fluxo no NubeSDK
nube.checkout.onOrderCreate(function (order) {
  var attributionCookie = document.cookie
    .split('; ')
    .find(row => row.startsWith('nx_attribution='));

  if (!attributionCookie) return;

  var attribution = JSON.parse(
    decodeURIComponent(attributionCookie.split('=')[1])
  );

  order.metadata.nx_gclid = attribution.gclid;
  order.metadata.nx_fbclid = attribution.fbclid;
  order.metadata.nx_source = attribution.utm_source;
  order.metadata.nx_campaign = attribution.utm_campaign;
});

O resultado: cada pedido na Nuvemshop carrega, em seus metadados, o identificador do clique que originou a sessão — independentemente de quanto tempo passou entre o clique e a compra.

Camada 3: Cruzamento com o Webhook do ERP (Bling)

Para uma visão da rotina operacional que essa arquitetura habilita — pausar ad sets por margem em tempo real — veja Otimização Orientada a Lucro com CMV do Bling.

Quando o pedido é confirmado na Nuvemshop, dois webhooks disparam em sequência:

Webhook da Nuvemshop (order/paid) — entrega o ID do pedido, o valor total, os SKUs comprados, e os metadados customizados (onde estão o gclid e fbclid gravados na camada 2).

Webhook do Bling — dispara quando o pedido é integrado ao ERP, entregando o CMV por SKU, a nota fiscal (com impostos calculados), e o custo de frete real da transportadora.

O backend do Nexopath cruza esses dois webhooks usando o ID do pedido como chave:

Pedido #48291 (Nuvemshop) ← → Pedido #48291 (Bling)
├── gclid: EAIaIQobChMI8d2x...        ← Da Nuvemshop
├── receita: R$ 320,00                ← Da Nuvemshop
├── CMV: R$ 112,00                    ← Do Bling
├── impostos: R$ 19,20                ← Do Bling (NF-e)
├── frete_real: R$ 18,50              ← Do Bling (logística)
└── lucro_liquido: R$ 170,30          ← Calculado

Com esses dados cruzados, o pipeline calcula o POAS real do pedido e o envia como conversion_value para o Google Ads via API Enhanced Conversions, usando o gclid como chave de match.

Por Que Não Basta Usar Enhanced Conversions Diretamente

O Google oferece Enhanced Conversions como uma forma de melhorar a atribuição via dados hasheados (email, telefone). Isso ajuda quando o gclid está ausente — o Google tenta fazer o match via identidade do usuário.

Mas há uma limitação fundamental: Enhanced Conversions com dados hasheados do browser ainda depende que o usuário esteja logado no Google. A taxa de match em cenários sem gclid fica entre 40-60%.

Com gclid disponível, o match rate sobe para 95%+. Isso significa que preservar o gclid via cookie first-party — e não depender do fallback de PII hasheada — é o que garante qualidade de atribuição em escala.

Cenários de Falha Que Esta Arquitetura Resolve

Usuário com ad blocker — o gclid está na URL no momento do clique. O script first-party executa antes de qualquer bloqueio externo. O cookie é criado. A conversão é atribuída.

Safari com ITP — o cookie é first-party, setado via document.cookie no contexto do domínio da loja. O ITP não o classifica como rastreamento de terceiro. O TTL de 30 dias é respeitado.

Ciclo de compra longo (> 7 dias) — o cookie persiste durante os 30 dias configurados. Um usuário que clica no anúncio na segunda e compra na quarta-feira da semana seguinte tem a conversão atribuída ao clique correto.

Navegação entre páginas sem UTMs — o cookie persiste durante toda a sessão e além. Um usuário que vai de /produto → /categoria → /produto-2 → checkout tem o gclid disponível no momento da compra, independentemente de qual URL carregou no final.

Frete subsidiado não contabilizado no ERP — o webhook do Bling carrega o custo logístico real da etiqueta de envio, não o valor cobrado do cliente. O pipeline usa esse número para calcular o impacto real do frete subsidiado na margem do pedido.

O Gargalo da Implementação Manual

É tecnicamente possível implementar cada camada desta arquitetura de forma independente:

  • Script first-party para captura de GCLID: um desenvolvedor experiente leva 2-4 horas
  • Amarração do cookie ao metadado do pedido: requer acesso ao NubeSDK, mais 4-8 horas
  • Webhook da Nuvemshop + webhook do Bling + cruzamento: backend, banco de dados de staging, retry logic — semanas de desenvolvimento
  • Enhanced Conversions API: autenticação OAuth2, deduplicação, retry exponencial — mais semanas

A implementação manual existe e funciona. O custo é de tempo de engenharia e manutenção contínua: cada mudança na API do Bling, na estrutura do webhook da Nuvemshop, ou nos requisitos da Google Ads API exige atualização.

O Nexopath POAS encapsula essa infraestrutura como serviço gerenciado. O setup leva menos de 10 minutos. As atualizações de API são absorvidas pelo time de infraestrutura do Nexopath.

Próximo Passo

O Nexopath POAS está disponível na Nuvemshop App Store. O setup de menos de 10 minutos inclui conexão com a Nuvemshop, integração com o ERP, e autenticação do Google Ads. As três camadas de rastreamento first-party descritas neste artigo são configuradas automaticamente. Free trial de 14 dias.