LinkedIn Conversions API dans n8n : mesurer les conversions B2B au-delà du clic

Un clic sur une publicité LinkedIn et la signature du contrat qui en découle sont rarement séparés de quelques minutes : dans une vente B2B classique, plusieurs semaines voire plusieurs mois s'écoulent entre les deux, largement au-delà de la fenêtre que l'Insight Tag LinkedIn peut suivre dans un navigateur. Le problème n'est pas propre à LinkedIn — une étude de Guy Aridor, Yeon-Koo Che, Brett Hollenbeck, Daniel McCarthy et Maximilian Kaiser publiée dans Management Science (2025) a montré qu'après l'introduction de l'App Tracking Transparency d'Apple, les annonces Meta optimisées pour la conversion ont vu leur taux de clic reculer de 37 %, un effet directement lié à la perte de signal de mesure côté annonceur. Toute plateforme publicitaire dont l'attribution dépend d'un suivi navigateur affronte la même érosion — et LinkedIn répond à ce problème, côté B2B, avec sa propre Conversions API, qui permet d'importer depuis votre CRM les conversions constatées bien après le clic initial. Ce guide montre comment construire ce pipeline dans n8n, du changement de statut CRM jusqu'à l'appel à l'API.

Pourquoi la Conversions API compte particulièrement en B2B

L'Insight Tag LinkedIn, comme tout tag installé dans un navigateur, mesure ce qui se passe dans une fenêtre de temps courte autour du clic ou de la visite : une demande de démo, un téléchargement de livre blanc. Mais l'action qui compte vraiment pour un budget publicitaire B2B — un devis accepté, un contrat signé, un abonnement activé — se produit typiquement dans le CRM, des semaines plus tard, après plusieurs allers-retours commerciaux invisibles pour LinkedIn. Sans remontée explicite, Campaign Manager optimise les enchères sur des micro-conversions (clics, formulaires) qui ne reflètent pas toujours la qualité réelle des leads générés par chaque campagne.

La Conversions API comble cet écart en acceptant des conversions hors ligne : votre CRM (HubSpot, Pipedrive, Salesforce) notifie n8n dès qu'un deal change de statut, et le workflow transmet l'évènement à LinkedIn avec la date réelle de conversion et les identifiants du contact. LinkedIn peut alors rapprocher cette conversion tardive de la campagne et du membre qui avait cliqué, et réoptimiser les enchères sur la base de la vraie valeur business plutôt que sur un simple clic.

Comment fonctionne la Conversions API LinkedIn

Deux prérequis avant tout appel API :

1. Créer la règle de conversion dans Campaign Manager (Data → Conversion tracking), qui génère un URN de type urn:lla:llaPartnerConversion:{id} — c'est cet identifiant que chaque évènement référence.
2. Générer un jeton d'accès depuis Data → Signals manager → Direct API → Generate access token. Ce jeton, propre à votre compte publicitaire, ne nécessite pas de créer d'application développeur et n'expire pas — il se stocke comme un credential n8n dédié, au même titre que n'importe quelle autre clé API sensible.

L'endpoint est un POST vers https://api.linkedin.com/rest/conversionEvents, avec les en-têtes Authorization: Bearer {token}, LinkedIn-Version (la version de l'API en vigueur) et X-Restli-Protocol-Version: 2.0.0. Le corps attendu pour un évènement :

{
  "conversion": "urn:lla:llaPartnerConversion:123456789",
  "conversionHappenedAt": 1754812800000,
  "conversionValue": {
    "currencyCode": "EUR",
    "amount": "1490.00"
  },
  "user": {
    "userIds": [
      { "idType": "SHA256_EMAIL", "idValue": "{{ $json.email_hash }}" }
    ],
    "userInfo": {
      "firstName": "{{ $json.first_name }}",
      "lastName": "{{ $json.last_name }}",
      "companyName": "{{ $json.company_name }}",
      "countryCode": "{{ $json.country_code }}"
    }
  },
  "eventId": "{{ $json.deal_id }}"
}

conversionHappenedAt est un timestamp epoch en millisecondes correspondant à la date réelle de la conversion (signature du deal), pas à l'instant de l'envoi à l'API. eventId sert au dédoublonnage : réutiliser l'identifiant du deal CRM garantit qu'un renvoi accidentel du même évènement n'est pas compté deux fois.

Construire le workflow dans n8n

Étape 1 — Déclencher sur le vrai évènement business

Le déclencheur n'est pas le clic publicitaire (déjà mesuré par l'Insight Tag) mais le changement de statut dans le CRM : un deal marqué « Closed Won » dans HubSpot ou Pipedrive, capté via un webhook sortant natif ou en polling régulier — voir notre guide sur la synchronisation CRM HubSpot/Pipedrive et notre article sur Salesforce et n8n pour la configuration de ce déclencheur selon votre CRM. Un filtre en amont (node Filter ou IF) ne laisse passer que les deals dont le stade correspond réellement à une conversion facturable, pas une simple étape intermédiaire du pipeline.

Étape 2 — Normaliser et hasher l'email

Seul l'email doit être hashé en SHA-256 avant l'envoi ; les autres champs de userInfo (prénom, nom, entreprise, pays) restent en clair, car ils servent de méthode de correspondance de secours quand LinkedIn ne peut pas rapprocher l'email hashé. Un node Code placé après le déclencheur prépare ces champs :

const crypto = require('crypto');

const hash = (value) =>
  crypto.createHash('sha256').update(value.trim().toLowerCase()).digest('hex');

return [{
  json: {
    ...$json,
    email_hash: hash($json.contact_email),
  },
}];

Le node Crypto en opération Hash (SHA256, sortie HEX) — voir notre guide du node Crypto — fait exactement le même calcul sans code si vous préférez rester sur des nodes standards.

Étape 3 — Construire le payload et appeler l'API

Un node Set assemble le JSON au format conversionEvents montré plus haut, puis un node HTTP Request en POST envoie la requête vers https://api.linkedin.com/rest/conversionEvents, avec le jeton stocké en credential — la même discipline que celle détaillée dans notre guide sur la sécurisation des credentials et clés API. Pour un import initial (historique de deals déjà signés), l'API accepte un tableau de plusieurs évènements dans une même requête, jusqu'à 5 000 par lot — largement suffisant pour rattraper plusieurs mois d'historique CRM en une poignée d'appels plutôt qu'un appel par deal.

Étape 4 — Filtrer les envois en doublon

Un webhook CRM qui se déclenche deux fois pour la même mise à jour de statut (relivraison réseau, synchronisation redondante) enverrait autrement la même conversion en double à LinkedIn. Le principe est identique à celui décrit dans notre article sur l'idempotence des webhooks : vérifier dans une table Supabase si l'eventId (l'identifiant du deal) a déjà été envoyé avant de déclencher l'appel API, plutôt que de compter uniquement sur le dédoublonnage côté LinkedIn.

Étape 5 — Vérifier dans Campaign Manager

Sous Analyze → Conversion tracking, la règle de conversion affiche le nombre d'évènements reçus par source (Insight Tag vs Conversions API) avec un délai de quelques minutes à quelques heures selon le volume. C'est le moment de vérifier que les montants (conversionValue) et les dates correspondent bien aux deals réels avant de généraliser l'envoi à l'ensemble du pipeline commercial.

Bonnes pratiques et pièges fréquents

• Respecter la fenêtre de 90 jours : conversionHappenedAt doit se situer dans les 90 jours précédant l'envoi de la requête — pas 90 jours après le clic publicitaire. Un CRM qui marque un deal signé avec plusieurs mois de retard doit déclencher l'envoi rapidement une fois le statut mis à jour.
• Ne jamais hasher les champs de userInfo — contrairement à l'email, ils doivent rester en clair pour servir de méthode de correspondance alternative.
• Réutiliser l'identifiant du deal CRM comme eventId, jamais un identifiant généré aléatoirement à chaque tentative, pour que le dédoublonnage LinkedIn et votre propre vérification d'idempotence pointent vers la même clé.
• Surveiller les limites de débit (600 requêtes/minute, 500 000/jour par jeton) si plusieurs workflows partagent le même compte publicitaire — regrouper les envois par lot dès que le volume dépasse quelques dizaines de deals par jour évite d'en approcher les seuils.
• Le même schéma général — déclencheur CRM, hashing de l'email, payload structuré, dédoublonnage par identifiant partagé — se retrouve presque à l'identique dans notre guide sur la Conversions API de Meta et sur le Measurement Protocol GA4 : une fois le premier pipeline construit dans n8n, les suivants réutilisent la même structure de nodes avec un endpoint et un format de payload différents.

En résumé

Construire un pipeline de Conversions API LinkedIn dans n8n tient en cinq briques : un déclencheur sur le vrai évènement business (changement de statut CRM, pas le clic), un hashage SHA-256 de l'email seul, un appel structuré vers conversionEvents avec un eventId partagé pour le dédoublonnage, une vérification d'idempotence côté n8n, et un contrôle dans Campaign Manager avant généralisation. Si votre instance n8n orchestre déjà la qualification de vos leads entrants ou leur enrichissement automatique, ajouter cet envoi ne prend qu'un nœud de plus à la sortie du pipeline existant. Et si vous voulez journaliser chaque envoi pour garder une piste d'audit complète des données transmises à un tiers publicitaire, les workflows de traçabilité Supabase du Pack Conformité & Audit (149 €) suivent exactement le même principe de journalisation que celui décrit dans notre article sur la piste d'audit RGPD avec Supabase, appliqué ici à un flux de conversions plutôt qu'à un flux de données personnelles interne.