Tracking de conversões em pagamento contra reembolso e checkouts externos

O tracking de conversões em pagamento contra reembolso consiste em enviar cada compra às suas plataformas de anúncios a partir da própria encomenda, no servidor, em vez de depender de um pixel do navegador numa página de agradecimento. As encomendas de apps de pagamento contra reembolso, de checkouts externos, de formulários de encomenda e de funis terminam muitas vezes fora do checkout normal, por isso o pixel falha-as ou reporta-as no momento errado.

Este guia explica porque é que essas encomendas se perdem e porque é que o estado do pagamento importa. Compara três momentos para enviar a compra: quando a encomenda é criada, quando é confirmada e quando é paga. Aborda também as encomendas recusadas e os reembolsos, e como a ROASaurus trata os checkouts externos.

Porque é que os pixels falham as encomendas com pagamento contra reembolso?

Um pixel do navegador reporta uma compra quando o comprador chega a uma página que o executa. Normalmente é a página de agradecimento do seu checkout. Qualquer percurso de encomenda que salte esta página, ou a execute noutro domínio, perde o evento de compra ou o clique no anúncio que lhe pertence.

A encomenda em si nunca se perde. Fica na sua loja online ou na sua ferramenta de funis, com um ID de encomenda, um valor, um endereço de email e, muitas vezes, um número de telefone. É por isso que a solução fiável é enviar a compra a partir dos dados da encomenda, server-side, e levar o clique no anúncio até à encomenda. O artigo Tracking server-side no Shopify explica o método geral. Este artigo trata das encomendas que exigem cuidados extra.

Algumas apps de pagamento contra reembolso também disparam os seus próprios eventos de pixel. Se usarem o mesmo pixel que o seu tracking server-side mas com um ID de evento diferente, a plataforma conta a encomenda duas vezes. Desative esses eventos das apps ou siga os passos para evitar a contagem em duplicado.

Porque é que o estado do pagamento importa

Um pagamento com cartão é capturado no checkout, por isso a encomenda está paga no momento em que existe. Uma encomenda com pagamento contra reembolso é diferente. O Shopify classifica o pagamento contra reembolso como um método de pagamento manual, e estas encomendas ficam em Payment pending até que as marque como pagas. Na prática, isso acontece depois de a transportadora cobrar o dinheiro, o que pode demorar dias. Algumas encomendas nunca chegam a ser pagas, porque o comprador recusa o pacote ou não está em casa.

Muitas configurações de tracking enviam a compra quando a encomenda é paga, porque nas encomendas com cartão esse é o momento mais seguro. Numa encomenda com pagamento contra reembolso, a mesma regra faz com que a compra chegue com dias de atraso ou nunca chegue. O registo abaixo mostra um caso típico numa loja que envia as compras no pagamento.

O WooCommerce funciona ao contrário. Coloca as encomendas com pagamento contra reembolso em Processing até o pagamento ser cobrado, exceto as encomendas com um produto descarregável, que passam para On hold. Uma configuração que envia as encomendas em Processing envia-as, por isso, assim que são feitas. Verifique que estado a sua plataforma atribui a estas encomendas antes de decidir qualquer outra coisa.

Criada, confirmada ou paga: quando deve enviar a compra?

Há três momentos à escolha. Cada um troca rapidez por rigor.

Porque é que os eventos de compra tardios são um problema

As plataformas de anúncios só atribuem uma compra a um anúncio quando ela acontece dentro da janela de atribuição após o clique. Com uma definição de atribuição de cliques de 7 dias na Meta, uma compra conta para um anúncio até 7 dias depois do clique. A Conversions API da Meta também recusa eventos cujo event_time seja anterior a mais de 7 dias e rejeita o pedido inteiro quando um evento é demasiado antigo. Uma compra enviada no pagamento tem, por isso, duas opções más:

• Enviá-la com a hora da encomenda. Se o pagamento chegou mais de 7 dias depois, a Meta rejeita-a.
• Enviá-la com a hora do pagamento. A Meta aceita-a, mas o clique no anúncio pode já ter mais de 7 dias, por isso a compra não é atribuída ao anúncio.

A rapidez também conta para a otimização. As campanhas que otimizam para compras aprendem com as compras que envia. Um sinal que chega uma semana depois informa o algoritmo sobre o público da semana passada.

Que momento escolher

Para a maioria das lojas com pagamento contra reembolso, enviar na criação é a melhor opção por predefinição. O sinal é imediato, o clique ainda está dentro da janela e nada é rejeitado. O custo é que as encomendas recusadas contam como compras no Ads Manager. Corrige isso nos seus objetivos, como mostra a secção seguinte.

Se a sua equipa confirma cada encomenda por telefone ou mensagem antes de a expedir, a confirmação é um bom meio-termo. Elimina as encomendas falsas e costuma acontecer em menos de um dia. Use-a quando o seu próprio sistema conseguir enviar a compra nesse momento, por exemplo através de uma API. As encomendas falsas importam mais do que parece: se a plataforma de anúncios aprender com elas, procura mais pessoas que fazem encomendas e não pagam.

Como tratar encomendas recusadas, cancelamentos e reembolsos

Depois de enviada, uma compra fica no Ads Manager. Uma encomenda recusada à porta não a remove. A ROASaurus também não envia reembolsos nem cancelamentos para a Meta, o TikTok e a maioria das outras plataformas de anúncios, por isso a receita que reportam inclui encomendas que nunca cobrou. Só os valores do Google Ads e do Microsoft Advertising podem ser corrigidos após um reembolso, quando as correções de valor estão ativadas. A solução é medir a sua taxa de recusa e ajustar os números com que compara.

Eis um exemplo prático para um mês. Para simplificar, os preços são sem IVA.

Com $3,000 de investimento em anúncios, o mesmo mês parece muito diferente consoante a receita que usar:

A taxa de margem bruta sobre a receita entregue é $3,878 ÷ $8,200 = 47.3%, por isso o ROAS de break-even é 1 ÷ 0.473 = 2.11. Esse break-even aplica-se à receita entregue. O Ads Manager conta também as encomendas recusadas, por isso tem de o converter antes de comparar. O artigo ROAS de break-even explica a fórmula de base.

Pode verificar o resultado diretamente. Os anúncios atingem o break-even quando o investimento em anúncios é igual ao lucro bruto de $3,878, e $10,000 de receita reportada ÷ $3,878 = 2.58.

As taxas de recusa costumam variar consoante a região, o produto e a campanha. Calcule-as por campanha quando tiver encomendas suficientes e use a calculadora de POAS para verificar o resultado sobre o lucro bruto.

Reembolsos e cancelamentos nos seus próprios números

No Shopify, os cancelamentos e reembolsos chegam à ROASaurus por webhook, por isso a análise de lucro desconta os reembolsos da receita. Pode escolher se as encomendas canceladas que nunca foram expedidas contam; por predefinição, ficam de fora. Uma encomenda cancelada que já tinha sido enviada continua incluída, porque o envio continuou a custar-lhe dinheiro. Para as encomendas recentes que ainda podem voltar, a definição Predicted returns retém uma parte esperada das vendas até chegarem os reembolsos reais.

Como a ROASaurus trata o pagamento contra reembolso e os checkouts externos

Shopify

Cada loja Shopify tem um Checkout type em Store settings, com duas opções:

• Shopify checkout: a compra é enviada quando o Shopify reporta a encomenda como paga, através do webhook orders/paid.
• External / COD checkout: a compra é enviada quando a encomenda é criada, através do webhook orders/create. Use-o para pagamento contra reembolso e para checkouts externos, como o CheckoutChamp ou o Checkify, que criam eles próprios a encomenda no Shopify.

A definição aplica-se a todas as encomendas da loja. As encomendas com cartão pagas no checkout são criadas e pagas quase no mesmo momento, por isso a escolha altera sobretudo o momento em que as encomendas por pagar são enviadas. Cada encomenda é enviada uma só vez. Quando a atualização de pagamento de uma encomenda com pagamento contra reembolso chega mais tarde, não é enviada uma segunda compra.

A compra usa os dados da própria encomenda: o valor, a moeda, os produtos e o email, o telefone e a morada do comprador, com hash antes de saírem. A ROASaurus associa a encomenda ao clique no anúncio através do ID de visitante que o seu script guarda no carrinho. Quando uma encomenda não o traz, a ROASaurus tenta, por esta ordem: os tokens de carrinho e de checkout, o evento de compra do checkout, um email que o visitante indicou antes no seu site e o mesmo endereço IP e navegador pouco antes da encomenda, quando só um visitante corresponde. A página da integração com o Shopify tem a configuração completa.

WooCommerce e outras lojas online

O plugin WooCommerce envia uma encomenda quando chega a Processing ou Completed. As encomendas com pagamento contra reembolso chegam a Processing quando são feitas, por isso são enviadas logo. As encomendas por transferência bancária são enviadas quando passam a Processing. Os outros conectores de lojas online enviam uma encomenda nestes momentos:

• Wix, Squarespace, Ecwid, Lightspeed, CCV Shop e Shopware: quando o estado de pagamento da encomenda é pago.
• BigCommerce: quando a encomenda atinge um estado como Awaiting Fulfillment, Awaiting Shipment, Shipped ou Completed.
• Magento: quando o estado da encomenda é Processing ou Complete.
• PrestaShop: quando a encomenda é marcada como válida.
• Webhook personalizado e API de encomendas: quando o seu próprio sistema envia a encomenda.

Verifique como a sua plataforma marca as encomendas com pagamento contra reembolso. Se ficarem por pagar até a transportadora entregar o dinheiro, as respetivas compras chegam tarde.

Funis e o seu próprio checkout

1. Adicione o script às páginas do funil

   Use a mesma chave de loja que na sua loja online, para que o visitante mantenha um único ID de visitante nos dois domínios.

2. Indique os seus domínios

   Em Store settings, adicione os domínios do funil e da loja em Linked domains. As ligações entre esses domínios passam então a levar o ID de visitante e os IDs de clique.

3. Envie as encomendas através da API de encomendas

   Se o funil recolher a encomenda ele próprio, envie cada encomenda por POST para /api/v1/orders com o cookie _tl como visitor_id. O seu sistema decide o momento: na criação, na confirmação ou no pagamento.

4. Verifique o Event log

   Quando chegarem as primeiras encomendas reais, abra o Event log e verifique se cada uma foi enviada para todas as plataformas ligadas.

POST /api/v1/orders
X-Roasaurus-Key: <store key>
Authorization: Bearer <API key>
Content-Type: application/json

{
  "order_id": "F-20931",
  "created_at": "2026-10-20T14:05:00Z",
  "total": 50.00,
  "currency": "USD",
  "email": "buyer@example.com",
  "phone": "+15555550123",
  "country": "US",
  "visitor_id": "<value of the _tl cookie>",
  "click_ids": { "fbc": "<_fbc cookie>", "fbp": "<_fbp cookie>" },
  "client_ip": "203.0.113.7",
  "user_agent": "Mozilla/5.0 ...",
  "items": [{ "variant_id": "SKU1", "quantity": 1, "price": 50.00 }]
}

A API de encomendas guarda a primeira cópia de cada ID de encomenda. Se o seu sistema a chamar na criação e outra vez no pagamento, só a primeira chamada envia uma compra. Há mais detalhes em funis e vários domínios.

Erros comuns a evitar

• Esperar pelo estado de pago numa loja com pagamento contra reembolso. As compras chegam com uma semana de atraso ou nem chegam, e os eventos tardios são rejeitados ou ficam fora da janela de atribuição.
• Comparar o ROAS do Ads Manager com um break-even calculado para encomendas pagas. Divida primeiro o break-even pela sua taxa de pagamento.
• Duas fontes para uma só compra. O pixel da própria app de formulário e os seus eventos de servidor contam a mesma encomenda duas vezes. Veja eventos de compra duplicados.
• Perder o clique entre domínios. Um funil noutro domínio precisa do script e dos domínios associados, ou as suas encomendas chegam sem clique no anúncio.
• Deixar as encomendas manuais de fora. As encomendas por telefone e chat não têm sessão de navegador, mas continuam a ter um endereço de email ou um número de telefone. Enviadas a partir dos dados da encomenda, dão à plataforma de anúncios algo com que fazer a correspondência.

Fontes

1. Meta for Developers: Server Event Parameters
2. Shopify: WebhookSubscriptionTopic (GraphQL Admin API)
3. Shopify Help Center: Manual payment methods
4. Shopify Help Center: Understanding your order statuses
5. WooCommerce: Cash on Delivery documentation

Na ROASaurus

• Integração com o Shopify
• Integração com o WooCommerce
• Ajuda: funis e vários domínios
• Análise de lucro na ROASaurus

Continue a ler