Mensuração de conversão na Tray: rastreamento server-side numa plataforma brasileira

A Tray é uma das plataformas de e-commerce mais estabelecidas do Brasil, muito usada por lojas de médio porte que precisam de uma solução hospedada e com suporte local. Como todo SaaS de loja fechada, ela roda o e-commerce por você, e a mensuração aparece primeiro como campos de configuração onde se cola o pixel. Isso resolve o básico, mas herda a fragilidade do rastreamento client-side. Para quem quer conversão que reflita a receita real, o caminho é o mesmo padrão de qualquer plataforma fechada: reagir a eventos de pedido por webhook e API, calculando a conversão fora do navegador. Este texto mostra como montar essa camada server-side sobre a Tray.

O piso client-side e por que ele não basta#

Na configuração da loja, a Tray permite integrar o pixel da Meta e a tag do Google, disparando os eventos padrão do lado do cliente ao longo da navegação: visualização, carrinho, checkout e compra. O evento de compra é acionado no navegador, na página de confirmação, e por isso sofre de todas as perdas conhecidas: script bloqueado, aba fechada antes do carregamento, restrição de cookie no navegador, e pagamento que redireciona para um gateway externo e não traz o comprador de volta. Cada uma dessas situações é uma venda real que não chegou à plataforma de anúncios. O rastreamento nativo serve como ponto de partida, mas subestima a receita e alimenta os algoritmos de campanha com dados incompletos.

A correção é capturar a conversão a partir do pedido pago registrado no back-end da Tray, e não do carregamento de uma página. Como a Tray é fechada, isso se faz por fora, com um serviço próprio que escuta a loja.

O serviço de conversão como entidade à parte#

O modelo mental correto é o de uma plataforma fechada: você não roda código dentro da Tray, você mantém um serviço separado que se comunica com ela. Esse serviço tem endereço próprio, sobe e funciona sozinho, e depende da Tray apenas para dois canais — os webhooks, que avisam quando algo acontece, e a API, que fornece os detalhes. Essa independência é uma virtude: o seu serviço de mensuração não quebra quando a loja muda de tema, não some numa atualização da plataforma, e pode inclusive atender várias lojas Tray de uma vez se você administra um portfólio.

Webhooks de pedido: o gatilho da conversão#

A Tray oferece webhooks para eventos de pedido, e os que importam para conversão são os que representam dinheiro garantido. A criação do pedido marca a intenção, mas ainda não o pagamento. A mudança de status para pago — ou o status equivalente que a sua loja usa para pagamento aprovado — é o momento da conversão para a maioria dos negócios. Cancelamentos e estornos servem para não contar receita que voltou atrás.

Quando o webhook de pagamento chega, ele geralmente traz o identificador do pedido e o novo status, não o pedido inteiro. O fluxo correto é usar o webhook como gatilho e, em seguida, chamar a API da Tray para buscar o pedido completo pelo identificador, obtendo valor, itens e dados do comprador. Nunca monte a conversão só com o que o webhook trouxe; a fonte da verdade é a API.

Autenticidade e credenciais#

Um endpoint que recebe webhook é público, e é preciso verificar que a notificação veio mesmo da Tray, e não de alguém que forjou um POST para inflar suas conversões. Verifique a autenticidade conforme o mecanismo que a plataforma oferece antes de processar. E as credenciais de acesso à API da Tray são segredo de servidor: moram no seu serviço, protegidas, nunca em código de cliente, tema ou bundle de navegador. Elas são usadas apenas na comunicação servidor-a-servidor.

Montando o payload#

Com o pedido completo em mãos, você extrai os blocos que a Conversions API da Meta e o Measurement Protocol do GA4 esperam. O valor e a moeda vêm do total; decida se inclui frete e desconto, e mantenha a decisão consistente com o que o financeiro reconhece como receita, porque valores diferentes entre anúncio e contabilidade são a fonte mais comum de divergência inexplicável na reconciliação.

Os itens vêm das linhas do pedido, cada uma com identificador, quantidade e preço. O identificador precisa casar com o feed de produtos usado nos anúncios dinâmicos, então confirme qual campo da Tray corresponde ao que o seu feed exporta.

Os dados de correspondência vêm do comprador: e-mail, telefone, nome, cidade, estado, CEP e país. Todos normalizados — minúsculas, sem espaços, telefone só com dígitos e código do país — 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, e quanto mais campos válidos você enviar, maior a fração de conversões que a plataforma consegue atribuir aos anúncios.

O parâmetro de clique numa loja fechada#

O desafio recorrente do server-side é levar o fbclid e o gclid da entrada do visitante até a conversão calculada no servidor. Na Tray, como em qualquer SaaS fechado, a abordagem é capturar o parâmetro de clique no navegador assim que o comprador entra vindo de um anúncio, gravá-lo num cookie de primeira parte, e associá-lo ao pedido de forma que o seu serviço consiga recuperá-lo quando o webhook disparar. Uma via prática é enviar esse valor a um endpoint seu no momento do checkout, indexado pelo identificador do carrinho ou do cliente, e recuperá-lo depois pelo pedido. O user agent do comprador também deve ser capturado no cliente, porque no envio server-side o IP visível é o do seu serviço, não o do comprador.

Deduplicação com o pixel nativo#

Se você mantém o pixel nativo da Tray disparando a compra no navegador e também envia server-side, é obrigatório deduplicar, senão a mesma venda conta duas vezes. A regra universal: os dois lados enviam o mesmo identificador de evento. O identificador do pedido da Tray é o candidato natural, por ser único e o mesmo dos dois lados. Se o pixel nativo não deixa você controlar o event_id, a decisão mais limpa é desligar o evento de compra do pixel e deixar o server-side como fonte única, mantendo o pixel só para os eventos de topo de funil, como visualização e carrinho.

Idempotência e entrega confiável#

Webhooks podem chegar duplicados, fora de ordem, ou ser reenviados quando a Tray não recebe confirmação. Três defesas mantêm a integridade. A idempotência por identificador de pedido — guardar quais pedidos já viraram conversão e ignorar repetições — impede o double counting. A fila com retentativa garante que, se a API da Meta ou do Google estiver instável, o evento fica pendente e é retentado com espera crescente, em vez de se perder. E a confirmação rápida do webhook — responder sucesso assim que gravar o evento na fila, sem esperar o envio à plataforma terminar — evita que a Tray considere falha e reenvie, multiplicando o trabalho. Esse desacoplamento entre receber o webhook e entregar à API é o que torna o rastreamento confiável em vez de "quase sempre" funcional.

Cancelamentos e reembolsos#

A receita que voltou atrás não pode continuar contada como conversão viva. Escute os webhooks de cancelamento e estorno da Tray e dispare um evento de reembolso para a plataforma de anúncios, ou pelo menos registre o cancelamento para que a reconciliação com o financeiro não acuse divergência sem explicação. Ignorar esse caminho faz a conversão medida inflar em relação à receita reconhecida, e mais cedo ou mais tarde alguém vai cobrar a diferença.

Consentimento e a base legal do envio#

Rastrear no servidor não isenta a operação de respeitar a privacidade do comprador. Os dados que alimentam a conversão — e-mail, telefone, parâmetro de clique — são pessoais, e enviá-los à plataforma de anúncios exige base legal e respeito à escolha do usuário. Na Tray, como em qualquer loja, isso significa que o consentimento coletado precisa chegar até o seu serviço de mensuração, para que ele decida se envia os dados de correspondência ou não. O server-side, por acontecer longe da vista do comprador, demanda ainda mais rigor: como o usuário não vê o que se passa no seu serviço, cabe a você garantir que o processamento honra a escolha dele. Passar o estado de consentimento adiante, associado ao pedido, e condicionar o envio dos dados a esse estado é a forma correta de manter precisão para quem consentiu sem atropelar quem recusou. Tratar consentimento como parte do desenho, e não como um adendo, evita que a mensuração vire um passivo de conformidade.

Monitorando a saúde da mensuração#

Uma vez em produção, o serviço de conversão precisa ser observável, senão você só descobre que ele parou quando os números despencam sem explicação. Registre, para cada evento, se ele foi enviado com sucesso, quantas tentativas foram necessárias, e qual a qualidade de correspondência que a plataforma reportou. Acompanhe a fila de pendentes: se ela cresce, é sinal de que a API de anúncios está instável ou de que o worker parou. Compare, periodicamente, o número de pedidos pagos na Tray com o número de conversões enviadas — os dois devem andar juntos, e uma divergência crescente denuncia um problema no fluxo. Esse monitoramento transforma a mensuração de uma caixa-preta em algo que você confia porque enxerga funcionando, e é o que permite pegar uma falha em horas em vez de descobri-la semanas depois, quando o estrago na otimização de campanha já foi feito.

Validando antes de confiar#

Antes de acreditar nos números, teste de ponta a ponta num ambiente controlado. Faça um pedido de teste, acompanhe a chegada do webhook, confirme que a busca na API trouxe o pedido completo, e use a aba de eventos de teste da Meta e o modo de depuração do GA4 para ver o evento chegar com valor, itens e correspondência corretos. Teste também os caminhos de cancelamento e reembolso. Só depois de o fluxo estar limpo você liga em produção e passa a confiar na contagem.

O caminho na Tray#

Numa plataforma brasileira e fechada como a Tray, o server-side é um serviço à parte que escuta a loja. Registre o webhook de pagamento como gatilho, verifique a autenticidade, busque o pedido completo na API, monte um payload com valor, itens e correspondência hasheada, resolva o parâmetro de clique com captura no cliente amarrada ao pedido, unifique o event_id para deduplicar, e proteja tudo com idempotência, fila de retentativa e tratamento de estorno. O resultado é uma mensuração que reflete a receita paga de verdade, resiste a falhas de rede e sobrevive à auditoria financeira — o mesmo padrão de engenharia que vale para qualquer SaaS, aplicado à realidade da Tray.