LinkedIn's September 2026 marketing API release is unusually consequential for a version note. Three of its changes touch how B2B advertising gets counted: a new attribution window length, a new way to match offline conversions, and a new geographic reporting dimension. None of them improves a campaign. All of them change what a campaign appears to have done.
The 180-day window
The Conversions API now accepts 180 as a value for both post-click and view-through attribution window size, alongside the existing 365-day option. It applies to a defined list of conversion types — application submissions, purchases, add-to-cart, leads, qualified leads, and the marketing-qualified and sales-qualified lead types — and is available on all active API versions.
A longer window does not create conversions. It relabels them. Any conversion that happens 120 days after a click was already happening; the only question was whether the platform was allowed to claim it. Extending a window therefore raises reported conversions and lowers reported cost per conversion without anything changing in the market — which is exactly why the choice has to be made deliberately and then left alone.
| Window | Fits | Risk if chosen badly |
|---|---|---|
| 30–90 days | Self-serve, low-consideration, short cycles | Systematically under-credits any channel that works early in a long cycle |
| 180 days | Mid-market B2B, considered purchases, most agency retainers | Half a year of lag before a cohort is complete; slow to detect real decline |
| 365 days | Enterprise, procurement-led, multi-stakeholder deals | A number that cannot be acted on within a budget year |
The right length is the one that matches your actual median time from first touch to closed deal, which your CRM can tell you and your instinct cannot. If that figure is 140 days, a 90-day window has been quietly discarding the majority of your evidence.
Changing a window mid-year
If you do extend the window, the periods either side of the change are not comparable, and the platform will not annotate that for you. Record the date, keep the old window's figures for the trailing twelve months, and state the change explicitly in the first report that uses the new one. A performance improvement that turns out to be a settings change is the single fastest way to lose a client's trust in every other number you send them.
There is a second-order point worth raising with any client whose reporting you inherited: until now the choice was effectively between a short window and a year, and a great many accounts are on whatever the default was, chosen by nobody. A new middle option is a good moment to ask what the window is currently set to, why, and whether anyone has ever looked. That question has changed more reports than most optimisations do.
Hashed name matching
The conversion events endpoint now accepts hashedFirstName and hashedLastName in the user info object, alongside the existing plain-text fields. Each value must be lowercased, stripped of spaces and punctuation, encoded as UTF-8 and hashed with SHA-256 into a 64-character hexadecimal string. The endpoint requires either a first name or its hash, together with either a last name or its hash.
This is a straightforward privacy improvement and an equally straightforward operational hazard. The improvement: names leave your systems as hashes rather than as text. The hazard: hashing is unforgiving. A trailing space, a capital letter, a hyphen left in a double-barrelled surname, an accented character encoded as something other than UTF-8 — each produces a valid 64-character string that matches nothing. There is no error, because the request is well-formed. Match rates simply fall.
- Normalise before hashing, in one shared function, and test it against names with accents, apostrophes, hyphens and non-Latin characters.
- Record your match rate before switching to hashes, then again after. A drop is an implementation bug, not a data-quality finding.
- Keep the normalisation rules in code that both marketing and engineering can see. Two teams normalising differently is the usual cause of a silent halving.
DMA-level reporting
The ads reporting API adds a pivot for member designated market area, returning geography as URNs that resolve to Nielsen DMA names through the targeting entities resource. Anyone publishing those names has to carry the registered mark and the attribution notice that Nielsen requires.
For advertisers operating in the United States this makes LinkedIn reporting directly comparable with television and radio planning, which have used DMAs for decades. It also makes LinkedIn a usable read-out for geographic experiments: a market-level breakdown is what turns a holdout design into something you can actually measure, which is the mechanism behind any geo-lift test.
One more, for anyone reporting on buying committees
The Company Intelligence endpoint gains campaign group, objective type and seniority filters — but only one of them may be used at a time, organic metrics return zero when a campaign-related filter is applied, and the seniority filter works only with a 90-day lookback. Those are tight constraints, and they mean a dashboard that shows seniority next to a campaign breakdown cannot be built from one call. Better to know that before promising the view.
The version treadmill
Two API versions sunset shortly: one in mid-October and one in mid-November 2026. If any part of your reporting stack pins a version — and most do, because pinning is what stops a silent break — someone needs to own the upgrade before those dates. The new filters are not available on older versions at all, so the choice is to upgrade or to do without.
That is the unglamorous conclusion of a release like this. The interesting decision is the attribution window, and it is a decision about honesty in reporting rather than about performance. The rest is maintenance — but maintenance that, left undone, produces a dashboard that quietly stops being true.
Sources
- https://learn.microsoft.com/en-us/linkedin/marketing/integrations/recent-changes?view=li-lms-2026-05
