Infraestrutura de Dados para Plataformas de Venda: Os 6 Pilares que Todo Gestor de Tráfego Deve Exigir

Por que a infraestrutura de dados da sua plataforma de venda importa

A qualidade da infraestrutura de dados de uma plataforma de vendas digitais é um dos fatores mais determinantes para o sucesso de campanhas pagas. Uma plataforma que não expõe dados ricos no momento da compra obriga o gestor de tráfego a trabalhar no escuro: sem saber quem comprou, de onde veio, qual anúncio converteu ou como recuperar quem não finalizou.

Cada transação que ocorre em uma plataforma deve gerar um conjunto abrangente de dados estruturados, disponibilizados de forma nativa tanto via dataLayer (para GTM) quanto via webhook, possibilitando integração direta com Meta Ads, Google Ads, outras plataformas de tráfego, plataformas de CRM e sistemas de BI.

“Esta documentação descreve as vantagens estruturais de plataformas com boa infraestrutura no contexto de dados, rastreamento, trackeamento e atribuição de vendas.

Visão Geral dos Recursos

A plataforma deve oferecer pelo menos seis pilares fundamentais de infraestrutura de dados:

Integração nativa com GTM no checkout — DataLayer rico com eventos de jornada e dados de usuário em tempo real
Checkout transparente (domínio próprio) — Jornada do lead sem quebra de domínio, preservando cookies e atribuição
Redirecionamento com parâmetros dinâmicos — Repasse de UTMs e parâmetros para páginas de upsell pós-compra
GTM instalado globalmente (nível de conta e de produto) — Uma única instalação vale para todos os produtos, com possibilidade de GTM específico por produto
Webhook completo com dados transacionais — Payload detalhado com dados do comprador, produto, financeiro e UTMs
Suporte a assinaturas no webhook — Ciclos de cobrança, inadimplência, renovação e dados de fatura

1. Integração Nativa com GTM no Checkout

Integração direta com o Google Tag Manager dentro do próprio checkout. Isso significa que o dataLayer já é populado automaticamente pela plataforma com dados ricos a cada etapa da jornada do comprador, sem necessidade de desenvolvimento customizado.

Por que isso importa: A maioria das plataformas dispara apenas um evento de compra na página de obrigado. Uma plataforma boa dispara eventos em cada etapa do checkout, com dados completos do usuário já disponíveis desde o primeiro contato com o formulário.

Eventos Disparados no DataLayer

Os seguintes eventos devem ser disparados automaticamente durante a jornada de checkout:

form_start — Abertura do formulário de checkout. Dados disponíveis: infraestrutura (IP, cidade, user agent, cookies). São dados que é possível obter sem preenchimento por parte do usuário.
addToCart — Início do preenchimento (step 1). Dados adicionais: produto, valor, currency junto com os dados dos eventos anteriores.
begin_checkout — Após preenchimento de contato. Dados adicionais: email hasheado e não hasheado, nome, telefone, método de pagamento, entre outros dependendo das informações preenchidas.
purchase — Confirmação da compra (redirect). Todos os dados completos da compra + transaction_id.

Eventos Disparados no DataLayer

Estrutura do DataLayer

Cada evento contém um payload padronizado com quatro blocos principais de dados:

Identificadores de Clique (Atribuição Multi-plataforma) — Presentes em todos os eventos, desde o primeiro acesso: fbclid (Click ID do Facebook Ads), fbp (Facebook Browser ID), ga (Google Analytics client ID), gid (Google Analytics session ID), gclid (Google Click ID), além de gbraid, wbraid para Google Ads e outros para TikTok Ads, Kwai, Taboola, etc.

Identificadores de Clique (Atribuição Multi-plataforma)

Dados de Contato do Usuário — Disponíveis em dois formatos: hasheado (SHA-256) para as APIs de conversão, e unhashed para uso interno. Inclui email, telefone, nome, documento (CPF/CNPJ), cidade, estado, CEP e país.

Dados de Contato do Usuário

Dados de Infraestrutura — Informações geográficas e técnicas do dispositivo do comprador: IP, cidade, coordenadas geográficas, região, país e user agent completo do navegador. Dados obtidos automaticamente via API de geolocalização pelo IP.

Dados de Infraestrutura

Dados de Produto e Transação — product_id (UUID interno), product_name, product_type, total_value, subtotal, shipping, taxValue, currency, payment_method e transaction_id (UUID único da transação).

Dados de Produto e Transação

Compatibilidade com eCommerce Enhanced (GA4 e UA)

O dataLayer deve ser compatível com os padrões de eCommerce Enhanced do Google Analytics, incluindo os objetos ecommerce.purchase, ecommerce.checkout e ecommerce.checkout_option, além da matriz items[] do GA4.

Matriz Items do Google Analytics 4

Compra sem Página de Obrigado

A plataforma deve permitir registrar e rastrear conversões do próprio checkout, eliminando a necessidade obrigatória de uma página de obrigado. O evento de purchase é disparado no momento da confirmação, direto no checkout.

Isso aumenta a precisão do rastreamento porque evita perdas causadas por usuários que fecham o navegador antes de chegar na página de obrigado.

2. Checkout Transparente (Domínio Próprio)

O checkout transparente permite integrar o seu próprio domínio no checkout. Exemplo: checkout.seudominio.com.br.

Por Que o Domínio Importa para o Rastreamento

Sem quebra de domínio: o lead não sai do seu domínio durante a jornada. Isso mantém cookies, sessions e identificadores intactos
Cookies first-party: navegadores como Safari (ITP) limitam cookies de terceiros. Com checkout no seu domínio, os cookies são first-party e têm validade maior
Melhor atribuição: o fbclid, gclid e UTMs que chegaram no site continuam disponíveis no checkout

Impacto na Qualidade do Match de Dados — Meta Ads

O checkout transparente melhora diretamente a Event Match Quality (EMQ) do Meta Ads. Quando o checkout está no mesmo domínio:

O cookie fbp (Facebook Browser ID) é first-party e persistente
O fbclid é preservado na URL durante toda a jornada
O Meta consegue fazer match entre o clique no anúncio e a conversão com maior precisão

Sem checkout transparente, o lead muda de domínio e o browser pode bloquear os cookies — reduzindo a taxa de match e prejudicando a otimização do algoritmo.

3. Redirecionamento Customizado para Upsell

Após a compra, a plataforma deve permitir redirecionar o comprador para uma página de upsell com parâmetros de URL customizados.

Como Funciona

O comprador finaliza a compra e é redirecionado para uma URL configurável. Nessa URL, a plataforma pode injetar automaticamente parâmetros dinâmicos como UTMs, IDs de transação e dados do comprador.

Redirecionamento para página de Upsell com parâmetros de URL

Parâmetros Dinâmicos Suportados

A plataforma deve suportar repasse de UTMs originais, transaction_id, email do comprador e outros parâmetros customizados para a página de upsell — mantendo a cadeia de atribuição intacta.

Sem isso, a compra do upsell apareceria como "direto" no seu dashboard — sem saber qual anúncio original gerou aquele lead.

“O ideal também é ter um sistema que possa gerenciar qualquer parâmetro de URL que chegue na URL do checkout além de ter apenas parâmetros fixos que são coletados.

Parâmetros Dinâmicos Suportados

4. GTM Instalado em Nível Global de Conta e em Nível de Produto

A plataforma deve permitir a instalação do GTM tanto a nível global (uma única instalação vale para todos os produtos da conta) quanto a nível de produto individual.

Vantagens Operacionais

Vantagens Operacionais de se ter configuração global do GTM na plataforma de vendas

Sem GTM Global: cada produto precisa de configuração individual manual, risco de esquecer de instalar em novos produtos, manutenção de múltiplos IDs e containers, scripts duplicados geram conflitos.

Com GTM Global: um container GTM vale para toda a conta, novos produtos já nascem configurados, manutenção centralizada em um único container, sem risco de duplicidade de disparos.

Também deve ser possível configurar a nível de produto para cenários onde você usa domínios diferentes para produtos diferentes. Por exemplo: um domínio para treinamentos e outro para ferramentas SaaS, com GTMs separados.

Para operações com múltiplos produtos, esse recurso elimina horas de configuração repetitiva e reduz drasticamente o risco de erro humano na implementação de rastreamento.

5. Webhook Completo com Dados Transacionais

O webhook deve ser disparado a cada evento transacional relevante (compra aprovada, reembolso, assinatura criada, inadimplência, etc.) e entregar um payload JSON extremamente rico, permitindo integração com qualquer sistema externo: CRM, planilha, servidor de traqueamento, ferramenta de BI ou sistema proprietário.

“O webhook elimina a necessidade de depender exclusivamente do frontend para trackear conversões. Com um servidor de traqueamento (server-side GTM, por exemplo), é possível capturar 100% das conversões, incluindo usuários com adblockers.

5.1 Dados do Comprador

O payload inclui o perfil completo do comprador: nome, email, CPF, telefone (com DDI), endereço completo (logradouro, número, bairro, cidade, estado, CEP, país).

Dados do Comprador

5.2 Dados de Infraestrutura

Dados de Infraestrutura

Informações técnicas e geográficas capturadas no momento da compra: IP, cidade, coordenadas geográficas, região, país, user agent, domínio do checkout utilizado, Google Analytics client ID e Facebook browser ID (fbp).

5.3 Dados Financeiros Detalhados

Dados Financeiros Detalhados

O payload expõe informações financeiras completas: valor bruto total, valor líquido após taxa da plataforma, método de pagamento, número de parcelas, valor de cada parcela, juros aplicados, moeda, desconto (cupons), valor de imposto/taxa, motivo de recusa ou reembolso, adquirente/gateway utilizado, NSU e TID da transação.

5.4 Afiliados e Coprodutores

Afiliados e Coprodutores

Visão do payload do Webhook contendo informações sobre Afiliados e Coprodutores

O payload lista todos os afiliados e produtores que participam da transação, com suas respectivas comissões: nome do afiliado, email, tipo de comissão (percentual ou fixo), valor da comissão, escopo (todas as vendas ou primeira venda) e ID na plataforma.

5.5 Dados do Produto

Dados do Produto

Informações completas sobre o produto comprado e a oferta específica: nome, tipo (product, plan), ID interno, ID na plataforma de pagamento, valor total e unitário, quantidade, nome e ID da oferta, URL da imagem, nome do produtor e grupo/categoria.

5.6 Datas Separadas e Organizadas

Datas Separadas e Organizadas

O payload organiza todas as datas relevantes em um objeto dedicado: data de criação, confirmação do pagamento, pedido realizado, expiração do pix/boleto, última atualização, data fim da garantia e data de cancelamento.

5.7 UTMs Organizadas e Demais Parâmetros de URL

UTMs Organizadas e demais parâmetros de URL

As UTMs e outros parâmetros de URL da compra são mapeados em um objeto source dedicado, separando o parâmetro src do sck para máxima rastreabilidade:

source.utm_source — Fonte da campanha
source.utm_medium — Mídia/veículo
source.utm_campaign — Nome da campanha
source.utm_term — Termo/ad name (ID do anúncio)
source.utm_content — Conjunto de anúncios
source.source — Parâmetro src personalizado
source.checkout_source — Source do checkout (parâmetro sck)
source.other_params — Array de fontes e parâmetros adicionais

Importante: a plataforma deve registrar todos os parâmetros de URL que chegam ao checkout, não apenas parâmetros fixos. Vários projetos e empresas utilizam parâmetros customizados em suas URLs para enriquecimento de base de dados.

5.8 URLs para Recuperação de Abandono

URLs para Recuperação de Abandono

Para transações pendentes (pix expirado, boleto não pago, cartão recusado), o payload entrega URLs diretas para reativação: URL da imagem do QR Code Pix, chave copia-e-cola do Pix, data de expiração, URL do checkout de recuperação e URL de pagamento da fatura atual (assinaturas).

Essas URLs podem ser usadas em automações de recuperação: disparo via WhatsApp, email ou SMS com link direto para o pagamento, sem precisar gerar um novo checkout do zero.

6. Webhook de Assinatura

Além do webhook transacional padrão, a plataforma pode possuir um webhook específico para assinaturas recorrentes, com dados completos sobre o ciclo de cobrança.

Dados Exclusivos de Assinatura

Código único da assinatura, frequência de cobrança em dias, número de cobranças já realizadas, se cancelará ao fim do ciclo atual, motivo do cancelamento, dias de período de teste, início e fim do trial, status atual da assinatura, data da próxima cobrança, valor e parcelas da próxima cobrança.

Dados da Fatura Atual

O objeto current_invoice traz o estado da cobrança vigente: status da fatura (paid, pastdue, waiting), valor cobrado, número do ciclo, data agendada para cobrança, início e fim do período cobrado, URL para pagamento em atraso, total de tentativas e tentativa atual, desconto aplicado.

Fluxo de Status de Assinatura

Os seguintes status são transmitidos via webhook ao longo do ciclo de vida:

active — Assinatura ativa e em dia
pastdue — Fatura em atraso, mas assinatura ainda ativa
waiting_payment — Aguardando confirmação do pagamento
canceled — Assinatura cancelada definitivamente
trial — Em período de teste gratuito
ended — Ciclo de cobranças esgotado (produto com limite de ciclos)

O status pastdue permite acionar automações de recuperação de inadimplentes com os dados de contato e a URL de pagamento disponíveis diretamente no payload, sem consultas adicionais à API.

7. Casos de Uso e Integrações

Meta Conversions API (CAPI) via Server-side GTM

Com um dataLayer e webhooks ricos, é possível implementar o Meta CAPI de forma server-side: o evento de compra é disparado no dataLayer com email hasheado, telefone, IP e user agent. O sGTM recebe o evento e o encaminha para o CAPI com todos os dados de match. Resultado: alta taxa de match de eventos (Event Match Quality acima de 8/10) e redundância de traqueamento (cliente + servidor garantem cobertura total).

Google Ads Enhanced Conversions

Os dados hasheados disponíveis no dataLayer são compatíveis com o recurso de Enhanced Conversions do Google Ads: email hasheado via SHA-256, telefone e nome hasheados, e o gclid preservado para correta atribuição de conversão.

Recuperação de Abandono de Checkout

Com o dataLayer disparando desde o form_start e o begin_checkout, é possível identificar usuários que iniciaram mas não finalizaram a compra. O email pode ser capturado assim que digitado no campo (begin_checkout já contém email). Com esse email, sistemas de automação podem disparar sequências de recuperação. Para assinaturas inadimplentes, o webhook entrega a URL de pagamento pronta.

Atribuição Avançada com UTMs + sck

A combinação dos parâmetros UTM com o parâmetro sck (checkout_source) permite granularidade máxima de atribuição: utm_source, utm_medium, utm_campaign, utm_content e utm_term identificam a campanha. O utm_term costuma conter o ID do anúncio (nome_ad|ID_do_anuncio). O sck possibilita o armazenamento de mais informações além das UTMs. Esse nível de detalhe permite otimização mais robusta até o nível de criativo individual.

Integração com CRM e Automações

O webhook pode ser enviado para qualquer endpoint de CRM, ferramenta de automação ou sistema proprietário: ActiveCampaign, RD Station, HubSpot, N8N entre outros. Planilhas Google Sheets via webhook + Apps Script. Sistemas próprios via API REST. Servidor de traqueamento (sGTM) para processamento server-side.