ktg-plugin-marketplace/plugins/linkedin-studio/docs/remediation/research/02-analytics-publish-boundaries.md

type	created	question	confidence	dimensions	mcp_servers_used	local_agents_used	external_agents_used
trekresearch-brief	2026-05-29	As of 2026, can a personal LinkedIn profile self-serve post-level analytics via an API, are per-post saves visible in the native UI, and can a personal profile auto-publish via any API — with the exact constraints for a solo user without partner/company-page access?	0.86	4	tavily		docs-researcher community-researcher contrarian-researcher

Personal-Profile Analytics + Auto-Publish Boundaries (2026)

Generated by trekresearch (standard external swarm: docs + community + contrarian; no Gemini — scoped to Topic 1) on 2026-05-29. Topic 2 of 3 for the linkedin-studio remediation. Feeds Phase-1 honest boundary statements + the Phase-2 saves honesty-fix. Primary-sourced from Microsoft Learn (LinkedIn's canonical dev docs).

Research Question

As of 2026, can a personal LinkedIn profile self-serve post-level analytics via an API, are per-post saves visible in the native UI, and can a personal profile auto-publish via any API — with the exact constraints for a solo user without partner/company-page access?

Executive Summary

The audit's own boundary assumptions are partly wrong, and fixing them naively would replace one false claim with another. Three findings, all primary-sourced and high-confidence: (1) a personal profile CAN auto-publish self-serve — w_member_social is an Open Permission via the free "Share on LinkedIn" product, publishing immediately at ~150 posts/member/day; the plugin's clipboard-stop is a design + Terms-of-Service choice, not an API impossibility. (2) Per-post saves ARE visible in native post analytics (rolled out ~Sept 2025, count-only, no saver identity) and exposed via the API's POST_SAVE metric (since version li-lms-2026-04) — so "saves aren't trackable" is stale/false; the honest line is "visible in the UI, not self-serve via API." (3) Post-level analytics via API exist (memberCreatorPostAnalytics / r_member_postAnalytics) but sit behind the vetted Community Management API (verified organization + associated LinkedIn Page + use-case review) — not self-serve for a solo creator; CSV export is the practical floor, not the only technical path. Key caveat: every boundary statement must be dated ("as of 2026-05") — this surface changed fast (saves went UI→API inside ~12 months).

Dimensions

D1. Post-level analytics API for personal profiles — Confidence: high

External findings:

• The endpoint exists: GET /rest/memberCreatorPostAnalytics ("Member Post Statistics"), permission r_member_postAnalytics (versions ≥ li-lms-202506). Finders q=entity (one post) and q=me (aggregated). Metrics: IMPRESSION, MEMBERS_REACHED, RESHARE, REACTION, COMMENT (since 2025-06) and — added li-lms-2026-04 — POST_SAVE, POST_SEND, LINK_CLICKS, PREMIUM_CTA_CLICKS, FOLLOWER_GAINED_FROM_CONTENT, PROFILE_VIEW_FROM_CONTENT. (Video metrics are a separate endpoint memberCreatorVideoAnalytics; follower count is memberFollowersCount / r_member_profileAnalytics.) [learn.microsoft.com/.../members/post-statistics?view=li-lms-2026-05]
• The access gate is the crux: r_member_postAnalytics is listed exclusively under the Community Management API (a "Vetted Product") — never in the consumer Open Permissions. Community Management approval requires an approved use case, verified organization, verified domain, an app verified by a LinkedIn Page associated with the same organization, and (Standard tier) a privacy policy + screencast review. Dev-tier rate limits: 500 calls/app/24h, 100/member/24h. [learn.microsoft.com/.../increasing-access; .../community-management-app-review]
• The 2025 "LinkedIn opened Member Post Analytics to individuals" headline is true only through approved partner platforms (Metricool/Buffer/Hootsuite-class) that hold the approval — not by a creator calling the API directly. LinkedIn is also tightening: the read scope r_member_social (Member Post Management) is flatly closed — "not accepting access requests at this time due to resource constraints."

Contradictions: "CSV is the only way" (plugin/audit) is wrong at the capability level (an API exists) but right at the practical level for a solo dev (the API is org-vetted). Resolution: state "exists but partner-gated; not self-serve; CSV is the practical floor for a solo creator," not "no API exists."

D2. Per-post saves visibility — Confidence: high

External findings:

• Native UI: the official LinkedIn Help page on post analytics lists, under Social Engagement: Reactions, Comments, Reposts, Saves ("number of times members saved your post"), Sends — rolled out ~Sept 2025. Count only, never saver identity. Rollout was phased and historical backfill limited (older posts may show no saves). [linkedin.com/help/linkedin/answer/a516971; socialmediatoday.com/news/linkedin-adds-save-and-send-data-to-content-insights/759828/]
• API: POST_SAVE exposed via memberCreatorPostAnalytics from li-lms-2026-04 — but behind the same Community-Management gate as D1 (not self-serve).

Resolution (sharpens the Q3 honesty-fix): the honest downgrade is NOT "saves can't be tracked." It is: "saves are visible in your native LinkedIn post analytics (since Sept 2025, count-only) but there is no self-serve API to pull them, so this tool does not auto-ingest them — read them in LinkedIn directly." The operator's decision (no manual-entry feature) stands and is defensible: the number is human-readable but programmatically out of reach + would be hand-typed and instantly stale.

D3. Auto-publish from a personal profile — Confidence: high (capability) / the ToS line is the real boundary

External findings:

• A personal profile CAN auto-publish, self-serve. w_member_social is an Open Permission (no approval), granted by adding the free "Share on LinkedIn" product (filed under .../integrations/self-serve/). POST /v2/ugcPosts (or /rest/posts) with lifecycleState: PUBLISHED publishes immediately, no human-in-the-loop. Rate limit ~150 requests/member/day. Self-serve content types: text, image, video, article/URL share. [learn.microsoft.com/.../share-on-linkedin; .../getting-access]
• Genuine limitations: organic carousels (ad-style) are NOT available via API for a personal profile (sponsored only) — use MultiImage for swipeable images; member document/PDF posts and the modern /rest/posts member path are doc-ambiguous (don't promise without testing). You also cannot self-serve read your own posts back (r_member_social is restricted/closed) — capture the post URN from the publish response header instead.
• Operational friction (real, first-hand): 3-legged OAuth (one interactive auth); 60-day access tokens / ~365-day refresh tokens that invalidate on revoke or scope change (invalid_grant footgun); a common 403 me.GET.NO_VERSION trap (use /userinfo sub, not /v2/me); a placeholder company-page link required at app setup even for personal-only posting; "outdated docs everywhere." [marcusnoble.co.uk/2025-02-02-posting-to-linkedin-via-the-api/; github.com/linkedin-developers/linkedin-api-js-client/issues/35]
• The real boundary is ToS, not capability: w_member_social being "open" does not mean automated/scheduled posting is within LinkedIn's API Terms. The legitimate basis for the plugin's clipboard-stop is (a) per-user OAuth + token-refresh operational overhead and (b) LinkedIn's Terms posture on automated posting — not "the API can't do it."

Resolution: the plugin must not write "cannot auto-publish." Honest framing: "auto-publish to a personal profile is technically possible and self-serve (Share on LinkedIn / w_member_social); the plugin deliberately stops at the clipboard — OAuth + 60-day-token overhead and LinkedIn's Terms on automated posting make human-in-the-loop the safer default. A choice, not a wall." (Verify current Platform/Marketing API Terms language on automated personal posting before finalizing the wording.)

D4. Dwell time exportability — Confidence: medium-high (organic boundary holds, with carve-outs)

External findings:

• For organic personal posts, there is no creator-facing dwell metric — not in the UI Help metric list, not in memberCreatorPostAnalytics. Dwell is an internal ranking signal only. [linkedin.com/help/linkedin/answer/a516971]
• Carve-outs (so the claim isn't falsifiable): (1) video posts expose Watch time / Average watch time (UI + member video API) — a real per-post depth metric, just not for non-video; (2) averageDwellTime exists in the ads adAnalytics API (paid campaigns only, methodology improved ~+25% in a 2026 change).

Resolution: "for organic posts, dwell is internal-only — no creator number; video Watch time is the closest creator-visible depth proxy; a true dwell field exists but only for paid ads." Do not say "LinkedIn has no dwell metric anywhere."

External Knowledge

Best Practice (official / primary)

Microsoft Learn (li-lms-2026-05) is authoritative. The self-serve set for a solo dev is exactly three Open Permissions: profile, email, w_member_social. Everything analytics is Community-Management-vetted. This single fact drives every honest boundary statement.

Known issues

The surface moves fast and docs lag the API (saves went invisible→UI→API in ~12 months; r_member_social went from program to closed). Any boundary statement must be dated. Practitioner reality adds friction (token fragility, the /me 403 trap) that makes "feasible" ≠ "frictionless."

Synthesis

1. The audit's "honest scheduling boundary" finding (§5) was itself half-wrong. It assumed the plugin "stops at the clipboard because it can't auto-publish." The truth: it can (self-serve), and the honest disclosure is about the design + ToS choice, not an impossibility. Phase 1's boundary prose must encode the choice, or it ships a brand-new false claim — exactly the failure mode this whole remediation exists to kill.

2. The saves honesty-fix is a wording fix, not a "we can't" fix. Saves are now visible in the UI. The accurate downgrade points the user to LinkedIn's own analytics for the number while being honest that the tool can't pull it. This keeps the operator's "no manual-entry" decision and avoids a stale "saves aren't trackable" claim.

3. There is a latent, deliberately-deferred capability here. Auto-publish is buildable self-serve. It is explicitly a Non-Goal of this remediation (operator: disclose boundaries, don't engineer them away). Worth a one-line "possible but intentionally not built (ToS + token overhead)" note so a future maintainer doesn't rediscover it as a "missing feature."

Open Questions

• Exact ToS language on automated/scheduled personal posting — the load-bearing reason for the clipboard-stop. Carry as: verify current Platform/Marketing API Terms before finalizing the boundary wording. (Not a blocker for the plan; a finalize-time check.)
• Member document/PDF + /rest/posts member-author path — doc-ambiguous. Irrelevant unless a future version builds publishing; flag, don't resolve.

Recommendation

For Phase 1 (honest boundaries) and Phase 2 (saves honesty-fix), write these dated statements:

1. Analytics API: "A post-level analytics API for personal posts exists, but it's behind LinkedIn's vetted Community Management API (verified organization + LinkedIn Page + use-case review) — not self-serve for an individual. For a solo creator, CSV export is the practical path. (As of 2026-05.)"
2. Saves: "Saves are visible in your native LinkedIn post analytics (since ~Sept 2025, count-only). There's no self-serve API to pull them, so this tool doesn't track saves automatically — read them in LinkedIn directly." Remove any "saves (10x weight) are the highest-impact signal" claim presented inside a report the tool populates; reframe as strategy guidance pointing to the native number.
3. Auto-publish: "Auto-publishing to a personal profile is technically possible (self-serve w_member_social); this tool deliberately stops at the clipboard — OAuth + token-refresh overhead and LinkedIn's Terms on automated posting. A choice, not a limitation. (As of 2026-05.)" Reconcile the calendar/queue/"publish action" wording so it never implies the tool auto-posts.
4. Dwell: "Dwell time is an internal ranking signal — no creator-facing number for organic posts (video Watch time is the closest proxy)."

Sources

#	Source	Type	Quality	Used in
1	Member Post Statistics API (li-lms-2026-05)	official	high	D1, D2
2	Increasing Access — permissions table	official	high	D1
3	Community Management App Review	official	high	D1
4	Community Management Overview / FAQ (r_member_social closed)	official	high	D1
5	Share on LinkedIn (self-serve)	official	high	D3
6	Getting Access — Open Permissions	official	high	D3
7	Post analytics for your content — LinkedIn Help (Saves listed)	official	high	D2, D4
8	Social Media Today — LinkedIn adds Save/Send data (Sept 2025)	community	medium-high	D2
9	Refresh Tokens with OAuth 2.0	official	high	D3
10	Marcus Noble — Posting to LinkedIn via the API (first-hand)	community	medium-high	D3
11	GitHub — linkedin-api-js-client #35 (403 /me trap)	community	medium	D3
12	Recent Marketing API Changes (ads averageDwellTime)	official	high	D4
13	ConnectSafely — LinkedIn API guide 2026 (approval reality)	community	low-medium	D1