MCP com Chrome: Automação com IA · Capítulo 15 de 16 · 43 min
Provar que a conversão dispara antes de culpar a tag
Entre o time de mídia e o de tecnologia, o log de rede decide quem tem razão, desde que você não reprove uma tag funcionando.
Este capítulo faz parte do curso gratuito MCP com Chrome: Automação com IA.
O que é: a prova, capturada direto do navegador, de que uma conversão realmente disparou e chegou do outro lado, no lugar da palavra de um time contra o outro. Por que importa: quando a mídia diz que a conversão sumiu e a tecnologia diz que está tudo instalado, a verba continua queimando enquanto a discussão não fecha. A sua decisão: definir que print de painel não encerra a disputa e que a prova aceita é a tripla de requisição capturada, horário e confirmação na fonte. O que delegar: capturar a requisição, ler o payload e confirmar a chegada. O passo a passo para operar vem logo abaixo.
Glossário rápido
Três camadas de prova
Imagine uma encomenda: o pacote embalado, o comprovante de postagem e o aviso de entrega. O dataLayer prova que o dado foi montado na página (embalado), a requisição de rede prova que ele saiu do navegador (postado) e o relatório em tempo real prova que foi aceito do outro lado (entregue). Um laudo que mostra só a primeira e conclui sobre a terceira inventou o meio do caminho.
Preservação de requisições
O log de rede do navegador é apagado a cada página nova, e muita conversão dispara justamente na navegação seguinte. Preservar as requisições é o interruptor que mantém a trilha entre as páginas, para o disparo não cair no vão e uma tag que funciona não ser condenada por engano.
A reunião tem sempre o mesmo roteiro. O time de mídia diz que a conversão (o registro de que o visitante comprou ou pediu contato, como o bip do caixa) parou de chegar. O time de tecnologia abre o gerenciador de tags, mostra a tag publicada e diz que está tudo instalado. Você fica no meio, sem instrumento para decidir quem tem razão, e a verba continua rodando enquanto a discussão se arrasta.
O agente com browser resolve isso porque ele consegue fazer a única coisa que encerra a conversa: capturar a requisição que sai do navegador e mostrar o que foi enviado. Interface de configuração é promessa. Requisição de rede é entrega.
Aqui, print de painel não conta como prova. Painel mostra um número agregado, com atraso de processamento, filtro de propriedade e amostragem no meio do caminho. O que serve de prova para um terceiro é a tripla: requisição capturada com payload legível, horário, e confirmação de chegada na fonte.
Antes de abrir qualquer ferramenta, fixe o falso negativo mais caro deste trabalho: olhar o log de rede, não ver a requisição e reprovar uma tag que estava funcionando. Isso acontece porque o log é zerado a cada navegação, e boa parte das conversões dispara justamente na navegação seguinte ou na saída da página.
Quem não sabe disso condena a tag certa e manda o time de tecnologia refazer um trabalho que estava correto.
Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.
Ausência de requisição no log, sem preservação ligada, só prova que você não capturou nada; tag quebrada é outra conclusão. As duas coisas parecem iguais na tela e significam o oposto uma da outra. Só depois de ativar a preservação de requisições a ausência começa a valer como sinal.
A ferramenta que resolve isso no chrome-devtools-mcp é a list_network_requests. Ela aceita paginação, filtro por tipo de recurso e o parâmetro includePreservedRequests, que é exatamente o interruptor que impede o log de ser descartado quando a página navega.
Primeiro navegue, depois filtre; a ordem inversa perde o disparo.
// Passo 1: leve o navegador ao ponto de partida da jornada.
// A navegacao vem ANTES da captura, senao voce mede uma pagina ja aquecida.
{
"tool": "navigate_page",
"params": {
"url": "https://seusite.exemplo/produto/plano-anual"
}
}
// Passo 2: execute o fluxo ate o fim (clique, formulario, envio).
// Use as ferramentas de input do servidor, nunca coordenada de pixel.
// Passo 3: liste as requisicoes PRESERVANDO o que veio das navegacoes anteriores.
// Sem includePreservedRequests, tudo que ocorreu antes da ultima navegacao sumiu.
{
"tool": "list_network_requests",
"params": {
"includePreservedRequests": true,
"resourceTypes": ["xhr", "fetch", "image", "ping"],
"pageSize": 100
}
}O filtro por tipo de recurso existe porque uma página comum dispara centenas de requisições e quase todas são imagem, fonte e script de layout. Coleta de evento costuma viajar como xhr, fetch, image (o pixel clássico, uma imagem de um pixel com os dados na URL) ou ping (o envio de saída de página, feito para sobreviver ao fechamento).
Comece largo, com os quatro tipos, e só estreite depois que souber por qual deles a sua plataforma manda.
1. navigate_page .............. leva o browser ao início do trajeto 2. executar o fluxo ........... clique, preenchimento, envio 3. wait_for ................... espera o estado observável de conclusão 4. list_network_requests ...... includePreservedRequests: true 5. get_network_request ........ lê o payload cru da requisição suspeita 6. confirmação na fonte ....... relatório em tempo real da plataforma ^ inverter 1 e 4 mede página aquecida ^ pular 3 captura antes do disparo acontecer ^ pular 6 entrega envio, não chegada
Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.
Localizada a requisição, o próximo passo é ler o conteúdo dela com get_network_request. Aqui mora o valor real do módulo: você deixa de discutir o que a tag deveria enviar e passa a ler o que ela enviou.
Duas formas de transporte aparecem. Em GET, os pares de chave e valor viajam na query string da URL. Em POST, viajam no corpo, e olhar só a URL não mostra nada.
// Leia a requisicao inteira: cabecalhos, metodo, query string e corpo.
// A URL vem da listagem do passo anterior, copiada exatamente como saiu la.
{
"tool": "get_network_request",
"params": {
"url": "https://coleta.plataforma.exemplo/endpoint?..."
}
}Não decore nomes de parâmetro. Cada plataforma nomeia o campo do evento à sua maneira e essas chaves mudam entre versões de tag. O hábito que resiste a essas mudanças é decodificar o payload capturado e ler os pares que estão lá, comparando com a documentação vigente da plataforma no dia da auditoria. Laudo que cita parâmetro de memória envelhece e vira erro.
// Decodificador de payload de coleta. Rode em Node (node decodificar.js)
// colando a URL capturada. Serve para GET (query string) e para corpo
// no formato application/x-www-form-urlencoded.
const entrada = process.argv[2] || "";
// Se veio URL completa, separa o endpoint da query string.
const temUrl = entrada.startsWith("http");
const query = temUrl ? entrada.slice(entrada.indexOf("?") + 1) : entrada;
if (temUrl) {
console.log("endpoint:", entrada.split("?")[0]);
}
// Cada par chave=valor vira uma linha legivel, ja decodificada.
const pares = new URLSearchParams(query);
for (const [chave, valor] of pares.entries()) {
console.log(`${chave.padEnd(24)} = ${valor}`);
}
// Payload em JSON (algumas plataformas mandam assim) cai no catch e
// e impresso formatado, para voce ler os campos do evento na mao.
try {
if (!temUrl && entrada.trim().startsWith("{")) {
console.log(JSON.stringify(JSON.parse(entrada), null, 2));
}
} catch {
console.log("corpo nao e JSON valido, trate como texto");
}Falta a camada da página. O dataLayer é o vetor que o gerenciador de tags lê para montar os disparos, e ele é útil para diagnosticar de onde veio o dado. Mas ele prova apenas que a informação foi montada dentro da página.
Entre o dataLayer e a requisição existem consentimento, condição de gatilho, bloqueio de extensão e erro de configuração. Confundir as duas camadas é o segundo erro mais comum deste trabalho.
// Leia o dataLayer da pagina como ele esta no momento da captura.
// Isso mostra a INTENCAO: o que a pagina ofereceu ao gerenciador de tags.
{
"tool": "evaluate_script",
"params": {
"function": "() => (window.dataLayer || []).map((e) => JSON.parse(JSON.stringify(e)))"
}
}Três camadas, três vereditos diferentes. dataLayer prova intenção (o dado foi montado). Requisição de rede prova envio (o dado saiu do navegador). Relatório em tempo real prova chegada (o dado foi aceito do outro lado). Um laudo que apresenta só a primeira camada e conclui sobre a terceira está inventando o meio do caminho.
Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.
A terceira camada é a que encerra a discussão, e ela não vem do browser. Para o Google Analytics existe servidor MCP (programa que liga o assistente a um sistema, como uma tomada padrão) oficial, no repositório googleanalytics/google-analytics-mcp, licença Apache 2.0, com sete ferramentas, entre elas run_realtime_report, que é exatamente a que confirma a chegada do evento poucos segundos depois do disparo.
O ciclo fica fechado: o agente dispara o evento no navegador e, em seguida, confirma a chegada pelo lado do dado, sem trocar de ferramenta e sem esperar processamento diário.
Para o Search Console não existe servidor MCP oficial. Todas as implementações disponíveis são de terceiros, e isso traz risco de escopo concedido e de manutenção abandonada. Se for usar uma delas, leia o que ela pede de permissão antes de autorizar, e prefira uma conta com acesso mínimo à propriedade.
Meia página basta para o laudo deste módulo. Ele existe para ser lido por alguém que não estava na sessão e que precisa decidir sobre verba. Por isso ele tem quatro elementos, e não três nem cinco.
LAUDO DE CONVERSÃO .......... <nome do evento> 1. URL e horário Fluxo: /produto/plano-anual -> /checkout -> /obrigado Captura: 2026-07-19 14:32 (America/Sao_Paulo) Preservação de requisições: ATIVA 2. Requisição capturada Endpoint: <host de coleta>/<caminho> Método: POST Momento: na transição /checkout -> /obrigado 3. Payload (campos lidos, não deduzidos) nome do evento ....... <valor exato lido> parâmetro 1 .......... <valor exato lido> parâmetro 2 .......... <valor exato lido> 4. Confirmação na fonte Relatório em tempo real: evento presente às 14:32, contagem 1 Ferramenta: servidor MCP oficial de Analytics (run_realtime_report) VEREDITO: a tag dispara e o evento chega. A ausência relatada pelo time de mídia não está na coleta; investigar janela de atribuição e filtro do relatório usado na reunião.
Depois de fechar o laudo, repita o mesmo fluxo com a preservação desligada e guarde o resultado ao lado. Você vai ver a mesma conversão funcionando aparecer como ausente. Esse par de evidências é a melhor peça didática que existe para convencer um time inteiro a nunca mais reprovar uma tag olhando um log zerado.
Concluir que o pixel não dispara porque a requisição não apareceu (log zerado). Auditar com cache quente e comparar com uma medição a frio. Ler só o dataLayer e assinar veredito sobre chegada. Citar nome de parâmetro de memória em vez do que foi lido no payload. E aceitar print de painel como prova, quando painel agrega, atrasa e filtra.
Guia prático: auditar GA4, Meta Pixel e UTMs numa landing de campanha
O laudo de conversão acima responde se um evento chegou. O roteiro abaixo é a rotina completa que a equipe de mídia pede antes de subir verba: as duas tags principais disparam, a página preserva os parâmetros de campanha, o consentimento se comporta como prometido e o peso das tags de anúncio cabe na página. Rode no servidor do Chrome com perfil isolado.
Analista de mídia de uma escola de idiomas
Educação, captação de alunos por Meta Ads e Google Ads
Dor
O gerenciador do Meta mostra 40 leads na semana e o GA4 mostra 12 formulários enviados. Cada time culpa a tag do outro.
Solução
Uma rotina com o agente: abrir a landing com UTMs, aceitar o consentimento, enviar o formulário de teste e capturar as requisições do GA4 e do Pixel com preservação ligada, lendo os parâmetros do payload.
Resultado
A rotina mostra que o Pixel dispara Lead no clique do botão e o GA4 só na página de obrigado, que perde as UTMs no redirecionamento. A diferença tinha causa nomeada, e a correção virou tarefa de uma linha.
Cenário construído para fins didáticos. Números não correspondem a cliente específico.
Auditoria de tags de uma landing antes de subir verba
Sete passos. Use um formulário de teste combinado com o time comercial, para o lead falso não entrar no funil.
Passo 1: Navegue até a URL exata do anúncio, com todos os parâmetros utm_ e o identificador de clique de teste
Copie a URL do próprio gerenciador de anúncios, não a montada de cabeça. A página de entrada é onde a campanha costuma se perder.
Deu certo quando: take_snapshot mostra a landing carregada e a barra de endereço com as UTMs intactas.
Erro comum: Testar a URL sem parâmetros e concluir que a atribuição funciona.
Passo 2: Decida o consentimento antes de qualquer clique e registre a decisão
Rode duas vezes: uma aceitando e outra recusando o banner. Com o modo de consentimento, a recusa muda o que a tag envia; o comportamento esperado é o que a política do site declara.
Deu certo quando: Duas capturas rotuladas, aceitou e recusou, com diferenças que batem com a política.
Erro comum: Auditar só com tudo aceito e assinar que o site respeita a recusa.
Passo 3: Execute o fluxo até a página de obrigado e liste as requisições com includePreservedRequests ligado
Filtre pelos tipos de recurso de coleta. Procure as chamadas para os hosts do Google Analytics e para facebook.com/tr, o endpoint do Pixel que aparece no código-base da documentação da Meta.
Deu certo quando: Pelo menos uma requisição de cada plataforma no momento do envio.
Erro comum: Procurar só google-analytics.com quando a empresa usa tag no próprio domínio (gateway ou tag do lado do servidor). Pergunte antes qual host coleta.
Passo 4: Leia o payload de cada requisição com get_network_request e confira nome do evento e endereço da página
O endereço da página dentro do payload precisa carregar as UTMs da chegada. Se o formulário redireciona, compare a primeira página com a de obrigado.
Deu certo quando: Nome do evento e utm_source, utm_medium e utm_campaign lidos no payload, sem dedução.
Erro comum: Usar Resend ou Edit and resend do painel de rede numa requisição de conversão em produção. Reenviar duplica o evento na plataforma.
Passo 5: Abra Application, seção Ads, para ver o peso das tags de anúncio
O painel novo do Chrome 153 e 154 mostra densidade e contagem de anúncios na tela, CPU e rede gastas por anúncios e a tabela de scripts de anúncio do frame principal.
Deu certo quando: Você sabe quantos scripts de anúncio a landing carrega e quanto de rede eles consomem.
Erro comum: Ler as métricas como problema da plataforma de anúncio. Na sua própria landing, script de remarketing duplicado é o suspeito mais comum.
Passo 6: Confirme a chegada no DebugView do GA4 e na ferramenta de teste de eventos do Gerenciador de Eventos da Meta
As duas telas são a terceira camada do laudo: envio visto no navegador e recebimento visto na plataforma.
Deu certo quando: O evento de teste aparece nas duas plataformas com o mesmo horário da captura.
Erro comum: Conferir no relatório padrão do GA4, que tem atraso de processamento, e concluir que nada chegou.
Passo 7: Feche o laudo com uma linha por plataforma: disparou, com quais parâmetros, em qual página, chegou ou não
Se uma plataforma dispara no clique e a outra na página de obrigado, as contagens nunca vão bater, e isso não é defeito de nenhuma das duas.
Deu certo quando: Quem lê o laudo entende a diferença de números sem abrir ferramenta nenhuma.
Erro comum: Entregar só prints de painel, sem payload.
No fim você tem: Um laudo de meia página que mostra o que cada tag envia, quando envia e se a campanha chega com as UTMs até a conversão.
Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.
Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.
Escolha uma conversão que esteja em disputa hoje, de verdade. Execute o fluxo completo com preservação de requisições ativa, capture o payload do disparo com o nome do evento e dois parâmetros, e confirme a chegada no relatório em tempo real. Monte o laudo de meia página com os quatro elementos.
Depois repita o mesmo fluxo sem preservação, salve as duas saídas lado a lado e escreva uma frase explicando ao time por que a segunda versão condenaria uma tag correta.
Critério de sucesso observável: (1) o laudo contém o payload capturado com o nome do evento legível e a evidência de chegada na fonte, ou demonstra com a mesma clareza a ausência do disparo, mostrando a lista filtrada que foi examinada; (2) existe o par de execuções com e sem preservação, provando o falso negativo; (3) nenhum campo do laudo foi deduzido, todos foram lidos. Um print do painel da plataforma, sozinho, não conta como prova neste módulo.
A decisão executiva é qual evidência a sua operação aceita antes de mexer em verba. Estabeleça que nenhuma tag seja dada como quebrada ou como funcionando a partir de um print de painel, e que todo veredito mostre o payload lido e a confirmação na fonte. Esse padrão encurta a reunião e evita refazer trabalho que já estava certo.
Seu caderno neste capítulo
Abrir o caderno completoSelecione um trecho do capítulo para destacar ou anotar. Nos vídeos e áudios, use Anotar este momento. No teclado, selecione com Shift e as setas e use Alt+Shift+D para destacar ou Alt+Shift+N para anotar.
Salvo neste navegador. Entre na sua conta para levar o caderno a outros aparelhos.
Entre na sua conta para compartilhar o que aprendeu e convidar alguém para estudar com você.
Conexões deste capítulo
Veja o que estudar antes e para onde seguir depois, explore os conceitos e compare abordagens em outros cursos. Sugestões marcadas como “sugerido pelo grafo” vêm dos assuntos em comum, não do índice do curso.
Estude antes
- CursoMCP para quem decidesugerido pelo grafo7 capítulos de “MCP com Chrome: Automação com IA” usam conceitos apresentados em “MCP para quem decide”.
- CursoNode.js: JavaScript no Servidorsugerido pelo grafo3 capítulos de “MCP com Chrome: Automação com IA” usam conceitos apresentados em “Node.js: JavaScript no Servidor”.
- CursoSetup Completo: do zero ao Claude Codesugerido pelo grafo3 capítulos de “MCP com Chrome: Automação com IA” usam conceitos apresentados em “Setup Completo: do zero ao Claude Code”.
- CursoVídeo com IA: Claude Code, Codex e ElevenLabssugerido pelo grafo3 capítulos de “MCP com Chrome: Automação com IA” usam conceitos apresentados em “Vídeo com IA: Claude Code, Codex e ElevenLabs”.
Conceitos deste capítulo
O mesmo assunto em outros cursos
- Agentes de IA Autônomos: Do Conceito à ProduçãoFerramentas e function callingExaminar conexões de Ferramentas e function calling
- CRO: Otimização de Conversão e ExperimentaçãoO motor de aquisição: CRM, inbound, outbound, SEO, GEO e mídia pagaExaminar conexões de O motor de aquisição: CRM, inbound, outbound, SEO, GEO e mídia paga
- GEO Universal FrameworkMeça a presença em IA em três camadas confiáveisExaminar conexões de Meça a presença em IA em três camadas confiáveis
- Node.js: JavaScript no ServidorCriando um servidor HTTPExaminar conexões de Criando um servidor HTTP
Leve uma ideia para a prática
Escolha uma atividade no painel e volte a este curso quando quiser.
Atividades e evolução ficam reunidas no painel da sua conta.