playbooks

home / skills / gtmagents / gtm-agents / identity-resolution

identity-resolution skill

/plugins/data-signal-enrichment/skills/identity-resolution

This skill helps unify accounts, contacts, and opportunities across sources using governed rules to improve data quality and downstream matching.

npx playbooks add skill gtmagents/gtm-agents --skill identity-resolution

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
1.3 KB
---
name: identity-resolution
description: Use to match accounts, contacts, and opportunities across enrichment
  sources with governed rules.
---

# Identity Resolution Playbook Skill

## When to Use
- Normalizing provider outputs before syncing to CRM/CDP.
- Tying intent, enrichment, and product telemetry to the same account/contact IDs.
- Diagnosing duplicate or conflicting records in downstream systems.

## Framework
1. **Key Hierarchy** – define primary/secondary keys (domain, account_id, email, person_id).
2. **Matching Logic** – configure deterministic and fuzzy rules, tie-breakers, and confidence scoring.
3. **Conflict Handling** – specify precedence rules, merge policies, and exception queues.
4. **Governance** – document owners, change control, and monitoring cadence.
5. **Audit Trail** – capture lineage metadata, before/after snapshots, and rollback steps.

## Templates
- Matching rule matrix (field, rule type, weight, confidence threshold).
- Exception queue workflow with owners + SLAs.
- Audit workbook for sampling matches vs source-of-truth.

## Tips
- Start with deterministic keys (domain, CRM ID) before fuzzy logic to reduce noise.
- Version rules so downstream teams know when behavior changes.
- Pair with `signal-taxonomy` to keep IDs aligned with schema updates.

---

Overview

This skill performs identity resolution to match accounts, contacts, and opportunities across enrichment sources using governed rules. It centralizes matching logic, conflict handling, and audit trails so teams can unify records before syncing to CRMs or CDPs. The goal is consistent IDs, higher-confidence merges, and traceable changes across sales and revenue workflows.

How this skill works

Define a key hierarchy (primary and secondary identifiers such as domain, account_id, email, person_id) and apply configured deterministic and fuzzy matching rules with weights and confidence thresholds. The skill evaluates candidate matches, applies tie-breakers and precedence rules, and assigns confidence scores. Conflicts are routed to exception queues per SLA and all decisions capture lineage metadata for audit and rollback.

When to use it

  • Normalize provider enrichment outputs before loading into CRM or CDP.
  • Unify intent signals, enrichment, and product telemetry to the same account/contact IDs.
  • Diagnose and resolve duplicate or conflicting records in downstream systems.
  • Establish a governed merge process during source-of-truth migrations.
  • Validate matching behavior after rule or schema changes.

Best practices

  • Start with deterministic keys (CRM ID, domain) before introducing fuzzy matches to reduce false positives.
  • Version matching rules and publish change notes so downstream teams can adapt.
  • Define clear precedence and merge policies to automate safe merges and minimize human review.
  • Implement an exception queue with owners, SLAs, and a triage workflow for edge cases.
  • Capture before/after snapshots and lineage metadata to enable audits and rollbacks.

Example use cases

  • Merge enrichment records from multiple vendors into a single account record for pipeline reporting.
  • Link product telemetry and intent signals to CRM accounts for targeted sales outreach.
  • Automate duplicate detection and merging with manual review for low-confidence matches.
  • Create an audit workbook to sample matches against a source-of-truth during rule changes.

FAQ

What identifiers should I prioritize?

Prioritize deterministic identifiers like CRM account_id and domain first, then email and person_id; use fuzzy matching only after deterministic checks.

How do I handle low-confidence matches?

Route low-confidence matches to an exception queue with owners and SLAs for manual review, and log decisions to improve rules over time.