Enviar conversões pelo servidor com a Conversions API sem contar duas vezes

Com a tag contando certo no navegador, sobra o que ela nunca vê. Conversions API: o canal pelo qual o servidor da empresa, ou o do CRM, avisa o LinkedIn de uma conversão diretamente, sem depender do navegador do visitante. Por ele passam o SQL marcado pelo SDR, a reunião realizada e a venda fechada por telefone.

Sem esse canal, o Campaign Manager enxerga o começo do funil e fica cego para o resto. O algoritmo otimiza pelo formulário porque é o único resultado que conhece, e bloqueador de anúncio, navegador que apaga cookie e visitante que recusa o banner reduzem ainda mais o que a tag consegue ver.

Mandar a mesma ação pelos dois caminhos traz o risco oposto, que é contar duas vezes. Evitar isso depende de um detalhe técnico com nome próprio, o identificador de evento, e de uma decisão de arquitetura tomada antes de ligar a integração.

A diferença entre navegador e servidor está em quem carrega o recado. Na tag, o navegador do visitante leva a informação ao LinkedIn, e qualquer coisa no caminho pode barrar. Na Conversions API, o sistema da empresa manda o recado de servidor para servidor, como um malote entre escritórios, e a mensagem chega mesmo que o visitante tenha fechado a aba há semanas.

Existem dois jeitos de implementar. Na integração direta, a equipe de tecnologia gera um token no Signals manager e programa o envio; a Central de Ajuda estima de duas a quatro semanas, e o FAQ da API fala em uma a duas. Pelo parceiro, uma ferramenta pronta faz o envio: a lista oficial traz HubSpot, Google Tag Manager, Salesforce Data 360, Segment, Zapier e outros.

Essa escolha define responsabilidades. Na integração direta, a empresa cuida do token, que não expira e que o LinkedIn não guarda, das versões mensais da API e do limite de 5.000 eventos por requisição. No parceiro, essas tarefas passam ao fornecedor, e a empresa fica com o mapeamento dos campos e a conferência dos números. Quem não tem desenvolvedor dedicado começa pelo parceiro.

Qualquer que seja o caminho, a conversão nasce como regra dentro do Campaign Manager. O caminho é Measure (Medir), Conversion tracking, botão Create conversion. O menu oferece três origens: Insight Tag conversion, Conversions API e CSV conversion, este para subir eventos offline em planilha. Para o SQL que sai do CRM, a escolha é Conversions API.

Na etapa Settings, as janelas de Clicks e Views oferecem 1, 7, 30 e 90 dias. As janelas maiores entram pela API: desde a versão 202609, de setembro de 2026, os campos de janela da regra aceitam 180 dias, ao lado dos 365, para lead, lead qualificado, MQL, SQL, candidatura, compra e adição ao carrinho. Combine com quem programa a integração qual janela vale antes do primeiro envio.

A Conversions API aceita eventos online e offline. Online é a ação no site, repetida pelo servidor para não depender do cookie. Offline é o que acontece longe da tela: lead aceito pelo SDR, reunião realizada, contrato assinado, contato colhido no estande de um evento presencial. Desde a versão de agosto de 2026 da API, MQL e SQL existem como tipos próprios de conversão.

O limite de tempo pesa num ciclo longo. O evento precisa chegar em até 90 dias da conversão, e a janela de atribuição recomendada pelo LinkedIn é de 90 dias de clique e 90 de visualização; janelas de 180 e 365 dias existem só para alguns tipos, como lead, lead qualificado, MQL e SQL. Com ciclo de 110 dias, o contrato tende a cair fora da janela, e o SQL vira o sinal de otimização.

Para atribuir, o LinkedIn precisa reconhecer a pessoa do outro lado. Os dados de correspondência aceitos incluem e-mail com hash SHA-256, o identificador de clique do LinkedIn (li_fat_id), endereço IP, nome, cargo, empresa, país e o identificador do lead de um Lead Gen Form. Hash é a impressão digital do e-mail: o mesmo endereço sempre gera o mesmo código, e o código não revela o endereço.

Normalizar antes do hash separa correspondência alta de baixa. O e-mail vai em minúsculas e sem espaços, senão 'Diretora@Empresa.com ' e 'diretora@empresa.com' viram códigos diferentes. O modelo de GTM para a Conversions API faz o hash sozinho desde junho de 2025. Vale capturar o li_fat_id num campo oculto do formulário, porque ele liga o contato ao clique exato.

A correspondência também ganhou campos em 2026. Desde a versão 202607, de julho, o endereço IP pode seguir com hash SHA-256, por enquanto só no formato IPv4. Na 202609, nome e sobrenome passaram a aceitar hash, depois de normalizados em minúsculas, sem espaços nem pontuação. Mais campos com hash elevam a chance de o LinkedIn reconhecer o contato do CRM.

Deduplicação é a regra que impede a mesma ação de contar duas vezes. Quando o pedido de demonstração vai pela tag e pelo servidor, o LinkedIn pede uma regra de conversão para cada fonte e o mesmo eventId nos dois envios. Havendo coincidência, a plataforma descarta o evento da Conversions API e conta o do Insight Tag. O eventId nasce uma vez, no envio, e os dois caminhos o repetem.

Qualidade do sinal se mede em quatro perguntas. Completude: quantos eventos chegam com e-mail e li_fat_id? Validade: o e-mail tem formato certo e o valor veio preenchido? Atualização: o SQL chega em poucos dias depois da mudança de fase? Consistência: o número do Campaign Manager fica perto do CRM no mesmo período?

Monitorar é olhar essas perguntas toda semana e ter plano para falha. Envio que para em silêncio é o defeito mais caro, porque a campanha continua otimizando com dados velhos. A rotina cobre reenvio dentro dos 90 dias, conexão do parceiro revogada, versão da API perto da aposentadoria (a 202510 sai em 15 de outubro de 2026) e um dono para cada alerta.

A Conversions API tem limites que a documentação deixa claros. Os dados ficam armazenados e processados nos Estados Unidos, são apagados depois de 180 dias e seguem o acordo de processamento de dados do LinkedIn. Mandar pelo servidor não dispensa o consentimento que o site precisa colher: a regra que exclui quem recusou o banner vale também para o envio. Cobertura integral não existe, e parte das conversões é modelada.

Armadilha comum: ligar a integração do parceiro e esquecer que a tag já contava a mesma ação. Sem eventId compartilhado, o pedido de demonstração entra duas vezes, o custo por conversão cai pela metade no relatório e a otimização passa a acreditar num desempenho que não existe. O erro só aparece quando alguém compara o total com o CRM.

No mês 1, a Vértice ligou a Conversions API pelo parceiro HubSpot, sem desenvolvimento próprio. O pedido de demonstração passou a sair pelos dois caminhos com o mesmo eventId, e três eventos offline começaram a sair do CRM: SQL, reunião realizada e oportunidade criada. O formulário do site ganhou um campo oculto para o li_fat_id, preenchido em 84 por cento dos envios vindos de anúncio.

O teste de aceite repetiu o critério do plano. Em 30 dias, o Campaign Manager registrou 33 pedidos de demonstração contra 31 no HubSpot, dentro da tolerância, e nenhum em dobro. Os SQL chegaram ao LinkedIn em média quatro dias depois da mudança de fase. Foi esse sinal que, no mês 4, sustentou a otimização para lead qualificado.

Para a Vértice, a conta passou a enxergar o SQL, e o algoritmo ganhou um alvo que vendas reconhece. Calcule, para os últimos 30 dias, quantos eventos da Conversions API chegaram com e-mail com hash e com li_fat_id; acima de 80 por cento nos dois, o sinal está pronto para o capítulo "Ligar o CRM ao Campaign Manager e auditar do formulário ao contrato".