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.