LinkedIn Conversions API Troubleshooting, Symptom by Symptom

• Wrong rule. The payload carries a conversion rule ID. Compare it to the rule on your screen. Two rules with near-identical names on one account is common, and the event lands on whichever ID was sent.
• No match. LinkedIn states that only matched events can be used for attribution and optimization. An unmatched event arrives and then goes nowhere. The rule reads Active while the campaign column stays empty.
• Dedup. If the Insight Tag sent the same action with the same eventId, LinkedIn keeps the tag event and drops the server copy. You got one conversion. That is correct.
• No credit. The campaign is not linked to the rule, or the ad click sits outside the lookback window. Both are covered below.

Then check the report itself: date range, campaign filter, and which conversion column you added. “Received today” and “credited to this campaign in this date range” are two different claims. And if your events pass through middleware, get LinkedIn’s response, not the middleware’s. A green tick in a connector describes the connector. A queued event has not reached LinkedIn yet.

The API returns an error, or one bad row sinks the batch

Errors are the easy case, because the response tells you what broke. Read it before you touch the payload.

The docs name the usual causes: a missing access token, missing permissions on the ad account, an event time out of range, no user identifier, or a rule that was switched off or deleted. Log the status code, the error body with secrets stripped, the send time and the rule ID. Keep the auth header out of that log. For token errors, check how that route issued its credentials. Expiry rules differ by route, so one fix will not cover every setup.

Batches need more care. The API takes up to 5,000 events per batch, and one invalid value can fail every record in it. The error names the bad row by batchIndex. In a full batch, the other 4,999 rows failed with it, so none of them count as delivered. Fix the bad field. Then resend the batch with each event’s original ID and original timestamp. A retry is the same conversion sent again, not a new one.

Timestamps trip up CRM syncs most. conversionHappenedAt is a millisecond timestamp, and it must fall inside the past 90 days. A stage backfill older than that gets rejected. Stamping an old event with today’s date makes the request pass and the data lie. Send the true time, or leave the event out.

Events arrive, match rate is low

Active: Low Match Rate means the pipe works and the payload is thin. LinkedIn got the events but cannot tie most of them to a member. Each unmatched event is dead weight for campaign credit.

Every event needs at least one identifier. The accepted set, taken from the API’s own validation error, is SHA256_EMAIL, LINKEDIN_FIRST_PARTY_ADS_TRACKING_UUID (the li_fat_id first-party cookie), ACXIOM_ID, PLAINTEXT_IP_ADDRESS, GOOGLE_AID, first and last name together, externalIds, or a lead. The docs put it plainly: “Send multiple user identifiers if available, to increase match rates.” More fields raise the odds. They do not promise a match.

A low match rate traces to what left your server far more often than to what sits in your CRM. Open the outbound payload and look for four faults:

• The email field was empty when the event fired. The CRM filled it an hour later, after the sync had run.
• The email was hashed twice. The connector hashed a value the CRM had already hashed, and the result is a valid-looking string that matches nobody.
• An empty string passed a “field exists” check and went out as the identifier.
• li_fat_id never reached the server. The browser had the cookie. The server route never read it.

Pick one step to lowercase, trim and hash, and make every other step pass the value through untouched. Then fill the gaps with real data. Guessing an email, or sending the account owner’s, turns an unmatched event into a wrongly credited one, which is worse. A low match rate is never a reason to skip consent.

Conversions show up in the wrong campaign or not at all

The event matched. The rule shows it. The campaign you care about still reads zero. Now it is a credit problem, and credit runs on rules you can read.

First, the campaign link. The API guide says only campaigns linked to a conversion rule can get credit for it. Creating a rule does not link every campaign by itself. The API has a setting for auto-linking, but what counts is the list of links that exists today. Open the rule, read its campaign list, and compare it to the campaign you expected.

Second, two clocks. They get mixed up all the time:

• Event age is how old the conversion is when you send it. The API rejects anything older than 90 days.
• Lookback is how far back from the conversion LinkedIn looks for an ad click or view. Post-click windows come in 1, 7, 28, 30 and 90 days. Click and view windows are set apart, so read both.

Take a CRM stage change from yesterday. It passes the age check. Say the ad click that started the deal was 120 days ago. With a 90-day post-click window, that deal gets no credit, and the API was still right to take the event. Our buyers run sales cycles of 60 days and longer, so for opportunity and closed-won events this is the normal case, not the edge case. Widening the window is a reporting policy change. Make it on purpose, write down the date, and never call it a repair.

Moving a campaign’s target to a CRM stage has one more cost. It restarts the LinkedIn learning phase on that campaign, which needs roughly 50 events a month to finish. A thin stage event can hold a campaign in learning for months, so check the monthly volume before you switch.

This is what attribution implementation, as opposed to attribution claims, looks like on a real ticket. The rules that tie an event to a campaign are written down. You read them instead of guessing.

Server count is lower than tag count

You run the Insight Tag and CAPI side by side, which is the setup LinkedIn recommends. The server rule shows fewer conversions than the tag rule. Most of the time, that is dedup doing its job.

LinkedIn’s dedup docs, checked September 26, 2026, say it directly: “If we receive an Insight Tag event and a Conversions API event from the same account with the same eventId, we discard the Conversions API event and count only the Insight Tag event in campaign reporting.” The tag wins. The server copy exists to catch the events the browser lost to ad blockers, iOS privacy rules and expired cookies. The rest of the gap is usually match rate, since unmatched server events never reach a campaign.

So a lower server count is expected. The questions worth asking are about the IDs:

• Does the page set window._linkedin_event_id before the Insight Tag base code runs? If it sets it after, the tag fires with no ID.
• Does the server send that exact value as eventId? Random IDs made up on each side break the pair, and the action counts twice.
• Is one fixed ID reused across different actions? Then separate, real conversions fold into one.

Retries are a separate problem. If a request times out after LinkedIn already took it, find out what your connector sends next before you trust a fresh ID.

The reverse symptom is the one to worry about. If the server count sits above the tag count, and campaign totals jumped the week CAPI went live, check for broken IDs first. Double counting makes cost per lead look healthier without adding a single prospect. Switching dedup off to grow the total is the same trick with extra steps.

The LinkedIn Conversions API troubleshooting table: symptom, cause, first check

Each row starts from what you can see and ends at the one place to look first.

Run the checks on one event, in this order:

After a fix, run one test event through the failing path with the same report settings. Replaying live events until the number moves just adds noise to real data.

Close the ticket with a record: the source event, the rule, the request outcome, the status, the change made, and whatever is still unproven. “We reconnected it” is an action. It is not a diagnosis.