Pedidos da loja e marketplaces, GA4 e mídia
Pedido pago pelo status financeiro, dia no fuso da loja
Fato diário com receita líquida, CVR, AOV e funil
Dashboard, relatório recorrente e alertas
O que resolve
- A receita do relatório bate com o painel da loja e não inclui pedido expirado, pendente ou de teste.
- Conversão e ticket médio calculados do mesmo jeito para todas as lojas da carteira.
- O funil do site mostra onde o cliente perdeu venda, com a cobertura do GA4 declarada.
Perguntas de negócio que responde
Faça estas perguntas ao seu agente quando o caso estiver pronto.
O que você precisa
- A loja e os marketplaces do cliente conectados na Nekt
- O GA4 da loja conectado (relatórios diários e eventos)
- O fuso e a moeda da loja, e o funil de eventos combinados com o cliente
O que você recebe
- Um fato diário por loja e canal com pedidos pagos, receita bruta, líquida e reembolsos
- Funil view_item, add_to_cart, begin_checkout e purchase com taxas por etapa
- Dashboard com CVR, AOV e RPV recalculados para qualquer período
- Alerta de queda de receita e de buraco de carga do GA4
Onde ativar
Receita, pedidos, CVR, AOV e funil por dia e canal, com a cobertura do GA4 ao lado.
Receita = sessões x conversão x ticket, para explicar a variação da semana pelo fator que mudou.
Queda de receita contra a média das últimas semanas e purchase do GA4 desalinhado com os pedidos.
As regras são fechadas e o pacote se replica por loja. O esforço está em cada marketplace, que tem status e grão próprios, e no funil personalizado de cada site. O detalhado traz as regras de negócio, as armadilhas e o teste de aceitação. Ou mande tudo direto para o seu agente com o MCP da Nekt.
A loja grava o pedido assim que o carrinho é fechado, pago ou não, em UTC, com o reembolso escondido numa lista de transações. O GA4 conta eventos, não pedidos, e às vezes conta o mesmo purchase duas vezes. Quem soma os pedidos da loja sem filtro conta Pix vencido e pedido de teste; quem corta o dia em UTC joga a venda da noite para o dia seguinte; quem tira média das conversões diárias entrega uma taxa que ninguém reproduz.
Como costuma ser feito, e a regra
Cada linha é um erro que já aconteceu na prática.
Receita é só de pedido com displayFinancialStatus PAID ou PARTIALLY_REFUNDED, cancelledAt vazio e test = false. PENDING e AUTHORIZED ainda não são venda; EXPIRED (Pix ou boleto vencido) e VOIDED nunca serão. Mantenha cada status como linha própria no fato, para o cliente ver quanto ficou pendente ou expirou.
Receita bruta = subtotal + descontos. Receita líquida = subtotal - reembolsos. Reembolso é a soma das transações do pedido com kind = REFUND e status = SUCCESS. Frete e imposto ficam fora da receita de produto e entram só no total. Declare se o reembolso fica no dia do pedido ou no dia em que aconteceu, e não mude.
Converta a data do pedido (processedAt ou createdAt, uma só, declarada) para o fuso da loja antes de cortar o dia: America/Sao_Paulo no Brasil, o fuso local em lojas no exterior. A data do GA4 já vem no fuso da propriedade.
O painel de sessões da loja conta robôs que raspam preço e catálogo, com picos de países sem relação com o público. Sessões, usuários e funil vêm do GA4. Pedidos e receita vêm sempre da loja; o purchase do GA4 serve para conferência. CVR = pedidos pagos da loja / sessões do GA4.
CVR, AOV e RPV são razões de somas no período escolhido: pedidos / sessões, receita / pedidos, receita / sessões. Nunca média de taxas diárias. O fato diário guarda os numeradores e denominadores; a taxa é calculada na leitura.
O funil padrão é view_item, add_to_cart, begin_checkout e purchase, pelo eventCount de cada evento, com taxa de cada etapa sobre a anterior. Sites com jornada própria (escolher rota, assento e forma de pagamento) declaram os nomes dos eventos como dado no contexto do cliente. Contagem de evento não é contagem de pessoas.
Vários contêineres do Google Tag Manager ou duas propriedades disparando purchase dobram o evento. Compare purchase do GA4 com pedidos pagos da loja por dia; diferença sistemática para cima é rastreamento duplicado. Na tabela de transações do GA4, fique com uma linha por transactionId e descarte '(not set)'.
Relatórios do GA4 são extraídos de novo e o mesmo dia aparece mais de uma vez. Fique com a linha da extração mais recente de cada loja e dia. A data pode vir como YYYYMMDD ou YYYY-MM-DD na mesma série: aceite os dois formatos.
Antes de comparar sessões entre meses, conte os dias carregados de cada mês. Mês com menos de 80% dos dias fica sem número (no mês corrente, contra os dias já decorridos). Todo número de tráfego vem com a cobertura ao lado.
Cada marketplace tem status e grão próprios: na Amazon o relatório é por item e o pedido aprovado é o enviado; na Shopee o grão é o pedido e ficam fora CANCELLED e UNPAID. Conte itens numa subconsulta por pedido, nunca abrindo a lista de itens no cruzamento, que repete o valor do pedido. Loja em outra moeda não soma com real.
Status do pedido no fato diário
Pelo displayFinancialStatus e pelas marcas do pedido na loja.
Definições
Armadilhas que já aconteceram
Pedidos com Pix ou boleto que venceu sem pagamento continuavam na loja com valor no carrinho e entravam na receita.
Filtre pelo status financeiro e mostre os expirados à parte.
Lojas no exterior tinham o dia cortado em UTC e a venda da noite caía no dia seguinte, sem bater com o painel da loja.
Converta para o fuso da loja antes de agrupar por dia.
O painel nativo da loja mostrava picos de sessões de países sem nenhuma relação com o público. Eram robôs raspando catálogo.
Sessões só do GA4; pedidos só da loja.
Um cliente com vários contêineres de tag e várias propriedades do GA4 tinha o evento purchase disparando duas vezes.
Compare purchase com pedidos pagos e deduplique por transactionId.
Um mês com dois dias de GA4 carregados foi comparado com um mês com oito, e a variação de sessões parecia gigantesca.
Conte os dias carregados e anule o mês com menos de 80%.
Abrir a lista de itens no cruzamento repetia o valor do pedido em cada item e inflava a receita dos pedidos com mais de um produto.
Conte itens numa subconsulta por pedido.
Teste de aceitação
O caso está pronto quando todos os itens passam.
- Para uma loja e um mês fechado, pedidos pagos e receita líquida batem com o relatório de vendas da loja (diferença abaixo de 1%).
- Nenhum pedido EXPIRED, VOIDED, cancelado ou de teste entra na receita.
- O fato tem uma linha por loja, canal e dia, sem repetição.
- CVR do mês = soma de pedidos pagos / soma de sessões do mês, e não a média das taxas diárias.
- Purchase do GA4 do mês fica dentro de 10% dos pedidos pagos da loja, ou o desvio aparece como alerta de rastreamento.
Pacote para o agente
Cole no Claude, ChatGPT ou outro cliente com o MCP da Nekt conectado.
E-commerce do cliente - Pedido pago: displayFinancialStatus PAID ou PARTIALLY_REFUNDED, cancelledAt vazio e test = false. PENDING, AUTHORIZED, EXPIRED e VOIDED não são receita. - Receita líquida = subtotal - reembolsos (transações kind = REFUND e status = SUCCESS). Frete e imposto fora. - O dia é o dia da loja: converta a data do pedido para o fuso <fuso da loja> antes de agrupar. - Sessões, usuários e funil vêm do GA4. Pedidos e receita vêm da loja. Não use sessões da loja: contam robôs. - CVR, AOV e RPV se recalculam como razão de somas no período. Nunca média de taxas. - Funil padrão: view_item, add_to_cart, begin_checkout, purchase (eventCount). - Mês com menos de 80% dos dias de GA4 carregados não é comparado. Informe a cobertura. - Marketplaces têm regras próprias e não somam moedas diferentes. Exceções por cliente: - <cliente>: funil próprio com os eventos <evento 1>, <evento 2>, <evento 3> e purchase. - <cliente>: loja em <moeda>, fuso <fuso>; não somar com lojas em real.
Construa no meu workspace Nekt o caso "E-commerce do cliente" seguindo as regras em https://academy.nekt.com/industrias/agencias/ecommerce-do-cliente.md. 1) Encontre as tabelas de origem e confirme as colunas usadas pelas regras. 2) Crie uma transformação no grão indicado aplicando todas as regras. 3) Rode o teste de aceitação e me mostre o resultado de cada item. 4) Crie o context document do caso no workspace, com as exceções dos meus clientes em aberto para eu preencher.
Variações
Junte o investimento da tabela de mídia da carteira à receita paga da loja no mesmo dia e loja, em vez de usar o valor de conversão da plataforma.
Use a última sessão externa do pedido (ignorando o retorno do próprio checkout) e, ao lado, a primeira visita paga em até 30 dias, nunca uma no lugar da outra.
Cliente com 2 ou mais pedidos pagos, sem limite de tempo; pedidos expirados e pendentes não contam.