Rastreamento de conversão na Loja Integrada: server-side onde os recursos são enxutos

A Loja Integrada é uma plataforma brasileira voltada principalmente para lojas pequenas e para quem está começando no e-commerce. Justamente por esse público, ela é enxuta em recursos de integração se comparada a plataformas empresariais — e isso torna o rastreamento server-side um exercício de fazer bastante com pouco. A boa notícia é que os princípios não mudam: mesmo com recursos limitados, dá para capturar a conversão a partir do pedido pago, e não do navegador, e enviar à Meta e ao Google de forma confiável. Este texto mostra como construir essa camada quando a plataforma não te dá muitos ganchos.

O ponto de partida: pixel nativo e suas perdas#

Como toda plataforma de loja, a Loja Integrada permite colar o identificador do pixel da Meta e a tag do Google, e a partir daí dispara os eventos padrão do lado do cliente. O evento de compra acontece no navegador, na página de agradecimento, e aí está o problema de sempre: script bloqueado, aba fechada, restrição de cookie e pagamento que redireciona para gateway externo fazem uma fração das vendas nunca chegar à plataforma de anúncios. Numa loja pequena, onde cada conversão pesa mais na otimização das campanhas, essa perda é ainda mais custosa, porque o algoritmo tem menos dados e cada evento perdido atrasa o aprendizado.

Por isso, mesmo numa operação enxuta, vale capturar a compra a partir de um fato do servidor — o pedido pago. Como a Loja Integrada é fechada, isso se faz por fora, com um serviço próprio, ainda que simples.

Trabalhando com o que a plataforma oferece#

A Loja Integrada expõe uma API para consultar pedidos e, dependendo do plano e da configuração, mecanismos de notificação de pedido. O caminho mais robusto, quando há webhook de pedido disponível, é o mesmo de qualquer SaaS: o webhook avisa que o pedido mudou de status, e o seu serviço reage. Quando o webhook não está disponível ou é limitado, existe uma alternativa mais rústica, porém funcional: consultar a API periodicamente em busca de pedidos novos que atingiram o status de pago desde a última verificação.

Esse padrão de sondagem — o seu serviço pergunta à API a intervalos regulares "quais pedidos foram pagos desde a última vez que perguntei?" — é menos elegante que um webhook, porque introduz atraso e consome chamadas de API, mas é totalmente viável para lojas pequenas com volume moderado. O importante é guardar um marcador da última verificação (o horário ou o último identificador processado) para não reprocessar os mesmos pedidos e para não perder nenhum. Essa marca de progresso é o coração de um coletor por sondagem confiável.

O serviço de conversão, mesmo simples, é uma entidade à parte#

Mesmo numa loja pequena, o serviço que calcula e envia a conversão deve ser uma entidade separada da loja. Ele tem sua própria vida: sobe sozinho, guarda seu marcador de progresso, mantém as credenciais protegidas, e continua funcionando independentemente do que acontece com o tema ou a configuração da loja. Essa separação evita que a mensuração quebre por um motivo alheio a ela, e mantém as credenciais de API e os tokens de conversão longe de qualquer coisa que chegue ao navegador.

As credenciais da API da Loja Integrada e os tokens da Conversions API da Meta e do Measurement Protocol do Google são segredos de servidor. Eles moram no serviço, nunca em código de cliente, tema ou bundle. Essa é uma regra que não afrouxa por a loja ser pequena — um token vazado é um token vazado, do mesmo jeito.

Montando o payload a partir do pedido#

Seja por webhook, seja por sondagem, quando você identifica um pedido pago, busca o pedido completo na API e extrai os blocos de conversão. O valor e a moeda vêm do total; decida se inclui frete e desconto e mantenha a decisão consistente com o financeiro. Os itens vêm das linhas do pedido, cada uma com identificador, quantidade e preço, e o identificador precisa casar com o feed de produtos usado nos anúncios dinâmicos.

Os dados de correspondência vêm do comprador: e-mail, telefone, nome, cidade, estado e CEP. Todos normalizados e hasheados com SHA-256 antes de sair do servidor. E-mail e telefone são os campos de maior peso na qualidade da correspondência. Numa loja pequena, onde o volume de conversões é baixo, capricho nos dados de correspondência importa ainda mais, porque cada conversão bem atribuída conta muito no aprendizado da campanha. Enviar o máximo de campos válidos é o que eleva a fração de vendas que a plataforma consegue creditar aos anúncios.

O parâmetro de clique: capturando cedo#

O fbclid e o gclid chegam na URL quando o comprador entra vindo de um anúncio, mas quem os vê é o navegador, não o seu serviço. Para levá-los até a conversão, capture-os no cliente assim que o visitante entra e persista-os num cookie de primeira parte. O desafio na Loja Integrada é amarrar esse valor ao pedido, dado que a plataforma oferece pouca customização. Uma via é enviar o parâmetro de clique a um endpoint seu no momento do checkout, associado a um identificador que você consiga recuperar depois (o e-mail do comprador ou o identificador do pedido, quando disponível). Recupere-o quando processar o pedido pago. Se a amarração precisa for difícil, ao menos o e-mail hasheado e os demais dados de correspondência sustentam boa parte da atribuição, mesmo sem o parâmetro de clique.

Deduplicação com o pixel nativo#

Se o pixel nativo continua disparando a compra no navegador enquanto você envia server-side, é preciso deduplicar. A regra é a de sempre: os dois lados enviam o mesmo identificador de evento, e o identificador do pedido é o candidato ideal. Se o pixel nativo da Loja Integrada não permite controlar o event_id, a saída mais limpa é desligar o evento de compra do pixel e deixar o server-side como fonte única da conversão, mantendo o pixel apenas para eventos de topo de funil. Numa loja pequena, ter uma única fonte clara da conversão costuma ser mais simples de manter do que orquestrar a deduplicação entre dois lados.

Idempotência e confiabilidade num coletor por sondagem#

Quando a captura é por sondagem, a idempotência é ainda mais importante, porque a mesma consulta pode trazer um pedido que já foi processado se o marcador de progresso não for bem cuidado. Guarde quais pedidos já viraram conversão enviada e nunca reenvie o mesmo. Além disso, se a API de anúncios falhar na hora do envio, não descarte o pedido — deixe-o pendente para retentar na próxima passada. Assim, uma indisponibilidade momentânea da Meta ou do Google não faz você perder a conversão; ela apenas será enviada na tentativa seguinte. Esse cuidado é o que separa um coletor que você confia de um que perde vendas silenciosamente.

Cancelamentos e reembolsos#

Mesmo numa operação pequena, receita que voltou atrás não deve continuar contada. Ao detectar um pedido cancelado ou estornado — por webhook ou na sondagem —, dispare um evento de reembolso à plataforma de anúncios ou ao menos registre o cancelamento para a reconciliação com o financeiro. Numa loja de baixo volume, um único estorno não tratado distorce percentualmente mais os números do que numa loja grande, então o cuidado compensa.

Sondagem versus webhook: escolhendo o ritmo certo#

Quando a captura é por sondagem, a frequência com que o seu serviço pergunta à API pela lista de pedidos pagos é uma decisão que equilibra frescor e custo. Perguntar a cada poucos minutos deixa a conversão quase em tempo real, mas consome mais chamadas de API e pode esbarrar em limites de taxa da plataforma. Perguntar de hora em hora economiza chamadas, mas atrasa o sinal que a plataforma de anúncios usa para otimizar, e um atraso grande demais prejudica a atribuição, especialmente em janelas de conversão curtas. Para a maioria das lojas pequenas, um intervalo de poucos minutos a um quarto de hora é um bom meio-termo: rápido o suficiente para a otimização e leve o suficiente para não estourar limites. O importante é que o intervalo seja consciente, e não um valor deixado ao acaso. E vale desenhar a sondagem para ser tolerante a atrasos: se uma passada falhar ou o serviço ficar fora por um tempo, a próxima passada deve recuperar todos os pedidos pagos desde o último marcador, sem perder nenhum. É por isso que o marcador de progresso é tão central — ele é a garantia de que a sondagem, mesmo intermitente, cobre todos os pedidos sem buracos nem repetição.

Quando crescer além da sondagem#

A sondagem é o caminho pragmático para começar, mas ela tem um teto. Conforme a loja cresce em volume, o atraso e o custo das chamadas repetidas pesam, e migrar para o webhook — se a plataforma passar a oferecer um mais robusto, ou conforme o plano da loja evoluir — vira a escolha natural. A boa notícia é que a parte mais trabalhosa do serviço não muda com essa migração: a montagem do payload, o hashing dos dados de correspondência, a deduplicação, a idempotência e a fila de retentativa são idênticas, sejam os pedidos descobertos por sondagem ou entregues por webhook. Só o mecanismo de descoberta troca. Desenhar o serviço com essa separação clara desde o início — um coletor que descobre pedidos pagos, e um processador que os transforma em conversões — permite trocar o coletor sem tocar no processador. Assim a loja pequena começa simples, com sondagem, e cresce sem jogar fora o que construiu.

Validando antes de confiar#

Antes de acreditar em qualquer número, teste de ponta a ponta. Faça um pedido de teste, deixe-o chegar ao status de pago, e acompanhe: o webhook disparou ou a sondagem capturou, a busca na API trouxe o pedido, e o evento chegou à plataforma com valor, itens e correspondência corretos, verificados na aba de eventos de teste da Meta e no modo de depuração do GA4. Confirme também que um cancelamento é tratado. Só então ligue em produção.

Fazer bem com pouco#

A Loja Integrada mostra que rastreamento server-side não é privilégio de plataforma cara. Mesmo com recursos enxutos e, às vezes, sem webhook robusto, dá para capturar a conversão a partir do pedido pago usando a API — por notificação quando existe, por sondagem com marcador de progresso quando não existe. Mantenha o serviço de conversão como entidade à parte, guarde os segredos no servidor, monte um payload com correspondência hasheada, capture o parâmetro de clique cedo, unifique o event_id ou eleja o server-side como fonte única, e proteja tudo com idempotência e reprocessamento. O resultado é uma mensuração que reflete a receita real de uma loja pequena — justamente onde cada conversão bem contada mais importa.