Conversions API do Pinterest e do LinkedIn: as outras CAPIs que ninguém configura

A conversa sobre mensuração server-side gira quase sempre em torno de Meta e Google, e com razão — são os maiores volumes. Mas quem anuncia em Pinterest ou LinkedIn e mede essas conversões apenas por tag de navegador está deixando na mesa exatamente o mesmo sinal que já aprendeu a resgatar nas grandes plataformas. A erosão do cookie de terceiro, o bloqueio de scripts e as restrições de navegador afetam todas elas por igual. E as duas oferecem uma Conversions API própria, subutilizada justamente porque quase ninguém a configura.

Este guia percorre as duas de forma prática: o que cada API espera no payload, como identificam o usuário, como deduplicam contra a tag do navegador e o que muda em relação à Meta CAPI para quem já a conhece. O objetivo é dar o mapa mental que permite implementar as duas sem partir do zero.

Por que as plataformas "secundárias" também precisam de server-side

O argumento é idêntico ao das grandes: a tag de navegador é o método mais frágil de coleta. Uma parcela relevante dos disparos nunca chega ao destino, e essa perda não é aleatória — concentra-se justamente em públicos com mais bloqueio e mais restrição, que muitas vezes são os de maior valor. Enviar o evento do servidor, direto para a API da plataforma, recupera essa fatia e melhora a base de otimização.

Há um segundo motivo, particularmente forte no LinkedIn: conversões que não acontecem no site. Muito do valor em campanhas B2B se materializa depois — um lead que vira oportunidade no CRM, um negócio que fecha semanas após o clique. Isso só entra na plataforma por um canal server-side que importa a conversão offline correspondida por dados de identidade.

Pinterest Conversions API

A Conversions API do Pinterest recebe eventos direto do seu servidor e os associa às campanhas, em paralelo ou complemento à tag do Pinterest.

Eventos e payload

Os eventos cobrem o funil típico de e-commerce e geração de interesse: page_visit, add_to_cart, checkout, lead, signup, entre outros. O payload traz a identificação do evento, os dados de usuário e os dados de conversão:

``json { "event_name": "checkout", "action_source": "web", "event_time": 1718900000, "event_id": "ord_8f3a91c2", "user_data": { "em": ["b4c9a289323b21a01c3e940f150eb9b8c542587f1abfd8f0e1cc1ffc5e475514"], "ph": ["e2b1f6..."], "click_id": "epik_abc123", "hashed_maids": ["..."] }, "custom_data": { "currency": "BRL", "value": "259.90", "content_ids": ["SKU-1029"], "num_items": 1 } } ``

Os campos-chave:

• event_name e action_source — o nome do evento e onde ele ocorreu (web, app, offline).
• event_id — identificador único da ocorrência, base da deduplicação.
• user_data — e-mail (em) e telefone (ph) hasheados em SHA-256, além de identificadores de clique e de dispositivo.
• custom_data — value, currency, content_ids e quantidade.

Correspondência e o epik

O Pinterest usa os dados hasheados de user_data para correspondência, reforçados pelo epik — o click ID do Pinterest, anexado à URL quando alguém clica no anúncio. Capturar e persistir o epik no primeiro acesso permite religar a conversão ao clique, mesmo quando o e-mail não está disponível no momento do evento. Quanto mais sinais válidos você fornece, melhor a taxa de correspondência.

Autenticação e deduplicação

A chamada é autenticada por um token de acesso server-side — segredo que vive apenas no back-end. A deduplicação contra a tag do Pinterest funciona pelo event_id: o mesmo identificador nos dois canais faz a plataforma contar a conversão uma vez só. A regra de sempre: gere o event_id num ponto único e propague para o navegador e o servidor.

LinkedIn Conversions API

A Conversions API do LinkedIn tem um sabor diferente, porque o LinkedIn é primordialmente uma plataforma B2B, onde a conversão que importa muitas vezes é um lead qualificado ou um negócio fechado, não uma compra imediata.

Foco em leads e conversão offline

O caso de uso central é levar de volta ao LinkedIn as conversões que se concretizam fora do site: um lead que avançou no funil, uma oportunidade criada no CRM, um contrato assinado. Você envia esses eventos server-side, correspondidos por dados de identidade, e o LinkedIn os credita às campanhas que geraram o clique original. Isso fecha o ciclo entre o investimento em mídia B2B e a receita real, que raramente acontece na primeira sessão.

Regras de conversão e matching

No LinkedIn, os eventos são associados a uma regra de conversão (conversion rule) previamente definida, identificada por um ID. Cada evento enviado referencia a regra correspondente. O matching se apoia em dados de identidade hasheados — e-mail profissional é um sinal forte no contexto B2B — e em atributos que ajudam a plataforma a reconhecer o usuário.

``json { "conversion": "urn:lla:llaPartnerConversion:12345", "conversionHappenedAt": 1718900000, "conversionValue": { "currencyCode": "BRL", "amount": "259.90" }, "user": { "userIds": [ { "idType": "SHA256_EMAIL", "idValue": "b4c9a289..." } ] }, "eventId": "lead_77c1" } ``

O hashing é exigido: e-mail normalizado (minúsculas, sem espaços) e convertido em SHA-256 antes de compor o userIds. O conversionValue permite atribuir valor monetário à conversão, útil quando você consegue estimar o valor de um lead ou de um negócio.

Autenticação e boas práticas

Como nas demais, o envio é autenticado por credencial server-side, mantida em segredo. A boa prática de retry vale integralmente: uma fila persistente reenvia eventos que falharam, sempre com o mesmo identificador para evitar duplicidade. E, como muitos eventos são offline (vindos do CRM), atenção ao conversionHappenedAt correto de cada um — deve refletir o momento real da conversão, respeitando as janelas de aceitação da API, que recusam eventos antigos demais.

Conversão offline: a cadência de envio

Tanto no Pinterest quanto no LinkedIn, boa parte do valor real chega depois do clique — um lead que amadurece, uma venda que fecha semanas adiante. Levar essas conversões offline de volta à plataforma exige atenção a alguns detalhes que costumam ser ignorados.

O primeiro é o event_time/conversionHappenedAt correto. Cada conversão offline deve carregar o instante em que ela de fato aconteceu, não o instante em que você a enviou. Uma venda fechada na segunda-feira e importada na sexta precisa registrar a data da segunda, senão a atribuição à janela correta se perde. O segundo é a janela de aceitação: as APIs recusam eventos antigos demais, então um fechamento que ficou semanas parado no CRM pode chegar tarde demais para ser aceito. Isso torna a cadência importante — importar conversões offline com regularidade (diária, por exemplo) evita acumular eventos que envelhecem além do limite.

O terceiro é a correspondência. Como a conversão offline não tem cookie nem click ID capturados no navegador, ela se apoia inteiramente nos dados de identidade que você guardou: e-mail e telefone hasheados, associados ao registro no CRM. É aqui que uma identidade bem resolvida no seu back-end faz toda a diferença — sem ela, a conversão offline não tem por onde ser ligada ao clique original.

Validar cada integração

Assim como nas grandes plataformas, tanto Pinterest quanto LinkedIn oferecem formas de conferir se os eventos chegam corretamente antes de confiar nos números. O fluxo é o mesmo em espírito: dispare uma conversão de teste, confirme no painel da plataforma que ela chegou com todos os campos (nome do evento, valor, moeda, dados de identidade presentes e hasheados), verifique que a deduplicação contra a tag do navegador está funcionando pelo identificador compartilhado, e só então trate a integração como confiável. Validar antes de ligar vale para toda plataforma, não só para as maiores — e nas secundárias, onde há menos gente de olho, um defeito silencioso pode passar despercebido por muito mais tempo.

Comparação prática com a Meta CAPI

Para quem já domina a Conversions API da Meta, o essencial transfere-se, com traduções:

• Estrutura do payload. Pinterest é bastante próximo da Meta (event_name, user_data com em/ph, custom_data, event_id). LinkedIn tem um formato próprio, orientado a regras de conversão e userIds.
• Identificador de clique. fbclid/fbc na Meta corresponde ao epik no Pinterest; no LinkedIn, o peso recai mais sobre a correspondência por e-mail e sobre a conversão offline do que sobre um click ID de URL.
• Deduplicação. Pinterest usa event_id, exatamente como a Meta. No LinkedIn, o eventId cumpre papel semelhante para evitar dupla contagem.
• Hashing. Todas exigem SHA-256 sobre dados normalizados — o pipeline de normalização e hashing é o mesmo, muda apenas o nome dos campos.
• Segredo do token. Em todas, a credencial de envio é server-side e nunca vai ao cliente.

A conclusão prática é que vale a pena tratar essas plataformas como destinos de uma camada de conversão única: você mantém um contrato de evento interno canônico e traduz para o formato de cada API no ponto de distribuição. Assim, adicionar Pinterest ou LinkedIn deixa de ser uma reimplementação e vira apenas um novo mapeamento de saída.

Segurança e operação do token

Um ponto que merece disciplina em qualquer uma dessas integrações é o tratamento do token de acesso. Ele é a credencial que autentica o envio, e quem o possui pode enviar eventos em nome da sua conta — poluindo dados, distorcendo otimização e, no limite, consumindo orçamento em direção errada. Por isso o token vive exclusivamente no servidor, nunca no bundle do navegador, nunca numa variável exposta ao cliente, nunca versionado em texto puro no repositório. O lugar dele é um cofre de segredos, injetado por variável de ambiente, com rotação periódica.

A rotação importa porque um token vazado não se "desvaza" sozinho: a única defesa é trocá-lo e invalidar o antigo. Uma operação madura rotaciona as credenciais das plataformas de tempos em tempos e imediatamente diante de qualquer suspeita de exposição. Vale também o princípio do menor privilégio — cada token com o escopo mínimo necessário para a sua função, para que um comprometimento tenha o menor alcance possível. Segurança de credencial não é detalhe de conformidade; é o que impede que sua fonte de dados seja envenenada por terceiros.

Síntese

Pinterest e LinkedIn oferecem Conversions API tão capazes quanto as das grandes plataformas, e são justamente as menos configuradas — o que significa sinal desperdiçado para quem anuncia lá. No Pinterest, o payload lembra o da Meta, com user_data hasheado, epik como click ID e event_id para deduplicar contra a tag. No LinkedIn, o foco é B2B: leads e conversões offline do CRM, associados a regras de conversão e correspondidos por e-mail hasheado. Em ambos, a receita é a de sempre: normalizar e hashear a identidade, proteger o token no servidor, deduplicar por identificador único e reenviar falhas por uma fila. Tratadas como destinos de uma camada de conversão comum, essas APIs deixam de ser um projeto à parte e passam a ser mais um mapeamento de saída sobre a infraestrutura que você já tem.