LinkedIn Conversions API
The same server-side pattern, a B2B-shaped conversion
LinkedIn's Conversions API follows the now-familiar server-to-server model: events sent directly from your backend or server-side tagging layer to LinkedIn, supplementing the browser-based Insight Tag and recovering signal lost to ad blockers, ITP, and B2B buyers browsing from corporate networks that often block third-party trackers more aggressively than consumer traffic does. The structural difference from Meta/TikTok/Snap/Pinterest isn't the transport mechanism — it's that LinkedIn conversions are usually several steps removed from revenue (a demo request, a gated whitepaper download, an MQL handoff to sales) rather than an immediate purchase.
Why offline conversion import matters more here than on consumer platforms
Because B2B sales cycles routinely span weeks or months between the ad click and actual revenue, LinkedIn's Conversions API is frequently used less for real-time website events and more for feeding *later-stage CRM events* back to LinkedIn — a lead qualifying as a Sales Accepted Lead, or a deal closing — using the LinkedIn click identifier captured at the original ad click and carried through the CRM record, the same pattern as Google Ads' offline conversion import. This makes LinkedIn's CAPI implementation closer in spirit to offline conversion import than to a typical real-time ecommerce CAPI integration.
{
"conversion": "urn:lla:llaPartnerConversion:123456789",
"conversionHappenedAt": 1735689600000,
"user": {
"userIds": [
{ "idType": "SHA256_EMAIL", "idValue": "f660ab912ec121d1b1e928a0bb4bc61b15f5ad44d5efdc4e1c92a25e99b8e44" }
],
"userInfo": {
"firstName": "J***",
"lastName": "D***",
"companyDomain": "example.com"
}
},
"conversionValue": {
"currencyCode": "USD",
"amount": "5000.00"
}
}companyDomain is a B2B-specific matching signal with no consumer analog
Conversion ID setup is manual and happens in Campaign Manager first
Unlike some platforms where a pixel ID alone suffices, LinkedIn requires creating a specific Conversion object in Campaign Manager first — defining its type, attribution window, and counting method — and the resulting conversion URN (urn:lla:llaPartnerConversion:...) is what every CAPI payload references. This means CAPI integration work can't start purely at the engineering layer; it depends on marketing/ads team configuration happening first in the Campaign Manager UI.
LinkedIn CAPI vs. consumer-platform CAPI implementations
| Dimension | Consumer platforms (Meta/TikTok/Snap/Pinterest) | |
|---|---|---|
| Typical conversion type | Immediate ecommerce purchase | Multi-stage B2B funnel event (lead, MQL, closed deal) |
| Time lag between click and conversion | Minutes to days | Days to months — often requires CRM-sourced offline events |
| Matching signals | Email, phone, device/click identifiers | Email, plus company domain and firmographic signals |
| Setup dependency | Pixel ID usually sufficient to start | Requires a pre-configured Conversion object in Campaign Manager |
Privacy and anonymization expectations are stricter for professional data
firstName/lastName in LinkedIn's schema are explicitly expected to be partially masked (a convention reflected in LinkedIn's own documentation examples) given the sensitivity of professional identity data. Treat LinkedIn CAPI payloads with at least the same PII-handling rigor as consumer platforms, and verify current field requirements against LinkedIn's documentation before building a production pipeline, since B2B data handling expectations can differ from consumer ad tech defaults.What's Next?
Having closed the loop on ad-platform conversion APIs across both consumer and B2B contexts, the next natural area is what happens to a lead *after* it's captured — nurturing, scoring, and routing it through marketing automation until it's ready for the sales handoff these conversion events ultimately represent.
I build these systems professionally.
Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.