Rastreamento de conversão no Wix: os limites do SaaS e como contornar com Velo e webhooks

O Wix construiu sua reputação sendo a plataforma mais amigável para quem não é técnico: você monta a loja arrastando blocos, e a mensuração aparece como uma caixinha onde se cola o identificador do pixel. Isso funciona, mas herda todas as limitações do rastreamento client-side, e quem quer conversão precisa que a captura da compra depende do navegador chegar à página final. A boa notícia é que o Wix evoluiu para além do arrasta-e-solta: ele oferece o Velo, um ambiente de código que roda no lado do servidor da plataforma, e um sistema de automações e webhooks que permite reagir a eventos de pedido. Com essas peças, dá para montar um rastreamento server-side confiável mesmo num ambiente fechado. Este texto mostra os limites reais do Wix e o caminho para contorná-los.

O que o Wix entrega sem código#

Na configuração de marketing da loja, o Wix permite colar o identificador do pixel da Meta e a tag do Google, e a partir daí ele dispara os eventos padrão do lado do cliente: visualização de página, visualização de produto, adição ao carrinho, início de checkout e compra. Para uma loja iniciante isso é um começo aceitável. O evento de compra, porém, é disparado no navegador na página de agradecimento, e é aí que mora a fragilidade: bloqueadores de script, abas fechadas cedo, restrições de cookie de navegador e pagamentos que redirecionam para gateways externos fazem uma parte das compras nunca chegar à plataforma de anúncios. A conversão nativa, portanto, subestima a receita real.

Para levar a mensuração além desse piso, é preciso capturar a compra a partir de um fato do servidor — o pedido pago —, e não do carregamento de uma página. É aí que entram o Velo e as automações.

Velo: código do lado do servidor dentro do Wix#

O Velo é a camada de desenvolvimento do Wix. Ele permite escrever código que roda no servidor da plataforma, reagindo a eventos do e-commerce. Um desses eventos é o de pedido pago: o Velo expõe um gancho que dispara quando o status de pagamento de um pedido muda para pago. Esse gancho é o equivalente, dentro do universo fechado do Wix, ao hook de pedido de um WooCommerce.

Quando esse gancho dispara, o seu código Velo recebe o pedido com seus dados. Dali você pode fazer uma chamada HTTP de saída — o Velo permite requisições do servidor para APIs externas — enviando a conversão para a Conversions API da Meta e o Measurement Protocol do Google. Como essa chamada parte do servidor do Wix e não do navegador do comprador, ela não é afetada por bloqueadores nem por o comprador ter fechado a aba. É server-side de verdade, ainda que hospedado dentro da plataforma.

Segredos ficam nos segredos do Velo#

A chamada às APIs de conversão exige tokens de acesso — o token da Conversions API da Meta, a chave do Measurement Protocol do Google. Esses são segredos de servidor e jamais podem aparecer em código de página nem em qualquer parte que chegue ao navegador. O Velo tem um gerenciador de segredos justamente para isso: você guarda o token lá e o recupera apenas no código de servidor, no momento da chamada. Colar o token direto no código exposto ao cliente é o erro que transforma a sua integração numa porta aberta.

Montando o payload a partir do pedido#

Com o pedido em mãos no gancho do Velo, você extrai os blocos de conversão. O valor e a moeda vêm do total do pedido; decida se inclui frete e desconto e mantenha a escolha 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 dos anúncios dinâmicos.

Os dados de correspondência vêm do comprador: e-mail, telefone, nome e endereço com cidade, estado e CEP. Como sempre, tudo normalizado e hasheado com SHA-256 antes de sair do servidor. E-mail e telefone são os campos de maior peso na qualidade da correspondência. Como o gancho roda no servidor, o IP visível é o do Wix, não o do comprador — então o parâmetro de clique e o user agent do comprador precisam ser capturados no lado do cliente e amarrados ao pedido.

O parâmetro de clique num ambiente fechado#

Levar o fbclid e o gclid da entrada do visitante até a conversão calculada no servidor é o ponto mais delicado no Wix, como em qualquer SaaS. A abordagem é capturar o parâmetro de clique no navegador assim que o visitante entra vindo de um anúncio, gravá-lo num armazenamento de primeira parte, e associá-lo ao pedido de forma que o código Velo consiga recuperá-lo. O próprio Velo permite código de página que lê a URL e persiste o valor, e permite gravar informação adicional no pedido ou num registro relacionado, que depois o gancho de servidor consulta. Sem essa ponte, a conversão chega sem o parâmetro de clique, e a plataforma tem muito mais dificuldade de atribuir a venda ao anúncio que a gerou.

Automações e webhooks como alternativa#

Além do Velo, o Wix tem um sistema de automações que reage a eventos de negócio, e permite disparar webhooks para endereços externos quando um pedido é pago. Essa é uma alternativa para quem prefere manter a lógica de conversão fora do Wix, num serviço próprio. O fluxo é: a automação do Wix dispara um webhook para o seu serviço quando o pedido é pago; o seu serviço recebe, verifica a autenticidade, busca detalhes se necessário pela API do Wix, monta o payload e envia à plataforma de anúncios.

A escolha entre Velo e webhook externo é de arquitetura. O Velo mantém tudo dentro do Wix, o que é simples mas amarra a lógica à plataforma. O webhook externo coloca a mensuração num serviço à parte, independente do Wix, que sobe e funciona sozinho — o que é mais robusto e portável, mas exige que você mantenha esse serviço. Para uma loja única, o Velo costuma bastar; para quem administra várias lojas ou quer independência de plataforma, o serviço externo compensa.

Deduplicação com o pixel nativo#

Se você mantém o pixel nativo do Wix disparando a compra no navegador e também envia server-side, precisa deduplicar, senão a mesma venda conta duas vezes. A regra universal vale: os dois lados enviam o mesmo identificador de evento. O identificador do pedido do Wix é o candidato natural, por ser único e o mesmo dos dois lados. O desafio prático é que o pixel nativo do Wix nem sempre deixa você controlar o event_id que ele usa. Quando não deixa, a decisão mais limpa é desligar o evento de compra do pixel nativo e deixar o server-side como fonte única da conversão, mantendo o pixel apenas para os eventos de topo de funil, como visualização de produto e adição ao carrinho.

Idempotência e entrega confiável#

O gancho de pedido pago ou o webhook podem disparar mais de uma vez para o mesmo pedido, seja por reprocessamento, seja por reenvio quando o Wix não recebe confirmação. A idempotência por identificador de pedido é a defesa: guarde quais pedidos já viraram conversão enviada e ignore repetições. E, para não perder evento quando a API de anúncios estiver instável, prefira gravar o evento e responder rápido, deixando o envio de fato acontecer com possibilidade de retentativa. Num serviço externo isso é uma fila; dentro do Velo, é uma abordagem de gravar o pendente e reprocessar. O princípio é o mesmo: nunca deixar a conversão depender de a API responder de primeira, na hora exata do gancho.

Consentimento e privacidade no Wix#

Rastreamento server-side não dispensa o cuidado com consentimento. Mesmo que a conversão seja calculada no servidor, os dados que a alimentam — e-mail, telefone, parâmetro de clique — são dados pessoais do comprador, e o envio deles à plataforma de anúncios precisa respeitar a base legal e a escolha do usuário. No Wix, isso significa que a captura do parâmetro de clique e o disparo do evento de conversão devem levar em conta o estado do consentimento coletado na loja. Se o comprador recusou o rastreamento de marketing, o server-side não é uma brecha para ignorar essa escolha e mandar os dados assim mesmo — pelo contrário, a decisão de enviar ou não, e com quais dados, precisa refletir o consentimento tanto no client quanto no servidor. Muitas lojas implementam isso passando o estado de consentimento adiante junto com o pedido, para que o gancho de conversão saiba se pode ou não incluir os dados de correspondência. O server-side, por rodar longe dos olhos do usuário, exige ainda mais disciplina nesse ponto: como o comprador não vê o que acontece no servidor, cabe a você garantir que o que acontece lá honra a escolha que ele fez. Tratar consentimento como parte do desenho da mensuração, e não como um detalhe do banner, é o que mantém a operação em conformidade sem sacrificar a precisão para quem consentiu.

Deduplicação, atribuição e o valor do lead recorrente#

Vale lembrar que muitas lojas Wix vendem serviços e assinaturas, não só produtos avulsos. Nesses casos, a conversão não é um evento único: há a primeira compra e há as renovações. Decidir o que reportar — só a aquisição, ou também cada renovação — é uma escolha de negócio que precisa ser explícita, porque contar cada renovação como conversão nova infla o número de aquisições e engana a otimização de campanha, que passa a mirar volume em vez de clientes novos. O padrão saudável é reportar a aquisição como a conversão principal que a campanha otimiza, e tratar as renovações como um sinal separado de valor ao longo do tempo. O gancho de pedido pago do Velo permite distinguir os dois casos, contanto que você guarde se aquele comprador já converteu antes. Essa distinção mantém a mensuração fiel ao que a campanha realmente gerou.

Validando o fluxo#

Antes de confiar nos números, teste de ponta a ponta. Faça um pedido real, acompanhe o gancho do Velo ou o webhook disparar, confirme que o payload saiu com valor, itens e dados de correspondência, e use a aba de eventos de teste da Meta e o modo de depuração do GA4 para ver o evento chegar corretamente. Verifique também o comportamento em cancelamento e reembolso, para que receita que voltou atrás não fique contada como viva.

O Wix dá mais do que parece#

O Wix carrega a fama de plataforma só para leigos, mas quem precisa de rastreamento sério tem, no Velo e nas automações, as ferramentas para escapar da armadilha do client-side. Capture a compra a partir do pedido pago, mantenha os tokens no gerenciador de segredos, monte um payload completo com correspondência hasheada, resolva o parâmetro de clique com captura no cliente amarrada ao pedido, unifique o event_id para deduplicar e proteja o fluxo com idempotência e reprocessamento. Com isso, mesmo uma loja montada arrastando blocos passa a medir a receita real, e não só a fração dela que sobreviveu ao navegador.