LinkedIn Conversions API for B2B: Tracking leads that the Insight Tag misses

The LinkedIn Conversions API (CAPI) sends conversion events to LinkedIn from your own server rather than from the visitor's browser. It exists because the LinkedIn Insight Tag depends on two conditions that can no longer be fulfilled for B2B: an unblocked browser script and a sales cycle that’s short enough that the cookie still exists when the lead converts.

LinkedIn is where a lot of business-to-business (B2B) pipeline starts. Demo requests, webinar sign-ups, gated content downloads, all driven by campaigns that get judged inside Campaign Manager.

The measurement side has not kept up. For years, the LinkedIn Insight Tag was good enough. A JavaScript snippet loaded, read the page, and told LinkedIn that a lead happened. That worked while browsers left third-party pixels alone, and while sales cycles were short enough that the cookie still existed when the form went in.

Both of those conditions have changed. In Safari 27, which is in beta and ships with iOS 27 and macOS 27, the Insight Tag is classified as a fingerprinting-related script, and its access to query parameters and referrer data can be revoked. Ad blockers remove it outright. B2B buying cycles run past the cookie windows the tag depends on. So the customer relationship management (CRM) system fills up with leads while Campaign Manager reports fewer conversions than sales can see, and automated bidding keeps optimizing on the smaller number.

LinkedIn Conversions API (CAPI) is the path that survives all three. The conversion leaves your own server carrying a hashed email, LinkedIn's click ID (li_fat_id), and a shared event ID so the browser tag and the server call never get counted twice.

Why the LinkedIn Insight Tag stopped being enough on Safari

The Insight Tag is a browser script. It loads, reads what it can from the page, then calls LinkedIn. Break any of those steps and Campaign Manager never learns the conversion happened.

Ad blockers handle the crude version. Filter lists stop snap.licdn.com and the related Insight Tag endpoints, the thank-you page renders normally, and nothing reaches LinkedIn.

Safari does something more selective, which is why it trips people up. Safari 27 tracking protection places the Insight Tag on WebKit's fingerprinting-related lists, and Advanced Fingerprinting Protection works by revoking specific capabilities from a classified script rather than blocking it outright. A classified script can lose query-parameter and referrer access while it keeps the ability to make network requests. The tag fires, the request succeeds, and the click ID that should have tied the lead back to a campaign was never readable in the first place. Nothing in the tag manager preview looks broken.

Cookies leak on a slower clock. Safari's Intelligent Tracking Prevention (ITP) caps JavaScript-written first-party cookies at seven days. The li_fat_id cookie is designed to outlast a single session, but the Insight Tag writes it with JavaScript, so on Safari the seven-day cap is the one that applies. A buyer who reads a case study in week one and books a demo in week four has already lost the click ID.

Retail conversions usually happen in the same session, while the B2B event worth money is a form, a booked call, or a CRM stage change that lands hours or weeks later.

What the LinkedIn Conversions API sends

CAPI sends events from your own server or from a Google Tag Manager (GTM) server container, to LinkedIn's /conversionEvents endpoint. The schema and the full error tables sit in LinkedIn's Conversions API documentation.

Every event references a conversion rule, in the form urn:lla:llaPartnerConversion:123. That rule is created with its method set to Conversions API, which is exactly why the browser rule and the server rule are two separate rules rather than one shared one. Campaign Manager surfaces the same value as "Conversion ID for Google Tag Manager" when you open the rule settings and pick the tag manager option.

Then there is conversionHappenedAt, an epoch timestamp in milliseconds. LinkedIn rejects anything older than 90 days, and any system that stores seconds needs three zeros appended before sending. It is a small detail that breaks more integrations than it should.

Matching happens on the user object. For B2B lead gen, two identifiers carry most of the weight:

Hashed email, sent as SHA256_EMAIL. LinkedIn expects the address lowercased with whitespace removed, then hashed with SHA-256 (Secure Hash Algorithm 256-bit) and sent as a hex string.

li_fat_id, sent as LINKEDIN_FIRST_PARTY_ADS_TRACKING_UUID. LinkedIn appends this click ID to landing page URLs once enhanced conversion tracking is enabled on the Insight Tag. New Insight Tags get that setting by default. Anything created a while ago is worth opening and checking rather than assuming.

eventId is the deduplication key against the Insight Tag. Same string on both sides, same real-world action. Plaintext IP address, first and last name, job title, and company can ride along on the same payload where consent allows, and they help match rates without replacing email or click ID on a lead form.

An event still gets accepted without li_fat_id as long as a hashed email or another supported identifier is present. What drops is match quality, which shows up later as campaigns that look weaker than the CRM says they are.

Which identifiers to send

Identifier	LinkedIn field	Where it comes from	What happens if it’s missing
Hashed email	SHA256_EMAIL	The lead form, hashed on your server	Match rate drops sharply on B2B forms
LinkedIn click ID	LINKEDIN_FIRST_PARTY_ADS_TRACKING_UUID	The landing page URL, or the cookie the Insight Tag writes	The event is accepted, but attribution to the ad click weakens
IP address	PLAINTEXT_IP_ADDRESS	The server request	Little impact when email or click ID is present, and a partial fallback when neither is
Name, title, company	userInfo fields	The lead form	Little impact when email or click ID is present

LinkedIn scores every event on how likely it is to match a member profile, and that score affects your cost per result. Send hashed email and li_fat_id together whenever you have both.

Insight Tag and CAPI: the redundant setup that LinkedIn recommends

LinkedIn recommends sending the same conversion twice, once through a website tag (Insight Tag or image pixel) and once through CAPI. They call it a redundant setup. The advertiser-facing version is in Deduplication for Conversion Tracking and the implementation detail is in LinkedIn's deduplication documentation.

You build one conversion rule per data source. One browser, one server. At conversion time you generate a single eventId and attach it to both events.

When LinkedIn receives an Insight Tag event and a CAPI event from the same account with the same eventId, it discards the CAPI event and counts the Insight Tag one in campaign reporting. The browser wins the tie, which surprises anyone who assumed the server signal would be treated as the more reliable of the two. After deduplication the Insight Tag line in your conversion breakdown usually sits higher than the CAPI line, because the duplicate gets deducted from the server side.

Deduplication only has something to do when both events actually arrive. If Safari or an ad blocker stopped the browser event, there is no twin to prefer and the CAPI event is what gets counted. That is the whole point of running both.

B2B events worth optimizing to

Map conversion rules to outcomes you would put budget behind. A demo request, a completed contact or trial form, a confirmed webinar registration. Marketing qualified lead (MQL) and sales qualified lead (SQL) stages belong here too, as long as sales actually maintains them, which is the part most teams underestimate.

Conversion rule type matters more than it looks. LinkedIn supports post-click attribution windows of 1, 7, 30, and 90 days, with 30 days as the default. A 365-day window is available for five conversion types: Lead, Qualified Lead, Submit Application, Purchase, and Add to Cart. For a nine-month enterprise sales cycle, choosing an eligible conversion type can determine whether the original ad click receives credit.

Page views rarely justify the work. Soft engagement can stay on the Insight Tag or be dropped entirely. A pricing-page download only belongs on the server path if you already bid toward it.

Late conversions from HubSpot or your CRM

Plenty of B2B value shows up after the thank-you page. A prospect fills in the form on Tuesday, sales books the demo on Thursday, and the Insight Tag never sees the second step because there is no page to fire on.

When HubSpot or another CRM is the system of record, the useful loop runs from the site form to the CRM record, out through a webhook into the server container, and on to LinkedIn CAPI. Trigger it on form creation, meeting booked, or the qualified-lead stage. The join key is the hashed email captured on the original lead, plus li_fat_id if you stored it on the contact record.

That recovers conversions that never had a pixel anywhere near them. The HubSpot server-side tracking guide covers the CRM half of the loop, including why HubSpot's own browser cookie makes a poor clock for long journeys.

Reuse the website form's eventId if the CRM event describes the same action. Give the event a fresh eventId when the CRM stage is a later outcome with its own conversion rule. And watch the 90-day timestamp limit when someone suggests backfilling a year of historical CRM data. Those events will be rejected, and the fix is to start sending forward rather than reaching backward.

If you are sending a batch from the CRM, the limits are 600 requests per minute and 300,000 per day for a single access token, with up to 5,000 conversion events in one batch request.

LinkedIn CAPI in server-side GTM: the high-level shape

This is the measurement architecture rather than a click-by-click walkthrough. Our LinkedIn server-side tracking guide covers the setup in full, while LinkedIn publishes its own server-side GTM implementation guide for the screen-level detail.

1. Capture li_fat_id on landing. Turn on enhanced conversion tracking for the Insight Tag in Campaign Manager so LinkedIn starts appending the click ID. Read it from the query string on paid landings and persist it in a first-party cookie or the data layer, so a form filled in twenty minutes later still has it. Where the Insight Tag is installed, the li_fat_id cookie it writes is a second source.

2. Generate one eventId when the lead converts. A universally unique identifier (UUID), or your lead ID plus a timestamp, does the job. Push that exact string into the data layer before either event goes out.

3. Keep a thin Insight Tag wherever it still loads. The LinkedIn Insight Tag 2.0 template in the web container has an Event ID field. Feed it the same value. Watch the naming: the data layer and the CAPI payload both use eventId, while a manual lintrk('track', ...) call uses event_id. Two tags can look perfectly healthy in preview while that mismatch breaks deduplication underneath.

4. Forward the conversion into the server container. The usual route is a form event in the web container, then a Google Analytics 4 (GA4) event into the server container where a GA4 client picks it up. Carry email, eventId, li_fat_id, and page URL. Add value only where you genuinely optimize toward it.

5. Send CAPI from the server container. LinkedIn maintains an official server-side tag, LinkedIn | CAPI Tag, in the Community Template Gallery. It translates the GA4 event model into LinkedIn's schema and posts it, so you avoid hand-building the payload in an HTTP Request tag. It needs the conversion rule ID and an access token. Tokens expire, so someone has to own renewing that before a quarter of conversions goes missing.

6. Hash and gate before anything leaves. Hash email on the server rather than in the browser. If the consent management platform (CMP) has denied ads storage or ads user data, LinkedIn CAPI gets blocked like any other ads tag. Moving a call server-side changes nothing about consent obligations.

7. Verify against the CRM. Allow three days before drawing conclusions. LinkedIn takes up to 24 hours to ingest events and a further 48 hours before they appear in reporting. Both sources should appear in the conversion breakdown when the dual setup works, with the Insight Tag line running higher. Compare totals to CRM form counts. Measuring the new setup against last year's Insight-only numbers tells you nothing useful, since that baseline is the thing you just replaced.

When you compare CAPI totals to CRM form counts, check whether you are looking at click and view conversions combined. Campaign Manager reports them as a single number by default, and the view-through window defaults to seven days.

Mistakes that inflate or hide LinkedIn conversions

No shared eventId. Every browser and server pair becomes two conversions. Without that string LinkedIn has no way to spot the duplicate.

Treating the conversion rule ID as the deduplication key. These do different jobs. The rule ID says which conversion to increment, eventId says which real-world action this is. Two rules and one eventId is the correct shape for a single form submit.

The conversion rule was never linked to a campaign. LinkedIn only attributes a conversion to campaigns the rule is linked to. Events arrive, the API returns success, and reporting stays empty. It is a frustrating one to debug because nothing actually errored.

No click ID. Either enhanced conversion tracking was never switched on, or li_fat_id was read on the landing page and then lost before the form. Email matching still works. Attribution gets worse, and long B2B cycles feel it most.

Checking only in Chrome. The tag looks fine in Chrome preview, so the setup gets signed off. Safari traffic and blocked browsers are already missing from that view, and "our buyers don't use ad blockers" tends to be a hope rather than a measured fact.

Sending page views to CAPI. LinkedIn will happily optimize toward traffic if that is what you feed it.

Where TAGGRS fits

LinkedIn server-side tracking needs somewhere stable to run the server container, first-party delivery on your own subdomain, and a place to hash and attach identifiers before anything reaches LinkedIn.

TAGGRS provides that hosting layer and the subdomain connection. The web container reports the conversion once, and the server decides what happens next: hash the email, attach li_fat_id, then fire LinkedIn CAPI alongside HubSpot or Google Ads from the same event. Setup detail for the LinkedIn pieces:

• LinkedIn Insight Tag
• LinkedIn Conversions API
• LinkedIn event deduplication

Conclusion

Safari 27 and ad blockers have turned Insight-Tag-only measurement into a weak base for B2B bidding. CAPI moves the lead event onto a server path you control, keeps the click ID and hashed email attached to the conversion, and leans on eventId so a redundant setup never double-counts.

If LinkedIn drives pipeline, it deserves the same treatment ecommerce teams already give Meta CAPI. Core measurement infrastructure, budgeted and owned.

Ready to set up Server-side Tracking for Linkedin? Create a free TAGGRS account or book a demo to talk through your specific setup.

FAQ

Should I turn the Insight Tag off once CAPI is live?

Not by default. LinkedIn still recommends running browser and server together, and when both events arrive it keeps the browser one. Leave the Insight Tag where it loads, send CAPI for the same conversion, share the eventId, and let CAPI cover the sessions the browser never reports.

Is hashed email required?

The API accepts several identifier types, so strictly speaking no. In practice hashed email is the anchor for B2B forms, with li_fat_id tying the conversion back to the ad click. Send both whenever you have both.

Can I send MQL or SQL stages from the CRM?

Yes, through a webhook into the server container, provided you can join the CRM record back to the email or click ID captured on the original lead. Give that stage its own conversion rule and its own eventId, and consider a lead-shaped conversion type so the longer attribution window is available.

Does any of this help organic LinkedIn traffic?

CAPI exists to measure and optimize ad conversions. Organic performance still belongs in your site analytics stack.

Why is my Insight Tag count higher than CAPI after go-live?

Usually because deduplication is working. LinkedIn keeps the browser event and deducts the matching server one, so a higher Insight Tag number in the breakdown is the expected shape rather than a sign the server path failed.