E-commerce e marketplace: pedidos, produtos e atribuição de canal
O padrão para colocar pedidos, produtos e origem de venda num modelo consumível, com as armadilhas de cancelamento e atribuição.
- Ver as fontes típicas de um e-commerce
- Modelar pedidos e atribuição de canal
- Ter um checklist de implementação end-to-end
Num e-commerce, o dado que importa nasce espalhado: o pedido está na plataforma de loja, o dinheiro confirmado está no gateway, e a origem da venda está no pixel de mídia e no analytics. Cada sistema conta um pedaço da mesma história de venda, e sozinho nenhum responde as perguntas que o negócio faz todo dia. Este playbook mostra o padrão que a Nekt usa para juntar pedidos, produtos e canal de origem num modelo único e consumível, tratando desde o começo as duas coisas que mais distorcem número de e-commerce: cancelamentos e atribuição.
1. Contexto: o que um e-commerce precisa medir
Poucas métricas guiam quase toda decisão de uma operação de venda online. Elas respondem perguntas diferentes, mas se apoiam na mesma base de pedidos bem modelada.
- Faturamento líquido: quanto entrou de verdade, depois de tirar pedidos cancelados, devoluções e descontos. É o número que o board olha primeiro, e o que mais gente calcula errado ao somar pedido bruto.
- Ticket médio: o valor médio por pedido válido. Diz se a estratégia está trazendo compras maiores ou menores, e muda de leitura conforme o canal.
- Produtos mais vendidos: o que sai, em volume e em receita. Guia estoque, curadoria e o que empurrar na mídia.
- Canal que traz venda: de onde veio cada pedido (mídia paga, orgânico, direto). É o que conecta o gasto de marketing ao faturamento e decide onde investir.
- Cancelamentos e devoluções: quanto da venda bruta escapa depois. É o vazamento do balde, e precisa aparecer separado para não inflar a receita.
Cada uma aponta para uma alavanca diferente: o faturamento mede o tamanho, o ticket mede a qualidade da compra, o mix de produtos guia o estoque, o canal conecta marketing a receita, e os cancelamentos medem o vazamento. O problema é que, sem uma base modelada, cada time calcula do seu jeito, o marketing soma o pedido bruto e o financeiro soma o líquido, e ninguém fecha o número. É esse trabalho que a modelagem na Nekt resolve.
2. Fontes típicas de um e-commerce
A maioria das operações tem os dados divididos entre a plataforma de loja, o gateway de pagamento, as plataformas de mídia e o analytics. Cada fonte entrega uma peça, e o valor aparece quando elas se juntam numa camada modelada. Todas entram cruas na Bronze.
- Plataforma de loja (ex: Shopify, VTEX, Nuvemshop). A fonte da verdade sobre o pedido: itens, cliente, valores, frete, status, e o catálogo de produtos. É o coração do modelo, quase tudo gira em torno dela.
- Gateway de pagamento (ex: Stripe, Pagar.me, Mercado Pago). A confirmação do dinheiro: cobrança aprovada, recusada, estornada. É o que separa pedido feito de pedido efetivamente pago, e traz taxas que o líquido precisa considerar.
- Mídia (ex: Meta Ads, Google Ads). O gasto e o desempenho de campanha por canal, além dos parâmetros de origem que ligam o clique ao pedido. É a metade da conta de atribuição.
- Analytics (ex: GA4). A jornada do visitante até a compra: origem da sessão, primeira e última interação. Ajuda a resolver de qual canal a venda realmente veio.
Plataforma de loja e gateway costumam ter informação sobreposta sobre valor e status do pedido. Defina desde o começo qual é a fonte da verdade para cada campo: normalmente a loja manda em itens, cliente e frete, e o gateway manda em pagamento confirmado e taxas. Documentar isso evita conflito na hora de calcular o faturamento.
3. Modelagem recomendada na Gold
O objetivo é chegar a uma tabela larga de pedidos na camada Gold: uma linha por pedido, já com produto, cliente, canal, valor bruto, descontos, frete e status juntos. As fontes cruas da loja e do gateway entram na Bronze, a limpeza e a padronização acontecem na Silver, e o modelo de negócio final, o pedido wide com atribuição, vive na Gold.
- Pedidos e catálogo da plataforma de loja
- Cobranças do gateway, gasto de mídia
- Como veio, sem edição
- Valores e datas ainda como texto
- Valores tipados, datas de verdade
- Uma tabela por entidade
- Status padronizado num vocabulário só
- Fonte da verdade definida por campo
- Uma linha por pedido, tudo junto
- Produto, cliente, canal e valores
- Cancelados e devoluções tratados
- É daqui que dashboard e MCP leem
Por que uma tabela wide de pedidos
A tentação é deixar tudo normalizado, o pedido numa tabela, os itens
em outra, o cliente em outra, o canal em outra, e pedir para quem
consome fazer os joins. Num e-commerce isso trava tanto o BI quanto a
IA. Uma tabela wide, com uma linha por pedido e as
dimensões mais usadas já resolvidas na própria linha (produto
principal, cliente, canal, valor bruto, desconto, frete, status),
deixa a maioria das perguntas a um GROUP BY de distância.
O dashboard soma e filtra direto, sem join. E o agente de IA, que erra
ao encadear joins, acerta ao ler uma tabela plana e bem descrita. Uma
modelagem, dois consumos fáceis.
Uma linha por pedido, com produto, cliente, canal e a decomposição do valor já resolvidos:
| pedido | data | cliente | produto | canal | bruto | desconto | frete | status | liquido |
|---|---|---|---|---|---|---|---|---|---|
| a83f | 08/03/2026 | Loja Silva | Filtro P15 | R$ 240 | R$ 20 | R$ 30 | entregue | R$ 250 | |
| a840 | 08/03/2026 | M. Souza | Filtro P20 | R$ 180 | R$ 0 | R$ 25 | entregue | R$ 205 | |
| a851 | 09/03/2026 | R. Costa | Filtro P15 | Direto | R$ 240 | R$ 0 | R$ 30 | cancelado | R$ 0 |
| a860 | 09/03/2026 | Ana Dias | Filtro P30 | R$ 320 | R$ 30 | R$ 0 | devolvido | R$ 0 |
Somando liquido por canal, você tem o
faturamento por canal. Agrupando por produto, o mix
de vendas. Repare que os pedidos cancelado e
devolvido já entram com líquido zero, então nunca
inflam a receita, mesmo continuando visíveis para análise de
perdas.
Wide não quer dizer "jogue tudo numa tabela só". Mantenha a granularidade clara: uma linha por pedido. Se um pedido tem vários produtos e você precisa analisar item a item, crie uma segunda tabela de itens (uma linha por item de pedido) em vez de esticar a de pedidos. Duas granularidades limpas são mais fáceis de manter e de explicar para a IA do que uma tabelona ambígua.
4. Atribuição de canal
Atribuição é ligar cada venda ao canal que a originou: mídia paga,
busca orgânica, tráfego direto, indicação. Na prática, você usa os
parâmetros de origem que a plataforma de loja guarda no pedido (os
famosos UTMs) e cruza com a sessão do analytics para preencher a
coluna
canal da tabela wide. Feito isso, somar faturamento por
canal vira um GROUP BY.
O desafio é que a jornada de compra quase nunca é de um toque só. O cliente vê um anúncio no Instagram, pesquisa no Google dias depois, e volta digitando o endereço direto para comprar. A qual canal pertence essa venda? A resposta depende da janela de atribuição que você escolhe. O modelo mais comum é o last click, que credita o último canal antes da compra (no exemplo, direto), mas ele apaga o papel do Instagram que gerou a descoberta. Outros modelos creditam o primeiro toque, ou dividem o crédito entre os canais da jornada. Não existe modelo certo, existe o modelo que o negócio combina e usa de forma consistente.
Nenhum modelo de atribuição é a verdade absoluta. Cada um é uma forma de simplificar uma jornada real que passou por vários canais, dispositivos e dias. O valor não está em acertar o canal "correto" de cada venda isolada, e sim em usar o mesmo modelo de forma consistente para comparar canais entre si ao longo do tempo. Deixe explícito na modelagem qual janela e qual regra (last click, first click, etc.) você usou, e documente isso na Camada Semântica para que dashboard e agente respondam com a mesma definição.
5. Armadilhas
Duas armadilhas aparecem em quase todo projeto de dados de e-commerce. Elas não quebram o pipeline, o que é pior: entregam números plausíveis, mas errados. Vale conhecer as duas antes de modelar.
Faturamento tem que tratar cancelados e devoluções. Um pedido cancelado ou devolvido nunca virou receita, então somá-lo no faturamento infla o número, às vezes de forma dramática em operações com muita devolução. A regra prática: a receita da tabela wide deve refletir só o que foi efetivamente pago e mantido. Mantenha os pedidos cancelados e devolvidos visíveis na tabela (com o líquido zerado e o status explícito), porque a análise de perdas precisa deles, mas garanta que o faturamento some apenas os pedidos válidos. Nunca calcule receita a partir do valor bruto sem descontar cancelamento, devolução e desconto.
O status de um pedido não é fixo: ele nasce como "aguardando pagamento", vira "pago", depois "enviado", "entregue", e pode virar "cancelado" ou "devolvido" semanas depois. Se a modelagem capturar o status de um momento e nunca mais atualizar, a tabela mente: um pedido que foi devolvido continua aparecendo como entregue e contando como receita. A tabela wide precisa refletir o estado atual de cada pedido, reprocessando o status a cada atualização da fonte. Sem isso, o faturamento de hoje muda a leitura do faturamento de ontem, e ninguém confia no histórico.
6. Use case: dashboard de vendas + agente de IA
Com a tabela wide de pedidos na Gold, dois consumos aparecem quase de graça em cima do mesmo modelo.
Um dashboard de vendas por canal e produto lê direto da tabela wide: receita líquida por canal, mix de produtos mais vendidos, ticket médio, evolução por dia. Como cancelados e devoluções já entram com líquido zero e o status reflete o estado atual, os números fecham com o financeiro sem retrabalho, e o time de marketing enxerga na hora qual canal está de fato trazendo receita, não só pedido bruto.
Um agente de IA, via MCP, responde perguntas em linguagem natural sobre a mesma tabela: "qual produto vendeu mais no Instagram essa semana", "qual canal teve mais devolução no mês", "qual o ticket médio no Google Ads". Em vez de esperar um analista montar a query, quem precisa da resposta pergunta e recebe o número na hora.
O que faz o agente ser confiável é a Camada Semântica descrevendo a tabela: o que é cada coluna, que o faturamento usa o líquido e não o bruto, que cancelado e devolvido contam como zero, qual modelo de atribuição alimenta a coluna de canal. Sem essa descrição, a IA adivinha e erra. Com ela, a IA responde com as mesmas regras que o dashboard usa, e os dois batem. Uma modelagem, dois consumos que nunca se contradizem.
Um e-commerce de filtros vendia pela loja própria e por marketplaces, com pagamento no gateway e mídia no Meta e no Google. O faturamento reportado nunca fechava com o financeiro porque somava pedido bruto, sem descontar cancelamento e devolução, e o status congelava no momento da carga. Ao refazer a modelagem numa tabela wide de pedidos na Gold, com líquido tratando cancelados e devoluções, status refletindo o estado atual e o canal resolvido por atribuição last click, o número virou uma métrica em que o time confiava. Em cima da mesma camada, plugaram um dashboard de vendas por canal e produto e um agente que responde perguntas de venda no dia a dia.
7. Checklist de implementação
O caminho end-to-end, na ordem em que costuma fazer sentido. Cada passo se apoia no anterior, então vale seguir de cima para baixo.