docs(linkedin-studio): Voyage remediation setup — brief + research + plan (Phase 0-3)
Audit-remediation Voyage project authored end-to-end this session: - brief.md (reviewer PROCEED; validator pass) — full Phase 0-3 scope, phased, with success criteria refined by research - research/01-03 — high-effort external swarm + Gemini (Topic 1); reconciled the external bar and corrected several audit feature-premises (no publishable model name/date; saves UI-visible not API-pullable; auto-publish possible-not-built; 9:16 not mandatory; newsletter notifications deduplicated not triple; CLI crash = missing npm install, depth-bug latent) - plan.md (21 steps, 7 sessions, 5 waves; validator pass; A- 88/100) — plan-critic REVISE (3 blockers + majors) addressed; scope-guardian ALIGNED; gemini Pass-2 folded in 2 blind spots (git-history decision; lint stat-grep sequencing) Execution is future sessions (one wave each) via /trekexecute, /trekreview as the release gate. Audit report stays local until the article ships. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
parent
90fcc1069d
commit
a61b818578
6 changed files with 2082 additions and 0 deletions
|
|
@ -0,0 +1,218 @@
|
|||
---
|
||||
type: trekresearch-brief
|
||||
created: 2026-05-29
|
||||
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?"
|
||||
confidence: 0.86
|
||||
dimensions: 4
|
||||
mcp_servers_used: [tavily]
|
||||
local_agents_used: []
|
||||
external_agents_used: [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)](https://learn.microsoft.com/en-us/linkedin/marketing/community-management/members/post-statistics?view=li-lms-2026-05) | official | high | D1, D2 |
|
||||
| 2 | [Increasing Access — permissions table](https://learn.microsoft.com/en-us/linkedin/marketing/increasing-access?view=li-lms-2026-05) | official | high | D1 |
|
||||
| 3 | [Community Management App Review](https://learn.microsoft.com/en-us/linkedin/marketing/community-management-app-review?view=li-lms-2026-05) | official | high | D1 |
|
||||
| 4 | [Community Management Overview / FAQ (r_member_social closed)](https://learn.microsoft.com/en-us/linkedin/marketing/community-management/community-management-overview?view=li-lms-2026-05) | official | high | D1 |
|
||||
| 5 | [Share on LinkedIn (self-serve)](https://learn.microsoft.com/en-us/linkedin/consumer/integrations/self-serve/share-on-linkedin) | official | high | D3 |
|
||||
| 6 | [Getting Access — Open Permissions](https://learn.microsoft.com/en-us/linkedin/shared/authentication/getting-access) | official | high | D3 |
|
||||
| 7 | [Post analytics for your content — LinkedIn Help (Saves listed)](https://www.linkedin.com/help/linkedin/answer/a516971) | official | high | D2, D4 |
|
||||
| 8 | [Social Media Today — LinkedIn adds Save/Send data (Sept 2025)](https://www.socialmediatoday.com/news/linkedin-adds-save-and-send-data-to-content-insights/759828/) | community | medium-high | D2 |
|
||||
| 9 | [Refresh Tokens with OAuth 2.0](https://learn.microsoft.com/en-us/linkedin/shared/authentication/programmatic-refresh-tokens) | official | high | D3 |
|
||||
| 10 | [Marcus Noble — Posting to LinkedIn via the API (first-hand)](https://marcusnoble.co.uk/2025-02-02-posting-to-linkedin-via-the-api/) | community | medium-high | D3 |
|
||||
| 11 | [GitHub — linkedin-api-js-client #35 (403 /me trap)](https://github.com/linkedin-developers/linkedin-api-js-client/issues/35) | community | medium | D3 |
|
||||
| 12 | [Recent Marketing API Changes (ads averageDwellTime)](https://learn.microsoft.com/en-us/linkedin/marketing/integrations/recent-changes?view=li-lms-2026-01) | official | high | D4 |
|
||||
| 13 | [ConnectSafely — LinkedIn API guide 2026 (approval reality)](https://connectsafely.ai/articles/linkedin-api-complete-guide-2026) | community | low-medium | D1 |
|
||||
Loading…
Add table
Add a link
Reference in a new issue