# LinkedIn Conversions API review worksheet

Use this record to decide what to implement and what the evidence proves. Keep access tokens, raw personal information, and real user identifiers out of this worksheet and any AI prompt. Use private receipt references and redacted event labels.

## 1. Choose the delivery route

- Business action and source of truth: [unknown]
- Trigger condition, including what does not qualify: [unknown]
- Route: [direct API / named partner / undecided]
- Why this route fits the source system and team: [unknown]
- Integration owner and maintenance owner: [unknown]
- For a partner, its exact product, supported event, account mapping, and delivery receipt available: [unknown]
- For direct API, access approval, OAuth permission check (rw_conversions and r_ads), eligible account role, supported LinkedIn-Version, and version-check date: [unknown]
- Authorization to implement or send test events: [unknown]
- Permission to use the proposed customer data and identity fields: [unknown]

An unknown route, owner, access requirement, or authorization keeps implementation on Hold. A partner's support for a source system does not establish that your event is configured correctly.

## 2. Fix the scope before testing

- Review timestamp and timezone: [unknown]
- Event occurrence window: [unknown]
- Ad account label and private reference: [unknown]
- Server conversion rule, enabled state, conversion type, and receipt: [unknown]
- Browser conversion rule if redundant tracking is intended: [unknown / not applicable with reason]
- Campaign/ad-set associations for each relevant rule, with readback receipt: [unknown]
- Attribution model, click window, view window, and reporting date basis: [unknown]
- Monetary value mode and currency, or no-value decision: [unknown]
- Source count of distinct qualifying actions in this exact scope, and receipt: [unknown]

Separate reporting scopes if the account, rule, trigger, model, window, or source snapshot changes. Do not compare totals across those changes as if only delivery changed.

## 3. Record one business action, then its delivery attempts

Use capi-event-ledger.csv. Each row is one delivery attempt for a business action. The same action can have a browser row, a server row, and a retry row. Retain the same business_action_id so attempt counts cannot become business-result counts. The supplied blank row is an unfilled template; replace it before calculating totals.

Use verified, failed, unknown, or not_applicable in status columns. Not applicable requires a reason in next_action. A blank cell means unknown. Zero is a measured number and needs a receipt. attempt_id identifies the local attempt; event_id records the intended deduplication identity, not a person's identity. Store only redacted labels here.

For each source action, check the actual occurrence time. API conversionHappenedAt is epoch milliseconds and must be within the past 90 days. Record the identifier type and normalization check, without copying its value. SHA256_EMAIL starts with lowercase email without whitespace, then SHA-256 hashing. A hash alone does not establish permission to send the data.

For redundant browser/server tracking, use separate conversion rules in the same ad account. Carry the same event identity from the browser to the server. Event-specific Insight Tag uses event_id; the API uses eventId. A page-load implementation sets window._linkedin_event_id before the base tag executes. Record which mechanism you inspected. A new business action needs its own event identity.

A server retry needs its own attempt record and the same source-action reference. The browser/server deduplication documentation does not establish that arbitrary server retries are idempotent. Resolve an ambiguous delivery result before replaying; record the retry decision and its evidence.

## 4. Write five separate conclusions

| Question | Status | Evidence reference | Next action and owner |
|---|---|---|---|
| Did the qualifying business action occur? | unknown | | |
| Was the server event accepted? | unknown | | |
| Was the user matched? | unknown | | |
| Was redundant browser/server tracking handled as intended? | unknown | | |
| Was a conversion attributed in the stated reporting scope? | unknown | | |

HTTP 201 supports acceptance of the submitted event request. It does not prove user matching, browser/server deduplication, or attribution. A batch validation failure can reject every record; preserve the batch response and item mapping rather than treating unmentioned rows as accepted.

Check both conversion rules in reporting. LinkedIn documents that a redundant same-account, same-eventId browser/server event is counted under the Insight Tag rule and deducted from the API rule. A larger browser count alone does not prove that your specific test event was deduplicated. If the available reporting is aggregate, state that limit and keep event-level conclusions unknown.

Only calculate an acceptance rate when numerator and denominator are distinct server attempts from the same scope and every outcome is known. Label it an attempt acceptance rate. A business-action coverage rate needs distinct qualifying actions as its denominator, with retries collapsed. When the source count is complete but delivery is partial, confirmed accepted actions divided by source actions is a lower bound. Label it confirmed coverage and keep final coverage unknown. If the denominator is zero, return not applicable; if any required count is missing, return unknown. Never derive a match rate from accepted requests.

## 5. Decide the next action

- Implementation readiness: [Ready for authorized test / Hold]
- What has been verified: [unknown]
- What remains unknown or failed: [unknown]
- Next check, evidence needed, and owner: [unknown]
- Changes or sends authorized by this review: [none unless explicitly supplied]

Ready for an authorized test requires route, scope, access, permissions, event mapping, and an explicit test authorization. It is not a claim that matching or attribution works. Record those outcomes after the test.

## Sources

Reviewed 29 October 2026. Check the version relevant to your integration before implementation.

- https://learn.microsoft.com/en-us/linkedin/marketing/integrations/ads-reporting/conversions-api?view=li-lms-2026-10
- https://learn.microsoft.com/en-us/linkedin/marketing/integrations/ads-reporting/conversions-api-schema?view=li-lms-2026-10
- https://learn.microsoft.com/en-us/linkedin/marketing/conversions/deduplication?view=li-lms-2026-10