Analítica de checkout de agentes WooCommerce

Um cliente já não tem de visitar a sua loja para comprar nela. Em 2026, um agente de IA consegue ler o seu catálogo, adicionar um produto e finalizar uma encomenda WooCommerce em nome do comprador, e faz tudo isso através de uma interface, não num separador do navegador. A encomenda cai no seu painel de administração. O dinheiro chega. E a sua analítica não regista nada.

Isto não é hipotético. O próprio blogue de programadores do WooCommerce apresentou o roteiro de IA e agentic commerce, incluindo testes de checkout instantâneo fora da loja com parceiros como a Google e a Stripe, e o ecossistema está a fechar-se em torno dele mais depressa do que os plugins de rastreio conseguem acompanhar. Na WPPoland construímos e instrumentamos lojas WooCommerce para clientes que vendem por toda a UE, e as primeiras lojas a receber encomendas de agentes já veem a diferença entre o que venderam e o que os painéis dizem que venderam.

Aqui ficam o mecanismo, as coisas concretas que se avariam, porque a Conversions API não o salva automaticamente e a forma de instrumentar isto corretamente.

A escala cresce depressa: segundo a Stripe, o produto de pagamentos Link já serve cerca de 200 agentes de IA, contra cerca de 70 nos dados da empresa de setembro (Upstarts Media, 18.10.2026). A Stripe ressalva que a Anthropic e a OpenAI usam o Link, mas ainda não para compras feitas por agentes.

#Encomendas de agentes de IA que não aparecem no GA4

A resposta curta: não acontece nada à sua analítica, e esse é o problema. A sua pilha de relatórios foi construída sobre o pressuposto de que cada compra é precedida por um humano a carregar páginas num navegador. Um agente quebra esse pressuposto. Conclui a encomenda do lado do servidor, por isso cada sinal baseado no navegador de que a sua analítica depende simplesmente nunca dispara.

Fica com uma encomenda WooCommerce sem sessão correspondente no Google Analytics, sem evento correspondente no pixel da Meta e sem atribuição, porque não houve clique, não houve chegada com tag UTM e não houve navegador de onde ler o que quer que fosse. A receita é real. O rasto está vazio.

#Porque é que o GA4 e o pixel da Meta precisam do navegador

A maior parte da medição no WooCommerce é, por definição, do lado do cliente. O Google Analytics 4 recolhe através do gtag.js, um script que o navegador do visitante descarrega e executa. O pixel da Meta é a mesma ideia: um excerto que corre no navegador e reporta PageView, AddToCart, InitiateCheckout e Purchase à medida que o comprador avança pelo funil. O Google Tag Manager, o contentor por onde a maioria das lojas encaminha estas tags, é também um ambiente de execução do navegador.

Cada uma destas ferramentas precisa de uma página renderizada e de um script executado. É esse o único ponto de falha. Retire a sessão do navegador e retirou o único sítio onde estas tags alguma vez iriam correr.

Um checkout de agente retira a sessão do navegador.

#Que relatórios WooCommerce falham com encomendas de agentes

Vale a pena ser preciso, porque “a analítica avaria-se” esconde quantos relatórios separados correm mal ao mesmo tempo.

1. Funil e eventos de compra do GA4. Sem page_view, sem add_to_cart, sem begin_checkout, sem purchase. A encomenda nunca entra no GA4, por isso a receita, a taxa de conversão e o abandono do funil ficam todos subestimados.
2. A conversão do pixel da Meta. Nenhum evento Purchase chega à Meta a partir do navegador, por isso a venda falta no seu relatório de anúncios e no sinal de otimização com que o algoritmo aprende.
3. Atribuição. Os modelos de atribuição leem um clique, um referenciador, parâmetros UTM ou um client id guardado da sessão do navegador. Uma encomenda de agente não tem nenhum destes, por isso não pode ser atribuída a um canal, a uma campanha ou a uma fonte. Aparece, na melhor das hipóteses, como direta ou não atribuída, e muitas vezes nem isso.
4. Públicos de remarketing. Um comprador que o pixel nunca viu não pode ser adicionado a um público de clientes nem excluído de um público de prospeção. Vai continuar a pagar para anunciar a pessoas que já compraram através de um agente.
5. Retorno do investimento publicitário. A receita no WooCommerce deixa de bater certo com a receita nos seus painéis de anúncios. O ROAS parece pior do que a realidade, e a reação natural, mas errada, é cortar precisamente as campanhas que estão a funcionar.

Nada disto lança um erro. É isso que o torna perigoso. A loja continua a funcionar, as encomendas continuam a chegar, e os painéis afastam-se em silêncio da verdade.

#A Conversions API da Meta regista encomendas de agentes

A objeção óbvia é que a Meta já resolveu o rastreio do lado do servidor. A Conversions API envia eventos diretamente do seu servidor, sem navegador. Então as encomendas de agentes deviam estar cobertas.

Não estão, pelo menos não com uma instalação padrão, e a razão é a deduplicação. A Conversions API foi concebida para trabalhar ao lado do pixel, não em vez dele. Espera-se que envie a mesma conversão duas vezes, uma a partir do pixel do navegador e outra a partir do servidor, e a Meta funde o par num só através de um event_id e event_name partilhados. É esse o objetivo: medir de forma fiável sem contar duas vezes.

Uma encomenda de agente não tem metade de navegador. Não há evento de pixel para emparelhar com o evento de servidor, e as configurações CAPI populares para WooCommerce constroem a chave de deduplicação no momento em que a página de agradecimento é renderizada. Para uma encomenda de agente, essa página nunca é renderizada, por isso a chave nunca é produzida, e o evento de servidor ou não é enviado ou é enviado sem a informação de identidade que a Meta espera. O mesmo modelo de deduplicação que o protege de contar duas vezes as encomendas navegador-mais-servidor é o modelo que descarta em silêncio uma encomenda que só alguma vez existiu no servidor.

O rastreio do lado do servidor é a direção certa. Colar isso a um pressuposto de navegador primeiro não é o mesmo que estar pronto para agentes.

#Como rastrear compras WooCommerce do lado do servidor

A solução durável é deixar de tratar a renderização da página de agradecimento como o momento da verdade e começar a tratar a própria encomenda como o momento da verdade. A encomenda é a única coisa que existe de forma fiável independentemente de como a venda foi colocada.

Concretamente:

• Dispare a compra do lado do servidor a partir de um hook de encomenda. O WooCommerce levanta o woocommerce_order_status_completed e hooks de pagamento relacionados no servidor para todas as encomendas, de navegador ou de agente. Envie a sua compra do GA4 através do Measurement Protocol e o seu Purchase da Meta através da Conversions API a partir desse hook, para que a recolha já não dependa de uma página carregar.
• Deduplique pelo id da encomenda. Use o id da encomenda WooCommerce como event_id. Uma encomenda de navegador e o seu gémeo de servidor continuam a fundir-se numa só porque ambos carregam o mesmo id de encomenda, e uma encomenda apenas de agente passa de forma limpa porque a chave não precisa de contraparte de pixel.
• Marque a origem da encomenda. Guarde de onde veio a encomenda, o id do gateway ou um campo meta dedicado, no momento da criação. Agora cada relatório pode separar a receita de agentes da receita de navegador em vez de as fundir numa média que esconde a mudança.
• Reconstrua a atribuição em torno de uma identidade que realmente possui. Para encomendas de agentes, a conta do cliente, o email ou os próprios identificadores do agente são o que tem. Mapeie-os deliberadamente para os seus canais em vez de esperar que apareça uma string UTM.

Isto é engenharia WooCommerce comum, hooks, webhooks e eventos servidor-a-servidor, mas tem de ser concebida para o caso do agente desde o início, em vez de remendada num pixel que pressupõe um navegador.

#Como o WooCommerce regista a origem de uma encomenda

Antes de criar um campo de origem próprio, veja os dois sítios onde o WooCommerce já escreve dados de origem, porque ambos se comportam de forma diferente com encomendas de agentes.

O primeiro é a propriedade created_via da encomenda. No código-fonte do WooCommerce, o checkout clássico por shortcode define-a como checkout (class-wc-checkout.php), a Store API define-a como store-api (OrderController.php) e o endpoint de encomendas da REST API v3 define-a como rest-api, a não ser que o pedido traga o seu próprio valor de created_via (class-wc-rest-orders-controller.php). Este último pormenor é útil: uma integração que cria encomendas de agentes pela REST API pode marcá-las com um valor seu. O limite está na Store API. O checkout de blocos no navegador também passa pela Store API, por isso store-api sozinho não distingue um comprador num separador de um agente que chama o mesmo endpoint.

O segundo é a atribuição de encomendas. A documentação de atribuição de encomendas do WooCommerce descreve um conjunto de cookies sbjs_ que guardam o referenciador, os parâmetros UTM, o tipo de dispositivo e as visualizações de página da sessão, lidos apenas quando a encomenda é colocada e gravados como metadados da encomenda com o prefixo _wc_order_attribution. A etiqueta de origem na lista de encomendas é construída a partir de um tipo de fonte: UTM, orgânico, referência, direto, aplicação móvel, administração web ou ponto de venda. Tudo o resto cai em “Desconhecida” (OrderAttributionMeta.php). Um agente que nunca carrega a sua loja nunca recebe esses cookies, por isso as encomendas dele aparecem na coluna Origem como Desconhecida, ao lado de todas as outras encomendas cujos dados se perderam.

A ordem prática de trabalho é, portanto: leia primeiro o created_via, acrescente a sua própria marca apenas onde ele não consegue separar agente e navegador, e trate uma fatia crescente de origens Desconhecida como um primeiro sinal de que o tráfego de agentes começou.

#O que o ACP e o UCP passam ao comerciante para atribuição

Se uma encomenda de agente chega com alguma atribuição depende do protocolo por trás dela. O próprio artigo do WooCommerce refere o Agentic Commerce Protocol da Stripe e o trabalho em MCP; não menciona o UCP nem o AP2, por isso confirme o que a sua integração de pagamento ou de agente implementa de facto antes de confiar em qualquer um dos campos abaixo.

O Agentic Commerce Protocol é mantido pela OpenAI e pela Stripe, continua em beta, é publicado sob a licença Apache 2.0 e tem versões identificadas por data. Na especificação de checkout de 2026-04-17, o agente trabalha através de POST /checkout_sessions e depois de /complete ou /cancel nessa sessão. Tanto a chamada de criação como a de conclusão aceitam um objeto opcional affiliate_attribution: um provider obrigatório, mais um token ou um publisher_id, ids opcionais de campanha, criativo e sub-rastreio, e um touchpoint com o valor first ou last. A especificação diz que é só de escrita: fica guardado junto da encomenda resultante, mas não é devolvido na resposta. A encomenda devolvida na conclusão traz o seu próprio id, o checkout_session_id, um permalink_url e um estado, e o comerciante envia os eventos seguintes da encomenda de volta à plataforma do agente, assinados com um HMAC no cabeçalho Merchant-Signature. O checkout_session_id é a chave que vale a pena guardar na encomenda WooCommerce: liga a encomenda à conversa com o agente que a produziu.

Atualização, 28 de outubro de 2026. A sessão de checkout descrita acima é agora um caminho apenas para parceiros aprovados. A 24 de março de 2026, a OpenAI limitou o Instant Checkout no ChatGPT a parceiros aprovados, deixou os comerciantes usarem a sua própria finalização de compra e afirmou que se concentra em ajudar os compradores a encontrar produtos, com o ACP a servir para partilhar dados de produtos e promoções (OpenAI). Na maioria das lojas WooCommerce, uma compra que começa no ChatGPT termina, por isso, como uma visita à sua própria finalização de compra no navegador. Essa visita carrega a loja, pelo que os cookies sbjs_, a coluna Origem e as suas etiquetas do GA4 e da Meta a veem como qualquer outra sessão: a atribuição acontece no seu site, não num campo do ACP. Antes de criar uma regra para estas visitas, verifique nos dados das suas encomendas com que referenciador ou parâmetros UTM chegam de facto.

O Universal Commerce Protocol tem um campo de atribuição genérico. A visão geral da especificação define um campo attribution que as plataformas podem enviar em pedidos de carrinho, checkout e catálogo, com os mesmos parâmetros de campanha e ids de clique, como gclid ou fbclid, que de outra forma chegariam num URL. O UCP não impõe um modelo de atribuição, o campo é opcional e a especificação lembra que ids de clique e chaves de sessão podem ser dados pessoais, por isso as suas regras de consentimento e retenção aplicam-se a ele. A encomenda pode expor uma cópia só de leitura da atribuição do checkout, e os eventos do ciclo de vida da encomenda seguem para a plataforma como webhooks com cabeçalhos Standard Webhooks.

O AP2, anunciado a 16 de setembro de 2025, é uma camada de confiança para pagamentos e não uma fonte de analítica. O Checkout Mandate e o Payment Mandate assinados provam o que o utilizador autorizou. Dizem-lhe que a encomenda foi colocada por um agente, não que campanha levou até ela.

#Limites do Measurement Protocol e da Conversions API em encomendas de agentes

Passar a recolha para o servidor resolve os eventos em falta, mas ambas as APIs têm regras com que uma encomenda sem página choca.

O Measurement Protocol do GA4 espera, para streams web, um client_id igual ao ID que a tag Google gerou no navegador do visitante. Uma encomenda de agente não tem esse ID, por isso tem de criar um, e convém guardá-lo na encomenda para que reembolsos e eventos posteriores o reutilizem. Os eventos podem ser datados até 72 horas para trás, um pedido leva no máximo 25 eventos e o api_secret tem de ficar no servidor. A Google descreve o protocolo como pensado para ambientes do lado do servidor, com eventos juntos aos que o gtag.js recolhe, por isso uma encomenda de agente enviada com um client id acabado de criar conta como um utilizador novo, e não como o fim de uma sessão de navegador anterior.

Os parâmetros de eventos de servidor da Meta impõem um relógio mais apertado: o event_time pode ter no máximo 7 dias, e um único evento mais antigo faz a Meta rejeitar o pedido inteiro. Cada evento precisa de um action_source, um de email, website, app, phone_call, chat, physical_store, system_generated, business_messaging ou other. Se enviar website, o event_source_url é obrigatório, e uma encomenda de agente não tem URL de página para lá pôr. A lista da Meta não tem um valor para agentes de IA, por isso escolha um de forma deliberada, registe porquê e mantenha-o, porque trocar de valor mais tarde dificulta comparações entre o antes e o depois. A mesma página confirma que um número de encomenda é um event_id aceitável.

Essas janelas são também o seu orçamento de novas tentativas. Se o hook que envia o evento falhar, uma nova tentativa em fila tem 72 horas no GA4 e 7 dias na Meta antes de o evento se perder.

#Encomendas de agentes de IA, SAF-T e e-fatura

Em Portugal, esta diferença tem uma segunda camada. Uma encomenda de agente tem na mesma de gerar uma fatura certificada, entrar no ficheiro SAF-T (PT) e chegar ao registo da e-fatura da Autoridade Tributária, por isso, para a contabilidade, a encomenda existe perfeitamente, mesmo quando o GA4 nunca a viu. É muitas vezes o primeiro sítio onde o dono da loja repara no problema: o número de faturas comunicadas à AT não bate certo com o número de transações no painel de marketing. Reconciliar as vendas do SAF-T (PT) contra os números do painel de anúncios é uma forma prática de sequer detetar quantas encomendas chegaram por agentes, antes de corrigir a recolha do lado do servidor.

#Uma loja WooCommerce deve deixar entrar agentes de IA

Antes de uma encomenda de agente poder desaparecer do GA4, o agente tem de conseguir passar pelo checkout. O The Verge noticiou a 17 de outubro de 2026 que cada vez mais serviços fecham a porta aos agentes: o Yelp só admite agentes que pagam pelo programa de licenciamento de dados, a Delta Air Lines impede-os de comprar bilhetes, e o JPMorgan Chase e a Charles Schwab bloqueiam-lhes o acesso a contas por motivos de segurança. A Amazon bloqueou o agente de compras da Perplexity e processou a empresa; depois de um tribunal de recurso ter anulado a proibição em agosto, a Amazon apresentou uma queixa alterada. Do outro lado, a Meta fez parcerias com a Walmart, a Gap, a Sephora e a Best Buy para que o seu assistente Muse possa comprar nessas lojas, e a Shopify abriu as suas lojas aos agentes.

Para uma loja WooCommerce, a parte mais útil vem a seguir: os agentes também esbarram em sistemas antibot que nunca foram configurados contra eles. Houve utilizadores a relatar problemas no checkout da Walmart, apesar da parceria com a Meta. No WordPress, o mesmo efeito vem de regras de WAF, do Bot Fight Mode da Cloudflare, do Turnstile ou de um CAPTCHA no formulário de encomenda e dos limites de pedidos de um plugin de segurança. Essa encomenda não aparece no GA4 nem no WooCommerce, porque nunca chegou a ser criada.

A decisão é do dono da loja, mas deve ser tomada de forma consciente:

1. Reveja os eventos do WAF e os registos do servidor para /checkout/ e para a Store API (/wp-json/wc/store/v1/checkout) e conte quantos pedidos terminam em 403 ou num desafio.
2. Se quer receber encomendas de agentes, deixe-os entrar através de uma integração escolhida por si (ACP ou UCP), e não desligando a proteção do formulário para todos.
3. Se não quer, bloqueie-os explicitamente com uma regra para caminhos ou user agents específicos, em vez de deixar ao acaso qual bot passa pela camada antibot.

As regras da Walmart para agentes de compras, atualização de 23 de outubro de 2026: a 21 de outubro, a Walmart anunciou três peças. Os Agent Profiles, com lançamento previsto para o próximo mês, dão a cada agente autorizado pelo cliente um perfil próprio dentro da conta do cliente, para que as compras do agente apareçam em separado. O cliente escolhe se aprova cada encomenda ou se define um limite de gastos. O Walmart Agent Gateway permite aos agentes comprar através de MCP em vez de navegar por páginas feitas para pessoas, e arranca como beta para empresas e programadores. Os termos para agentes de IA dizem que o cliente aprova as compras do agente por predefinição, que os agentes nunca recebem os dados do cartão nem podem alterar os métodos de pagamento, que o processo de devoluções da Walmart se aplica mesmo quando um agente não age como pretendido, e que os agentes que violem os termos serão bloqueados. Para o cliente, os Agent Profiles fecham a mesma lacuna que este artigo trata do lado do comerciante: distinguir as encomendas de agentes das encomendas feitas por pessoas. Qualquer loja, em WooCommerce, Shopify ou plataforma própria, pode aplicar a ideia desde já: registar o agente como origem própria da encomenda, manter uma aprovação humana antes do pagamento e publicar o que os agentes podem e não podem fazer no seu site. O nosso serviço de preparação para o comércio com IA cobre essa configuração.

#Quando corrigir o rastreio de encomendas de agentes no WooCommerce

Por agora, as encomendas de agentes são um fio de água para a maioria das lojas, e é precisamente por isso que este é o momento certo para corrigir. As lojas que instrumentam a recolha do lado do servidor enquanto o volume é pequeno terão números limpos e comparáveis quando já não for. As lojas que esperam vão passar 2027 a tentar explicar uma diferença cada vez maior entre a sua receita WooCommerce e os seus painéis de anúncios, e reconstruir a atribuição sob pressão é muito mais caro do que construí-la uma vez, com calma, agora.

Se vende através do WooCommerce e começa a ver encomendas que os seus pixels não conseguem explicar, esse é o sinal. É um problema de canalização com uma solução conhecida, e é o tipo de trabalho que se paga a si mesmo da primeira vez que uma campanha que estava prestes a cortar afinal era rentável o tempo todo.

Fazemos este trabalho como parte dos nossos projetos de desenvolvimento WooCommerce, e ele fica ao lado da questão mais ampla de saber se a sua loja é sequer descoberta e comprada por agentes, que abordamos no nosso guia de prontidão para o comércio de IA e na explicação do Universal Commerce Protocol. Se quiser perceber como os agentes chegam sequer ao seu catálogo, o nosso servidor MCP do WooCommerce apenas de leitura mostra a mecânica, e para as fundações do lado do cliente que continuam a contar, o nosso guia Google Analytics 4 para WordPress cobre o lado do navegador que as encomendas de agentes contornam.

Última atualização: 20 de outubro de 2026.