value, currency e content_ids: os parâmetros de e-commerce que alimentam a otimização por valor

Existe uma diferença enorme entre contar conversões e otimizar por valor, e ela mora em três ou quatro parâmetros que muita gente preenche no automático. Uma campanha que só sabe que houve uma compra pode, no máximo, otimizar por volume de compras. Uma campanha que sabe quanto cada compra valeu, em qual moeda, de quais produtos, pode otimizar por retorno — buscar não mais compras, e sim mais receita. Essa inteligência inteira depende de value, currency, content_ids e alguns companheiros estarem corretos em cada evento.

Preencher esses campos errado não gera erro. A plataforma aceita o evento, conta a conversão, e você só descobre o problema quando o ROAS reportado não bate com a realidade ou quando o remarketing dinâmico mostra o produto errado. Este guia explica o que cada parâmetro significa, como preenchê-lo corretamente e onde ele aparece no pixel, na CAPI e no GA4.

Por que esses parâmetros separam contar de otimizar#

Otimização por valor é o mecanismo pelo qual a plataforma aprende a buscar conversões mais valiosas, não apenas mais numerosas. Para isso, ela precisa saber o valor de cada conversão. Sem value e currency, a plataforma trata todas as compras como equivalentes — a de R$ 30 e a de R$ 3.000 pesam o mesmo —, e a campanha não consegue perseguir receita. Sem content_ids casando com o catálogo, o remarketing dinâmico não sabe qual produto mostrar de volta ao usuário. Estes parâmetros não são metadados decorativos: são a matéria-prima da otimização financeira e do retargeting.

value: o número, e só o número#

O value é o valor monetário da conversão. Parece trivial, mas concentra vários erros clássicos.

Tipo correto, sem símbolo#

value é um número, não uma string, e não carrega símbolo de moeda. O certo é 259.90, não "R$ 259,90" nem "259,90". Enviar o valor como string com símbolo é um dos erros mais frequentes e mais destrutivos: a plataforma pode ler zero, pode rejeitar silenciosamente, ou pode interpretar mal. O separador decimal é o ponto, no formato que a API espera, não a vírgula do português.

O que entra no valor: uma decisão a ser tomada e mantida#

Há uma decisão de negócio embutida: o value inclui frete? Inclui impostos? Não existe resposta universal — existe a exigência de escolher e ser consistente. Se você inclui frete numa campanha e não inclui em outra, os valores ficam incomparáveis e o ROAS fica distorcido. O mais comum e defensável é usar o valor dos produtos (a receita que interessa), de forma idêntica em todos os eventos e todos os canais. O que não pode é variar sem controle.

currency: obrigatório junto do value#

O currency é o código da moeda no padrão ISO 4217 — BRL, USD, EUR — e é obrigatório sempre que há value. Um valor sem moeda é ambíguo: 259.90 pode ser reais ou dólares, e a plataforma não tem como converter nem comparar sem saber. Enviar value e esquecer currency é um erro comum que faz a plataforma ignorar o valor ou aplicar uma moeda padrão errada, corrompendo o ROAS. A dupla value + currency anda sempre junta; um sem o outro é meio evento.

content_ids e content_type: a ponte com o catálogo#

O content_ids é a lista de identificadores dos produtos envolvidos no evento, e o content_type diz se esses ids são de produtos individuais (product) ou de grupos de produtos (product_group).

A função crítica desses campos é casar com o catálogo/feed que você mantém na plataforma. É essa correspondência que habilita o remarketing dinâmico (as campanhas que mostram de volta ao usuário exatamente o produto que ele viu). Se os content_ids enviados nos eventos não batem com os ids do feed — porque um usa SKU e o outro usa o id interno, por exemplo —, o remarketing dinâmico não encontra o produto e a campanha não funciona, mesmo com os eventos chegando.

A regra prática: os content_ids dos eventos e os ids do feed de produtos precisam vir da mesma fonte de identificação. Alinhar isso é pré-requisito para retargeting de catálogo.

contents: o detalhamento por item#

Além dos ids, muitas implementações enviam um array contents (ou items) que detalha cada produto do evento com id, quantidade e preço unitário:

``json { "event_name": "Purchase", "custom_data": { "currency": "BRL", "value": 519.80, "content_type": "product", "content_ids": ["SKU-1029", "SKU-3311"], "contents": [ { "id": "SKU-1029", "quantity": 1, "item_price": 259.90 }, { "id": "SKU-3311", "quantity": 1, "item_price": 259.90 } ], "num_items": 2, "order_id": "ord_8f3a91c2" } } ``

O contents dá granularidade: permite à plataforma entender a composição do carrinho, e é a base para relatórios de valor por produto. O num_items informa a quantidade total de itens, e o order_id identifica o pedido.

order_id: valor único por pedido e deduplicação#

O order_id cumpre dois papéis. Primeiro, ele evita contagem duplicada de valor: se o mesmo pedido for enviado mais de uma vez (por retry, por recarregamento da página de sucesso, pelo pixel e pelo servidor), o identificador do pedido permite reconhecer que é a mesma compra e não somar o valor duas vezes. Segundo, ele é a âncora natural do event_id de deduplicação — usar o id do pedido como base do event_id garante que os dois canais coincidam. Contar a mesma receita duas vezes é um erro que infla o ROAS e leva a decisões de orçamento equivocadas; o order_id é a defesa.

Reembolsos e valor negativo#

A conversão nem sempre é definitiva: pedidos são cancelados, produtos são devolvidos, pagamentos são estornados. Uma mensuração que só conta compras e ignora reembolsos superestima a receita real e engana a otimização, que passa a perseguir clientes que compram e devolvem. As plataformas permitem registrar reembolsos como eventos de valor negativo ou como eventos específicos de estorno, referenciando o order_id original.

O ponto de projeto é que o reembolso precisa ser tratado como parte do ciclo de vida da conversão, não como um evento solto. Ele nasce, tipicamente, de um webhook do gateway ou do sistema de pedidos — o mesmo tipo de fonte confiável que dispara a compra — e deve carregar o identificador do pedido para que a plataforma saiba qual conversão ajustar. Ignorar reembolsos é medir só metade da verdade financeira.

Assinaturas e valor recorrente#

Negócios de assinatura ou recorrência colocam uma questão a mais: qual valor reportar na conversão inicial? O valor da primeira cobrança? O valor projetado ao longo do contrato (o valor de tempo de vida)? Não há resposta única, mas há uma exigência de coerência. Se você reporta o valor da primeira cobrança na conversão de aquisição, precisa manter esse critério em toda a operação para que os números sejam comparáveis. Reportar o valor de tempo de vida infla a conversão inicial e exige cuidado para não contabilizar duas vezes as renovações que virão como eventos próprios. A decisão é de negócio; a disciplina de aplicá-la consistentemente é de engenharia.

Onde esses campos aparecem: pixel, CAPI e GA4#

Os mesmos conceitos aparecem, com nomes ligeiramente diferentes, em cada canal:

• Pixel de navegador (Meta) — value, currency, content_ids, content_type, contents, num_items no objeto de dados do evento.
• Conversions API (Meta) — os mesmos campos dentro de custom_data, como no exemplo acima.
• GA4 — o padrão de e-commerce usa um array items com item_id, item_name, price, quantity, além de value e currency no evento. A ideia é a mesma; muda a nomenclatura.

Para que pixel, CAPI e GA4 não divirjam, todos devem ler os mesmos valores da mesma fonte — tipicamente o data layer — em vez de cada um calcular por conta própria. Divergência entre canais quase sempre nasce de cada um pegar o valor de um lugar diferente.

Detalhe do mapeamento no GA4#

No GA4, o array items merece atenção porque sua estrutura é ligeiramente diferente da usada nas plataformas de anúncio. Cada item traz item_id, item_name, price, quantity e pode incluir categoria, variante e marca. O item_id do GA4 cumpre o papel do content_ids — e, de novo, precisa casar com a mesma fonte de identificação de produto usada nos demais canais, senão os relatórios de produto do GA4 não conversam com o remarketing dinâmico das plataformas. O value e o currency do evento GA4 seguem as mesmas regras: número puro e ISO 4217. Manter um mapeamento explícito de "campo interno → campo GA4 → campo da plataforma" é o que garante que a mesma compra apareça com o mesmo valor em todo relatório, em vez de três números levemente diferentes que ninguém consegue reconciliar.

Como o valor influencia o lance#

Vale entender o efeito prático a jusante para dimensionar a importância desses campos. Quando você usa estratégias de lance orientadas a retorno, a plataforma decide quanto pagar por cada oportunidade em função do valor esperado da conversão. Ela aprende, com o histórico de value que você enviou, quais perfis tendem a gerar compras maiores, e passa a lançar mais alto por eles. Se o value está ausente, zerado ou errado, esse aprendizado não acontece ou acontece torto: a plataforma trata compras de valores muito diferentes como equivalentes e desperdiça orçamento perseguindo volume em vez de receita. Ou seja, um campo mal preenchido no payload se traduz, lá na ponta, em lance ineficiente e ROAS pior — a cadeia inteira depende do dado de valor estar certo na origem.

Erros comuns#

Reunindo os problemas que mais aparecem:

• value como string com símbolo. "R$259,90" em vez de 259.90.
• Separador decimal errado. Vírgula onde a API espera ponto.
• currency ausente. Valor sem moeda, ambíguo e frequentemente ignorado.
• content_ids que não batem com o feed. SKU nos eventos, id interno no catálogo — o remarketing dinâmico não encontra o produto.
• Frete/imposto inconsistente. Incluir num evento e não em outro, tornando o ROAS incomparável.
• Valor duplicado. Enviar o mesmo pedido pelos dois canais sem event_id/order_id compartilhado e somar a receita duas vezes.
• Tipos trocados no contents. Preço como string, quantidade ausente, ids inconsistentes com o content_ids.

A relação com o data layer#

Todos esses valores deveriam ter uma origem única: o data layer. O valor da compra, a moeda, a lista de ids e o detalhamento de itens são preenchidos pela aplicação num contrato estável, e dali são lidos pelo pixel e pelo envio server-side. Quando os parâmetros de e-commerce saem de uma fonte comum, com tipos corretos e ids alinhados ao feed, a otimização por valor e o remarketing dinâmico simplesmente funcionam. Quando cada canal raspa o valor de um lugar diferente, a divergência é inevitável.

Síntese#

value, currency e content_ids são os parâmetros que transformam "contar conversão" em "otimizar por valor". O value é um número puro, sem símbolo de moeda, com uma política consistente sobre frete e imposto; o currency em ISO 4217 é obrigatório junto dele; o content_ids precisa casar exatamente com os ids do feed para o remarketing dinâmico funcionar; o contents detalha o carrinho; e o order_id evita contar a mesma receita duas vezes e ancora a deduplicação. Preenchidos corretamente, a partir de uma fonte única como o data layer, e replicados sem divergência entre pixel, CAPI e GA4, esses campos são o que permite à campanha perseguir receita, e não apenas volume. É o detalhe que separa mensuração que informa de mensuração que otimiza.