# Resolving a Duplicate Person Across GitHub, LinkedIn, and the CRM

*You will carry an ambiguous same-name cluster through a documented match decision, pick surviving field values, and leave a reversible audit trail without fusing two people.*

- Canonical URL: https://www.refolk.ai/guides/resolving-duplicate-person-across-sources
- Pillar: Process, data, and compliance
- Format: Teardown
- Published: 2026-09-13
- Last reviewed: 2026-09-13
- Reading time: 6 min

You have two or three records that might be the same human, spread across the public GitHub graph, public LinkedIn records, the open web, and your CRM. You have to decide merge, link, or keep separate without fusing two different people, and you have to be able to explain and reverse the call later. This guide carries one hard, common-name case all the way through - the real queries, the intermediate counts, and the wrong turn where the evidence pointed at a merge that was actually two people.

It is written for recruiting operations, revenue operations, and anyone answerable for how the data was gathered. Most dedupe content stops at exact-match keys inside one CRM and treats merging as bulk cleanup. This one shows the disambiguation and survivorship decisions at each fork, including the one that would have cost you a record.

## Why common names break exact-match dedupe

Name-plus-title cannot resolve a common-name person, because the base rate of collisions is larger than most match thresholds assume. The enemy is not the algorithm. It is the number of real people who legitimately share a name and a job.

Consider the case I will use throughout: a "James Smith" who is a software engineer in the San Francisco Bay Area, appearing once in the CRM and twice in public sources. FiveThirtyEight estimated more than 31,000 James Smiths in the US. "Smith" is the most popular US surname at roughly 2,627,141 people, and James is the most common given name among them. So the name alone narrows nothing meaningful.

The title does not save you either. In Refolk's index of professional profiles, the US "Software Engineer" population is 349,377. Cross a 31,000-strong name pool with a 349,377-strong title pool and you still have a candidate space where two distinct humans can match on name, title, city, and stack.

**349,377 - US "Software Engineer" profiles in Refolk's index**

Against 43,436 in the UK - the identical title has roughly 8x more US bearers, so the same match threshold is far riskier in the larger market.

The practical consequence: your disambiguation effort should scale with the pool size, not the record count. A rare-name senior director in a 40-person function is a five-minute call. A "James Smith" software engineer in the Bay Area needs relational evidence before you touch the merge button.

### The two error directions

Dedupe has two failure directions, and most content only guards one.

- A **homonym error** merges two different people who share a name. You lose a real person's record inside someone else's.
- A **synonym error** splits one person across multiple records. You keep contacting the same human three times and treat their history as three histories.

Check both directions on every cluster. The instinct to "clean up duplicates" pushes hard toward merging, which is exactly the direction that destroys distinct people.

## The identifiers that resolve and the ones that lie

Hard identifiers are strong but not infallible, and the strongest-feeling key is the one that most quietly produces false positives. Rank your keys by how much they actually prove, and know the failure shape of each.

GitHub associates commits with your account using your commit email address. But it is possible to have multiple GitHub accounts on the same email, and GitHub treats them as separate entities that do not automatically relate to each other. So a shared email can hide two people, and it can also split one person. Commit metadata is worse: Git does not validate or constrain the author name and email, which opens the door to commit spoofing. A commit that says "James Smith" was not necessarily authored by the James Smith who pushed it.

| Key | What a match proves | What it looks like when it lies |
|---|---|---|
| Verified commit email (GPG-signed) | Strong: host verified the identity | Rare; unsigned commits carry no such guarantee |
| Account email | Medium: often one person | Shared inbox, or one email on two GitHub accounts |
| Canonical profile URL | Strong: one account | Two accounts for one person after a job move |
| Name similarity | Weak alone | Two "James Smith" engineers in the same city |

Name similarity is a soft key. Most AML screening systems use Jaro-Winkler thresholds between 0.80 and 0.90 for name matching, with 0.85 - meaning strings must be 85% similar - a common alert cutoff. The tradeoff is documented: a high threshold minimizes false positives but leads to more false negatives, and a low one does the reverse. OpenSanctions' rule baseline runs a very low 0.15 threshold to capture every true match at the expense of precision, on the assumption a human reviews after. That is the point: a name-similarity score is a routing decision, not a merge decision.

> **Rule:** Never auto-accept a near-threshold name match
>
> Anything in the 0.80 to 0.90 band goes to human review, not to an automated merge. A tuned system can target a 1 to 5 percent false-positive rate, and at common-name scale even 3 percent is many wrong merges.

## Corroborating evidence: what actually separates twins

For same-name people, relationship evidence beats attribute evidence. Two same-name engineers can share an employer, a city, and a tech stack, but they rarely share the same collaborators.

Named-entity disambiguation research is consistent here. Among features like co-authors, titles, topics, and affiliations, co-authorship is the most influential, since inter-person acquaintances discriminate identities more clearly than other features. Patent methods combine co-authors, citations, affiliated institutions and departments, city and country of those institutions, and author email addresses, and note the need is especially acute for common surnames.

Translate that to prospecting and recruiting sources:

- **Co-occurrence in the graph.** Shared repositories on GitHub, mutual connections on LinkedIn, co-authored posts or talks. This is your strongest disambiguator.
- **Employment timeline continuity.** A clean company-to-company sequence supports one person. A gap that looks like two overlapping jobs in two cities is a warning.
- **Attribute cluster.** Employer, location, career field. Useful, but weakest for twins because it is exactly what two same-name people share.

Persistent identifiers exist - ORCID has over 6 million active profiles with education, employment, and authorship records - but their uneven adoption limits standalone use. Treat a persistent ID as a bonus corroborator when present, never as a required key.

#### Evidence strength for same-name disambiguation

1. **Relationship graph** - Shared repos, mutual connections, co-authors - most discriminating
2. **Timeline continuity** - Coherent job history across sources
3. **Attribute cluster** - Employer, location, field - shared by twins
4. **Hard identifier** - Email, profile URL - strong but quietly ambiguous

*For twins, relationship evidence sits on top because collaborators rarely overlap even when attributes do.*

### The wrong turn, made explicit

Here is the fork in the James Smith case. Both public profiles listed the Bay Area, both listed Python, and both linked an account email that matched the CRM record on a freemail domain. Three keys agreed. The tempting call was merge.

Then I gathered relationship evidence. Profile A's GitHub showed contributions to a payments library alongside a set of collaborators; profile B's GitHub showed a different repo cluster with zero collaborator overlap. Profile A's current employer was a fintech; profile B's was a gaming studio, with a continuous timeline showing no move between them. The freemail address resolved to profile A only; profile B had reused a similar-looking inbox that a human reviewer, but not a match key, could distinguish. The correct call was keep separate. A same-name, same-city, same-stack pair had passed three keys and still been two people. Relationship evidence and timeline continuity broke the tie.

```pull
Two same-name engineers can share a city, a stack, and even an inbox pattern, and still never share collaborators.

## Frequently asked questions

### How do I tell if two contacts are the same person?

Start with hard identifiers - exact email, verified commit email, and canonical profile URLs - then treat name similarity as a soft key that needs corroboration. The decisive evidence for common names is relational: shared repositories, mutual connections, or co-authors. Require at least two independent corroborators pointing the same way before you call it a match, because a single strong key like a shared email can produce a confident false positive.

### Can I undo a contact merge in Salesforce or HubSpot?

Not natively. Salesforce merges are permanent, though deleted records stay in the Recycle Bin for 15 days. HubSpot states plainly that merging contacts cannot be undone and there is no way to separate the contacts afterward. Third-party tools can partially reconstruct records but do not truly unmerge. Because the action is one-way, export both records and their child objects before committing.

### What survivorship rules decide which field value wins?

Organizations typically use source priority, completeness, recency, verification status, and conditional overwrite rules, applied attribute by attribute rather than record by record. Sequence them: let source priority gate recency, because a recency rule can be fooled by a nightly batch sync where the newest write is a machine timestamp, not new human truth. Normalize fields first, or the comparison itself is unreliable.

### How do I avoid merging two different people with the same name?

Never auto-accept a name match near the 0.85 similarity band; route it to human review. Then check for relationship evidence, because two same-name engineers rarely share collaborators even when they share employer, location, and stack. Also check employment timeline continuity so you do not split one person's legitimate job change into two records, and confirm a shared email resolves to a single verified identity.

### What does the audit trail need to capture for a merge?

Under the accountability principle you must be able to demonstrate what happened. Log precisely what data was accessed or modified, who performed the action with unique user identification, when with a precise timestamp, and where. Add the reasoning and the surviving and losing record IDs so the decision is reconstructable. Records of processing activities act as this trail, and non-compliance can draw fines up to €20 million.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/resolving-duplicate-person-across-sources*