Instrumentar a loja do view_item ao refund e conciliar com o financeiro

Com os públicos montados, a loja da Verde Vivo ainda entrega ao GA4 um purchase que nem sempre corresponde a dinheiro no caixa. O checkout da Shopify dispara o evento na página de obrigado, mas 22 por cento dos pedidos são pagos por Pix ou boleto depois que a sessão terminou, e uma parte deles nunca é paga.

O custo de medir a loja pela metade aparece na reunião de resultado. O financeiro fala de uma receita, a Shopify de outra e o GA4 de uma terceira. Sem saber qual diferença é esperada e qual é defeito, ninguém confia no relatório, e a decisão de mídia volta a ser tomada por intuição.

A referência de eventos de e-commerce do GA4 resolve a primeira parte: cada etapa da compra tem um evento com nome e parâmetros publicados, estável desde 2024. A segunda parte, conciliar três números que nunca serão iguais, é método, e a Verde Vivo o aplicou sobre 1.650 pedidos por mês com ticket médio de R$ 215.

Um plano de mensuração da loja começa pelas perguntas comerciais e só depois escolhe eventos. Qual lista de produtos gera clique? Em que etapa do checkout a pessoa desiste? Qual produto volta como estorno? Cada pergunta exige um evento num ponto do caminho, e a referência oficial cobre da vitrine ao estorno com treze eventos recomendados.

A descoberta usa três deles. view_item_list registra que uma lista apareceu na tela: a categoria de vasos de cerâmica, o resultado da busca interna, a vitrine de recomendados. select_item registra o clique num item dessa lista, e view_item, a página do produto aberta. A comparação entre os três diz qual lista transforma exposição em visita ao produto.

Carrinho é intenção declarada. add_to_cart, remove_from_cart e add_to_wishlist carregam o mesmo array items, e o GA4 soma quantidade e preço sem que o site calcule nada. Um remove_from_cart concentrado logo depois do add_to_cart costuma apontar frete revelado tarde demais, e foi a primeira coisa que Marina olhou na Verde Vivo.

Checkout tem três etapas com nome: begin_checkout quando a pessoa entra, add_shipping_info quando escolhe a entrega e add_payment_info quando escolhe como pagar. É nesta última etapa que Pix, boleto e cartão se separam, antes de qualquer compra, e é dela que sai a taxa de abandono por forma de pagamento.

purchase é o evento que vira receita nos relatórios, e transaction_id é obrigatório nele. Esse parâmetro carrega o número do pedido, a chave que liga o evento ao registro da Shopify e à linha do financeiro. value traz o total e currency a moeda, BRL no caso da Verde Vivo; sem os dois, o relatório de receita fica vazio ou mistura moedas.

refund espelha o purchase. Ele leva o mesmo transaction_id e, quando a devolução é parcial, o array items com o que voltou. Loja que nunca envia refund exibe uma receita que só cresce, e a análise de produto passa a recomendar o item mais devolvido como se fosse o mais vendido.

O array items é o coração de todos esses eventos, e ele tem estrutura fixa. item_id e item_name identificam o produto; price e quantity dão o valor; item_category até item_category5 permitem cinco níveis de categoria, como jardim, vasos, cerâmica, médio e esmaltado; item_brand e item_variant separam marca e variação, como cor ou tamanho. Promoções entram por view_promotion e select_promotion, com promotion_id, promotion_name, creative_name e creative_slot.

Pagamento brasileiro quebra a premissa do evento purchase: a página de obrigado aparece antes de o dinheiro existir. No Pix, a confirmação chega em minutos, muitas vezes com a aba já fechada. No boleto, chega dias depois, ou nunca. Um purchase disparado na página de obrigado é, nesses casos, um pedido pendente com nome de venda.

Há duas escolhas honestas, e a Verde Vivo precisou fazer uma. Disparar purchase na página de obrigado, com a forma de pagamento como parâmetro, e aceitar que uma fatia é pedido pendente. Ou disparar purchase só na confirmação, enviado pelo servidor, e aceitar que a sessão de origem já acabou quando o evento chega. O capítulo 31 monta o segundo caminho; este capítulo mede o primeiro.

Compra duplicada é o efeito colateral do pagamento lento. A pessoa gera o boleto, desiste, volta e paga com cartão: a Shopify tem dois pedidos e o financeiro, um pagamento. Como cada pedido tem o próprio transaction_id, o GA4 conta dois purchase, e só o refund do pedido cancelado, ou um filtro pelo status do pedido na exportação, devolve a contagem certa.

Conciliação é comparar três fontes sabendo por que elas diferem. O GA4 perde quem negou consentimento, quem usa bloqueador e quem comprou pelo telefone ou na loja física. A Shopify conta pedidos, pagos ou não. O financeiro conta dinheiro recebido, na data em que entrou, com estorno descontado. Nenhuma das três está errada; cada uma responde a uma pergunta.

A exportação para o BigQuery ajuda na conciliação por um motivo publicado pelo Google: os dados brutos não passam por modelagem, não agregam em (other) e não amostram, então a lista de transaction_id do GA4 sai inteira para casar com a Shopify. A interface, ao contrário, pode incluir compras modeladas quando a identidade de relatório é Blended, e esse número não existe pedido a pedido.

Armadilha comum: disparar purchase sem transaction_id, ou com um número gerado na hora em vez do número do pedido. Cada recarga da página de obrigado, cada volta pelo botão do navegador e cada clique no e-mail de confirmação cria uma venda nova no relatório. A loja conclui que a taxa de conversão é 2,6 por cento quando é 1,9, e aumenta o orçamento de uma campanha que não sustenta o aumento.

Na Verde Vivo, Caio reescreveu a tag de purchase da Shopify para enviar o número do pedido como transaction_id, a forma de pagamento como parâmetro e o array items com item_category até o terceiro nível. Marina montou uma consulta no BigQuery que lista todos os transaction_id do mês e uma exportação da Shopify com número, status e data de pagamento.

O mês de teste fechou assim: a Shopify registrou 1.650 pedidos; o GA4 observou 1.310 purchase, porque 21 por cento das sessões negaram o consentimento e uma parte pequena usou bloqueador; 363 dos pedidos, os 22 por cento pagos por Pix ou boleto, receberam confirmação depois da sessão; 96 boletos venceram sem pagamento e 31 pedidos voltaram como estorno. O financeiro fechou com 1.523 pedidos pagos.

O que mudou foi a natureza da diferença. Antes, 340 pedidos de distância entre GA4 e Shopify pareciam defeito da tag. Depois, a diferença ficou escrita no plano com as causas nomeadas, e a taxa de conversão do e-commerce passou a ser lida como 1,9 por cento sobre sessões com consentimento, com a ressalva de que o pedido pendente entra como venda até o boleto vencer.

Exporte hoje os pedidos do último mês da sua plataforma e compare com os transaction_id do GA4, pedido a pedido. Se a diferença passar de 30 por cento das linhas sem causa escrita ao lado, a tag de purchase está quebrada, e nenhuma análise de produto vale antes do conserto. O próximo capítulo sai da loja e vai para o orçamento de R$ 42.000 que não tem página de obrigado.

Antes de conciliar pedido a pedido, a Verde Vivo precisou provar que cada evento de compra chega ao GA4 com o array items completo. Caio montou os eventos no Gerenciador de tags a partir da camada de dados da Shopify e só publicou depois de ver um pedido de teste inteiro no DebugView, com item_id, price e quantity em cada item.