Comment Mining: Turning Your Own Audience Into ICP Signal
Your audience already told you what to make next. Comment mining is the difference between that signal sitting unread and it feeding the strategist directly.
The signal that's already sitting in your comments
Every other lane in this track works from data the operation generates itself -- the vault's performance columns, the grader's rubric, the scheduler's due-date math. Comment mining is different. It's the one lane whose raw material comes directly from the audience, unprompted, in their own words: what's frustrating them, what they wish existed, what they're stuck on, what they're asking for outright.
That signal is valuable specifically because nobody had to go looking for it. It's not a survey response shaped by the questions asked, or an assumption about the audience baked into a persona doc. It's what real people, already engaged enough to comment, chose to say. The job of this lane is narrow and mechanical: pull it, sort it, and route it back into what gets made next.
Five buckets, one priority order
Every comment on the operation's own media gets checked against five signal buckets: pain, desire, blocker, question, and praise. Each bucket has a keyword list -- phrases that reliably indicate a comment belongs there -- and a comment gets assigned to the FIRST bucket in a fixed priority order whose keywords it matches.
The priority order matters more than it might look. A comment like "I've been stuck on this for weeks and it's honestly so frustrating" plausibly touches both blocker language ("stuck") and pain language ("frustrating"). Checking blocker first and stopping there isn't an arbitrary tie-break -- a blocker (something actively preventing progress) is a sharper, more actionable signal than a general pain point, and reads that way to whoever is triaging these buckets for what to build content around next. The priority order encodes that judgment once, in the bucketing logic, instead of leaving it to be re-decided inconsistently every time someone reads the raw comments by hand.
A comment that matches none of the five buckets is dropped, not forced into whichever bucket seems closest. Forcing an ambiguous comment into a bucket it doesn't clearly belong to pollutes the signal -- a "pain" count that's quietly padded with comments that were actually just neutral chatter looks like more demand than actually exists, and that's worse than under-counting.
From buckets to ranked topic candidates
Bucketing alone isn't the deliverable -- a pile of individually-tagged comments doesn't tell the strategist what to make next. The digest step groups bucketed comments by quadrant and bucket, counts them, and ranks the results so that within each quadrant, the strongest signal bucket sorts to the top. A quadrant with a stack of blocker comments about one specific sub-topic is a stronger content candidate than a quadrant with scattered praise and nothing else -- the digest surfaces that difference directly instead of leaving it buried in raw comment volume.
This is also where the quadrant itself gets reattached. The bucketing step doesn't need to know which quadrant a comment's source media belonged to -- it's purely a text-classification decision. The digest step is what actually needs the quadrant, because it's grouping and ranking per-quadrant the way the quadrant gate and the strategist's topic selection both expect. Keeping that join separate from the bucketing logic keeps each piece focused on exactly one job.
Feeding the loop, not just a report
The ranked topic candidates aren't an analytics dashboard sitting off to the side -- they feed directly into the generation lane's topic selection, alongside the quadrant demand signal from the coverage gate. A quadrant that's underfed AND has a stack of unaddressed blocker comments is about as strong a "make this next" signal as the operation produces. New content gets made from that signal, gets published, draws its own comments, and the cycle runs again on the next pull. It's a flywheel, not a one-time report -- the value compounds specifically because it keeps running.
Failing clean when the scope is missing
Pulling comments on your own media requires the instagram_manage_comments permission scope, and that scope isn't guaranteed to always be present -- a token can be re-issued with a narrower grant, a permission review can lapse, an app review status can change. The pipeline probes for the scope before it ever attempts a fetch, and the failure path for a missing scope is deliberately unremarkable: log a specific warning naming exactly what's missing, skip comment mining for this cycle, and let every other lane keep running.
That last part is the detail worth internalizing. Comment mining feeds topic selection, but grading, publishing, and scheduling don't depend on fresh comment signal to do their jobs correctly this cycle -- they'll simply work from whatever signal is already available. Treating a missing scope as a reason to halt the entire operation would turn one narrow, well-understood failure mode into an outage across every lane that had nothing to do with it. A missing scope is an expected, nameable condition, not an exception that should propagate.
Build it: implement bucketComments and signalDigest
You're implementing the two functions that turn raw comments into ranked topic candidates: bucketComments, which classifies each comment into one of five buckets by priority-ordered keyword match, and signalDigest, which joins the results back to their source comments and ranks them per quadrant.