LinkedIn CAPI server-side GTM : déduplication et matching (2026)

Installer LinkedIn Conversions API en server-side GTM est désormais documenté par Microsoft : le guide officiel (version li-lms-2026-05, mis à jour en mai 2026) décrit les étapes du setup en quelques minutes. Le problème, c’est que LinkedIn n’est pas Meta. Il impose une contrainte d’architecture que presque aucun guide n’explique : deux règles de conversion distinctes par source de données, reliées via event_id pour que la déduplication fonctionne. Sans ce câblage, votre installation double silencieusement les conversions, ou n’en rapporte qu’une moitié. Cet article adopte le même angle que les guides Meta CAPI server-side GTM et TikTok Events API server-side GTM pour l’appliquer à LinkedIn, avec sa contrainte clé : la règle “source-bound”. Objectif : repartir avec un CAPI propre, sans doublons, et un score de qualité de matching exploitable dans LinkedIn Campaign Manager.

LinkedIn CAPI n’est pas Meta CAPI : le piège source-bound

C’est le réglage que tout le monde rate, et la conséquence est directe : doublons silencieux dans vos conversions rapportées, ou signal amputé côté serveur.

Chez Meta, une seule règle de conversion peut recevoir des événements de plusieurs sources (Pixel et CAPI) et les déduplicer automatiquement via event_id. Chez LinkedIn, ce n’est pas possible. Chaque source de données exige sa propre règle de conversion. Une règle pour l’Insight Tag (client-side), une autre pour l’API serveur. Les deux règles restent distinctes dans LinkedIn Campaign Manager et ne se fusionnent pas en une seule ligne.

Ce modèle s’appelle “source-bound conversion” : une règle est liée à une source précise, elle ne peut pas combiner plusieurs origines. Si vous créez une seule règle et lui envoyez les événements Insight Tag et CAPI en même temps, LinkedIn ne déduplique pas : il compte deux conversions distinctes.

La déduplication intervient quand même, mais à un autre niveau : LinkedIn compare les événements reçus via les deux règles et les rapproche via event_id. Pour que ce rapprochement fonctionne, les deux règles doivent partager le même event_id pour un même événement réel. L’interface Campaign Manager affiche ensuite un décompte dédupliqué dans les rapports de conversion.

Architecture : Insight Tag + conteneur serveur + déduplication

L’architecture comporte trois briques, comme pour Meta et TikTok. Mais la logique de déduplication est propre à LinkedIn.

Le flux est le suivant : l’Insight Tag se déclenche dans le navigateur via votre conteneur web GTM. En parallèle, le conteneur server-side (sGTM) envoie le même événement à l’API LinkedIn. Les deux chemins décrivent la même conversion réelle. LinkedIn reçoit deux signaux et les rapproche si l’event_id est identique.

Cette architecture suppose un conteneur serveur hébergé (Cloud Run, Stape ou Addingwell). Si vous n’avez pas encore de conteneur server-side, commencez par le guide GTM server-side : pourquoi et comment migrer. La mise en place initiale représente un coût d’infrastructure à prévoir, détaillé dans combien coûte vraiment le GTM server-side.

Mise en place dans GTM server-side

Créer les deux règles de conversion dans Campaign Manager

C’est l’étape que presque tout le monde ignore. Dans LinkedIn Campaign Manager, rendez-vous dans Analyze > Conversion Tracking > Create conversion.

Créez deux règles distinctes pour chaque événement de conversion (par exemple, un formulaire Lead Gen ou un achat) :

1. Règle Insight Tag : sélectionnez “Insight Tag” comme source. Cette règle recevra les événements déclenchés côté navigateur.
2. Règle API : sélectionnez “Conversions API” comme source. Cette règle recevra les événements envoyés depuis votre conteneur server-side.

Les deux règles doivent porter le même nom d’événement (par exemple Lead) et être associées à la même campagne. C’est la condition pour que LinkedIn rapproche correctement les signaux.

Configurer le tag LinkedIn CAPI dans sGTM

Dans votre conteneur server-side, utilisez le tag officiel LinkedIn Conversions API (disponible dans la galerie des templates ou via les partenaires comme Stape). Renseignez :

• L’ID de conversion de la règle API créée à l’étape précédente.
• L’event_id : récupéré depuis le dataLayer, généré une seule fois côté client et transmis au serveur (voir la section déduplication ci-dessous).
• Le li_fat_id : le cookie LinkedIn déposé par l’Insight Tag côté navigateur. Il doit être lu par le conteneur web GTM, poussé dans le dataLayer et transmis au serveur. C’est l’équivalent du _fbp chez Meta.

L’event_id : règle d’or pour la déduplication

Générez l’event_id une seule fois, côté client, au moment où l’événement se produit. Poussez-le dans le dataLayer. Le conteneur server-side le récupère via la requête et le transmet à LinkedIn sans le régénérer.

Si le navigateur et le serveur génèrent chacun leur propre identifiant, les deux valeurs ne correspondent jamais : LinkedIn voit deux événements distincts au lieu d’un seul, et vous doublez vos conversions.

Vérifier la déduplication dans Campaign Manager

La vérification se fait dans LinkedIn Campaign Manager > Analyze > Conversion Tracking. Sélectionnez votre événement de conversion et regardez le breakdown par source : vous devez voir des attributions réparties entre “Insight Tag” et “Conversions API”, mais le total dédupliqué doit rester cohérent avec le nombre réel de conversions.

LinkedIn ne fournit pas un indicateur visuel aussi explicite que le “1 event from 2 sources” de Meta Events Manager. La vérification repose donc sur la cohérence du volume total. Si vous voyez le double du volume attendu, la déduplication via event_id est cassée. Si vous ne voyez que des attributions d’une seule source, l’une des deux règles ne reçoit pas de données.

L’interface Campaign Manager évolue régulièrement : vérifiez les libellés exacts au moment de votre audit, mais la logique de déduplication, elle, reste stable.

Qualité de matching : les paramètres qui font la différence

Le score de qualité de matching est visible dans LinkedIn Campaign Manager > Analyze > Events Manager. Il mesure la capacité de LinkedIn à associer vos événements serveur à des profils LinkedIn réels. Plus le score est élevé, plus votre signal est exploitable par l’algorithme d’enchères.

Les paramètres qui améliorent le plus le score :

Le piège le plus fréquent concerne le li_fat_id : ce cookie doit voyager en clair, exactement comme le _fbp chez Meta. Le hacher casse le matching, car LinkedIn s’attend à le lire tel quel pour retrouver le profil navigateur. À l’inverse, l’email doit être haché en SHA-256 et normalisé avant l’envoi. Inverser ces deux logiques est la cause la plus fréquente d’un score de matching insuffisant.

LinkedIn compare en priorité l’email haché avec les données de compte. Si votre formulaire collecte un email professionnel et que l’utilisateur est connecté à LinkedIn avec le même email, le matching est quasi certain. Ajoutez le prénom, le nom et le pays pour couvrir les cas où l’email seul ne suffit pas.

Consentement et RGPD : envoyer CAPI proprement

LinkedIn Conversions API ne vous affranchit pas du consentement. Transmettre un email haché ou un li_fat_id reste un traitement de donnée personnelle au sens du RGPD. Votre conteneur server-side doit lire l’état du consentement avant d’envoyer les paramètres d’identité, et s’abstenir d’envoyer email, firstName, lastName ou li_fat_id quand la base légale fait défaut.

Le cadre de consentement Consent Mode s’applique ici de la même façon que pour Meta CAPI ou les enhanced conversions Google Ads. Pour le pendant Google de cette logique server-side, voir les conversions optimisées en server-side.

Checklist : votre LinkedIn CAPI est-il sain ?

Avant de considérer votre installation comme terminée, vérifiez ces points :

1. Deux règles de conversion : une règle “Insight Tag” et une règle “Conversions API” existent dans Campaign Manager pour chaque événement clé.
2. Déduplication : le même event_id part de l’Insight Tag (navigateur) et du conteneur serveur, généré une seule fois côté client. Le volume total dans Campaign Manager correspond au nombre réel de conversions.
3. li_fat_id : le cookie LinkedIn est lu côté client, transmis au serveur et envoyé à l’API en clair (jamais haché).
4. Email haché : l’email est normalisé (minuscules, sans espaces) et haché en SHA-256 avant l’envoi serveur.
5. Score de matching : visible dans Events Manager. Améliorez-le en ajoutant prénom, nom et pays aux paramètres envoyés.
6. Consentement : aucune donnée d’identité ne part sans base légale. La balise est branchée sur le Consent Mode.

Si la déduplication patine ou que le score de matching refuse de grimper malgré ces réglages, le diagnostic devient plus fin : ordre de déclenchement des tags, perte de l’event_id dans le dataLayer, li_fat_id non transmis ou normalisé de façon incorrecte. C’est le moment de faire auditer l’ensemble du tunnel plutôt que de multiplier les essais à l’aveugle.

Conclusion

LinkedIn Conversions API repose sur la même logique server-side que Meta ou TikTok, mais avec une contrainte propre : deux règles de conversion distinctes, une par source, reliées par un event_id partagé. Sans ce câblage, vous comptez deux fois, ou vous ratez la moitié du signal. Réglez la déduplication en premier, puis améliorez le score de matching avec un email haché et un li_fat_id envoyé en clair. Ce sont les deux leviers qui décident si votre LinkedIn CAPI devient une vraie source de signal, ou reste un tuto coché sur une liste.