Autor
Data
Categoria
O seu CRM reporta menos leads pagos do que o Google ou o Meta porque infere a origem de cada lead em vez de ler o UTM, então um lead cuja conta é criada dentro do produto é registrado como offline, orgânico ou direto mesmo vindo de um clique pago. O conserto é fazer do UTM a fonte da verdade, juntar as plataformas de anúncio e o CRM numa camada governada, e devolver as conversões, para que a mesma camada que mede a atribuição também aja sobre ela.
Porque o CRM chuta de onde veio cada lead, e o chute esconde o pago. Numa análise real, um canal do Google mostrava 4 leads a $908 por lead no CRM, enquanto o número certo era 46 leads a $79 por lead, um dos canais mais baratos da conta. 42 leads pagos estavam escondidos, num único mês, num único canal, numa única análise. A plataforma de anúncio nunca foi o problema. O jeito padrão de medir esconde o pago de todo mundo.
Uma cláusula mudou o quadro: um canal foi de 4 leads reportados para 46, e de $908 para $79 por lead. Mesmo investimento, mesma campanha, número diferente por baixo.
A mídia paga vive em pelo menos cinco sistemas, Google, Meta, LinkedIn, TikTok e o CRM, e juntar tudo é mais ou menos uma dúzia de problemas manuais de integração: levar o lead até o CRM, manter a origem ao longo da jornada, padronizar colunas e moedas, reconciliar os totais, amarrar investimento à receita. O resultado é que o número que um CEO abre no CRM não é o número que as campanhas realmente produziram, e alguém passa a semana explicando a diferença.
Porque ele carimba uma origem que infere, não a que o clique carregava. Um campo como hs_analytics_source é o palpite automático da plataforma sobre de onde veio um contato, não o UTM. Quando uma conta é criada dentro do produto sem passar por uma página rastreada, o CRM muitas vezes a marca como offline, mesmo que a pessoa tenha clicado num anúncio pago com UTM trinta segundos antes. Então um lead de busca paga é registrado como offline, orgânico ou direto, e quando você filtra os leads pagos no CRM, ele devolve quase nada, porque os melhores leads, os que viraram conta, foram arquivados em outro lugar. Você não está medindo os seus anúncios. Você está medindo o palpite do CRM sobre os seus anúncios.
Porque cada plataforma é um jardim murado que só conta o que aconteceu dentro dela. Um painel mostra as conversões que aquela plataforma reivindica, e o próximo faz igual. Nenhum deles sabe que a pessoa viu um anúncio social, baixou um ebook e depois fez uma busca por marca três dias depois. Some os painéis e você conta conversão repetida que ainda assim não bate com a venda real. Três fontes da verdade é zero fonte da verdade. É a mesma falha descrita em por que os agentes de IA dão respostas diferentes sobre o mesmo dado: sem uma definição governada, cada ferramenta reporta o próprio número.
Faça do UTM a fonte da verdade e leia ele em vez do campo inferido do CRM. O UTM é o que o time carimbou quando a campanha subiu, não a inferência de um algoritmo. Numa camada governada onde o dado é seu para consultar, a correção é uma cláusula só.
| A query | No que ela se baseia | O que acontece com um lead pago |
|---|---|---|
| hs_analytics_source IN ('PAID_SEARCH', 'PAID_SOCIAL') | a origem inferida do CRM | uma conta criada no produto cai como offline, orgânico ou direto, então o pago é subcontado |
| utm_medium IN ('paid', 'paid_social', 'cpc') | o UTM capturado no clique | o lead mantém o canal de onde realmente veio, e os leads pagos escondidos reaparecem |
Trocar a primeira cláusula pela segunda é o conserto inteiro, e o canal do Google vai de 4 leads para 46. Isso só funciona porque uma camada por baixo já juntou contatos, cliques e leads e expôs um campo utm_medium limpo. No estado bruto, esse UTM está enterrado em dezenas de tabelas com nomes de coluna, fusos e moedas diferentes, por isso ninguém faz o cruzamento na mão numa sexta à tarde. Padronizar UTMs bagunçados (cpc, ppc e paid para a mesma coisa) uma vez, na camada, e devolver o valor limpo pro CRM é melhor do que um workflow frágil de CRM que quebra na primeira exceção.
Você vê o funil inteiro, do investimento à venda fechada, mais três cortes que nenhum painel sozinho entrega. Com cada canal atribuído do mesmo jeito, uma plataforma que mostra um engajamento lindo no próprio painel pode não ter trazido venda nenhuma no mês, o que só fica visível quando os canais ficam lado a lado e a conversão que conta é uma reunião ou uma venda, não um clique. Três cortes separam quem chuta de quem decide.
| Corte | O que a camada combinada revela |
|---|---|
| Qualidade do lead, não volume | Duas campanhas com volume de lead quase igual pareciam empatadas nos painéis. Cruzadas com o CRM, uma trouxe 11% de email corporativo e zero venda; a outra mais de 50% B2B, e fechou. Mesmo volume, qualidade oposta. |
| Velocidade por canal | O Meta fecha rápido, perto de 10 dias do lead à venda; o Google leva quase 40 dias. Julgue os dois na mesma janela curta e você pausa o Google achando que não converte, quando a venda dele só não amadureceu. |
| Dayparting, pela hora real da conversão | Quebrado pela hora em que a pessoa realmente converteu, não pela hora em que o lead caiu no CRM, a noite das 18:00 às 23:00 trouxe mais leads e mais baratos, com pico por volta das 22:00. |
Email corporativo versus pessoal é um exemplo clássico de contexto que precisa viver ao lado do dado, para o agente ler a regra em vez de chutar, abordado em context engineering para agentes de IA.
Atribuição é o primeiro passo; o valor é o loop. Quando a camada mede certo, ela pode agir, e ela escreve tanto quanto lê.
Esse write-back é o que transforma uma camada de relatório numa camada de operação, e é o próximo passo natural para operar anúncios com um agente, não só reportá-los. Alcançar o dado por um protocolo padrão é abordado em o que é um MCP server para dados, e quando você precisa de um.
A Nekt é uma plataforma de dados que dá contexto governado aos agentes de IA, e atribuição é um exemplo limpo das três partes que ela cobre.
O ganho é precisão e alcance ao mesmo tempo: uma fonte da verdade no lugar de uma aba secreta de planilha, e uma consulta só que cruza todos os canais em vez de um cruzamento manual entre exports.
Porque o CRM infere uma origem em vez de ler o UTM. Quando um contato é criado sem passar por uma página rastreada, por exemplo uma conta criada dentro do produto, o CRM carimba como offline, orgânico ou direto, mesmo que o clique que levou até ali tenha sido pago. A origem paga está no UTM, não no campo inferido do CRM.
No UTM, para atribuição de pago. É o valor que o time carimbou na campanha, não o palpite de um algoritmo. O campo inferido do CRM é conveniente, mas subconta o pago, porque reatribui contatos criados no produto e não rastreados para longe do canal que realmente os trouxe.
Dá, quando as fontes vivem numa camada governada com os UTMs padronizados, porque a consulta vira um filtro só em vez de um cruzamento manual entre exports. A modelagem é o trabalho de verdade; depois dela, a pergunta é feita em linguagem natural ou numa linha de SQL, e qualquer pessoa à vontade com PROCV consegue ler o que está acontecendo.
