---
id: agencias/ecommerce-do-cliente
industria: Agências de marketing
uso: específico
esforco: médio
grao: Loja x canal x dia no fuso da loja; pedido para auditoria
---

# E-commerce do cliente

Pedidos pagos, receita líquida, ticket e conversão da loja de cada cliente num fato diário que bate com o painel da loja, com o funil do GA4 ao lado e sem contar Pix vencido como venda.

## Resumo executivo

**Para quem:** Agências que fazem mídia, CRM ou gestão de loja para clientes de e-commerce.

**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.

**Por que importa:** Cliente de e-commerce compara o relatório da agência com o painel da loja na mesma hora. Se a receita inclui Pix vencido ou cai no dia errado por fuso, a discussão deixa de ser sobre mídia e passa a ser sobre o número. É também a base do ROAS real, que divide o investimento pela receita paga e não pela conversão da plataforma.

**Perguntas de negócio que responde**

- Por que a receita caiu esta semana?
- Qual a taxa de conversão do checkout neste mês?
- Quanto foi reembolsado no mês e em quais dias?
- Quanto vendemos no site e quanto em cada marketplace?
- Qual o ticket médio por canal de origem?
- Quantos pedidos ficaram pendentes ou expiraram no Pix e no boleto?

**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

## Detalhado

### O problema

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.

### Regras de negócio

1. **Pedido pago pelo status financeiro.** 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. (Evite: Somar todos os pedidos da loja com valor no carrinho.)
2. **Receita líquida desconta o reembolso real.** 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. (Evite: Usar o total do pedido como receita, com frete, imposto e sem reembolso.)
3. **O dia é o dia da loja.** 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. (Evite: Cortar o dia em UTC e jogar a venda da noite para o dia seguinte.)
4. **Sessão vem do GA4; pedido e receita vêm da loja.** 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. (Evite: Calcular conversão com sessões da loja e pedidos do GA4.)
5. **Taxa se recalcula no período.** 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. (Evite: Média das conversões diárias para o mês.)
6. **Funil por eventos fixos, declarados por cliente.** 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. (Evite: Montar o funil com os eventos que aparecem no relatório, mudando de mês a mês.)
7. **Purchase do GA4 maior que a loja é duplicação.** 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)'. (Evite: Reportar receita do GA4 quando ela passa da receita da loja.)
8. **Relatório do GA4 fica com a última extração.** 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. (Evite: Somar todas as extrações do mesmo dia.)
9. **Mês com buraco de carga não se compara.** 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. (Evite: Comparar um mês com dois dias carregados contra um mês completo.)
10. **Cada marketplace com a sua regra, sem multiplicar pedido.** 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. (Evite: Abrir os itens do pedido no cruzamento e somar o valor do pedido por item.)

### Status do pedido no fato diário

Pelo displayFinancialStatus e pelas marcas do pedido na loja.

- **PAID** → Receita (`cancelledAt IS NULL AND test = false`)
- **PARTIALLY_REFUNDED** → Receita, menos o reembolso (`transactions.kind = REFUND, status = SUCCESS`)
- **REFUNDED** → Reembolso, linha à parte
- **PENDING, AUTHORIZED, PARTIALLY_PAID** → Ainda não é venda, linha à parte
- **EXPIRED, VOIDED** → Pix ou boleto vencido, anulado: fora
- **cancelledAt preenchido** → Cancelado, linha à parte
- **test = true** → Pedido de teste: fora

### Definições

| Métrica | Definição |
|---|---|
| Pedido pago | pedido com displayFinancialStatus PAID ou PARTIALLY_REFUNDED, sem cancelamento e fora de teste, no dia da loja |
| Receita bruta | soma de subtotal + descontos dos pedidos pagos do dia |
| Receita líquida | soma de subtotal - reembolsos dos pedidos pagos do dia, sem frete e sem imposto |
| Reembolso | soma das transações kind = REFUND com status = SUCCESS do pedido |
| CVR | pedidos pagos da loja / sessões do GA4 no período |
| AOV (ticket médio) | receita líquida / pedidos pagos no período |
| RPV | receita líquida / sessões do GA4 no período |
| Taxa da etapa | eventCount da etapa / eventCount da etapa anterior no período |
| Cobertura do GA4 | dias com carga no período / dias do período (ou dias decorridos no mês corrente) |

### Armadilhas

- **Receita de Pix vencido.** Pedidos com Pix ou boleto que venceu sem pagamento continuavam na loja com valor no carrinho e entravam na receita. Como evitar: Filtre pelo status financeiro e mostre os expirados à parte.
- **Venda no dia errado.** 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. Como evitar: Converta para o fuso da loja antes de agrupar por dia.
- **Sessões de robôs.** 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. Como evitar: Sessões só do GA4; pedidos só da loja.
- **Purchase em dobro.** Um cliente com vários contêineres de tag e várias propriedades do GA4 tinha o evento purchase disparando duas vezes. Como evitar: Compare purchase com pedidos pagos e deduplique por transactionId.
- **Alta de milhares de por cento.** 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. Como evitar: Conte os dias carregados e anule o mês com menos de 80%.
- **Pedido multiplicado pelos itens.** 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. Como evitar: Conte itens numa subconsulta por pedido.

### Teste de aceitação

- [ ] 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.

### Context document

```text
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.
```

### Variações

- **ROAS real:** 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.
- **Atribuição pela jornada da loja:** 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 recorrente:** Cliente com 2 ou mais pedidos pagos, sem limite de tempo; pedidos expirados e pendentes não contam.