How to Study the Public Roles of LinkedIn Comment Authors

Keep comments and accounts apart

One saved row is one available top-level comment. It is not one person. It is not one reaction. It is not one full profile. It is not a full thread.

These are the row fields:

• `commentId`
• `commentUrl`
• `postUrl`
• `postUrn`
• `authorType`
• `authorUrl`
• `authorId`
• `authorUrn`
• `authorPublicIdentifier`
• `authorName`
• `authorHeadline`
• `authorLocation`
• `authorCurrentOrganizations`
• `text`
• `observedAt`

`authorUrn` and `postUrn` are URN values. A URN is a typed text identifier from the public source. An `authorId` is also a public source identifier. These identifiers are public. They are not secret keys.

`authorType` has three checked values: `person`, `organization`, or `null`. `null` means the type was not given. Do not read `null` as person.

`observedAt` is the time you observed the row. It is not the time the post was published. Write both times in your notes if you have both. Do not swap them.

`authorCurrentOrganizations` can hold more than one public entry. Keep every entry. Do not invent one employer. If the field is null or empty, organization evidence is unknown. Unknown is not zero. Unknown does not mean unemployed. Unknown does not mean no company.

Author details can be missing. A request can return a row with an empty headline or empty organizations. Leave those cells unknown. Do not fill them from the comment text.

Use one comment table only. You do not need a second dataset to code roles.

Set a small run

1. Choose known public posts. Write the study question before you collect. State the collection time. State a cap for each post. Mark promotion comments, post-author comments, and organization accounts when those rows would change the study. A promotion comment mainly promotes a product or service. Keep the marked rows. Do not delete them. If you leave a post-author account out of the share, say that and change the total.
2. Collect a small sample with author details turned on. The saved task checked on October 13, 2026 is LinkedIn Comment Authors with Public Profile Details. Its saved input is:

{"startUrls": ["https://www.linkedin.com/posts/timferriss_how-to-become-dramatically-more-productive-activity-7386884213343428608-wrF3"], "maxComments": 100, "collectAllAvailable": false, "includeAuthorDetails": true}

Replace that sample post with the public post you mean to study. For the first run, set `maxComments` to 3. Keep `collectAllAvailable` false. False keeps the number cap active. Keep `includeAuthorDetails` true.

Author details are a separate request from the comment row. A successful extra detail can cause a separate billing event. A billing event is a charge record. Not every request causes a charge. The detail fields can still come back empty. This article states no price.

1. Save the comment rows and the run OUTPUT. Read OUTPUT for each post before you code any role.

Run-level OUTPUT includes `savedRows`, `authorProfileRequests`, `authorDetailEvents`, and `rowsWithAuthorDetails`. Read them to see how many rows and detail requests were recorded. `rowsWithAuthorDetails` can be lower than the comment count when details are missing. Do not use these counts as the role total. Do not read them as a bill.

Each post has an `inputResults` entry. Read these fields there:

• `status`
• `statusReason`
• `pageCommentCount`
• `publicRowsOnPage`
• `savedRows`
• `isPublicPageComplete`
• `isComplete`
• `stopReason`

Use the `stopReason` inside that post's `inputResults`. A `stopReason` at the root of OUTPUT is not the cap state for the post.

`isPublicPageComplete` true means the exposed public page was extracted. It does not mean the full discussion was saved. `isComplete` false means the saved collection is incomplete. A cap, a public preview restriction, a source restriction, or a charge limit can cause this result. Read the status, the reason, and the stopReason for each input. A successful run status does not make the table complete. `pageCommentCount` and `publicRowsOnPage` are page counts. These page counts are not counts of observed person accounts.

On October 13, 2026, a bounded check saved 3 comments from 1 post. It made 3 author-detail requests. The cap stopped the run while the exposed page count was 4. For that post, `isPublicPageComplete` was true, `isComplete` was false, and `stopReason` was `max_comments_reached`. The 3 saved rows were not the whole discussion. They only show that public author details can be returned. They are not a role report. Do not use them as the worked example.

Build the two tables

Keep a comment table. Give each row its own `commentId`.

If `commentId` is missing, keep that row as its own source observation. Give it a label you make, such as `missing-comment-1`. Never merge two blank comment ids. Never merge two rows because the comment text matches. Equal text is not the same comment.

Build a person-account table only after you confirm the type.

1. Read `authorType`.
2. Group an id only when `authorType` is `person`.
3. Prefer `authorUrn` or `authorId` as the safe key.
4. If those ids are absent, a checked public profile URL may be a provisional label. Say that the URL label is weaker than a stable id. A URL label is not unresolved.
5. Unresolved means there is no safe key. No `authorUrn`, no `authorId`, and no checked profile URL. Do not call a row unresolved only because the stable id is missing when a checked URL exists.
6. Never merge rows by `authorName`.
7. Never merge blank ids with each other.

`organization` accounts stay in a separate group. Keep their ids apart from person ids. They do not enter the person-account total. State their count beside it.

If `authorType` is `null`, do not treat the row as a person account. If that row also has no safe person key, it stays unresolved. Do not assign it to a nearby name.

Unknown role and unresolved identity are different. Unknown role means you found the person account, but the headline does not state a role. That account stays in the person-account total. Unresolved identity stays out.

Code the headline you can see

Write a codebook before you count. A codebook is a short list of categories and the headline evidence each one needs.

Use this rule.

• `operations`: the headline states operations work.
• `technical`: the headline states software or engineering work.
• `marketing`: the headline states marketing work.
• `mixed`: the headline states more than one of those functions, and the rule cannot pick one.
• `unknown`: the headline is missing, or it states no function. A slogan is unknown.

Save the exact headline text next to the category. Use the whole stated function. Do not infer a job from a slogan. Do not infer a role from the comment mood. The comment text is not role evidence.

Use one primary category for each person-account identity. Shares then add once. You may keep extra tags in a second field. Do not add those tags as more accounts.

Keep both dated headline snapshots when the same account has conflicting texts. Keep the exact evidence text for each snapshot. Do not pick the title that makes a cleaner chart. Use one declared selected-observation rule for the report. If you cannot use that rule, the primary role remains `unknown`. Use `conflict pending review` only for a separate reader review state. Do not code roles from different times as `mixed`. Code `mixed` only when the selected headline states multiple roles and the codebook cannot pick one role. Code `unknown` when the selected headline does not show one clear function.

A role category is your label for a stated function. It is not a checked credential.

Count once, then divide

Count repeated comments in an activity table. Count each observed person-account identity once in the role table.

A denominator is the total you divide by. A numerator is the count you divide. A share is the numerator divided by the stated denominator.

For the role report, the denominator is the number of observed person-account identities. Organization rows are outside it. Unresolved rows are outside it. Unknown-role accounts stay inside it.

Known role coverage uses a second report, not a new audience. Its numerator is the person-account identities whose primary role is not `unknown`. Its denominator is all observed person-account identities. `mixed` is not `unknown`.

You may also show shares inside the known-role group only. That view has a smaller denominator. Write that denominator on the table. Keep the unknown count beside it. Do not compare those shares with the shares from the larger denominator. The accounts did not change. The total changed.

Ask a second reader to code a few headlines with the same codebook. Review the rows you code differently. This checks consistency. It does not prove the job is real.

Fictional worked example

The posts, labels, names, headlines, and counts in this section are fictional. They are not the October 13, 2026 check. They are not real people.

An invented post yields 8 comment rows. The fictional `commentId` values are `c1` through `c8`. None of these 8 rows has a blank `commentId`. Person ids for the person rows are checked. `c8` has no safe key.

Person-account table:

`org1` has `authorType` `organization` and 1 comment. It stays outside the person-account table. `c8` has `authorType` `null` and no safe key. It is 1 unresolved comment. Never assign `c8` to `p4`.

The 8 comments contain 4 observed person-account identities, 1 organization author, and 1 unresolved author row. Do not say there were exactly 6 people. The unresolved row may repeat a person account. `org1` is an organization.

Role shares use 4 observed person-account identities as the denominator.

The operations share is 1 divided by 4. That is 25%. The same math gives 25% for technical, marketing, and unknown. These four shares use one denominator, so they add to 100%.

Known role coverage uses 3 as the numerator and 4 as the denominator. 3 divided by 4 is 75%. The unknown account stays visible as 1 of the 4.

A second view uses only the 3 known-role accounts. Each known group is 1 divided by 3, which is about 33.3%. Keep the unknown count beside this view. That unknown account is 1, and it is outside this denominator.

Do not compare 33.3% with 25%. Those figures use different denominators. They are not a change in the audience.

Comment activity is a different total. It sums to 8.

`p1` and `p2` each wrote 2 comments. A role report that uses all 8 comment rows would count those two accounts twice. Use the activity table for volume. Use the 4 person-account identities for composition.

Fictional coverage note: the cap is 8. The observed source-page count is 12. In `inputResults`, `stopReason` is `max_comments_reached` and `isComplete` is false. This fictional note does not assign `status` or `statusReason`.

Decision: keep the 4-account role table as an observed sample. Collect more only if the study needs more coverage. Never call this sample all 12 participants. Do not read 12 as 12 person-account identities.

Fictional finding: in this capped sample, each primary role is 25% of 4 observed person-account identities. Known role coverage is 75%. The finding is only about that sample. It does not describe all customers. It does not show who can buy.

What you hand off

Hand off these items.

• The person-account table, with one primary role each.
• The codebook and the exact headline text used as evidence.
• The organization count, outside the person-account denominator.
• The unresolved identity count, with reader-made labels for any missing `commentId`.
• A coverage note for each post from `inputResults`.
• One narrow finding that names the denominator and the cap.

Say the collection time. Do not replace it with the post's publication time. If a headline or organization list was empty, show unknown. Do not turn unknown into zero.

If `isComplete` is false, say the table is not the whole discussion. If two headline snapshots disagree, show both. Do not hide the one you did not code.