Como inflacionam o ROAS e porque estás no vermelho

A maioria dos donos de loja avalia o gestor de tráfego por um único ecrã: o Meta Ads Manager. Ali os números são sempre bonitos. Investiste $920, "faturaste" $11 mil, ROAS 1230%. Parece que a pessoa faz magia.

O problema é que este ecrã não mostra o teu lucro. Mostra aquilo que a Meta decidiu creditar a si própria. São duas coisas muito diferentes. Com números reais vamos ver o "ROAS 1230%" transformar-se num prejuízo no banco.

Não sou um copywriter a reescrever o artigo de outra pessoa. Eu configuro analítica e tracking server-side para e-commerce, por isso vejo esta diferença por dentro: o número que o cliente recebe num relatório contra o dinheiro que entra mesmo na conta.

O truque central: o ROAS vendido como resultado

ROAS (return on ad spend) é o rácio entre "receita" e investimento em anúncios. ROAS 1230% significa apenas que o painel creditou cerca de $12 de vendas por cada $1 gasto. Os gestores de tráfego adoram este número porque quase sempre parece uma vitória. Mas tem três silêncios convenientes lá dentro:

1. É receita, não lucro. Margem, custo do produto, portes e devoluções não entram aqui.
2. Não é a tua receita, é a estimativa da Meta. É contada pela própria plataforma de anúncios, que tem todo o interesse em parecer eficaz.
3. Não é "graças ao anúncio", é "depois do contacto com o anúncio". É nessa diferença que vive a maior parte do crédito a mais.

A métrica honesta chama-se ROMI (return on marketing investment): conta o lucro real depois de margem, custos operacionais e devoluções, e não a receita de topo do painel. Quase nunca é mostrada, porque é menos favorável. Às vezes, como vamos ver, é negativa.

Caso: uma loja de cosmética

Um exemplo real na estrutura (sem nome de marca). Um mês, um canal principal, Meta Ads. Os valores são do caso real, em dólares.

Para nestas linhas. A Meta creditou a si própria $11 332. A loja inteira, somando todas as fontes (pesquisa, direto, email, anúncios), faturou $9 805 nesse mês. O painel de anúncios "vendeu" cerca de mil e quinhentos dólares mais do que existe fisicamente.

Isto não é um erro de arredondamento. É uma estrutura em que o relatório nunca vai bater certo com o banco. E eis porquê.

Quatro razões para o painel exagerar sempre

1. A janela de atribuição "7 dias clique, 1 dia visualização"

É a definição por omissão na Meta. O painel credita uma venda a si própria se a pessoa clicou no anúncio nos 7 dias antes de comprar, ou, no dia antes de comprar, apenas o viu (view-through). Passou ao lado no scroll, voltou cinco dias depois pelo Google e comprou, mas a Meta já registou essa venda como sua.

Uma janela mais estreita (por exemplo "1 dia clique") dá números mais honestos, mas faz o gestor de tráfego parecer pior no papel. Por isso a jogada habitual é manter a janela mais larga com visualização ligada. Tecnicamente não é mentira, mas é uma escolha deliberada de mostrar a imagem mais favorável.

2. Canibalização de outros canais

Pela mesma janela larga, os anúncios "puxam" vendas que outros canais trouxeram de facto: pesquisa orgânica do Google, Google Ads, fluxos de email e SMS, visitas diretas de clientes fiéis. A pessoa já ia comprar, viu a marca na pesquisa, recebeu um email de desconto. Mas como há uma semana passou um banner no feed, a venda vai para a Meta.

É exatamente daí que vem a diferença entre $11 332 no painel e $7 500 no canal "Facebook / CPC" da analítica. Mais de três mil e quinhentos dólares são crédito de outros canais que o painel anexou.

3. Devoluções, pagamentos falhados e falta de stock são ignorados

Aqui temos um número concreto desta loja: só 85% das encomendas se concluem mesmo. Os outros 15% são devoluções, pagamentos por cartão recusados ou abandonados, referências Multibanco que expiram sem pagamento, e casos em que o produto não está realmente em stock porque o estado no site não foi atualizado mas a encomenda já entrou.

A Meta não sabe nem quer saber desses 15%: contou a venda no checkout e nunca mais lá volta. O Google Analytics, pelo contrário, subtrai-os quando o evento "refund" está bem configurado (mais abaixo) — por isso o valor do GA4 é mais honesto: já está livre das encomendas que caíram.

Por isso a "receita" no painel da Meta é um cenário otimista em que cada encomenda é paga, enviada e ficada. Numa loja real isso nunca acontece: mais ou menos uma em cada sete encomendas cai.

4. O objetivo dispara no clique "Pagar", não no pagamento real

Há aqui um mal-entendido comum. A página "obrigado pela tua encomenda" costuma aparecer já depois de um pagamento com sucesso, por isso só por si não está a mentir. O problema é outra configuração: o evento "Purchase" é ligado ao clique no botão "Pagar" na página de checkout.

A pessoa clicou em "Pagar", mas o cartão foi recusado, ou desistiu já no gateway de pagamento, ou a página de pagamento nunca carregou. O evento já disparou, a venda está contada, o dinheiro não está lá. É assim que intenções de pagar acabam nas estatísticas em vez de pagamentos reais. O evento "Purchase" deve disparar no backend, na confirmação de uma transação com sucesso.

ROAS vs ROMI: levar o dinheiro do painel até à caixa

Agora a parte interessante. Pega não nos $11 mil imaginários, mas na receita que a analítica atribuiu realisticamente aos anúncios: $7 500 (cerca de 188 encomendas concluídas com ticket médio de $40). Um detalhe importante: este valor do GA4 já está líquido de devoluções, por isso não há que voltar a descontá-lo. Faz esse dinheiro passar pela economia real da loja.

Dados de entrada: margem de 30%, custo operacional de 15% por encomenda (cerca de $6 numa encomenda de $40), honorário do especialista $300, investimento em anúncios $920.

Olha para a primeira linha e para a última. O painel mostra uns triunfantes $11 332 e ROAS 1230%. O banco mostra menos $95. Uma campanha que parece uma mina de ouro no screenshot correu na verdade com prejuízo, assim que contamos margem, operação, o próprio investimento e o honorário do especialista.

Repara como a diferença se acumula. Cada passo parece inofensivo por si só: primeiro a janela de atribuição larga inflaciona a "receita" do painel, depois sobra apenas 30% de margem sobre o valor honesto, e a operação come outra fatia. Juntos transformam o "ROAS 1230%" num prejuízo. É por isso que "está tudo bem, vamos escalar" não se decide por um número do painel: não tem nada a ver com o teu dinheiro.

Analítica mais limpa: devoluções no GA4

Uma razão à parte para o Google Analytics estar mais perto da verdade do que o painel da Meta: o GA4 consegue subtrair devoluções, e a Meta praticamente não.

O GA4 tem um evento de e-commerce padrão chamado "refund". Quando uma encomenda é devolvida, cancelada ou o pagamento falha, envias um evento "refund" com o mesmo transaction_id da compra original. Para uma devolução parcial podes passar os itens específicos. O GA4 subtrai depois esse valor da receita nos relatórios, por isso "Purchase revenue" e a receita total já refletem as devoluções descontadas.

O que isto te dá na prática:

• O número no GA4 vai convergindo com o saldo real do banco, em vez de viver num mundo imaginário onde toda a encomenda é paga.
• Para devoluções ao abrigo do direito de livre resolução de 14 dias, podes enviar um "refund" no momento em que a encomenda é marcada como devolvida. Assim as devoluções deixam de inflacionar a "receita".
• O mais fiável é fazê-lo do lado do servidor: a tua CRM ou sistema de encomendas envia o "refund" para o GA4 via Measurement Protocol quando o estado da encomenda muda para "devolvida" ou "cancelada". Não depende do browser do cliente e não se perde com bloqueadores.

O painel da Meta quase não tem equivalente: nunca reverte uma conversão já contada. É por isso que duas fontes independentes e bem configuradas (o banco mais o GA4 com devoluções) são sempre mais de confiar do que um painel de anúncios com interesse próprio. Como montar isto tecnicamente está detalhado no artigo sobre tracking server-side com GA4 e Meta CAPI →.

Como auditar o teu gestor de tráfego em 10 minutos

Não precisas de ser analista. Basta conciliar alguns ecrãs:

1. Concilia a receita. O valor no painel da Meta contra a receita real da loja no mesmo período. Se os anúncios "faturaram" mais do que a loja inteira, a questão está fechada.
2. Pergunta pela janela de atribuição. Se o relatório usa "7 dias clique, 1 dia visualização", pede os mesmos números numa janela "1 dia clique" e vê quanto caem.
3. Calcula ROMI, não ROAS. Margem menos custo operacional menos investimento em anúncios menos o honorário do especialista. Esse é o teu resultado em euros.
4. Pergunta se o evento "Purchase" corresponde a um pagamento real, e não a um clique "Pagar".
5. Verifica se as devoluções estão configuradas no GA4. Se não, a tua analítica também exagera, só que menos do que a Meta.

Um bom especialista responde a isto com calma e mostra-te ele próprio os números honestos. Quem começa a explicar porque "não é assim que se conta" e porque só deves olhar para o painel já te respondeu com a reação.

Conclusão

Um gestor de tráfego não tem de ser um aldrabão para mostrar números inflacionados. Muitas vezes basta deixar as configurações por omissão e não contar as partes incómodas: nem as encomendas falhadas, nem a margem, nem o próprio honorário. O painel da Meta faz o resto e credita a si próprio vendas de outros canais.

O teu trabalho como dono não é confiar num ecrã bonito. Concilia o relatório de anúncios com o banco, a margem e a taxa de conclusão pelo menos uma vez. Muitas vezes um "ROAS 1230%" triunfante transforma-se, depois disso, num prejuízo pequeno mas bem real. E isso não é motivo para abandonar os anúncios, é motivo para começar a medi-los com honestidade: caso contrário estás a escalar um prejuízo a pensar que escalas lucro.

Próximo passo

Se investes em anúncios e ainda olhas só para o painel da Meta, não conheces o teu resultado real. A configuração de anúncios e analítica → inclui um relatório honesto de ROMI, atribuição correta e tracking server-side com devoluções no GA4. A construir uma loja de raiz? A analítica limpa já faz parte do baseline da online-store →.