One public conversation can match a category query, competitor query, pain phrase, recommendation pattern, and several projects. Treating every match as a new opportunity inflates volume and fragments the evidence. The better unit is one canonical conversation record with a match history, source events, and project-specific decisions. The representative examples below show which records should merge and which should remain separate.
A query match is not a new conversation
Multiple detection reasons should enrich one record rather than create parallel cards that ask the operator to repeat the same decision.
Canonical source identity comes first
Use the platform's stable post or thread identifier when available; normalized URLs and text similarity are fallbacks, not stronger evidence.
Comments can change the decision state
A new comment may introduce a budget, deadline, or explicit request. Append the event and rescore the conversation instead of silently discarding it as a duplicate.
Project decisions should stay independent
The same source can be high fit for one project and irrelevant to another. Merge the source record without merging every downstream disposition.
A four-step conversation deduplication contract
Apply deterministic identity first, then preserve every piece of context that could change qualification.
Resolve the canonical source
Store platform, stable post or thread ID, canonical source URL, author identity when public, and original publication time.
Attach every detection reason
Keep matched queries, projects, categories, and timestamps as evidence on one record instead of flattening them into one generic label.
Treat material updates as events
Append comments, edits, score changes, and new constraints when they could alter intent, fit, freshness, or reply permission.
Keep routing decisions scoped
Record reply, research, watch, or reject separately for each project or owner while retaining the shared source history.
Representative: one post matches four queries
A recommendation request names a competitor, describes a painful workaround, and asks for an alternative.
Why it matters: Create one conversation record with four detection reasons, not four reply opportunities.
Representative: a cross-post has different discussions
The same text appears in two communities, but each thread develops different requirements and participation norms.
Why it matters: Link the records as related content while keeping separate thread identity and routing context.
Representative: a later comment adds a deadline
The original post looked like research; a follow-up says the team must choose a replacement before renewal.
Why it matters: Append a material event, update freshness and intent, and return the record to review.
Define merge, link, and keep-separate rules
Merge identical source identity, link likely cross-posts or quoted sources, and keep independent discussions separate when context or community changes the action.
Audit suppressed events
Sample merged and ignored updates weekly to confirm that the system is not hiding new decision context behind an old record.
Measure unique decisions, not alert volume
Track distinct conversations reviewed, material updates reopened, and decisions completed instead of counting every query hit as new demand.
Make the founder feed quieter without throwing away the evidence behind a match.
ReplyRadar helps teams review a smaller project-aware feed while keeping the conversation context needed for a human decision.
Should identical text always be merged?
No. Identical text in different communities can create separate discussions, norms, and reply decisions. Link those records rather than erasing their context.
What is the safest deduplication key?
A stable platform post or thread ID is strongest. Canonicalized URLs can support it; text similarity alone should not silently merge records.
Can a duplicate alert become important later?
Yes. A new comment, edit, or constraint can materially change the opportunity. Store updates as events and reopen review when the decision state changes.