Post Comments Engagements Scraper Linkedin With Repeat Engagers
Pricing
from $5.99 / 1,000 results
Post Comments Engagements Scraper Linkedin With Repeat Engagers
LinkedIn Post Comments & Engagements Scraper extracts comments, reactions, engagement metrics, authors, and repeat engagers from posts. Ideal for identifying active audiences, tracking engagement, analyzing content performance, finding prospects, and building targeted B2B leads.
Pricing
from $5.99 / 1,000 results
Rating
0.0
(0)
Developer
Scrapier
Maintained by CommunityActor stats
0
Bookmarked
2
Total users
0
Monthly active users
4 days ago
Last modified
Categories
Share
LinkedIn Post Comments Scraper — Repeat Engagers and Audience Tiers
LinkedIn Post Comments Scraper reads public post comments logged out — no cookie required — then rolls every comment into a per-person, cross-post frequency record: how many scraped posts a commenter engaged with, when they first and last showed up, and whether they're first-time, returning, or a superfan. Point it at several posts from one creator and the output shows who keeps coming back, not just who spoke once. Every response is structured JSON, ready for an LLM, a vector store, or a monitoring pipeline.
What is LinkedIn Post Comments Scraper With Repeat Engagers?
It's an Apify Actor that scrapes comments from a set of LinkedIn posts and, instead of stopping at a comment list, aggregates the result into one record per commenter across the whole set. That's the capability the three other LinkedIn comment scrapers checked for this README don't have — none of them aggregate across multiple posts to score who is a repeat commenter. This Actor runs logged out by default, reading LinkedIn's own public post page, which any anonymous visitor can already see — no LinkedIn account or login is required for the default path.
- Reads real comments from LinkedIn's public post page while logged out, no cookie needed
- Aggregates every comment into a per-person, cross-post frequency record:
postsEngagedCount,repeatEngagerTier,firstSeenAt/lastSeenAt,totalReactionsReceived - Tiers commenters as first-time, returning, or superfan based on
superfanMinPosts, and withholds a tier belowminPostSampleForTierrather than guessing - Filters the output down to repeat engagers only with
minPostsEngaged, and never charges for the comments it removes - Optionally accepts a
liAtcookie to switch to LinkedIn's authenticated engine for deeper comment pages, nested replies, and per-type reaction breakdowns - Optionally persists engagement counts in a cross-run ledger (
enableEngagerLedger) so a scheduled run builds a growing audience record over time
What data can you get with this LinkedIn comments scraper?
Every run can write up to three kinds of dataset rows: charged comment rows, an uncharged per-person rollup, and uncharged accounting rows that explain anything that didn't become a comment row.
| Result Type | Extracted Fields | Primary Use Case |
|---|---|---|
| Comment (charged) | comment_id, text, posted_at, is_edited, is_pinned, comment_url, author, stats, replies, post_input, postUrl, totalComments, commentCreatedAt, sourceEngine, commentsAvailable, commentsTotal, scrapedAt, type, isChild, authorProfileSlug, identityResolved, postsEngagedCount, authorCommentsInRun, postSampleSize, repeatEngagerTier, isError, errorReason, errorMessage | Reading what was said and by whom, with each comment already carrying that commenter's run-wide frequency |
| Person rollup (engager, uncharged) | authorProfileSlug, authorName, authorProfileUrl, avatarUrl, postsEngagedCount, commentsCount, postSampleSize, engagementRatePct, repeatEngagerTier, firstSeenAt, lastSeenAt, totalReactionsReceived, reactionCountsObserved, avgCommentLength, engagedPostUrls, runId, scrapedAt, plus 8 ledger* fields | Ranking a creator's audience by loyalty — who to prioritize for outreach or community follow-up |
| Accounting row (uncharged) | type (post_accounting / filter_accounting / coverage_accounting), postUrl, post_input, isError, errorReason, errorMessage, plus null placeholders for the comment fields | Auditing why the row count doesn't match the input count — a throttled post, a filtered comment, or an unresolved identity, never a silent gap |
Repeat-engager frequency scoring
This is the capability the section above is really about. Every comment row carries postsEngagedCount — how many of the posts in this run that specific person commented on — and repeatEngagerTier, one of first-time, returning, superfan, or insufficient-sample. Identity is the person's normalized profile slug: https://uk.linkedin.com/in/jane-doe?trk=... and https://www.linkedin.com/in/jane-doe/ both resolve to the same jane-doe, so one human doesn't split into two "people" and inflate the count. A comment with no author profile link has no identity — it's counted (comments_without_identity) and reported, never merged into someone else's total. The signal scales with sample size: as documented in the Actor's own input schema, on real data the repeat rate was 32% across a 13-post corpus from one creator, and 1-in-28 across a 3-post corpus — which is why postSampleSize sits beside every frequency figure and no tier is assigned at all below minPostSampleForTier.
Per-person engager rollup
When includeCommenterRollup is on (the default), the Actor writes a second, uncharged dataset — engagers-<runId> — with one row per person instead of one row per comment. It's the ranked audience list: postsEngagedCount and commentsCount first, then firstSeenAt/lastSeenAt, totalReactionsReceived, avgCommentLength, and the full engagedPostUrls list so you can see exactly which posts drove the count. Rows are sorted by postsEngagedCount descending, so the most frequent engagers are always first.
Why not build a LinkedIn comment scraper yourself?
LinkedIn's developer platform does not offer open, self-serve access to post comment data — the available APIs are scoped to specific partner use cases and require approval, not a general query-and-fetch comment endpoint. That leaves scraping the public page as the practical option, and the maintenance load is the real cost of doing it yourself.
The public post page serves comments through two surfaces that have to agree: a <script type="application/ld+json"> block (LinkedIn publishes it under more than one @type — SocialMediaPosting, DiscussionForumPosting, Article, and VideoObject all show up in practice) and the server-rendered comment DOM. A guest wall returns HTTP 200 with a login page rather than an error status, so detecting a block means checking for the actual comment container, not the status code. Getting past that reliably means browser-accurate TLS impersonation, a proxy ladder that escalates from direct to datacenter to residential only when needed, and IP rotation on LinkedIn's HTTP 999 throttle response.
The second cost is specific to this Actor's purpose: turning a comment list into an audience-frequency record requires buffering the entire run before writing anything, because you can't know someone is a repeat engager until every post has been read. This Actor already does both — the scraping and the aggregation — so a working Voyager-cookie escalation path (for deeper comment pages) and repeat-engager scoring don't have to be built and maintained separately.
What's the difference between comment scraping and repeat-engager tracking?
Comment scraping returns a list of what was said on one post. Repeat-engager tracking answers a different question: across several posts from the same creator, who keeps showing up? A single post can only ever say someone commented "once" — you need a set of posts to see a pattern at all.
That distinction matters because a comment list per post, however complete, can't tell a community manager or creator who their most loyal commenters are — it takes reading multiple posts and matching the same person across them, which is exactly what the three competing LinkedIn comment scrapers reviewed for this README (checked 2026-07-26) don't do. Their output is one comment or one post at a time; none of them return a cross-post frequency figure.
This Actor returns both. Comment-level detail arrives as comment rows in the default dataset — text, author, reactions, replies. The audience-frequency answer arrives two ways: as postsEngagedCount / repeatEngagerTier attached to every comment row, and as a dedicated, ranked one-row-per-person object in the engagers-<runId> child dataset.
How to scrape LinkedIn post comments with this Actor?
- Open the Actor's listing on the Apify Store and click Try for free (or open it directly from your Apify Console if you already have access)
- Paste one or more LinkedIn post URLs, activity/ugcPost URNs, or bare numeric activity IDs into postUrls — the only input that changes the result; everything else has a working default
- Set the controls that matter for your case: commentsPerPost to bound comments read per post, minPostsEngaged / superfanMinPosts / minPostSampleForTier to tune the frequency scoring, commentOrder if you're supplying a cookie
- Click Start
- Download or stream results as JSON, CSV, or Excel from the default dataset — or open the child dataset
engagers-<runId>for the ranked one-row-per-person list
How to run multiple posts in one job
postUrls is a list — one URL, URN, or numeric ID per line. Frequency is only meaningful across a set of posts from the same creator: two posts can only ever say "once or twice," and the Actor's own schema description puts the useful threshold at 10+ posts, which is where repeat engagers become visible. Posts are processed in sequence with a short randomized 1–2 second delay between them; there is no documented concurrency setting for posts in this Actor.
⬇️ Input
Required per schema: none — every parameter below has a working default.
| Parameter | Required | Type | Description | Example Value |
|---|---|---|---|---|
postUrls | No | array | LinkedIn post URLs, activity/ugcPost URNs, or bare numeric activity IDs, one per line. The original base actor's startUrls key is still accepted. | ["https://www.linkedin.com/feed/update/urn:li:activity:7483582759836336130/"] |
commentsPerPost | No | integer | Upper bound on comments read per post. Min 1, max 500, default 100. Logged out, LinkedIn itself serves roughly the first 9–10 top-level comments per post, so this mostly bites on the cookie path. | 100 |
minPostsEngaged | No | integer | Only return commenters seen on at least N posts. Min 1, max 100, default 1 (keep everyone). 2+ returns only repeat engagers; filtered-out comments are not charged. | 2 |
superfanMinPosts | No | integer | Posts-engaged threshold to tier someone a superfan. Min 2, max 100, default 3. | 3 |
minPostSampleForTier | No | integer | Minimum successfully scraped posts before any tier is assigned. Below it, repeatEngagerTier reads insufficient-sample and engagementRatePct is null. Min 1, max 100, default 3. | 3 |
includeCommenterRollup | No | boolean | Writes the per-person rollup to the uncharged child dataset engagers-<runId>. Default true. | true |
enableEngagerLedger | No | boolean | Persists engagement counts in a named key-value store across runs. Accumulates only — never suppresses a previously-seen commenter. Default false. | false |
ledgerKey | No | string | Which persistent ledger this run writes into. Use one key per creator/company page. Ignored when the ledger is off. Default "default". | "microsoft" |
commentOrder | No | string | Order requested from LinkedIn on the cookie path: REVERSE_CHRONOLOGICAL (default, newest first) or RELEVANCE (most relevant). Logged out, LinkedIn serves its own fixed guest order and ignores this. The original base's sortOrder key is still accepted. | "REVERSE_CHRONOLOGICAL" |
liAt | No | string (secret) | Optional LinkedIn li_at session cookie. Leave empty to run logged out (the default, verified path). Supplying it switches to LinkedIn's authenticated engine for deeper comment pages, nested replies, and per-type reaction breakdowns. No cookie ships with the Actor; stored encrypted, used only for requests that need it. | (leave empty) |
proxyConfiguration | No | object | Apify Proxy settings. By default requests go direct and escalate to Apify datacenter, then residential, only if LinkedIn blocks or throttles (HTTP 999). Default {"useApifyProxy": false}. | {"useApifyProxy": false} |
liAt is flagged isSecret in the input schema — the Apify Console masks it and the value is encrypted at rest, the same way it treats any password field.
Example JSON input
Common pitfall: postsEngagedCount and repeatEngagerTier are properties of the run, not of any single post — they're computed after every post has been read. Running the Actor once per post, one post at a time, will never show a repeat engager, because each run's postSampleSize will be 1. Put multiple URLs from the same creator into a single postUrls list instead.
⬆️ Output
Every response is typed JSON with a consistent schema across runs. Export the default dataset as JSON, CSV, or Excel, or read it through the Apify API. Rows are pushed live as each post finishes.
Scraped results
A run against three posts, filtered with minPostsEngaged: 2, producing charged comment rows and an uncharged accounting row:
totalComments and commentsTotal carry the same value in every row — totalComments is the original base actor's field name kept for compatibility, commentsTotal is this Actor's own coverage-pair field alongside commentsAvailable.
The matching engager rollup row for the same run, from the engagers-<runId> child dataset:
The eight ledger* fields are only populated when enableEngagerLedger was on for that run; otherwise they're all null, as shown above.
How can I use LinkedIn comment and engager data?
- Community and social media managers pull the
engagers-<runId>dataset, sort bypostsEngagedCount, and get a ranked shortlist of the commenters worth a direct reply or a DM — the people already showing up repeatedly, not a guess. - AI engineers and LLM developers feed comment rows straight into an agent as grounded context: the agent issues a run, receives typed JSON back, and reasons over real
textandrepeatEngagerTierfields instead of a summary it has to trust blind. - Marketing and growth teams use
enableEngagerLedgeragainst a weekly content schedule to watch a specific creator's or company page's audience compound over time, usingledgerRunsSeenCountto see who has been present across multiple campaigns. - Sales and partnerships teams scanning a prospect's or partner's recent post history use
superfanMinPoststiering to separate genuine repeat supporters from one-off commenters before prioritizing outreach.
📚 How do you monitor repeat engagers over time?
Turn a single scrape into a standing audience record by running this Actor on a schedule against the same ledgerKey. Set enableEngagerLedger to true and pick one ledgerKey per creator or company page you track (for example "microsoft"), so different audiences never blend together in the same ledger.
Each run merges its observations into the persisted key-value store record (named linkedin-repeat-engagers-ledger, key ENGAGERS_<ledgerKey>): runsSeen increments, postsEngagedCount and commentsCount accumulate, and firstSeenAt/lastSeenAt widen to cover the full history. The ledger is deliberately additive — it never suppresses or hides a commenter for having been seen before, so a person seen last week comes back this week with a higher count, not a missing row. Per person, the ledger keeps up to 400 distinct post URLs; per ledger key, up to 5,000 distinct posts total, so a long-running weekly schedule can't grow one record without bound.
Diff ledgerPostsEngagedCount and ledgerRunsSeenCount between exports to see who crossed from "returning" into "superfan" territory over the tracking period, and use ledgerFirstSeenAt to know how long someone has been in the audience. To automate this, create an Apify schedule on this Actor with the same postUrls and ledgerKey on every run — a weekly cron trigger is enough to build a multi-month audience-loyalty record without any code of your own.
Integrate this scraper and automate your workflow
LinkedIn Post Comments Scraper works with any language or tool that can send an HTTP request, because it runs as a standard Apify Actor.
REST API with Python
The ranked per-person list lives in the separate engagers-<runId> dataset created by the same run — look it up by name through client.datasets().list() or find it in the Apify Console's Storage tab for that run.
Scheduled monitoring and delivery
Create an Apify schedule on this Actor to re-run it on a cron interval against the same postUrls and ledgerKey, which is what makes the cross-run ledger meaningful. Apify's run-finished webhooks can trigger a downstream step (a Slack notification, an HTTP callback, another Actor) each time a scheduled run completes, without polling.
Is it legal to scrape LinkedIn comments?
Scraping publicly accessible data is broadly permitted, and this Actor's default path returns only what any anonymous visitor already sees on a public LinkedIn post page — no login, no private content, no data from behind a connection wall.
The output does include personal data — commenter names, profile URLs, and profile pictures — so data-protection regimes like GDPR and CCPA apply to how you store, process, and retain it, separately from whether the scraping itself was permitted. LinkedIn's Terms of Service also govern automated access to the platform. Scraping for operational monitoring (tracking your own or a client's audience) carries a different risk profile than scraping for AI training data at scale — treat the two differently.
Consult your legal team for commercial use cases involving bulk data storage, especially if you plan to retain commenter identities beyond a single run.
❓ Frequently asked questions
Does this Actor require a LinkedIn account or cookie?
No. The default path runs logged out against LinkedIn's public post page. Supplying your own liAt cookie is optional — it switches to LinkedIn's authenticated Voyager engine for deeper comment pages, nested replies, per-type reaction breakdowns, and edited/pinned markers, which raises how many posts a person can realistically be seen on. No cookie ships with the Actor.
How many comments does it actually read per post?
Logged out, LinkedIn itself caps a guest visitor at roughly the first 9–10 top-level comments per post — commentsPerPost (up to 500) mostly only matters on the cookie path. Every row reports commentsAvailable against commentsTotal so the real coverage on that specific post is always visible, never hidden behind a flat count.
How does the Actor handle LinkedIn's anti-bot measures?
Requests use browser-accurate TLS impersonation and go direct by default, escalating to an Apify datacenter proxy and then residential only if LinkedIn blocks or throttles a request (HTTP 999, LinkedIn's own rate-limit status). A throttled post is retried on a freshly rotated IP and, if it still fails, is labelled with errorReason: "http_999" rather than silently returned as empty. A guest wall — which LinkedIn serves with a normal HTTP 200 status — is detected by checking for the actual comment container in the response, never by status code alone.
Does this Actor detect repeat engagers across posts, and how does it match the same person?
Yes. Identity is the commenter's normalized LinkedIn profile slug: country subdomains (uk., au., fr.) and ?trk= tracking parameters are stripped before comparison, so https://uk.linkedin.com/in/jane-doe?trk=abc and https://www.linkedin.com/in/jane-doe/ resolve to the same person. postsEngagedCount is the number of distinct posts that slug commented on in the run; repeatEngagerTier buckets that count against superfanMinPosts and minPostSampleForTier. A comment with no author profile link has no identity — it's counted separately and never merged into someone else's total.
How many posts and comments can I scrape in one run?
commentsPerPost accepts 1–500 (default 100), enforced in code as well as in the schema. minPostsEngaged, superfanMinPosts, and minPostSampleForTier each accept up to 100. There's no declared maximum on how many postUrls you can submit.
How do I use this to monitor a creator's repeat engagers over time?
Turn on enableEngagerLedger, pick one ledgerKey per creator or page, and put this Actor on an Apify schedule with the same postUrls and ledgerKey on every run. Each run accumulates into the persisted ledger rather than replacing it — compare ledgerPostsEngagedCount and ledgerRunsSeenCount between exports to see who's becoming a superfan.
Does this work with Claude, ChatGPT, and AI agent frameworks?
Yes, as a standard HTTP-triggered Actor callable through the Apify API. Any agent framework that can make an HTTP request — LangChain, CrewAI, a hand-written tool definition — can trigger a run and receive typed JSON back, which lets an agent ground its answer in comments it just fetched rather than a stale summary.
Can I use this without managing proxies or LinkedIn credentials?
Yes. The proxy escalation ladder — direct, then Apify datacenter, then Apify residential — runs automatically; you never create a proxy account or rotate an IP yourself. The one credential you need is your Apify token. Supplying a liAt cookie is entirely optional.
How does this compare to other LinkedIn comment scrapers?
Checked on the Apify Store on 2026-07-26: apimaestro/linkedin-post-comments-replies-engagements-scraper-no-cookies documents batch comment and reply scraping with sorting options and per-post pagination, but its README does not document any aggregation across posts. scraping_solutions/linkedin-profile-company-posts-scraper-engagers-comments documents posts, reactions, reposts, and comments from profiles or company pages, again per post or per target, with no cross-post frequency figure. api-empire/post-comments-engagements-scraper-linkedin documents bulk comment scraping (up to 500 posts) with the same base comment shape used here, but returns one dataset item per post rather than a per-comment or per-person record. None of the three document a repeat-engager or audience-frequency capability.
What happens to a post that gets throttled or blocked?
It's never silently dropped. A throttled post is retried on rotated IPs and, if LinkedIn still returns HTTP 999 after retries, the Actor writes an uncharged post_accounting row with errorReason: "http_999" so the gap is visible and auditable rather than looking like an empty post.
💬 Your feedback
Found a bug or missing a field? Let us know through the Actor's Issues tab on Apify — reports that include the exact input JSON and the post URL involved are the fastest to reproduce and fix.
