Preparado por
Altavance Media
Para
Altavance Media
Ouvi os seus áudios e cruzei os quatro prints que você mandou com o que eu já tinha lido no código da loja. A conclusão é objetiva: o problema não é configuração, é propriedade. O rastreamento da Kati Store roda inteiro dentro da integração nativa da VNDA — uma caixa fechada que você não abre, não audita e não conserta. Ela errou pra cima em junho, errou pra baixo em agosto, e nos dois casos a sua única saída foi abrir chamado e esperar.
Não precisei estimar nada. Você mandou o painel da VNDA e o Gerenciador lado a lado, nas mesmas datas. Três pares, e cada um conta uma parte da história.
Painel VNDA: 17 pedidos · R$ 7.025,91
Gerenciador: 20 compras · R$ 8.732,02
Meta reportou +17,6% em pedidos e +24,3% em receita que não existiram. ROAS
apareceu como 9,98 quando o real era 8,03.
Painel VNDA: 25 pedidos · R$ 10.566,20
Gerenciador: 14 compras · R$ 5.240,94
Sumiram 11 pedidos e R$ 5.325 num único dia. ROAS apareceu como 5,05 quando
o real era 10,18 — exatamente o dobro.
Painel VNDA: 91 pedidos · R$ 38.549,13
Gerenciador: 44 compras · R$ 18.412,24
R$ 20.136 de receita não chegaram no Meta em seis dias. ROAS apareceu como 3,36
quando o real era 7,03.
Você me falou do PurchasePix no áudio e eu fui atrás. Está tudo na documentação
oficial da própria Olist, publicada e atualizada em junho deste ano. Não é teoria minha: é o
comportamento declarado da integração que você usa.
Leia a primeira linha de novo: o Purchase dispara no clique do
botão, não no pagamento. Ou seja, todo pedido em PIX ou boleto que a cliente
gerou e nunca pagou entrou no Meta como venda. E num pedido PIX o
PurchasePix dispara junto, no mesmo instante. São dois eventos de compra
pra uma compra só. É exatamente a duplicação que você viu em junho, e é
comportamento documentado, não bug.
O único evento que representa pagamento de verdade é o OrderPaid —
e ele é personalizado. Isso tem uma consequência que talvez você não tenha
notado: evento personalizado não serve pra otimizar campanha por compra e não roda
catálogo/Advantage+. Mesmo no mês em que "estava funcionando", a sua venda paga nunca
treinou o algoritmo. Ela só aparecia no relatório.
E é por isso que sumiu agora. A configuração do seu checkout está com
facebookPixelPurchaseConfig em pix: false e
slip: false. Foi essa a chave que mexeram no fim de julho pra parar a
duplicação. Só que ela não desligou o evento duplicado: desligou a compra em PIX e
boleto inteira. E você dá 5% de desconto no PIX. Some com a fatia do PIX e chega
perto dos 52% que os seus próprios prints mostram.
pix: false e slip: false eu li direto da configuração pública do seu
checkout, então também são fato. A ligação entre uma coisa e outra é a minha hipótese,
e é ela que eu confirmo ou descarto no primeiro dia, com acesso ao seu Gerenciador, antes de
você pagar o restante.
O prejuízo não é o relatório errado. É o algoritmo aprendendo a coisa errada com ele, todo dia, com R$ 30 mil por mês em cima.
1. A otimização treina com metade da amostra. O Meta escolhe pra quem mostrar seu anúncio a partir de quem ele viu comprando. Com 44 compras em vez de 91, ele está construindo o perfil da sua cliente com metade da informação — e a metade que sumiu não é aleatória, é a que passa por um meio de pagamento específico.
2. Você está desligando campanha boa. Com ROAS aparecendo como 3,36 quando o real é 7,03, campanha lucrativa parece medíocre. Toda decisão de pausar, escalar ou cortar orçamento nos últimos dias foi tomada em cima de um número que vale metade do que deveria.
3. Em junho o erro foi o oposto e igualmente caro. ROAS inflado faz você escalar campanha que não sustenta, e faz o algoritmo perseguir um público que não converte na proporção que ele acha que converte.
4. O custo do desgaste. Você passou um mês inteiro em chamado com o suporte pra depois o problema voltar invertido. Esse tempo tem preço, e ele não aparece em nenhum relatório.
A ideia central: parar de perguntar pro navegador se houve venda, e passar a perguntar pro seu ERP. O número que o Meta recebe passa a ser o mesmo número que você vê no painel da VNDA.
Esse é o passo que não dá pra pular. Enquanto os quatro eventos da Olist continuarem saindo, qualquer coisa que eu mandar vira um quinto evento concorrendo com eles. Primeiro desligamos a nativa (ou isolamos num dataset novo), depois eu ligo o meu.
No lugar dos quatro entra um Purchase, disparado pelo webhook
order-confirmed da Olist, que roda quando a transação financeira é aprovada.
Pedido gerado e não pago para de contar como venda.
O payload traz o campo code, único por pedido. Ele vira a chave do evento: se
chegar duas vezes, o Meta junta e conta uma. Duplicação vira impossível por construção,
não por sorte.
Como é o Purchase padrão e não um evento personalizado, ele passa a servir
pra otimizar campanha por compra e pra rodar catálogo/Advantage+. É o que o
OrderPaid nunca pôde fazer.
A primeira estanca o sangramento. A segunda estanca e ainda destrava o que a conta nunca teve — e é a que faz sentido pra quem já coloca R$ 30 mil por mês na mesa.
7 dias úteis · servidor incluído na mensalidade
tag.katistore.com.br — em servidor nossoorder-confirmed, com o code do pedido como chave de deduplicação — o número do Meta passa a ser o número do seu painel12 dias úteis · inclui tudo da Opção 01 · servidor incluído
| Item | Hoje (nativo VNDA) | Opção 01 | Opção 02 |
|---|---|---|---|
| Purchase bate com o painel da VNDA | 44 de 91 | ✓ | ✓ |
| Quantos eventos de compra por venda | até 4 concorrendo | 1 | 1 |
| Compra dispara no pagamento, não no clique | no clique | ✓ | ✓ |
| Evento serve pra otimizar campanha | personalizado | ✓ | ✓ |
Dedup pelo code do pedido |
— | ✓ | ✓ |
| PIX e boleto disparando compra | desligado | ✓ | ✓ |
| Container e log sob seu controle | caixa fechada | ✓ | ✓ |
| Resistente a iOS / ITP / bloqueador | — | ✓ | ✓ |
| Advanced Matching (EMQ) | — | ✓ | ✓ |
| GA4 de e-commerce | só tag base | ✓ | ✓ |
| Alerta diário se o número descolar | — | — | ✓ |
| Catálogo + Advantage+ / anúncio dinâmico | — | — | ✓ |
| Google Ads + Enhanced Conversions | — | — | ✓ |
| Painel de funil próprio, acessível por link | — | — | ✓ |
A referência de mercado pra hospedar GTM Server é o Stape. É uma boa ferramenta e a comparação vai ser justa — o ponto é entender o que ele é: hospedagem. Implementação, manutenção e alguém olhando continuam sendo problema seu.
| Item | Por conta própria, com Stape | Com a Altavance |
|---|---|---|
| Hospedagem do GTM Server | Plano Pro US$ 20/mês (~R$ 120) até 500 mil requests. Com R$ 30 mil/mês de mídia e três destinos server-side esse teto estoura rápido — aí vira Business, US$ 100/mês (~R$ 560) | Incluída na mensalidade. Servidor próprio no Brasil; o preço não muda com o seu tráfego |
| Implementação (GTM web + server, CAPI, dedup, webhook VNDA, GA4, catálogo) | Não incluída. Você configura, ou contrata: o mercado cobra R$ 3.000–7.000 por esse escopo | É o setup da proposta. Entregue testado, com compra real validada no Events Manager |
| Descobrir por que duplicou em junho | Continua com você — foi o que consumiu o seu mês passado | É a primeira etapa do trabalho, antes de instalar qualquer coisa |
| Alerta quando o número descolar de novo | Não existe. Você descobre pelo relatório, semanas depois | Reconciliação diária painel × Gerenciador na Opção 02 |
| Manutenção quando Meta ou VNDA mudam algo | Por sua conta — e os dois mudam com frequência | Incluída. É meu trabalho perceber e corrigir antes de você notar |
| Suporte | Documentação e tickets, em inglês | WhatsApp direto com quem implementou |
Preços do Stape conferidos em stape.io/price em 15/07/2026 (US$ 17/mês no Pro e US$ 83/mês no Business em cobrança anual; US$ 20 e US$ 100 no mensal). Conversão a R$ 5,60 + IOF.
Somando o que a mensalidade já cobre — hospedagem, monitoramento e manutenção — o mesmo sistema montado por fora custa por mês:
Na escala em que você já está, a diferença chega a R$ 10 mil por ano entre manter isso por fora e a mensalidade fixa de R$ 290 — que não sobe quando o seu tráfego sobe. E o R$ 290 inclui alguém olhando, que é exatamente o que faltou nos últimos dois meses.
Por que eu consigo cobrar isso: já mantenho servidor próprio rodando GTM Server pra vários clientes, monitorado todos os dias. O container da Kati entra numa infraestrutura que já está de pé. Não é desconto — é o preço que faz sentido quando a infra já existe.
Sem amarra. Quiser sair, eu exporto o container e ele sobe em qualquer lugar, inclusive no Stape. O GTM é seu, o pixel é seu, a configuração é sua. E eu te mostro como ler tudo — o contrário do que você tem hoje com a integração nativa.
Sem reunião longa. Você me dá os acessos, eu diagnostico, implemento, testo com compra real e te mostro o número batendo.
Acesso ao painel da VNDA e ao Gerenciador do Meta. Aponto o webhook
order-confirmed pra um endereço de teste e leio o JSON real de um pedido
seu — é assim que eu confirmo o que dá e o que não dá pra fazer, sem chute. Te mando
por escrito. Se eu estiver errado, você fica sabendo antes de pagar o restante.
Primeiro tiro os eventos da Olist do caminho (chamado com eles ou dataset novo). Só depois subo o servidor no seu subdomínio, configuro GTM web e server, ligo a API de Conversões e conecto o webhook. Você não precisa fazer nada nessa fase.
Rodo um dia inteiro em paralelo e te mostro painel da VNDA e Gerenciador lado a lado, com o mesmo número. É o critério de aceite: se não bater, não está entregue.
Correção, ajuste e conferência mensal sem custo adicional. Se o Meta ou a VNDA mudarem algo nesse período, o problema é meu — não vira chamado seu.
Vou pedir acesso a cinco lugares, mais o Google Ads se você fechar a Opção 02. Prefiro deixar isso claro agora, na proposta, do que na hora de começar. Some tudo e dá menos de 20 minutos do seu tempo, uma vez só.
É onde eu ativo o webhook de pedido confirmado, aponto o subdomínio de tags e confiro a configuração do pixel que está causando a duplicação. Sem esse acesso não tem projeto.
Preciso do dataset (pixel) e do catálogo pra ligar a API de Conversões, conferir o Event Match Quality e ver o que a integração da VNDA está de fato mandando. Não preciso mexer nas suas campanhas.
Seu container GTM-TCFFG6RS já existe e está praticamente vazio. É nele que entra o rastreamento novo, e é dele que sai o container de servidor. Fica tudo na sua conta, não na minha.
Seu domínio está no registro.br. Preciso de um único registro apontando tag.katistore.com.br pro servidor. Se preferir, eu te mando o valor pronto e você mesmo cola. Não mexo em mais nada.
Sua propriedade G-QX2SCTYHN8 só tem a tag base hoje. Com acesso de editor eu ligo o e-commerce de verdade e você passa a ver o funil, não só sessões.
Pra deixar a conversão montada e pronta pra quando você voltar a rodar Google. Se não quiser abrir agora, a gente faz depois sem custo extra dentro dos 90 dias.
Enquanto o número não bate, cada decisão de pausar ou escalar campanha é um chute com aparência de dado. Você já tentou resolver pelo suporte por dois meses. Me chama que a gente resolve por fora em menos de duas semanas — e o critério de aceite é o seu painel e o Gerenciador mostrando o mesmo número.
Falar com o Gustavo →