Building a Feedback Identity Graph to Merge Feature Requests Without Losing Revenue Context

Why merged feedback usually loses the revenue signal

Most product teams eventually hit the same ceiling: feature requests arrive through too many channels (public portal, support tickets, sales calls, Slack, email), and “duplicate” requests are never truly duplicates. They come from different users, within different accounts, across different plans, and at different moments in the customer lifecycle. If you merge too aggressively, you flatten the context that drives prioritization: who is asking, what they pay, whether they’re expanding, and what risk exists if you don’t act.

A practical way out is to treat feedback like identity data. A “Feedback Identity Graph” is a lightweight model that connects feature requests to the people, accounts, tools, and commercial attributes behind them, so deduplication improves clarity without stripping away revenue and segment insight.

What a Feedback Identity Graph is

A Feedback Identity Graph links four core entities:

• Identity nodes: end users, contacts, and their cross-tool identifiers (email, external IDs, CRM contact ID, support requester ID).
• Account nodes: companies/workspaces, including plan, MRR/ARR, renew date, region, and segment.
• Feedback nodes: feature requests, pain points, and use cases collected from every channel.
• Tool nodes: sources of truth such as Intercom, Zendesk, Gong, HubSpot/Salesforce, Jira/Linear, and your public portal.

The “graph” part matters because the same person can appear in multiple tools under different IDs, and the same account can be represented differently depending on where it was created. The goal is not perfect identity resolution; it’s good enough linkage to preserve business meaning when you group and prioritize requests.

The minimum viable data model

You don’t need a complex data warehouse to start. Define the fields you must keep when merging feedback so you can score demand with confidence:

1) Canonical account identity

• Account ID (internal)
• Primary domain(s)
• CRM account ID
• Billing customer ID (Stripe, Chargebee, etc.)
• Segment tags (SMB/mid-market/enterprise, industry, region)

2) Canonical user/contact identity

• User ID (internal)
• Email and verified domain match
• CRM contact ID
• Support requester ID
• Product user ID (if you track in-app)

3) Feedback object and evidence

• Normalized title (what the request is “about”)
• Use-case summary (why they need it)
• Source evidence (ticket link, call snippet, portal post URL, etc.)
• Strength signals: frequency, severity, urgency, and user role (admin vs end user)

4) Commercial context snapshot

• ARR/MRR at time of request
• Plan and add-ons
• Lifecycle stage (trial, new, expanding, renewal risk)
• Opportunity linkage (open deal, expansion, churn risk)

Storing a “snapshot” is key. Revenue changes, segments evolve, and the point of feedback is often tied to a specific moment (e.g., a renewal quarter).

How to merge feature requests without collapsing identities

Deduplication should happen in two layers: idea-level grouping and evidence-level preservation.

Layer 1: Group by problem, not wording

Two requests that look different can be the same underlying job-to-be-done. Create a canonical “parent idea” and attach variants as child evidence. Use a stable taxonomy: product area, workflow step, and constraint (latency, permissions, export formats, etc.).

Layer 2: Keep every vote and comment tied to an identity node

When you merge, do not move only the text. Move the linkage: which user said it, which account they belong to, and which tool produced the signal. This is how you preserve the ability to answer questions like:

• “How many enterprise admins asked for this in the last 90 days?”
• “What’s the ARR at risk if we don’t deliver by renewal season?”
• “Is this driven by one loud account, or a pattern across segments?”

If you want a structured approach to merging while retaining segment nuance, the principles are similar to the workflows outlined in the Feedback Deduplication Playbook for Merging Requests Without Losing Segment Insight.

Identity resolution rules that work in real teams

Most teams overfit on perfect matching and stall. Use pragmatic rules with human override:

• Hard match: same verified email, same CRM contact ID, same billing customer ID, same SSO external ID.
• Soft match: same domain + same full name, or repeated mentions in call notes tied to the same account owner.
• No match: keep separate identities, but allow grouping at the account level if there’s credible evidence (e.g., support org mapping).

Whenever a soft match occurs, store the confidence score and the reason. This prevents “silent” identity merges that later undermine trust in the dashboard.

Scoring demand with revenue context intact

Once you have the graph, prioritization becomes more defensible. A useful scoring pattern is to separate demand volume from business impact:

• Demand volume: number of distinct accounts, number of distinct active users, recency-weighted mentions.
• Business impact: ARR touched, renewal proximity, expansion opportunities, strategic segment importance.
• Delivery constraint: estimated engineering effort, dependencies, risk.

Graph structure prevents double-counting. For example, ten users from one account should not outrank three separate enterprise accounts—unless you explicitly choose to weight by account size.

Operationalizing the graph across tools

The most common failure mode is building a model that never stays current. Make the graph self-healing with three habits:

1) Capture feedback where it naturally appears

Don’t force everyone into a single channel. Instead, ingest from support and sales tools and normalize into your feedback system. Platforms like canny.io are designed to centralize requests from a public portal and internal sources, while keeping user and company context attached to each item. When AI-based capture and deduplication are available, use them to reduce manual triage—but keep humans in the loop for identity edge cases.

2) Maintain a clear “source of truth” hierarchy

• CRM is authoritative for account ownership and pipeline stage.
• Billing is authoritative for revenue and plan.
• Support is authoritative for pain and urgency.
• Your feedback hub is authoritative for idea grouping and prioritization.

This prevents the graph from being “correct” in one place and stale everywhere else.

3) Build a triage loop that respects the graph

Triage is where deduplication can accidentally destroy context. Create a standard workflow: confirm identity linkage, attach evidence, update the commercial snapshot, then merge into the canonical idea. If you’re refining how requests are routed and merged at scale, the mechanics are closely aligned with the Feedback Triage Playbook for Deduping and Routing Product Requests.

What you gain when merging no longer hides the money

A Feedback Identity Graph doesn’t just make a cleaner backlog. It makes your roadmap discussion more concrete: you can explain why an idea is prioritized in terms of number of impacted accounts, revenue exposure, segment strategy, and timing. Most importantly, you stop treating “deduped” as “simplified.” Instead, you treat it as “normalized,” where every request rolls up into a shared understanding without losing who asked and what it’s worth.