DEV Community: Mentat Logic

Reading a comment section like an analyst: coordination signals without calling anyone a bot

Mentat Logic — Mon, 20 Jul 2026 17:15:25 +0000

Advertisers ask it after every campaign: "did my budget buy real engagement?" PR teams ask it during every pile-on: "is this organic?" Here is how to read a comment export like an analyst — the signals that mean something, the ones that don't, and the honest limit nobody selling "bot scores" will tell you about.

First, retire the word "bot"

Three different things hide behind it, and they leak differently:

Tier 1 — automated accounts. Scripts. They leak automation: machine-even posting intervals, generated-name patterns (Firstname Lastname8123 cohorts), impossible hours held for weeks.

Tier 2 — cheap operated fakes. Real humans, fake accounts, paid per comment. This is the tier that actually floods commercial and political campaigns — and it defeats every automation signal, because the typing is human. What it cannot hide is coordination: the campaign brief synchronizes them. They arrive in bursts, they paraphrase the same talking point, they repeat themselves across posts, they reply to each other to lift the thread.

Tier 3 — professionally managed personas. Full histories, varied interests, natural language. Here is the honest limit: in engagement data alone, these are indistinguishable from real people by design. Anyone selling certainty about this tier is selling vibes.

The signals worth trusting (each with its evidence)

Timing bursts — many distinct accounts commenting on one post inside a tight window. Evidence: the timestamp cluster. One burst is an influencer share; recurring bursts with overlapping membership are a pattern.
Duplicate and near-duplicate text — identical or lightly-edited comments across accounts. Copy-paste with cosmetic edits clusters beautifully.
Talking-point convergence — distinct accounts using the same rare phrase inside a window. Softer than duplication, still leaky.
Cross-post repetition — one account, one text, many posts.
Machine-regular cadence — posting intervals too even for a human (needs several comments per account to mean anything).
Burst-only participation — accounts that exist in your data only inside bursts.
Mutual reply-chains — pairs boosting each other's comments to lift thread ranking.

The two disciplines that keep the analysis honest

Insufficient data is an answer. An account with one comment cannot be judged — not "probably fine," not "suspicious." Insufficient signal. Most accounts in most datasets land here, and saying so is what makes the rest of the analysis credible.

Signals describe behaviour, never persons. "This account's comments sit inside two bursts and a duplicate cluster" is evidence. "This account is a bot" is a guess wearing a costume — and a legal exposure if you put it in a client deliverable. Report patterns with evidence attached; let humans decide what to do about them.

The procedure


1. Deduplicate comments first (same comment arrives twice via URL variants).

2. Group by account; count; below threshold -> INSUFFICIENT SIGNAL, stop.

3. Detect bursts per post (window + distinct-account minimum).

4. Cluster normalized text (exact, then near-duplicate, then rare-phrase).

5. Check cadence regularity, cross-post repeats, reply-chain pairs.

6. Levels from accumulated evidence: NO SIGNALS / WEAK / MULTIPLE / STRONG.

7. Print into the deliverable: the coverage block, the evidence per flag,

   and what the method CANNOT detect (Tier 3). The limits are the credibility.

Disclosure: I build a tool that runs exactly this — the Engagement Authenticity Audit processes any Facebook comments export ($0.66 per 1,000 unique comments, deduplicated first; free demo with a planted burst you can watch it catch — and a single-comment account you can watch it refuse to judge). Its siblings: the free Page Identity Resolver and Page Compare. The procedure above works without any of them — that's rather the point.

How to compare Facebook pages without fooling yourself

Mentat Logic — Mon, 20 Jul 2026 09:12:53 +0000

Page-vs-page comparisons drive real decisions — PR retainers, ad placements, competitive reviews, "why is their engagement triple ours" meetings. Most of them are quietly wrong before the analysis even starts. Here are the five ways they lie, and a procedure that doesn't. It works with any scraper's export and no particular tool.

The five ways comparisons lie

Duplicates get counted twice. The same post arrives as /posts/301 and /posts/301?ref=share, from www. and from m. — and naive counting books it twice. Worse, this isn't random noise: pages that cross-post and push share links get inflated systematically. Your "most active page" may just be your most duplicated one.
The windows aren't equal. One page was scraped deeper into the past than another (scrapers paginate unevenly), so page A gets 90 days of history and page B gets 30 — then someone compares totals. Align the window first, and say what it is.
The mean worships one viral post. A page with 49 dead posts and one 10,000-engagement hit "averages" 200 per post. Report the median for typical performance and list the top posts separately — they're different facts and both matter.
Absent fields become zeros. Mobile exports often lack shares entirely. Treat missing as zero and that page "has no shares" — a data artifact promoted to a finding. Absent data should render as absent ("—"), never as 0, and the report should say which fields were absent where.
Nobody states the coverage. "We compared the pages" — on how many rows? After removing how many duplicates? Over what window, in whose timezone? How many posts had no readable date? A comparison that can't answer these isn't evidence; it's vibes with a chart.

The procedure


1. Canonicalize every URL first (hosts folded, tracking params stripped,

   identity params kept) — see "The Facebook URL Zoo" for the full rules.

2. Deduplicate on the canonical post key. Record how many you removed.

3. Align the comparison window across all pages; state it, with timezone.

4. Per page: post count, total engagement gained, MEDIAN engagement,

   and top posts listed separately.

5. Render absent fields as "—", and note which pages lacked which fields.

6. Print the coverage block INTO the deliverable: rows in, duplicates

   removed, window, dateless rows, fields absent. The method is part of

   the report, not a footnote you keep to yourself.

Why this matters most in PR and advertising

If you make your living on these numbers, the deliverable is the argument. A competitive audit that states its coverage and shows its dedup survives the hostile question in the client meeting; one that can't explain its denominators dies there, and takes your credibility with it. And if you're an advertiser vetting pages for placements or partnerships: duplicate-inflated engagement is precisely how a mediocre page is made to look lively. The procedure above is how you check before the money moves.

Disclosure: I build tools that implement exactly this. Mentat Page Compare runs the whole procedure on any posts-scraper export and produces a client-ready HTML report — $3.99 per 1,000 unique posts (deduplicated first, so you never pay twice for the same post; platform compute included; the demo is free). Its free sibling, the Facebook Page Identity Resolver, handles step 1-2 alone. The full URL taxonomy is in The Facebook URL Zoo. The procedure works without any of them — that's rather the point.

The Facebook URL Zoo: every page-link format and how to canonicalize them

Mentat Logic — Sun, 19 Jul 2026 13:34:51 +0000

If you scrape or analyze Facebook data, the same page will arrive under half a dozen different URLs — and if you count anything before resolving that, your numbers are quietly wrong. This is the reference I wish had existed: the formats, the traps, and a canonicalization procedure that never guesses.

Why your counts are wrong

Pull posts from any Facebook scraper and look at the page URLs. The same fish market shows up as:

https://www.facebook.com/HelensFreshMarket
https://m.facebook.com/helensfreshmarket/
https://www.facebook.com/profile.php?id=100077000000001
https://www.facebook.com/p/Helens-Fresh-Market-100077000000001/

Group by URL and you have four "pages," each with a quarter of the real engagement. Every downstream number — rankings, share-of-voice, averages — inherits the error. Post URLs have the same disease: the same post arrives with and without tracking parameters, from mobile and desktop hosts, and through share redirects.

The zoo, part 1: hosts

All of these serve the same content and must be folded together:

Host	What it is
`www.facebook.com`	canonical desktop
facebook.com (bare)	redirects to www
m.facebook.com	mobile web (very common in scraped data)
mbasic.facebook.com	legacy low-bandwidth mobile
web.facebook.com	regional variant (common in Africa/Asia exports)
touch.facebook.com	legacy touch interface

Rule 1: fold every host to www.facebook.com, force https, drop the trailing slash. Trivial, and it already collapses a third of the zoo.

The zoo, part 2: page-identity URLs

These are the formats that name a page (strongest evidence first):

Format	Example	Identity signal
profile.php?id={N}	/profile.php?id=100077…	numeric ID — authoritative
/p/{Name}-{N}/	/p/Helens-Fresh-Market-100077…/	numeric ID — authoritative (newer format; the trailing number is the page ID)
/people/{Name}/{N}/	/people/Helen-M/100077…/	numeric ID — authoritative
/pages/{Name}/{N}	legacy	numeric ID — authoritative
/{vanity}	/HelensFreshMarket	slug — reliable but case-varies; case-fold before comparing
/pg/{vanity}/…	legacy page-tab wrapper	slug after stripping /pg/

Rule 2: extract identity by hierarchy — a numeric ID always outranks a slug. When both are observed for the same entity (a slug URL and a profile.php?id= URL that share posts or metadata), the numeric ID is the canonical key and the slug becomes an alias.

Rule 3: slugs are case-insensitive — case-fold before comparing. HelensFreshMarket and helensfreshmarket are the same page; a case-sensitive groupby splits them.

The zoo, part 3: post URLs

Format	Example	Note
/{vanity}/posts/{id}	/helensfreshmarket/posts/101	id may be numeric or an opaque pfbid… token
permalink.php?story_fbid={S}&id={P}	desktop permalink	the params are the identity — keep them
story.php?story_fbid={S}&id={P}	mobile permalink	same as above
/groups/{g}/posts/{id}	group post	group ≠ page; keep the distinction
photo.php?fbid={N} / /photo/?fbid={N}	photo post	fbid is the identity param
/watch/?v={N}	video watch page	carries no page identity (see traps)
/reel/{id}	reel	post-level only
/share/p/{token}/, /share/v/{token}/	share redirect	opaque (see traps)

Rule 4: for deduplication, strip tracking parameters but keep identity parameters. Strip: ref, refid, fbclid, mibextid, rdid, utm_*, tn, comment_id, notif_id, notif_t, locale. Keep: story_fbid, id, fbid, v. The same post with and without ?ref=share&utm=x is one post; the same path with a different story_fbid is not.

The traps (where guessing corrupts datasets)

Trap 1 — display names are not identity. Two pages named "Caladan Bay Tours" can be genuinely different entities (rebrand, fan page, impersonator, franchise). Merging on display name is how datasets rot. The correct behavior is to report the collision as a possible-same-entity hint with the evidence, and let a human decide.

Trap 2 — /watch?v= links carry no page identity. The URL names a video, not a page. Attribute it to a page only if the row carries separate page metadata; otherwise it is honestly unresolvable.

Trap 3 — share links are opaque. /share/p/{token}/ is a server-side redirect; the token doesn't encode the destination. Offline, you cannot resolve it — flag it, don't guess it.

Trap 4 — renames. A page that changed its vanity slug between scrapes, and never exposed its numeric ID, looks like two pages. Without an ID observation there is no safe automatic merge; surface it, don't force it.

Trap 5 — pfbid tokens. Modern post IDs are opaque pseudonymized tokens. Treat them as exact-match strings only; never parse meaning out of them.

The procedure, end to end

for each row:
  1. fold host → www.facebook.com, https, strip trailing slash
  2. classify URL: page-identity form vs post form
  3. page identity:
       numeric ID present → key = fb:{numeric}
       else vanity slug   → key = fb:{casefold(slug)}
       else               → UNRESOLVED (keep the URL as evidence)
  4. post dedup key: canonical path + kept identity params
       (tracking params stripped)
  5. merge pages only when keys match
       same display name, different keys → report hint, do NOT merge

The principle underneath: an unresolved row with its evidence attached is useful; a silently guessed merge is poison. Every downstream consumer can act on "here are 3 rows I couldn't resolve, and why" — nobody can undo a wrong merge they never knew happened.

Disclosure: I maintain a small free tool that implements exactly this procedure (including the refusals) for any posts-scraper export — Facebook Page Identity Resolver & URL Deduplicator on Apify, with a 3-second no-signup demo. But the procedure above works fine without it — that's rather the point.