GTM Engineering skill 07 of 13

Data Deduplication and Normalisation SKILL.md

The Data Deduplication and Normalisation skill makes Claude Code or another AI agent clean GTM data. It normalises domains, names, emails, countries, phones, titles, seniority and industries, matches companies on root domain and contacts on email and LinkedIn URL, merges only high-confidence matches, sets survivor rules and checks the CRM before creating records.

data-deduplication-normalisation/SKILL.md, version 1.0.0, 1,493 words.

Dirty data breaks GTM systems quietly. The same company appears as "Acme Ltd", "ACME" and "acme.co.uk"; one person has three records with different emails; job titles come in hundreds of spellings; countries are written as "UK", "United Kingdom" and "GB". The results are duplicate outreach, wrong routing, broken scoring, inflated reports and prospects contacted by two reps on the same day.

This skill cleans GTM data before and after enrichment: normalising domains, company names, people names, titles, seniority, departments, countries, phone numbers and industries; matching and merging duplicate companies and contacts with clear rules; checking against the CRM before creating records; and setting up prevention so duplicates do not return.

Operating principles

  1. Normalise before matching. Clean formats first, then compare.
  2. Domains are the best company key. Names vary; root domains rarely do.
  3. Email plus name for people. Use LinkedIn URLs or CRM IDs as stronger keys where available.
  4. Merge with rules, not guesses. Decide which record and fields survive before merging.
  5. Prevent at the door. Check the CRM before creating or pushing records.

Normalisation rules

FieldRuleExample
DomainLowercase, remove protocol, www and paths, keep root domainhttps://www.Acme.co.uk/about -> acme.co.uk
Company nameTrim, remove legal suffixes for matching (Ltd, Inc, GmbH), keep display versionACME Ltd -> acme (match key)
Person nameTrim, proper case, separate first and lastjOHN smith -> John Smith
EmailLowercase, trimJohn.Smith@Acme.co.uk -> john.smith@acme.co.uk
CountryISO standard name or codeUK, GB, Great Britain -> United Kingdom (GB)
PhoneE.164 format with country code07700 900123 -> +447700900123
Job titleKeep original; add normalised role, seniority and department"Sr. Mgr, Growth Mktg" -> Growth marketing, Manager, Marketing
IndustryMap to your own short list"Financial technology" -> Fintech
LinkedIn URLLowercase, remove tracking parameters and trailing slashesStandard profile URL

Title normalisation

SeniorityIncludes
C-levelCEO, CFO, CMO, COO, CTO, Chief
VPVP, Vice President, SVP, EVP
Head or DirectorHead of, Director, Senior Director
ManagerManager, Lead, Team Lead
Individual contributorSpecialist, Analyst, Executive, Associate

When to use, and when not to

Use it before scoring, before CRM syncs, when merging lists from several sources, after enrichment, during CRM clean-ups and when reports look inflated.

Don't use it to decide CRM ownership rules (crm-sync-routing) or to clean marketing email lists for consent (the CRM and Lifecycle skills).

Inputs

  • The tables or CSV exports to clean.
  • CRM exports of existing companies and contacts with IDs.
  • Your industry list, title mapping and country standard.
  • Merge rules agreed with sales operations.

Raw SKILL.md file

.md

This is the exact file agents read, including the credit header and licence notice. Save it as data-deduplication-normalisation/SKILL.md.

---
name: data-deduplication-normalisation
description: "Clean GTM data: normalisation rules for domains, company names, people, emails, countries, phones, titles, seniority, departments and industries, company matching on root domain, contact matching on email and LinkedIn, match confidence, survivor rules, CRM lookups before creating records and duplicate prevention. Use whenever someone has duplicate companies or contacts, messy job titles, inconsistent countries or phone formats, merges lists from several sources, prepares data for scoring or a CRM sync, or wants to stop duplicate outreach."
license: CC-BY-4.0
metadata:
  author: Afeez Adebayo
  author_url: https://afeezadebayo.com
  author_linkedin: https://www.linkedin.com/in/afeez-adebayo/
  author_x: https://x.com/za_icon
  source: https://afeezadebayo.com/skills-md/marketing/gtm-engineering/data-deduplication-normalisation/
  category: marketing
  subcategory: gtm-engineering
  version: "1.0.0"
  created: "2026-10-10"
  updated: "2026-10-13"
---

# Data Deduplication and Normalisation

Dirty data breaks GTM systems quietly. The same company appears as "Acme Ltd", "ACME" and "acme.co.uk"; one person has three records with different emails; job titles come in hundreds of spellings; countries are written as "UK", "United Kingdom" and "GB". The results are duplicate outreach, wrong routing, broken scoring, inflated reports and prospects contacted by two reps on the same day.

This skill cleans GTM data before and after enrichment: normalising domains, company names, people names, titles, seniority, departments, countries, phone numbers and industries; matching and merging duplicate companies and contacts with clear rules; checking against the CRM before creating records; and setting up prevention so duplicates do not return.

## Operating principles
1. **Normalise before matching.** Clean formats first, then compare.
2. **Domains are the best company key.** Names vary; root domains rarely do.
3. **Email plus name for people.** Use LinkedIn URLs or CRM IDs as stronger keys where available.
4. **Merge with rules, not guesses.** Decide which record and fields survive before merging.
5. **Prevent at the door.** Check the CRM before creating or pushing records.

## Normalisation rules
| Field | Rule | Example |
|---|---|---|
| Domain | Lowercase, remove protocol, www and paths, keep root domain | https://www.Acme.co.uk/about -> acme.co.uk |
| Company name | Trim, remove legal suffixes for matching (Ltd, Inc, GmbH), keep display version | ACME Ltd -> acme (match key) |
| Person name | Trim, proper case, separate first and last | jOHN smith -> John Smith |
| Email | Lowercase, trim | John.Smith@Acme.co.uk -> john.smith@acme.co.uk |
| Country | ISO standard name or code | UK, GB, Great Britain -> United Kingdom (GB) |
| Phone | E.164 format with country code | 07700 900123 -> +447700900123 |
| Job title | Keep original; add normalised role, seniority and department | "Sr. Mgr, Growth Mktg" -> Growth marketing, Manager, Marketing |
| Industry | Map to your own short list | "Financial technology" -> Fintech |
| LinkedIn URL | Lowercase, remove tracking parameters and trailing slashes | Standard profile URL |

## Title normalisation
| Seniority | Includes |
|---|---|
| C-level | CEO, CFO, CMO, COO, CTO, Chief |
| VP | VP, Vice President, SVP, EVP |
| Head or Director | Head of, Director, Senior Director |
| Manager | Manager, Lead, Team Lead |
| Individual contributor | Specialist, Analyst, Executive, Associate |

## When to use, and when not to
Use it before scoring, before CRM syncs, when merging lists from several sources, after enrichment, during CRM clean-ups and when reports look inflated.

Don't use it to decide CRM ownership rules (`crm-sync-routing`) or to clean marketing email lists for consent (the CRM and Lifecycle skills).

## Inputs
- The tables or CSV exports to clean.
- CRM exports of existing companies and contacts with IDs.
- Your industry list, title mapping and country standard.
- Merge rules agreed with sales operations.

## Workflow

### Step 1. Profile the data
Count rows, empty fields, distinct values per field and obvious duplicates.

### Step 2. Normalise fields
Apply the rules above into new normalised columns; keep originals.

### Step 3. Match companies
Exact match on root domain; then fuzzy match on normalised name plus country for rows without domains; review low-confidence matches.

### Step 4. Match contacts
Exact match on email; then LinkedIn URL; then normalised name plus company domain.

### Step 5. Decide survivors
Rules such as: keep the CRM record if it exists; keep the most recently verified email; keep rep-entered fields over enriched ones.

### Step 6. Merge or flag
Merge automatically only for high-confidence matches; flag the rest for review.

### Step 7. Check against the CRM
Before pushing, look up each record; update existing records instead of creating new ones.

### Step 8. Prevent recurrence
Normalise on entry, enforce unique keys, run a weekly duplicate report.

## Match confidence
| Match | Confidence | Action |
|---|---|---|
| Same root domain | High | Merge companies |
| Same email | High | Merge contacts |
| Same LinkedIn URL | High | Merge contacts |
| Same normalised name and country, no domain | Medium | Review |
| Similar name only | Low | Do not merge; flag |

## Fuzzy matching tips
- Compare normalised names with legal suffixes and punctuation removed.
- Require a second matching field (country, city or phone) for fuzzy company matches.
- Use similarity thresholds (for example 0.9 or higher) and review anything between 0.8 and 0.9.
- Never fuzzy-match people on name alone; common names collide.

## Merge field priority
| Field | Survivor rule |
|---|---|
| Owner | Existing CRM owner |
| Email | Most recently verified valid email |
| Title | Most recent source date |
| Phone | Rep-entered over enriched |
| Notes and activity | Combine; never delete history |
| Lifecycle stage | Furthest stage reached |

## Weekly duplicate report
List new duplicate pairs by type and source, the share of records created without a CRM lookup and the top sources of messy data. Fix the source workflow when one input keeps causing duplicates.

## Using an AI agent
The agent can profile data, write normalisation formulas or Python scripts, propose title mappings, run matching with confidence scores and prepare merge lists for review. Bulk merges in the CRM happen only after a backup and a human check of samples.

## Keeping originals
Always keep the original value beside each normalised field and record the source and date. When a mapping is wrong, originals make it easy to fix without re-buying data, and they show auditors exactly what changed and why. Store mapping tables, such as titles to seniority, in one shared place so every table uses the same rules.

Run the duplicate report before every large CRM push and after importing any new list, and fix the source of repeated problems rather than cleaning the same issues each month.

## Edge cases and judgement calls
| Situation | What to do |
|---|---|
| Group companies with many domains | Link subsidiaries to a parent account; do not merge |
| Shared generic domains (gmail.com) | Never match companies on them |
| Person moved company | New contact at new company; keep history linked |
| Country-specific domains of one brand | Decide account model: global parent or local accounts |
| Very large CRM clean-up | Back up first; work in batches; review samples |
| Records owned by different reps | Follow ownership rules before merging |

## Handoffs to related skills
- Table design: `clay-table-design`
- Waterfall outputs: `enrichment-waterfalls`
- CRM rules: `crm-sync-routing`
- QA: `gtm-workflow-qa`
- CRM hygiene programmes: the CRM and Lifecycle `crm-data-hygiene` skill

## Worked example
A team merged three lead sources into one table of 18,000 contacts. Profiling found 2,300 duplicate contacts, companies spelled up to five ways and 410 country variants. Normalisation, domain matching and email matching merged 1,950 duplicates automatically and flagged 350 for review. A CRM lookup found 1,100 contacts already in the CRM, which were updated instead of created. Title normalisation produced clean seniority and department fields for scoring. Duplicate outreach complaints stopped, and pipeline reports no longer double-counted accounts.

## Common mistakes
- Matching on company names instead of domains.
- Overwriting originals instead of adding normalised columns.
- Auto-merging low-confidence matches.
- Creating CRM records without checking for existing ones.
- Cleaning once and never preventing recurrence.

## Output format
```
1. Data profile
2. Normalisation rules applied
3. Match results by confidence
4. Survivor and merge rules
5. CRM lookup results (update versus create)
6. Prevention plan and weekly report
```

## Self-check before you answer
- Are fields normalised before matching, with originals kept?
- Are companies matched on root domain first?
- Are only high-confidence matches merged automatically?
- Is the CRM checked before creating records?

---
Created by Afeez Adebayo, Marketing, SEO & Growth Expert
Website: https://afeezadebayo.com
LinkedIn: https://www.linkedin.com/in/afeez-adebayo/
X: https://x.com/za_icon
Source: https://afeezadebayo.com/skills-md/marketing/gtm-engineering/data-deduplication-normalisation/

Licence: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). You may copy, share and adapt this skill, including for commercial use, as long as you credit Afeez Adebayo and link to the source URL above. Keep this notice in any copy or adapted version.

Workflow

Step 1. Profile the data

Count rows, empty fields, distinct values per field and obvious duplicates.

Step 2. Normalise fields

Apply the rules above into new normalised columns; keep originals.

Step 3. Match companies

Exact match on root domain; then fuzzy match on normalised name plus country for rows without domains; review low-confidence matches.

Step 4. Match contacts

Exact match on email; then LinkedIn URL; then normalised name plus company domain.

Step 5. Decide survivors

Rules such as: keep the CRM record if it exists; keep the most recently verified email; keep rep-entered fields over enriched ones.

Step 6. Merge or flag

Merge automatically only for high-confidence matches; flag the rest for review.

Step 7. Check against the CRM

Before pushing, look up each record; update existing records instead of creating new ones.

Step 8. Prevent recurrence

Normalise on entry, enforce unique keys, run a weekly duplicate report.

Match confidence

MatchConfidenceAction
Same root domainHighMerge companies
Same emailHighMerge contacts
Same LinkedIn URLHighMerge contacts
Same normalised name and country, no domainMediumReview
Similar name onlyLowDo not merge; flag

Fuzzy matching tips

  • Compare normalised names with legal suffixes and punctuation removed.
  • Require a second matching field (country, city or phone) for fuzzy company matches.
  • Use similarity thresholds (for example 0.9 or higher) and review anything between 0.8 and 0.9.
  • Never fuzzy-match people on name alone; common names collide.

Merge field priority

FieldSurvivor rule
OwnerExisting CRM owner
EmailMost recently verified valid email
TitleMost recent source date
PhoneRep-entered over enriched
Notes and activityCombine; never delete history
Lifecycle stageFurthest stage reached

Weekly duplicate report

List new duplicate pairs by type and source, the share of records created without a CRM lookup and the top sources of messy data. Fix the source workflow when one input keeps causing duplicates.

Using an AI agent

The agent can profile data, write normalisation formulas or Python scripts, propose title mappings, run matching with confidence scores and prepare merge lists for review. Bulk merges in the CRM happen only after a backup and a human check of samples.

Keeping originals

Always keep the original value beside each normalised field and record the source and date. When a mapping is wrong, originals make it easy to fix without re-buying data, and they show auditors exactly what changed and why. Store mapping tables, such as titles to seniority, in one shared place so every table uses the same rules.

Run the duplicate report before every large CRM push and after importing any new list, and fix the source of repeated problems rather than cleaning the same issues each month.

Edge cases and judgement calls

SituationWhat to do
Group companies with many domainsLink subsidiaries to a parent account; do not merge
Shared generic domains (gmail.com)Never match companies on them
Person moved companyNew contact at new company; keep history linked
Country-specific domains of one brandDecide account model: global parent or local accounts
Very large CRM clean-upBack up first; work in batches; review samples
Records owned by different repsFollow ownership rules before merging
  • Table design: clay-table-design
  • Waterfall outputs: enrichment-waterfalls
  • CRM rules: crm-sync-routing
  • QA: gtm-workflow-qa
  • CRM hygiene programmes: the CRM and Lifecycle crm-data-hygiene skill

Worked example

A team merged three lead sources into one table of 18,000 contacts. Profiling found 2,300 duplicate contacts, companies spelled up to five ways and 410 country variants. Normalisation, domain matching and email matching merged 1,950 duplicates automatically and flagged 350 for review. A CRM lookup found 1,100 contacts already in the CRM, which were updated instead of created. Title normalisation produced clean seniority and department fields for scoring. Duplicate outreach complaints stopped, and pipeline reports no longer double-counted accounts.

Common mistakes

  • Matching on company names instead of domains.
  • Overwriting originals instead of adding normalised columns.
  • Auto-merging low-confidence matches.
  • Creating CRM records without checking for existing ones.
  • Cleaning once and never preventing recurrence.

Output format

1. Data profile
2. Normalisation rules applied
3. Match results by confidence
4. Survivor and merge rules
5. CRM lookup results (update versus create)
6. Prevention plan and weekly report

Self-check before you answer

  • Are fields normalised before matching, with originals kept?
  • Are companies matched on root domain first?
  • Are only high-confidence matches merged automatically?
  • Is the CRM checked before creating records?

When to use this skill, and when not to

Use it before scoring or CRM syncs, when merging lists from several sources, after enrichment and when reports look inflated.

The same company spelled five ways or one person with three records leads to duplicate outreach, wrong routing and double-counted pipeline.

Example prompts

  • “Deduplicate these three lead lists.”
  • “Normalise job titles into seniority and department.”
  • “Check these contacts against our CRM.”
  • “Set merge rules with sales ops.”

Example output

The skill returns a fixed structure. A shortened example for an imaginary site:

Profile: 18,000 contacts, 2,300 duplicates
Auto-merged: 1,950 (high confidence) | Flagged: 350
CRM lookup: 1,100 updated instead of created
Titles: clean seniority and department fields

Fields are normalised before matching, originals are kept and only high-confidence matches merge automatically.

What the agent needs from you

It needs the tables or exports to clean, CRM exports with IDs, your industry list, title mapping and country standard and agreed merge rules.

How this skill hands off to related skills

Data Deduplication and Normalisation connects to related skills in the GTM Engineering skills, including GTM Workflow QA and GTM Engineering Audit.

How to run Data Deduplication and Normalisation step by step

  1. Install the skill as data-deduplication-normalisation/SKILL.md.
  2. Profile the data.
  3. Normalise fields.
  4. Match companies.
  5. Match contacts.
  6. Decide survivors.

Situations this skill handles

Data Deduplication and Normalisation handles these situations:

SituationWhat the skill does
Group companies with many domainsLink subsidiaries to a parent account; do not merge
Shared generic domains (gmail.com)Never match companies on them
Person moved companyNew contact at new company; keep history linked
Country-specific domains of one brandDecide account model: global parent or local accounts
Very large CRM clean-upBack up first; work in batches; review samples
Records owned by different repsFollow ownership rules before merging

What makes this skill different

Most clean-ups are one-off. This skill normalises before matching, merges by confidence with clear survivor rules and adds prevention so duplicates stop coming back.

Practical tips from real projects

  • Normalise before matching.
  • Domains are the best company key.
  • Email plus name for people.
  • Merge with rules, not guesses.

A worked example: A team merged three lead sources into one table of 18,000 contacts. Profiling found 2,300 duplicate contacts, companies spelled up to five ways and 410 country variants. Normalisation, domain matching and email matching merged 1,950 duplicates automatically and flagged 350 for review. A CRM lookup found 1,100 contacts already in the CRM, which were updated instead of created. Title normalisation produced clean seniority and department fields for scoring. Duplicate outreach complaints stopped, and pipeline reports no longer double-counted accounts.

Profile the data: Count rows, empty fields, distinct values per field and obvious duplicates. Normalise fields: Apply the rules above into new normalised columns; keep originals. Match companies: Exact match on root domain; then fuzzy match on normalised name plus country for rows without domains; review low-confidence matches.

Match contacts: Exact match on email; then LinkedIn URL; then normalised name plus company domain. Decide survivors: Rules such as: keep the CRM record if it exists; keep the most recently verified email; keep rep-entered fields over enriched ones. Merge or flag: Merge automatically only for high-confidence matches; flag the rest for review.

Check against the CRM: Before pushing, look up each record; update existing records instead of creating new ones. Prevent recurrence: Normalise on entry, enforce unique keys, run a weekly duplicate report.

Normalisation rules. Domain: rule Lowercase, remove protocol, www and paths, keep root domain; example https://www.Acme.co.uk/about -> acme.co.uk. Company name: rule Trim, remove legal suffixes for matching (Ltd, Inc, GmbH), keep display version; example ACME Ltd -> acme (match key). Person name: rule Trim, proper case, separate first and last; example jOHN smith -> John Smith. Email: rule Lowercase, trim; example John.Smith@Acme.co.uk -> john.smith@acme.co.uk. Country: rule ISO standard name or code; example UK, GB, Great Britain -> United Kingdom (GB). Phone: rule E.164 format with country code; example 07700 900123 -> +447700900123. Job title: rule Keep original; add normalised role, seniority and department; example "Sr. Mgr, Growth Mktg" -> Growth marketing, Manager, Marketing. Industry: rule Map to your own short list; example "Financial technology" -> Fintech. LinkedIn URL: rule Lowercase, remove tracking parameters and trailing slashes; example Standard profile URL.

Title normalisation. C-level: includes CEO, CFO, CMO, COO, CTO, Chief. VP: includes VP, Vice President, SVP, EVP. Head or Director: includes Head of, Director, Senior Director. Manager: includes Manager, Lead, Team Lead. Individual contributor: includes Specialist, Analyst, Executive, Associate.

Match confidence. Same root domain: confidence High; action Merge companies. Same email: confidence High; action Merge contacts. Same LinkedIn URL: confidence High; action Merge contacts. Same normalised name and country, no domain: confidence Medium; action Review. Similar name only: confidence Low; action Do not merge; flag.

Fuzzy matching tips. Compare normalised names with legal suffixes and punctuation removed. Require a second matching field (country, city or phone) for fuzzy company matches. Use similarity thresholds (for example 0.9 or higher) and review anything between 0.8 and 0.9. Never fuzzy-match people on name alone; common names collide.

Merge field priority. Owner: survivor rule Existing CRM owner. Email: survivor rule Most recently verified valid email. Title: survivor rule Most recent source date. Phone: survivor rule Rep-entered over enriched. Notes and activity: survivor rule Combine; never delete history. Lifecycle stage: survivor rule Furthest stage reached.

Weekly duplicate report. List new duplicate pairs by type and source, the share of records created without a CRM lookup and the top sources of messy data. Fix the source workflow when one input keeps causing duplicates.

Using an AI agent. The agent can profile data, write normalisation formulas or Python scripts, propose title mappings, run matching with confidence scores and prepare merge lists for review. Bulk merges in the CRM happen only after a backup and a human check of samples.

Keeping originals. Always keep the original value beside each normalised field and record the source and date. When a mapping is wrong, originals make it easy to fix without re-buying data, and they show auditors exactly what changed and why. Store mapping tables, such as titles to seniority, in one shared place so every table uses the same rules. Run the duplicate report before every large CRM push and after importing any new list, and fix the source of repeated problems rather than cleaning the same issues each month.

Frequently asked questions

Normalise and match on root domain first, then review fuzzy name matches with a second field.

By email, then LinkedIn URL, then normalised name plus company domain.

Only high-confidence matches; others go to review.

Normalise on entry, enforce unique keys and check the CRM before creating records.

Changelog

  • 1.0.0, 10 October 2026: first release.

Use, adapt and share this skill under CC BY 4.0: credit Afeez Adebayo and link to this page.