Pixel e Conversions API do ChatGPT: medir de verdade

A parte chata do ChatGPT Ads é a que decide o resultado. Sem medição instalada e conferida, não existe campanha otimizada por conversão: sobra comprar clique e torcer.

O que o formato é, quem vê e o que ainda não está confirmado sobre o Brasil está no guia do ChatGPT Ads. Aqui a pergunta é outra: o que instalar, quais eventos disparar, onde a implementação quebra e como ler um relatório que, por desenho, conta menos do que aconteceu.

O que segue vem da documentação da OpenAI para desenvolvedores, listada em fontes. O que ela não diz, aparece marcado.

Como o ChatGPT Ads mede uma conversão?

Por duas fontes que a OpenAI espera que convivam.

A primeira é o pixel, um SDK JavaScript servido pela OpenAI e instalado no <head> das páginas onde você quer capturar conversão. Ele é inicializado com um pixelId, criado na aba de conversões do gerenciador, e passa a aceitar chamadas de evento.

A segunda é a Conversions API, que recebe eventos pelo servidor num endpoint próprio, autenticado por token. A frase da documentação é direta: a Conversions API é fonte de rastreamento mais confiável que o pixel sozinho.

Para uma conversão ser contada, a documentação exige três condições ao mesmo tempo: a OpenAI recebe o evento de uma fonte conectada à conta, o evento corresponde ao configurado para a campanha, e ele acontece dentro da janela de atribuição, ligado a um clique elegível.

Nenhuma das três é “a venda aconteceu”. Uma venda pode existir e não virar conversão contada. É a mesma lógica de qualquer plataforma, e por isso a régua final é a do post irmão sobre CRM e mídia paga: o pedido pago.

Quais eventos existem e quais importam para uma loja?

A documentação lista os eventos padrão. Nem todos servem para e-commerce.

Evento	O que marca	Uso numa loja D2C
page_viewed	Visualização de página	Sinal de base, não serve como objetivo
contents_viewed	Visualização de conteúdo	Página de produto e página de categoria
items_added	Item adicionado	Adição ao carrinho
checkout_started	Início de checkout	Entrada no fluxo de pagamento
order_created	Pedido criado	O evento de otimização da loja
lead_created	Lead capturado	Catálogo, orçamento, venda assistida
registration_completed	Cadastro concluído	Criação de conta
subscription_created	Assinatura criada	Clube de assinatura
trial_started	Teste iniciado	Raro em produto físico
appointment_scheduled	Agendamento	Serviço, prova, visita
custom	Evento personalizado	Exige custom_event_name

A API aceita ainda app_installed e app_opened, ausentes na lista do pixel.

Cada evento carrega um objeto de dados com formato declarado: contents para compra e visualização de produto (com amount, currency e um array de id, name, content_type e quantity), customer_action para ação simples, plan_enrollment para assinatura (com plan_id) e custom para o resto.

Uma armadilha de unidade monetária: o exemplo da documentação para order_created traz amount: 2599 com currency: "USD", e a documentação da API de conversões confirma: o valor é um inteiro na menor unidade da moeda (centavos, no caso do real). Enviar reais em vez de centavos divide sua receita atribuída por cem, e o erro inverso multiplica.

E a restrição que trava planejamento: uma campanha oCPC suporta exatamente um evento padrão ativo como objetivo, evento personalizado não vale como meta, e nem o objetivo nem o evento mudam depois da criação. Escolheu errado, cria campanha nova.

Por que o parâmetro de clique é o ponto mais frágil da implementação?

Porque ele viaja na URL, e URL é justamente o que a maioria das lojas mexe sem pensar.

Quando alguém clica no anúncio, a OpenAI anexa ao fim da URL de destino um identificador de clique chamado oppref. O pixel captura esse valor e o guarda num cookie primário __oppref, para que as páginas seguintes da visita possam reutilizá-lo.

A documentação é explícita ao pedir que você preserve o oppref através de redirecionamentos e da navegação dentro do site. Essa frase existe porque o parâmetro morre fácil: encurtador que não repassa a query string, regra de redirecionamento de HTTP para HTTPS ou de domínio com e sem www que descarta parâmetros, normalização da URL para uma versão canônica limpa, checkout que abre em outro domínio.

O teste é banal e quase ninguém faz: cole a URL de destino com um oppref qualquer no fim, abra, siga até a página de obrigado e confira se o valor sobreviveu à jornada. Se sumiu em algum salto, aquela conversão não é atribuída e o relatório mostra um canal pior do que ele é.

Quem envia evento pelo servidor precisa de um passo a mais: capturar o oppref na chegada, gravar no pedido e repassar no evento da API, porque o servidor não enxerga a URL do navegador. A API aceita o campo oppref e pede o valor original, sem modificação. Existe também um obref, referência opaca de navegador guardada em cookie, que pode ir no objeto user para ajudar no pareamento.

Como enviar pelo servidor sem contar a mesma venda duas vezes?

Com o mesmo identificador nos dois caminhos. É a disciplina que vale para qualquer plataforma, e aqui o mecanismo está documentado.

No pixel, você define event_id na chamada do evento. Na API, o mesmo valor vai no campo id. A OpenAI diz que o pareamento usa Pixel ID, nome do evento e esse identificador, então os três precisam bater. Derivar o identificador do número do pedido resolve, porque ele já é único e já existe nos dois lados.

O evento da API pede id, type, timestamp_ms e o objeto data. Eventos web exigem source_url, e há um action_source que aceita valores como web, mobile_app, offline, physical_store, phone_call, email e other.

O timestamp_ms tem uma regra que muda arquitetura: o carimbo precisa estar dentro dos últimos 7 dias e no máximo 10 minutos no futuro. Você não pode acumular pedidos do mês e mandar tudo no fechamento, e fila de retentativa parada mais de uma semana perde o evento em silêncio. Some a isso o comportamento do lote: até mil eventos por requisição e, se um falhar, o lote inteiro falha. Vale processar em lotes menores e logar a resposta.

Para melhorar o pareamento, o objeto user aceita campos opcionais como email_sha256 e external_id_sha256, além de country, city, zip_code, ip_address e user_agent, com hashes em SHA-256 minúsculo. Como sempre que dado de cliente sai da sua casa, isso é tratamento de dado pessoal: consentimento e base legal entram na arquitetura antes do primeiro envio. O pixel tem controle de consentimento próprio, que permite desligar o rastreamento antes da inicialização e ligar depois da permissão.

O que a janela de atribuição deixa de contar?

Aqui está a leitura honesta que quase nenhum material sobre o canal faz.

A atribuição por visualização usa janela fixa de um dia após uma impressão elegível. A atribuição por clique usa a janela configurada para a campanha, e quando a conversão é elegível pelos dois caminhos o clique tem precedência. A documentação pública consultada não detalha quais opções de janela de clique existem nem qual é a padrão; confirme no gerenciador ao criar a campanha.

Um dia é curto para produto físico. Pense no comportamento real de quem compra numa loja D2C: vê o anúncio no meio de uma conversa, não clica, procura a marca dois dias depois, compra na semana seguinte. Nada disso é contado como conversão do canal.

O efeito é assimétrico. O canal aparece pior do que é, e a diferença cresce justamente onde o ciclo de decisão é mais longo: ticket alto, categoria considerada, primeira compra numa marca desconhecida. Em compra por impulso a distorção é menor.

Isso não é motivo para inventar multiplicador de correção. É motivo para não decidir orçamento olhando só a coluna de conversão da plataforma, e para comparar a receita total da loja nos períodos com e sem o canal ligado. As métricas que sustentam decisão continuam sendo as suas.

Um cuidado extra: não existe evento documentado de reembolso na lista padrão. Pedido cancelado depois de contado continua contado, e a correção fica por sua conta na reconciliação.

Como reconciliar o número da plataforma com o pedido pago?

Com a mesma rotina que já vale para Meta e Google, aplicada a um canal em que ela importa mais, porque não há histórico para calibrar expectativa.

Escolha uma fonte da verdade e não negocie: o pedido aprovado na loja, líquido de cancelamento e devolução. Toda outra tela é estimativa. Compare em período fechado a receita que o ChatGPT Ads reporta com o que entrou de fato. Não existe diferença aceitável universal: ela depende do seu ticket, do seu ciclo e da sua taxa de devolução, então defina a sua faixa com os primeiros meses de dado e acompanhe se ela se mantém.

Três verificações mensais pegam a maior parte dos problemas. Se a contagem de order_created despencou sem mudança de verba, suspeite de implementação antes de mídia: template, plugin ou redirecionamento novo. Se a receita atribuída ficou exatamente cem vezes maior ou menor que a real, o problema é unidade monetária. Se a plataforma conta mais pedidos que a loja, a deduplicação não está funcionando.

Nada disso é específico da OpenAI, e vale mais aqui porque o canal é novo: quando o número parece bom ou ruim demais, o primeiro suspeito é a medição, não a campanha.

O que fica

A medição do ChatGPT Ads são duas fontes que se completam. O pixel vive no navegador, captura o oppref da URL e guarda em cookie primário. A Conversions API sai do seu servidor, é descrita pela OpenAI como fonte mais confiável, aceita lotes de até mil eventos e exige carimbo dentro dos últimos 7 dias. As duas juntas, com o mesmo identificador de evento, é o desenho recomendado.

O evento que interessa a uma loja é order_created, e a campanha de conversão aceita exatamente um evento padrão, sem troca depois de criada. O ponto mais frágil não é código: é o oppref sobreviver ao caminho até a página de obrigado.

E a janela de visualização fixa em um dia significa que o relatório vai contar menos venda do que o canal influenciou. Aceitar isso é mais barato que inventar correção. O que sobra é a conta de sempre, feita fora da plataforma: quanto entrou de pedido pago, quanto custou, e se a diferença justifica continuar. Essa conta não é sobre o ChatGPT, é sobre como a sua operação decide onde colocar o próximo real.