Connect rate baixo: o que pode ser e como resolver sem perder velocidade

Connect rate baixo quase sempre tem uma de duas origens: a página demora para aparecer e a pessoa desiste antes de ver a oferta, ou a página aparece rápido, mas a medição chega tarde ou nem chega. A primeira todo mundo conhece. A segunda pega justamente quem já fez a lição de casa: otimizou imagem, ligou cache, deixou o PageSpeed verde e, mesmo assim, viu a métrica continuar lá embaixo.

O culpado mais comum desse segundo caso é o próprio plugin de otimização. Para ganhar nota, ele segura o JavaScript da página até a primeira interação do visitante, e o Pixel da Meta vai junto. Eu resolvo isso tirando o Pixel do WordPress: instalo pelo Cloudflare Zaraz, no navegador e pela API de Conversões, com o mesmo event ID. A página continua voando, e o PageView sai sem ninguém precisar tocar na tela.

Neste artigo eu mostro como chegar à causa do seu connect rate baixo, o que acontece com o Pixel atrasado e o passo a passo do jeito que eu configuro, com prints e números reais de uma página de cliente (anônima).

O que é connect rate e como calcular#

Connect rate é a porcentagem de pessoas que clicaram no anúncio e chegaram a ver a página carregar. No Gerenciador de Anúncios, a conta é:

Connect rate = visualizações da página de destino ÷ cliques no link × 100

A própria Meta explica que comparar essas duas métricas mostra quantas pessoas clicaram, mas saíram antes de o site carregar. Se o seu anúncio teve 1.000 cliques no link e 600 visualizações da página de destino, o connect rate é de 60%: 400 cliques pagos que, pelo menos na medição, não viraram visita.

Como a Meta mede a visualização da página

Este detalhe muda o diagnóstico. Segundo a Central de Ajuda, a visualização da página de destino é rastreada quando a pessoa abre a página no navegador do próprio app (Facebook ou Instagram) ou quando o Pixel da Meta está instalado nela. Quando falta dado, a Meta pode usar modelagem estatística.

Ou seja: a métrica depende de duas coisas, a página carregar e a Meta conseguir enxergar esse carregamento. Por isso, um Pixel mal configurado pode derrubar o connect rate mesmo com a página perfeita.

Por que o connect rate fica baixo#

Antes de mexer em qualquer coisa, separe as causas. Estas são as que eu mais encontro:

A página demora para aparecer

É a causa clássica. Quem clica no anúncio está no celular, muitas vezes com internet instável, e tem pouca paciência. Página pesada, imagem enorme na primeira dobra, fonte que bloqueia o texto, script de terceiro carregando antes do conteúdo: cada um desses itens empurra o momento em que a oferta aparece.

Redirecionamentos no caminho

Link do anúncio que passa por encurtador, por http antes do https ou por uma URL antiga redirecionada faz o navegador ir e voltar antes de começar a carregar a página de verdade. Cada salto é tempo de espera a mais.

O problema está em um anúncio ou posicionamento específico

Quebre o relatório por anúncio e por posicionamento. Se um posicionamento tem muito clique e pouca visualização, enquanto os outros vão bem, o problema está na origem do clique, não na página.

O Pixel não dispara, ou dispara tarde demais

É aqui que mora o caso mais traiçoeiro: página rápida, nota alta, e mesmo assim a métrica baixa. Vale uma seção só para ele.

O vilão de quem já otimizou tudo: o JavaScript atrasado#

Plugins de otimização como WP Rocket e LiteSpeed Cache têm uma função feita para subir a nota do PageSpeed: atrasar a execução do JavaScript.

• No WP Rocket, a opção Delay JavaScript execution segura todos os arquivos JavaScript e scripts inline até a primeira interação: mover o mouse, tocar na tela, rolar ou apertar uma tecla.
• No LiteSpeed Cache, a opção Load JS Deferred no modo Delayed faz o mesmo: o JavaScript só roda depois de detectar atividade do visitante.

O teste de velocidade não toca na tela. Para ele, quase todo o JavaScript simplesmente não existe, e a nota sobe. O problema é que o Pixel da Meta também é JavaScript. Se ele não foi excluído do atraso, o efeito é este:

1. A pessoa clica no anúncio, a página aparece rápido e ela começa a ler sem tocar em nada.
2. O Pixel continua parado, esperando a primeira interação.
3. Se ela sai antes de rolar ou tocar, o PageView nunca é enviado.

Nos casos em que a Meta depende do Pixel para medir a visita, essa pessoa some do connect rate. E, mesmo quando o navegador do app registra a visualização, o PageView que não chegou faz falta do mesmo jeito: o público de remarketing fica menor e o algoritmo recebe menos sinal sobre quem visitou a página.

Excluir o Pixel do atraso resolve?

Os dois plugins permitem excluir scripts do atraso. No WP Rocket, pela lista de exclusões ou pelo atributo nowprocket. No LiteSpeed Cache, pelo campo JS Deferred/Delayed Excludes. Funciona, e é melhor do que nada.

Mas eu não confio nesse caminho para uma operação que vive de tráfego pago. A exclusão precisa pegar o código base do Pixel e o script inline, se perde fácil numa atualização de plugin ou numa troca de tema, e o Pixel continua disputando a fila com todo o resto do WordPress. Se a sua página vive no Elementor, eu falo mais sobre esse peso no artigo Elementor ou código puro.

Como eu resolvo: Pixel e API de Conversões pelo Cloudflare Zaraz#

O Cloudflare Zaraz é o gerenciador de tags da Cloudflare. Com ele ligado, a própria Cloudflare insere um script pequeno na página, e é por ele que as ferramentas de terceiros carregam: Pixel da Meta, GA4, Google Ads, Clarity. Você não cola código de rastreamento no WordPress, então o plugin de cache não tem o que atrasar.

Na minha configuração, o evento PageView vai por dois caminhos ao mesmo tempo:

1. No navegador: uma ferramenta de HTML personalizado no Zaraz carrega o Pixel da Meta e dispara o PageView no gatilho de Pageview, já com um ID de evento.
2. Pelo servidor: a ferramenta nativa da Meta no Zaraz envia o mesmo PageView pela API de Conversões, com o campo Event ID preenchido com a mesma variável.

O código do navegador fica assim (troque SEU_PIXEL_ID pelo ID do seu Pixel):

<script>
  !function(f,b,e,v,n,t,s){if(f.fbq)return;n=f.fbq=function(){n.callMethod?
  n.callMethod.apply(n,arguments):n.queue.push(arguments)};if(!f._fbq)f._fbq=n;
  n.push=n;n.loaded=!0;n.version='2.0';n.queue=[];t=b.createElement(e);t.async=!0;
  t.src=v;s=b.getElementsByTagName(e)[0];s.parentNode.insertBefore(t,s)}
  (window,document,'script','https://connect.facebook.net/en_US/fbevents.js');

  fbq('init', 'SEU_PIXEL_ID');
  // o mesmo número vai para a API de Conversões
  fbq('track', 'PageView', {}, { eventID: '{{ system.misc.random }}' });
</script>

O mesmo event ID: como a Meta desduplica

Mandar o mesmo evento pelo navegador e pelo servidor só funciona se a Meta souber que é a mesma visita. A regra está na documentação de desduplicação: o nome do evento precisa ser igual e o eventID do Pixel precisa bater com o event_id da API, dentro de 48 horas.

O truque está na variável {{ system.misc.random }}. A documentação do Zaraz define essa variável como um número aleatório único por requisição. Como as duas ferramentas são disparadas pela mesma requisição de Pageview, as duas recebem o mesmo número. No Gerenciador de Eventos, o resultado aparece assim:

Rápido mesmo carregando o Pixel

A pergunta que sempre aparece: carregar o Pixel no navegador não deixa a página pesada de novo? Na prática, não. Esta é uma página de lançamento de um cliente (anônimo), testada no GTmetrix com iPhone em 4G, a partir de São Paulo:

E aqui está a linha do tempo real do carregamento, montada a partir da cascata do mesmo teste:

O conteúdo aparece em 0,8 segundo. Depois disso, sem disputar espaço com o que importa, o script do Zaraz carrega o Pixel, e o PageView é enviado em 1,96 segundo, sem ninguém tocar na tela. Velocidade e medição deixam de ser uma escolha entre uma e outra.

Por que Zaraz e não Google Tag Manager#

Muita gente instala o Pixel pelo Google Tag Manager achando que já resolveu a questão da velocidade. O GTM organiza as tags, mas não muda onde elas rodam. No contêiner web, que é o que quase todo mundo usa, o Google descreve o funcionamento assim: um contêiner dentro da página envia os dados para cada ferramenta. Na prática, o navegador do visitante precisa baixar o gtm.js do domínio do Google, executar o contêiner e só então começar a carregar o Pixel.

E se o código do GTM está colado no WordPress, ele também é JavaScript inline: entra no atraso do WP Rocket ou do LiteSpeed Cache se não for excluído, e aí o Pixel espera duas vezes. Na minha experiência, quando o Pixel vai pelo GTM, o PageView chega bem mais tarde, e o connect rate sente.

O Zaraz parte de outra lógica. A Cloudflare apresenta a ferramenta como um jeito de levar as ferramentas de terceiros para a nuvem, com impacto quase zero na performance. A página carrega um script pequeno do próprio domínio, e o que pode ir pelo servidor, como a API de Conversões, sai da Cloudflare direto para a Meta.

O GTM continua sendo uma ótima ferramenta, principalmente em sites grandes, com muitas tags e times de marketing acostumados com ele. Mas, para landing page de tráfego pago, em que cada visita medida conta, o Zaraz entrega a mesma organização com menos peso no navegador e o servidor já incluído.

Evento de Lead com dados que a Meta usa#

O mesmo raciocínio vale para a conversão que importa. No formulário das páginas que eu entrego, o envio dispara o evento de Lead pelo Zaraz, já com os dados que a pessoa digitou:

// no envio do formulário, depois de validar os campos
const tel = whatsapp.replace(/\D/g, '');
zaraz.track('Lead', {
  fn: nome,
  em: email,
  ph: '55' + tel // a Meta só usa o telefone com o código do país
});

A ferramenta da Meta no Zaraz faz o trabalho pesado:

• Criptografia: normaliza e criptografa com SHA-256 o e-mail, o telefone, o nome, a cidade, o estado e o país antes de enviar, como a Meta exige.
• Identificação do navegador e do clique: mantém o fbp em cookie e monta o fbc a partir do fbclid de quem veio do anúncio.
• IP e agente do usuário: vão automaticamente, sem você mexer em nada.
• País, cidade e estado: como a Cloudflare já sabe de onde vem a visita, dá para mapear esses dados nos campos padrão da ferramenta.

Esse volume de informação aparece na qualidade da correspondência de eventos, uma nota de 0 a 10 que a Meta calcula para os eventos do servidor. Segundo a Meta, quanto melhor a correspondência, maior a chance de atribuir a conversão ao anúncio e de entregar para quem tem mais probabilidade de converter. E-mail e identificação do clique estão no topo da lista de prioridade. Telefone, país e identificação do navegador vêm logo depois.

Checklist para diagnosticar o seu connect rate baixo#

Leva uns 15 minutos e já aponta para onde olhar:

1. No Gerenciador de Anúncios, coloque Cliques no link e Visualizações da página de destino lado a lado, por anúncio e por posicionamento.
2. Teste a URL exata do anúncio no PageSpeed Insights ou no GTmetrix, no perfil de celular.
3. Confira se o link abre direto na URL final, com https, sem redirecionamento no caminho.
4. Se a página é WordPress, veja se o atraso de JavaScript está ligado: Delay JavaScript execution no WP Rocket ou Load JS Deferred em Delayed no LiteSpeed Cache.
5. Abra o Testar eventos, acesse a página pelo celular e não toque em nada. O PageView precisa chegar sozinho.
6. Se você usa Pixel e API de Conversões juntos, confira se o evento do navegador aparece como desduplicado. Se aparecerem dois processados, o event ID não está batendo.
7. Veja a qualidade da correspondência do seu evento de Lead e quais dados a Meta sugere acrescentar.

Conclusão: velocidade e medição não são uma troca#

O erro mais comum que eu vejo é tratar connect rate só como problema de velocidade. Velocidade importa, e muito, mas página rápida com Pixel atrasado continua perdendo visita na medição, público de remarketing e sinal para o algoritmo. O jeito de ter as duas coisas é tirar o trackeamento de dentro do WordPress e do GTM e entregar pelo Cloudflare Zaraz, com navegador e servidor falando a mesma língua pelo event ID.

É assim que eu monto as páginas que entrego, do Figma ao trackeamento validado no Gerenciador de Eventos, como descrevo no meu processo. Se o seu connect rate está baixo e você não sabe se o problema é a página, o Pixel ou os dois, me chame: eu olho a sua página, o seu Gerenciador de Eventos e digo o que está travando.