The Person Match-Key Reference: What Each Identifier Pins Down

You need to merge records that describe the same human and never merge two who are not. This is a lookup reference for the people who own that decision in RevOps and RecOps: it grades each real sourcing identifier - verified email, corporate pattern email, phone, LinkedIn vanity slug, LinkedIn numeric ID, GitHub username, GitHub user ID, commit author email, name-plus-employer, and personal domain - on uniqueness, survival through a job change, how to normalize it, what a match proves, and the specific way it produces a false merge. Jump to the row you need. Each one is self-contained.

The abstract debate about deterministic versus probabilistic matching is covered everywhere. What is not written down anywhere public is a per-identifier grade of the keys you actually have in your source systems. That is what this reference is.

The one rule that governs every person key

The visible identifier is almost always the mutable one, and the stable identifier is hidden underneath it. This single pattern repeats across every platform you source from, and it is the reason most person-dedup rules are built on the wrong field.

LinkedIn shows people a vanity slug and keeps a numeric entity ID for its own systems. GitHub shows a username and keeps a numeric user ID. In both cases the thing that is easy to copy and paste is the thing that changes, and the thing that never changes is the thing you have to go dig out. Members can edit a LinkedIn slug up to five times in six months. A renamed GitHub username is released immediately for anyone else to claim. Both numeric IDs never change.

Every identifier that is easy to copy is the wrong one to store as your match key.

So the first move in any person match rule is the same: resolve the readable identifier to its hidden numeric one before you store it. If you skip that step, you have built your deduplication on a field whose owner can change it on a Tuesday.

The identifier grade table: strong versus weak

A key is strong if it is immutable and one-to-one, and weak if it is mutable or many-to-one. Strong keys can drive an automatic merge; weak keys can only form blocks or feed a score. Here is where each of the ten lands.

Treat this as the top-level routing table. The rest of this reference explains why each weak key is weak and gives you the guard that stops it from producing a false merge.

Why a narrow query is a collision proxy

Before trusting name-plus-title as even a block key, look at how many people share one. In Refolk's index, volume is a direct proxy for collision risk.

A title shared by 352,540 people is not a key by any definition. A narrow skill like Rust, held by 3,593 people in the US, narrows a block but still does not uniquely identify anyone. Use these numbers to calibrate: the larger the population behind an attribute, the more a composite built on it will collide.

Email: three different keys wearing one coat

Email is not one identifier. A verified unique email is strong, a corporate pattern email is weak and expires on a job change, and a consumer Gmail address needs canonicalization that is dangerous if applied to the wrong domain. Handle each as its own key.

A verified unique email - one you have confirmed deliverable and tied to a single person - is as strong as a numeric ID while the mailbox exists. The weakness is reassignment: a corporate address like first.last@ gets reused for a new hire with the same name, which merges two employees. Guard by re-verifying on a cadence and never trusting an address you have not confirmed is still the same human's.

A corporate pattern email breaks by definition on a job change, because the domain leaves with the employer. It is fine as a block key for current-employer dedup but useless for tracking a person across moves. For that, see the job-change reference guides in this library.

A consumer Gmail address collapses many strings to one inbox. For gmail.com and googlemail.com, dots are ignored, capitalization is ignored, and anything after a plus sign delivers to the same mailbox: A.B.C@gmail.com, abc@gmail.com, and AbC+Shop@gmail.com all reach the same person. So you canonicalize by lowercasing, removing dots in the local part, and dropping everything from the first plus, then treating googlemail.com as gmail.com.

Here is the trap. On Google Workspace, dots change the address. Two coworkers on a company Google domain can differ only by a dot, and stripping it merges two distinct people.

Plus-tag sub-addressing is defined only in RFC 5233, an extension to mail filtering, not a universal delivery rule, so do not assume every provider routes +tag to the base inbox. Confirm per domain or treat plus-tags conservatively.

Phone: the least safe key that looks unique

A phone number looks like a one-to-one identifier and is not, because numbers are reassigned fast and often. It is the weakest "unique" key you can match on and should never drive an automatic merge without a recency check.

The FCC sets only a floor on how long a number ages before reuse: numbers previously assigned to residential customers may be aged no less than 45 days and no more than 90 days, and business numbers no less than 45 days and no more than 365 days. That is the minimum. In practice carriers move faster: one filing told the FCC that some large carriers reassign disconnected numbers in as few as two days.

And reassignment is not rare. A Princeton study found a sampled number was recycled 41.6% of the time, with a 95% confidence interval of 30.5% to 52.6%.

Normalize phones to E.164 before comparing so formatting differences do not split a true match. But normalization does not fix the reassignment problem. The guard is an aging and recency check: only merge on a phone when you have evidence the number still belongs to the same person, and re-verify before you rely on it.

LinkedIn: slug lies, numeric ID holds

Match LinkedIn records on the numeric member ID, never on the vanity slug or the full URL. Every profile has a public vanity slug that members share and a numeric entity ID that LinkedIn's own systems use. The slug is editable up to five times per six months; the numeric ID never changes.

The false merge is specific. When a member edits their slug, the old one is released. If someone else later takes that slug, your record keyed on the slug now points to a different person. Resolve every profile to its numeric member ID before matching and the problem disappears.

One useful detail: default LinkedIn URLs append a hex hash for uniqueness when members share a name. That hash is a sign the person did not set a custom slug; it is still the slug, still mutable in principle, and still the wrong thing to key on.

GitHub: one field, three populations

GitHub identifiers need three separate rules because a commit email can be any of three things. The numeric user ID is immutable and is your strong key; the username is mutable and is not; and a commit noreply email is safe, unstable, or not even a person depending on its form.

GitHub usernames are explicitly not permanent. After a username change, the old username becomes available for anyone else to claim. GitHub retired its dormant-username release process, so support no longer reviews requests for inactive handles, and because not all activity is public, an empty-looking profile may be in active use. A deleted username is freed after 90 days; a renamed one is released immediately. Usernames max out at 39 characters, alphanumeric plus hyphens. None of that matters for matching except to tell you: do not key on the username.

The commit author email is the one field that splits into three populations:

• ID-based noreply - of the form ID+USERNAME@users.noreply.github.com, used by accounts created after 18 July 2017 and by older accounts that enabled privacy after that date. It carries the immutable numeric user ID. This is safe.
• Username-based noreply - of the form USERNAME@users.noreply.github.com, used by older accounts that enabled privacy before that date. It detaches from the account on a rename, so old commits stop resolving. Treat it as unstable.
• Bot addresses - of the form USERID+APP-NAME[bot]@users.noreply.github.com, for example 149130343+josh-issueops-bot[bot]. These belong to an app, not a human, and must be excluded.

The payoff of getting this right: you can match the same human across GitHub and LinkedIn by resolving each side to its immutable numeric ID and ignoring every mutable handle in between. That is the hard part of cross-source person resolution, and it is exactly the kind of query that plain-English search removes the friction from.

When you want the matched records back without building the resolver yourself, Refolk keys on the stable identifiers across the public GitHub graph and public LinkedIn records so the people who come back are the same humans, not slug collisions.

The procedure: block, then match

The sequence is settled: block first to shrink the comparison space, then match within blocks, running strong keys deterministically and weak keys through a score. Sources agree on this order; they disagree only on whether a learned model should replace hand-tuned weights in the scoring step. Here is the full procedure.

Two framing notes on the matching step. Deterministic matching applies strict rules: two records match only if specific fields are identical. It is precise and transparent but misses valid matches when data is inconsistent, misspelled, or incomplete. Probabilistic matching uses statistical models to weigh similarity across multiple fields; it catches more true matches but introduces false positives. The standard answer is to use both - deterministic rules for high-confidence matches where a unique ID is shared, probabilistic scoring for the ambiguous remainder.

Blocking is not only a speed trick. It is a precision-and-recall lever. If the blocking key is not distinctive, many irrelevant records land in one block and matching slows down. If the blocking key is not invariant across records of the same entity, true matches get split across different blocks and are silently lost. That is why you block on a stable key, never on a mutable one.

How this goes wrong: the named false-merge modes

Every weak key has a specific failure with a specific guard. Here are the eight that recur, each one a false merge or a false miss you can prevent.

The two worst in practice are name-plus-employer and phone, because both feel reliable and both fail most where you have the most data. Name-plus-employer fails hardest exactly where your records cluster: 352,540 US "Software Engineer" profiles with Google as the top employer means the composite collides most at your biggest targets. Phone fails because reassignment is fast and probable. Neither should ever trigger an automatic merge alone.

The two false misses - detached username-noreply commits and over-blocking on a mutable key - are quieter and more dangerous, because a false miss leaves two records for one person and you never see an error. Audit for them by sampling records that should have merged and checking why they did not.

What to verify before you call the merge rule done

Run this before you turn any match rule loose on live data. Each item is a specific check, not a topic.

Keeping the reference current

The grades in this document are stable because they describe mechanisms, not current values, but two things move and are worth a periodic re-check. First, platform rules: GitHub has already retired its dormant-username release process, and either platform could change how slugs, usernames, or noreply forms behave, so re-read the GitHub username and commit-email docs and confirm the LinkedIn slug edit limit when you revise your rules. Second, reassignment windows: the FCC floor of 45 days is a minimum, and carrier practice runs faster, so treat any phone match as time-bounded and set your recency threshold against current carrier behavior rather than the regulatory floor.

The core will not change. On every platform that matters, the easy-to-copy identifier is the mutable one and the stable identifier is hidden. Build on the hidden one, keep the readable one for display, and reserve probabilistic scoring for the records that share no immutable key at all.

LinkedIn: key = numeric member ID; slug = display only; auto-merge on exact ID.
GitHub: key = numeric user ID; username = display only; auto-merge on exact ID.
Commit email: keep ID-based noreply, flag username-only as unstable, drop any [bot].
Verified email: auto-merge on exact lowercased match; re-verify on a cadence.
Gmail: canonicalize (lowercase, strip dots and +tag) only for gmail.com/googlemail.com.
Phone: E.164; never auto-merge without a recency/re-verification flag.
Name+employer: block key only; require a second immutable key before merge.