LinkedIn Conversions API Server-Side GTM: Dedup and Match Quality

Setting up LinkedIn Conversions API in server-side GTM is now well-documented: Microsoft’s official guide (version li-lms-2026-05, updated May 2026) walks through the setup steps in minutes. The problem is that LinkedIn is not Meta. It imposes an architectural constraint that almost no guide explains: two separate conversion rules, one per data source, connected via event_id so deduplication actually works. Without this wiring, your install silently doubles conversions, or reports only half the signal. This article takes the same approach as the Meta CAPI server-side GTM guide and the TikTok Events API server-side GTM guide, applied to LinkedIn’s key constraint: the source-bound conversion rule. The goal: walk away with a clean CAPI, no duplicates, and a match quality score you can actually act on in LinkedIn Campaign Manager.

LinkedIn CAPI is not Meta CAPI: the source-bound trap

This is the setting everyone misses, and the consequence is immediate: silent duplication in your reported conversions, or a truncated server-side signal.

With Meta, a single conversion rule can receive events from multiple sources (Pixel and CAPI) and deduplicate them automatically via event_id. With LinkedIn, that is not possible. Each data source requires its own conversion rule. One rule for the Insight Tag (client-side), another for the server API. The two rules remain separate in LinkedIn Campaign Manager and do not merge into a single line.

This model is called a “source-bound conversion”: a rule is tied to one specific source and cannot combine multiple origins. If you create a single rule and send both Insight Tag and CAPI events to it, LinkedIn does not deduplicate: it counts two distinct conversions.

Deduplication still happens, but at a different level: LinkedIn compares events received through both rules and matches them via event_id. For this matching to work, both rules must share the same event_id for the same real-world event. Campaign Manager then displays a deduplicated count in your conversion reports.

Architecture: Insight Tag + server container + deduplication

The architecture has three building blocks, just like Meta and TikTok. But the deduplication logic is LinkedIn-specific.

The flow is: the Insight Tag fires in the browser through your web GTM container. At the same time, the server-side container (sGTM) sends the same event to the LinkedIn API. Both paths describe the same real conversion. LinkedIn receives two signals and matches them if the event_id is identical.

This architecture assumes a hosted server container (Cloud Run, Stape, or Addingwell). If you do not yet have a server-side container, start with the GTM server-side migration guide. The initial infrastructure has a cost to plan for, detailed in how much server-side GTM really costs.

Setting up in server-side GTM

Create the two conversion rules in Campaign Manager

This is the step nearly everyone skips. In LinkedIn Campaign Manager, go to Analyze > Conversion Tracking > Create conversion.

Create two separate rules for each conversion event (for example, a Lead Gen form or a purchase):

1. Insight Tag rule: select “Insight Tag” as the source. This rule will receive events fired client-side in the browser.
2. API rule: select “Conversions API” as the source. This rule will receive events sent from your server-side container.

Both rules must use the same event name (for example Lead) and be associated with the same campaign. That is the condition for LinkedIn to correctly match the signals.

Configure the LinkedIn CAPI tag in sGTM

In your server-side container, use the official LinkedIn Conversions API tag (available in the template gallery or through partners like Stape). Fill in:

• The conversion ID from the API rule created in the previous step.
• The event_id: retrieved from the dataLayer, generated once on the client and passed to the server (see the deduplication section below).
• The li_fat_id: the LinkedIn cookie set by the Insight Tag in the browser. It must be read by the web GTM container, pushed to the dataLayer, and forwarded to the server. This is the equivalent of _fbp in Meta.

The event_id: the golden rule for deduplication

Generate the event_id once, on the client side, at the moment the event occurs. Push it to the dataLayer. The server-side container picks it up from the request and forwards it to LinkedIn without regenerating it.

If the browser and the server each generate their own identifier, the two values never match: LinkedIn sees two distinct events instead of one, and your conversions are doubled.

Verifying deduplication in Campaign Manager

Verification happens in LinkedIn Campaign Manager > Analyze > Conversion Tracking. Select your conversion event and look at the source breakdown: you should see attributions split between “Insight Tag” and “Conversions API,” but the deduplicated total should match your actual conversion count.

LinkedIn does not provide a visual indicator as explicit as Meta’s “1 event from 2 sources.” Verification therefore relies on volume consistency. If you see double the expected volume, the event_id-based deduplication is broken. If you only see attributions from one source, one of the two rules is not receiving data.

The Campaign Manager interface changes regularly: confirm the exact labels when you audit, but the deduplication logic itself stays stable.

Match quality: the parameters that matter

The match quality score is visible in LinkedIn Campaign Manager > Analyze > Events Manager. It measures LinkedIn’s ability to associate your server events with real LinkedIn profiles. The higher the score, the more useful your signal is for the bidding algorithm.

The parameters that most improve the score:

The most frequent mistake involves li_fat_id: this cookie must travel in clear, exactly like _fbp in Meta. Hashing it breaks the match, because LinkedIn expects to read it as-is to identify the browser profile. Conversely, email must be SHA-256 hashed and normalized before sending. Confusing these two logics is the most common reason a match quality score stays too low.

LinkedIn’s primary matching signal is the hashed email compared against account data. If your form collects a professional email and the user is signed into LinkedIn with that same address, the match is nearly guaranteed. Add first name, last name, and country to cover cases where email alone is not enough.

Consent and GDPR: sending CAPI cleanly

LinkedIn Conversions API does not exempt you from consent. Transmitting a hashed email or a li_fat_id is still the processing of personal data under the GDPR. Your server-side container must read the consent state before sending identity parameters, and refrain from sending email, firstName, lastName, or li_fat_id when the legal basis is missing.

The Consent Mode framework applies here the same way it does for Meta CAPI or Google Ads enhanced conversions. For the Google Ads counterpart of this server-side logic, see server-side enhanced conversions, which completes the stack on the Google side.

Checklist: is your LinkedIn CAPI healthy?

Before you call the install done, run through these points:

1. Two conversion rules: one “Insight Tag” rule and one “Conversions API” rule exist in Campaign Manager for each key event.
2. Deduplication: the same event_id leaves both the Insight Tag (browser) and the server container, generated once on the client. The total volume in Campaign Manager matches your actual conversion count.
3. li_fat_id: the LinkedIn cookie is read client-side, forwarded to the server, and sent to the API in clear (never hashed).
4. Hashed email: the email is normalized (lowercase, no spaces) and SHA-256 hashed before the server sends it.
5. Match quality score: visible in Events Manager. Improve it by adding first name, last name, and country to the parameters you send.
6. Consent: no identity data leaves without a legal basis. The tag is wired to Consent Mode.

If deduplication keeps slipping or the match quality score refuses to climb despite these settings, the diagnosis gets more precise: tag firing order, loss of the event_id in the dataLayer, li_fat_id not forwarded or incorrectly formatted. That is the moment to have the full funnel audited rather than running blind trial and error.

Conclusion

LinkedIn Conversions API follows the same server-side logic as Meta or TikTok, but with its own constraint: two separate conversion rules, one per source, connected by a shared event_id. Without this wiring, you count twice, or miss half the signal. Fix deduplication first, then improve the match quality score with a hashed email and a li_fat_id sent in clear. Those are the two levers that decide whether your LinkedIn CAPI becomes a real source of clean signal, or stays a tutorial item checked off a list.