Fixing Duplicate Contacts and Broken Attribution in GoHighLevel

The short answer

Duplicate contacts are an identity-design problem, not a cleanup task. Define matching, update, source, and opportunity rules before merging records.

What the failure looks like

One person appears under several email or phone variations, opportunities duplicate after repeat forms, conversations split across records, and source fields change after later engagement. Reports then count contacts, opportunities, and revenue inconsistently.

Diagnose before changing anything

Select several affected records and trace them from the original event through every system, workflow, owner, and report. Record timestamps and identifiers. A global fix based on one screenshot can hide the true boundary and create a second failure.

• Measure duplicates by phone, normalized email, and external ID
• Identify which sources create versus update records
• Trace original and latest source fields separately
• Review opportunity creation on repeat conversion
• Inspect integrations for formatting and race conditions
• Sample merged records for lost consent or activity history

The most likely root cause

Multiple systems apply different identity rules. One source normalizes phone numbers, another omits country codes, and another uses email as the only key. Workflows then create opportunities on every event without checking the existing sales motion. Attribution fields are reused for both first touch and latest touch.

Design the repaired system

Choose canonical identity fields and preserve external system IDs. Store first-touch, lead-creation, latest-touch, and opportunity source separately. Define when a repeat conversion updates an existing opportunity, creates a new opportunity, or starts a new pipeline. Merging should preserve the most complete consent and activity record.

Implementation sequence

Make the smallest change that produces a testable improvement. Use synthetic records first, then a controlled production sample. Document the original and final behavior so future administrators can distinguish design from accident.

• Profile duplicate patterns before merging
• Normalize phone and email inputs
• Define create-versus-update contracts per source
• Separate attribution fields by meaning
• Add opportunity existence and lifecycle checks
• Merge a controlled sample and validate history
• Backfill reports only after rules stabilize

Measure whether the repair worked

Track duplicate-contact rate, duplicate-opportunity rate, unknown source rate, overwritten original-source rate, merge exceptions, and revenue reconciliation. Report definitions should state whether they count people, opportunities, or transactions.

Failure modes to prevent

Avoid bulk merges without backups, deleting consent evidence, assigning one person’s activity to another, collapsing legitimate shared phone or email records, and retriggering nurture during cleanup.

Operational handover

Assign an owner, alert path, review cadence, and rollback instruction. The repair is complete only when the operating team can detect recurrence without waiting for a customer complaint or a month-end report.