fbclid, gclid e UTMs: a anatomia dos parâmetros de clique e como não perdê-los

Toda conversão que você mede começa com um clique. Entre esse clique no anúncio e a venda que acontece minutos, horas ou dias depois, existe uma cadeia de identificadores que a plataforma de anúncios usa para dizer "esse pedido veio daquela campanha". Quando um elo dessa cadeia se rompe, a conversão até acontece — o cliente paga, o produto é enviado — mas ela chega à plataforma órfã, sem origem, e a otimização passa a decidir no escuro.

Os dois tipos de identificador que carregam essa informação são os parâmetros de campanha (as UTMs) e os click IDs de plataforma (fbclid, gclid e parentes). Eles têm funções diferentes, viajam por caminhos diferentes e se perdem por motivos diferentes. Entender a anatomia de cada um é o que separa uma implementação de mensuração que fecha a conta de uma que vaza sinal em silêncio.

Dois mundos: parâmetros de campanha e click IDs#

É comum tratar tudo que vem depois do ? na URL como "os parâmetros de rastreamento". Na prática, existem duas categorias com donos e propósitos distintos.

As UTMs são convenção sua. Você as define, você as lê, e elas servem para atribuir tráfego dentro das suas próprias ferramentas de analytics. Elas não têm nenhum significado especial para o Facebook ou o Google além do que você mesmo configura.

Os click IDs são identificadores opacos gerados pela plataforma no momento do clique. Você não os inventa nem os interpreta — apenas os captura e os devolve à plataforma quando a conversão acontece. É com eles que a plataforma reencontra o clique original e credita a conversão à campanha, ao conjunto e ao criativo certos.

| Parâmetro | Dono | Função | | --- | --- | --- | | utm_source | Você | De onde veio o tráfego (ex.: facebook, google, newsletter) | | utm_medium | Você | O canal ou tipo (ex.: cpc, social, email) | | utm_campaign | Você | Nome da campanha | | utm_term | Você | Palavra-chave (busca paga) | | utm_content | Você | Variação de criativo/link | | fbclid | Meta | Click ID do clique no anúncio da Meta | | gclid | Google | Click ID clássico do Google Ads | | gbraid / wbraid | Google | Click IDs para tráfego iOS/app com restrições de privacidade | | ttclid | TikTok | Click ID do TikTok Ads | | msclkid | Microsoft | Click ID do Microsoft Ads |

A distinção prática é simples: perder uma UTM prejudica seus relatórios internos; perder um click ID prejudica a otimização da plataforma, porque quebra a correspondência de conversão que alimenta o algoritmo de entrega.

Como o fbclid vira _fbc (e o que é o _fbp)#

O caminho do fbclid merece atenção porque é o mais mal compreendido. Quando alguém clica em um anúncio da Meta, a pessoa chega ao seu site com uma URL parecida com esta:

``text https://loja.exemplo.com/produto?fbclid=IwAR2aBc...9xYz&utm_source=facebook&utm_medium=cpc&utm_campaign=black_friday ``

Esse fbclid sozinho, na URL, não é o formato que a Conversions API espera. O pixel do navegador transforma o fbclid em um cookie first-party chamado _fbc, com uma estrutura específica que combina versão, subdomínio, um timestamp e o próprio valor do clique:

``text _fbc = fb.1.1700000000000.IwAR2aBc...9xYz ``

O _fbp é um cookie diferente: ele não vem do clique, é um identificador de navegador gerado pelo pixel na primeira visita e persistido em domínio próprio. Ele identifica o dispositivo/navegador de forma estável entre visitas, mesmo sem um clique de anúncio associado.

Quando você dispara a conversão pelo servidor via CAPI, os dois viajam dentro de user_data:

``json { "user_data": { "fbc": "fb.1.1700000000000.IwAR2aBc...9xYz", "fbp": "fb.1.1699990000000.1234567890" } } ``

A moral: o servidor só consegue enviar fbc e fbp se alguém os capturou e os persistiu enquanto o usuário ainda estava no navegador. Se o clique cai numa página e a conversão acontece três dias depois em outro contexto, esses valores precisam ter sido guardados e carregados junto do pedido. Não existe como reconstruí-los depois.

Por que o click ID é a peça central da correspondência#

Plataformas de anúncio correspondem conversões a cliques por várias vias — email hasheado, telefone, endereço, IP, user agent. Mas o click ID é, de longe, o sinal mais forte, porque é determinístico: ele aponta para um clique único e específico. Email e telefone dependem de correspondência probabilística ou de a pessoa estar logada; o click ID aponta direto para o registro do leilão que entregou aquele anúncio.

Isso tem uma consequência prática importante: mesmo que você não colete nenhum dado pessoal, preservar o click ID já entrega uma correspondência de altíssima qualidade para eventos de conversão originados de anúncio. É o retorno mais alto por unidade de esforço em toda a mensuração server-side.

Onde os parâmetros se perdem#

O click ID chega na URL de destino. A partir daí, tudo que apaga, sobrescreve ou não propaga a query string é um ponto de vazamento. Os mais comuns:

Redirects que dropam a query string#

Um redirect de http para https, de www para apex, ou de uma URL antiga para a nova, muitas vezes é configurado sem preservar a query string. O usuário clica com ?fbclid=..., o servidor responde 301 para a URL limpa, e o click ID evapora antes de qualquer script rodar. Regra: todo redirect na entrada precisa repassar a query string.

Formulários e checkout que não propagam#

O usuário chega com o click ID na landing page, mas o formulário de lead ou o botão de checkout leva para uma URL nova sem carregar os parâmetros. Se o valor não foi persistido em cookie ou storage antes, ele não existe mais no momento da conversão.

Domínio diferente no checkout#

Muitas lojas processam o pagamento em um subdomínio ou domínio de terceiro. Cookies first-party não cruzam fronteira de domínio. Se o click ID ficou preso no cookie do domínio da landing e o evento de compra dispara no domínio do checkout, a correspondência quebra.

SPAs e navegação client-side#

Em aplicações de página única, a primeira URL carrega com os parâmetros, mas a navegação seguinte reescreve a URL sem eles. Se a captura só acontece no load inicial e você confia na URL atual mais tarde, perde o valor.

Apps e webviews#

Fluxos que saem do navegador para um app nativo raramente propagam a query string. Aqui os click IDs de app do Google (gbraid/wbraid) e integrações específicas entram em cena, mas o princípio é o mesmo: capturar cedo, persistir e repassar.

Como preservar: capturar, persistir, propagar#

A estratégia robusta tem três movimentos, sempre nessa ordem.

Capturar no primeiro toque. Assim que a página carrega, leia a query string e extraia tudo que interessa. Faça isso o mais cedo possível, antes de qualquer redirect client-side.

Persistir em armazenamento first-party. Grave em cookie de domínio próprio (ou localStorage) com um tempo de vida compatível com sua janela de atribuição. Guarde o timestamp junto — você vai precisar dele para montar o _fbc e para saber qual toque veio primeiro.

Propagar no momento da conversão. Injete os valores em campos ocultos do formulário e envie-os no payload do evento server-side.

Um exemplo mínimo de captura e persistência em JavaScript:

```javascript // Roda no carregamento de toda página, o quanto antes. function capturarParametrosDeClique() { const url = new URLSearchParams(window.location.search); const chaves = [ "fbclid", "gclid", "gbraid", "wbraid", "ttclid", "msclkid", "utm_source", "utm_medium", "utm_campaign", "utm_term", "utm_content" ];

for (const chave of chaves) { const valor = url.get(chave); if (!valor) continue;

// first-touch: só grava se ainda não existe const chavePrimeiroToque = ft_${chave}; if (!localStorage.getItem(chavePrimeiroToque)) { localStorage.setItem(chavePrimeiroToque, valor); localStorage.setItem(${chavePrimeiroToque}_ts, Date.now().toString()); } // last-touch: sempre sobrescreve localStorage.setItem(lt_${chave}, valor); } }

// Ao montar o cookie _fbc a partir do fbclid (se o pixel não o fez): function montarFbc() { const fbclid = localStorage.getItem("ft_fbclid"); const ts = localStorage.getItem("ft_fbclid_ts") || Date.now(); return fbclid ? fb.1.${ts}.${fbclid} : null; } ```

E a propagação para um campo oculto antes do envio do formulário:

``javascript function preencherCamposOcultos(form) { const campos = { fbc: montarFbc(), gclid: localStorage.getItem("ft_gclid"), utm_campaign: localStorage.getItem("ft_utm_campaign") }; for (const [nome, valor] of Object.entries(campos)) { if (!valor) continue; let input = form.querySelector(input[name="${nome}"]); if (!input) { input = document.createElement("input"); input.type = "hidden"; input.name = nome; form.appendChild(input); } input.value = valor; } } ``

O detalhe que amarra tudo: esses campos ocultos precisam viajar com o pedido até o back-end. Quando a conversão real dispara no servidor — a compra confirmada, o lead qualificado — o back-end lê esses valores e os inclui no evento enviado à plataforma. É assim que um clique de segunda-feira encontra uma compra de quinta.

First-touch versus last-touch#

Vale guardar as duas versões de cada parâmetro. O first-touch (primeiro toque) responde "o que trouxe essa pessoa para a marca". O last-touch (último toque) responde "o que fechou a venda". Para os click IDs que alimentam a otimização da plataforma, o comportamento padrão costuma privilegiar o clique mais recente dentro da janela de atribuição; para relatórios internos de origem, o primeiro toque conta uma história diferente e igualmente útil. Persistir ambos custa pouco e evita ter que escolher cedo demais.

Higiene de UTMs#

Como as UTMs são convenção sua, indisciplina aqui vira ruído nos relatórios. Facebook, facebook e FB viram três fontes distintas no analytics. Padronize: sempre minúsculas, sem espaços, um vocabulário fechado de valores para source e medium, e um padrão de nomenclatura para campaign. Documente esse padrão e gere as URLs a partir de um construtor único, não à mão. UTMs limpas não melhoram a correspondência da plataforma, mas são o que torna seus próprios relatórios confiáveis.

O checklist mental#

Antes de considerar a mensuração pronta, percorra a jornada como um usuário real que chegou de um anúncio e verifique cada transição:

• O redirect de entrada preserva a query string?
• Os parâmetros são capturados e persistidos logo no primeiro carregamento?
• Eles sobrevivem à navegação interna, ao formulário e ao checkout?
• Se o checkout está em outro domínio, os valores atravessam junto do pedido?
• No momento da conversão real, o servidor tem em mãos o fbc/fbp/gclid para enviar?

Cada "não" nessa lista é uma fração das suas conversões chegando anônima à plataforma. E, diferente de um bug que quebra a tela, esse vazamento não aparece em lugar nenhum — a venda acontece, o dinheiro entra, e só a qualidade da sua otimização silenciosamente piora. Preservar os parâmetros de clique é, no fim, o trabalho invisível que mantém a correspondência de conversão honesta.