🚨 alerta máximo: a estrutura de tracking da loja integrada está prejudicando vendas, roas, performance e escala – vamos nos unir aqui!

[fernando_alkimim]

Pessoal, estou criando este tópico porque o problema é sério, estrutural, afeta TODOS que fazem tráfego, e ninguém está falando disso com a força necessária.

Sou profissional de tráfego pago avançado (Meta Ads, GA4, GTM Web + Server e Stape) e venho expor um erro gravíssimo da Loja Integrada que está destruindo dados, distorcendo ROAS e prejudicando o crescimento das lojas.

E preciso que todos aqui que passam por isso se manifestem, porque só uma mobilização coletiva vai forçar a plataforma a agir.

1 — O MAIOR PROBLEMA: PURCHASE DISPARADO NO MOMENTO ERRADO (“pedido criado”)

A Loja Integrada dispara o evento PURCHASE no DataLayer antes do pagamento ser confirmado.

Sim: o “pedido criado” vira “compra”, e isso vai direto para:

• Meta Ads

• GA4

• GTM

• Relatórios

• Otimização

• ROAS

• Funis

• Algoritmos de entrega

Isso gera:

Vendas falsas

ROAS mentiroso

Pixel contaminado

Métricas quebradas

Otimização completamente errada

Campanhas que param de entregar

Eventos duplicados em CAPI

Ads gastando dinheiro no público errado

Isso não é um detalhe.

É um erro estrutural que compromete o negócio inteiro.

E pior: É uma prática tecnicamente errada segundo Google, Meta e GTM Server.

2 — NÃO EXISTE NENHUMA FERRAMENTA PARA TRACKING SÊNIOR (NENHUMA!)

A plataforma NÃO oferece:

• webhook de “pedido pago”

• endpoint configurável

• API de status real-time

• campo exposto no checkout

• acesso a user_data

• integração nativa com CAPI server-side

• suporte ao modelo moderno de tracking

Ou seja:

Quem usa tracking profissional hoje fica completamente bloqueado.

Quem investe pesado em tráfego perde dinheiro.

Quem tenta escalar sai prejudicado.

E isso NÃO é culpa do anunciante.

É limitação da plataforma.

3 — CHECKOUT FECHADO EM IFRAME = SEM DADOS DO CLIENTE

O checkout da LI é totalmente fechado dentro de iFrame.

Isso impede a leitura de:

• email

• telefone

• nome

• endereço

• CEP

• cidade

Sem isso, Meta Ads classifica os eventos como:

Baixa qualidade (~6/10)

→ Algoritmo perde força

→ Custo sobe

→ Conversão cai

→ Escala se torna impossível

Se você trabalha com tráfego, sabe exatamente o impacto disso.

4 — A INTEGRAÇÃO META/PÍXEL É ULTRAPASSADA

A integração nativa:

• não suporta CAPI real

• não aceita deduplicação

• não usa event_id

• não envia user_data

• não permite server-side de verdade

• não acompanha as atualizações técnicas de anúncios

Resultado:

Quem tenta trabalhar profissionalmente com a plataforma acaba limitado.

5 — CONSEQUÊNCIAS REALMENTE GRAVES PARA NÓS, VENDEDORES

Esse conjunto de falhas gera:

ROAS totalmente falso

Funil distorcido

Pixel desajustado

Métricas quebradas

Algoritmo desnorteado

Perda de faturamento real

Dificuldade de escalar campanhas

CAPI incompleto

Perda constante de dinheiro com anúncios

Confusão nos relatórios

Impossibilidade de operar como profissional

NÃO É UM DETALHE.

É algo que impacta todas as vendas, todos os anúncios, todas as campanhas.

ESTA PUBLICAÇÃO É UM CHAMADO

Se você também:

• sofre com ROAS distorcido,

• vê Purchase duplicado,

• percebe inconsistência nos relatórios,

• não consegue fazer CAPI avançada,

• sente que a plataforma limita você…

Comenta aqui!

Se manifeste!

Compartilhe sua experiência!

A plataforma precisa ver que o problema é coletivo.

Quanto mais gente comentar, mais força teremos para exigir:

• correção do Purchase

• criação de webhook

• melhoria no checkout

• abertura de dados

• integração moderna com Meta Ads

• tracking profissional de verdade

Vamos unir forças.

Tracking não é opcional — é ESSENCIAL para qualquer negócio que depende de anúncios.

Estamos juntos.

Comenta aqui embaixo se você também é prejudicado por isso.

[Bella_Casa]

Vamos nos unir comunidade, o que ele esta relatando é real, afeta todos, até você que não tem conhecimento e tenta usar o google shopping ou tiktok nativo.

[fernando_alkimim]

Eu criei a sugestão no painel da loja integrada , vamos ver se eles aprova , pra gerarmos votação e eles resolver isso !

[Bella_Casa]

Mais um silenciado, provavelmente teria algum reclamação também.

[Groomb]

O tópico ficou excelente e bem detalhado, realmente a Loja Integrada tem várias questões quem cabem melhorias.

Mas também é importante ressaltar que várias pontuações feitas não cabem a uma plataforma SMB, são pontos que você só vai conseguir em uma plataforma aberta, e desenvolvendo você mesmo de acordo com sua demanda.

Já outros pontos são possíveis via personalização de código, até porque são pontos opcionais de formas diferentes de leitura de actions e métricas.

Em relação ao webhook, eu acredito que eles lançaram há algum tempo um webhook de pedidos, você já deu uma nova checada? Realmente era um ponto bem importante que faltava.

@Bella_Casa Não é a LI que está silenciando, é o Discourse IA, é um bot que automaticamente silencia as postagens que quebram as regras da comunidade, quando possuem xingamentos, dados pessoais, citam outras plataformas entre outras regras.

[Bella_Casa]

O que estamos reclamando aqui cabe a LI sim, enviar o disparo no momento correto é de suma importância e cabe a ela fazer isso.
Vemos aqui um conflito de interesses, vocês vendem produtos dentro da LI e claro vão vir defender eles.
Mas é só fazer um teste e ver que o disparo é feito no clique e não na pagina de obrigado, sobre o webhook de pedidos tem sim, mas não da para fazer muita coisa, pois muitos dados ela não envia no webhook, mas esta muito desatualizado a questão da API, mas essa é uma outra questão, o que reclamamos aqui é o básico que deveriam fazer.

[fernando_alkimim]

Pessoal, obrigado pelas contribuições.

Só reforçando tecnicamente, para que o debate fique claro e 100% baseado nas documentações oficiais:

Purchase disparado em “pedido criado”

Segundo Meta (CAPI) e Google (GA4), o evento de compra deve representar uma venda real.

Disparar Purchase no clique, antes da aprovação do pagamento, quebra deduplicação, distorce receita e inflaciona ROAS.

Isso não é avançado — é o básico do tracking moderno.

Webhook/Endpoint de pedido pago

Não existe hoje, de forma documentada e funcional, um webhook capaz de enviar:

• status pago

• dados completos do cliente

• valores reais

• conteúdo do carrinho

Sem isso, nenhum lojista consegue operar CAPI + GA4 Server corretamente.

Dados para user_data (EMQ)

Meta exige email, telefone, cidade, estado e CEP para correspondência adequada.

Atualmente, esses dados não são expostos de forma oficial nem acessível pelo GTM Web, prejudicando campanhas de todos que utilizam mídia paga profissional.

Não é questão de ser “plataforma SMB”

É uma questão de entregar o mínimo padrão de rastreamento compatível com Meta e GA4 — algo que qualquer plataforma atual oferece.

Estamos reunindo lojistas justamente porque isso afeta TODA a base que usa tráfego pago.

Se a LI deseja competir no mercado atual, precisa corrigir o PURCHASE e disponibilizar um evento oficial de pedido pago.

Seguimos no aguardo da manifestação técnica da plataforma.

[Bella_Casa]

@lojaintegrada O que vocês deveriam verificar é isso aqui.

[Groomb]

Oi @Bella_Casa , não estamos defendendo e nem há conflito de interesses, pelo contrário, a LI melhorar em tudo que for possível só é melhor pra gente, por isso estamos desse lado também.

Quanto a minha postagem, foi apenas para elucidar algumas questões, tanto das mensagens ocultadas, como da parte técnica.

Em relação ao webhook em especifico, que algo que usamos bastante nos nossos desenvolvimentos, ele envia tudo isso que citou, acho que cabe dar uma olhadinha melhor nele e em suas possibilidades.

Não vamos entrar em detalhes técnicos, porque não é a questão da minha resposta, mas é sempre bom concentrar nas questões mais urgentes e possíveis. Como já possuimos muitos anos de trabalho em diversas plataformas como devs e parceiros, fiz apenas essa observação, de que várias das reinvidicações não cabem a uma plataforma SBM, e várias são melhorias válidas. Mas obviamente, isso cabe a plataforma avaliar.

Também sigo acompanhando e torcendo para que consigam exito nas reinvidicações, sempre pela melhoria da plataforma, e por consequencia, dos clientes.

[fernando_alkimim]

Nada do que está sendo solicitado aqui é recurso avançado ou enterprise.

Disparar o Purchase somente quando existe pagamento aprovado é o básico do básico segundo Meta, GA4, GTM Server e qualquer documentação oficial de tracking.

Isso não é uma “demanda de alto nível”, é fundamento operacional.

O problema não é complexidade, é alinhamento com o momento correto do funil.

Quando o Purchase dispara na finalização do pedido (antes do pagamento), o que acontece é:

• conversões sem receita,

• funil quebrado,

• dados contaminados,

• otimização prejudicada.

Isso afeta qualquer operação — grande ou pequena — porque dados errados prejudicam todo mundo.

Não estamos pedindo estrutura aberta, personalização profunda ou código customizado.

Estamos pedindo apenas o evento no momento correto, como indicado pelos manuais oficiais utilizados pelo mercado de tráfego pago.

Dados mínimos de user_data precisam ser expostos de forma segura e documentada.

Sem isso, a correspondência dos eventos fica baixa, e o desempenho da mídia cai.

Isso é um requisito básico das plataformas de anúncios, não um “recurso opcional”.

O objetivo de todos aqui é o mesmo:

Garantir que a mensuração esteja correta, o funil coerente e que a plataforma acompanhe a realidade atual do tráfego digital.

Nenhum ponto levantado aqui foge do escopo de uma plataforma que deseja competir com saúde no mercado atual.

São correções estruturais simples e essenciais para garantir integridade dos dados — não pedidos avançados.

Continuo acompanhando e colaborando para que isso evolua, sempre de forma construtiva.

[alesantos]

A pergunta que fica é, porque ainda não resolveram esse problema? Visto que só abrir os foruns e psotagens, é um problema recorrente há alguns anos já.

Infelizmente acredito que não seremos contemplados com tais ajustes. Uma pena…

[RenatoRea]

A comunidade é silenciada sim de acordo com os critérios da LI, tanto que se colocar o nome de qualquer concorrente aqui não consegue postar porque a LI tem medo dos concorrentes, é do tempo que dava para silenciar e esconder as informações.

E pior, não é a primeira vez que isso ocorre, ao contrário, é esta postura de censurar tópicos ou postagens que afastou praticamente todo mundo daqui, que faz pouco tempo era uma comunidade de muita troca de informações e ajuda mútua e hoje virou um deserto.

[Leonardo_Vicentini_F]

Um dos motivos que me fez praticamente não ficar mais tanto tempo na comunidade é que eu não acho mais a LI uma plataforma seria.. “nunca vamos cobrar comissão!“ tinha isso na página deles, mas a coisa mudou!

Outra coisa, não existe mais uma pessoa dedicada a comunidade para ajudar os lojistas… então eu pergunto, O que eu vou fazer aqui na comunidade? Para mim não faz mais sentido!

[Bella_Casa]

Boa noite, e eles dizem que não dispara antecipadamente!

[alesantos]

minhas campanhas estão no mesmo padrão, ficam perdidas. A inteligencia fica sempre quebrada. Google Merchant não conversa direito com o google ads que não conversa direito com o GA4.

[Bella_Casa]

Bom dia, não é que não conversam, o motivo é justamente esse que estamos relatando.
E eles sabem e é proposital esse modelo, dessa forma prejudicando diversos vendedores.

[Bella_Casa]

Para ter uma ideia do quanto prejudica esse disparo errado, até venda cancelada, marca como venda:

[Bella_Casa]

Boa tarde. Entendo completamente tanto a sua perspectiva, quanto a sua expectativa sobre o funcionamento da integração.
Porém, o comportamento atual do disparo de purchase não é um erro, nem um desvio técnico da plataforma. Ele segue exatamente o modelo definido para todas as lojas da base e está alinhado à documentação oficial das integrações nativas utilizadas como GA4, Meta e demais ferramentas. A plataforma trabalha com duas camadas de dados, e nenhuma delas ignora ou substitui o dataLayer padrão. A camada window.LIgtagDataLayer é utilizada internamente pelas integrações nativas (GA4, Ads, Meta etc.), enquanto window.dataLayer está disponível normalmente para lojistas que utilizam GTM e integrações personalizadas.
Ou seja, não há quebra de padrão e o dataLayer tradicional permanece acessível para qualquer implementação avançada.
​

Em relação ao GA4, o evento purchase é disparado após a conclusão do pedido, e não após o pagamento. Esse é o fluxo recomendado pelo próprio Google para representar a finalização da jornada de compra dentro do site. O Google não exige que o purchase represente apenas pagamentos aprovados, permitindo seu envio na página de confirmação do pedido. Por isso, a interpretação de que o evento estaria sendo enviado “antes da hora” não corresponde a um erro técnico, mas sim à forma como o funil de e-commerce foi projetado oficialmente.
​

Entendemos, também, a sua visão sobre a documentação da Meta. Contudo, o comportamento implementado na LI segue o padrão utilizado pela maior parte das plataformas de e-commerce do mercado, baseando-se no conceito de pedido concluído no checkout.
Alterar esse funcionamento agora, passando a enviar purchase apenas após a liquidação financeira, seria uma mudança estrutural que afetaria toda a base, quebraria comparações históricas e alteraria completamente a semântica de relatórios de e-commerce no GA4 e na própria Meta. Por esse motivo, não é algo que possa ser ajustado individualmente ou via suporte.
​

Quero reforçar que todas as sugestões que você enviou (incluindo disparos diferenciados, novos eventos nativos e ajustes na modelagem do purchase) já foram encaminhadas para os times de Produto e Engenharia.
Não existe, neste momento, previsão de mudança nesse comportamento, pois não se trata de um erro operacional, mas de uma decisão estrutural de produto.

Como relatei, caso qualquer evolução ou nova funcionalidade seja implementada, ela será comunicada pela aba de Novidades do painel, nosso canal oficial para avisos desse tipo.
​

Entendemos completamente sua preocupação com a precisão das métricas e o impacto direto nas campanhas, e estamos aqui para garantir que você tenha clareza sobre como a plataforma opera hoje e quais caminhos estão disponíveis para alcançar os resultados desejados dentro desse modelo.

OBS: é proposital e a desculpa contém diversas contradições.

[fernando_alkimim]

Vamos todos abrir uma reclamação então no RR..

E comentar os post do Instagram deles

precisa ser resolvido isso! Deve se disparar no pedido pago não na intenção (criado)