Separate people, inquiries and events
A duplicate conversion is a repeated count of what the measurement definition intends to treat as one event or outcome. A duplicate contact is a different problem. One person can make several legitimate inquiries, and one inquiry can create several legitimate activities.
Write down the units before merging anything. A customer requesting two separate projects should not lose the second opportunity because their email address matches. At the same time, refreshing a confirmation page should not create a second sale.
One person
The customer identity.
One opportunity
A distinct commercial request.
Several events
Calls, submissions and stage updates.
One count rule
The event or outcome your report measures.
Deduplication depends on what you are counting. Several events can legitimately describe one opportunity.
Identify where duplication enters
| Boundary | Possible duplicate | Check |
|---|---|---|
| Form interaction | Repeated click or refresh | Whether an event represents confirmed intake or only a UI action |
| Delivery | Retry of the same accepted request | Stable request identity and duplicate-safe handling |
| CRM matching | A new contact created for an existing person | Matching rules and ambiguous cases |
| Sales stages | A milestone emitted more than once | Event identity and stage-change history |
| Reporting | Several platform claims for one sale | Distinct outcome count separate from attribution claims |
A repeated provider request and a second genuine customer inquiry require different handling. A blanket “remove matching emails” rule can damage the sales history while failing to address duplicate event delivery.
Resolve duplicates without erasing the useful history
A prospect can submit a form and then call about the same request. Those are two interactions, but they may belong to one opportunity. Another form from the same person months later may represent a genuinely new project. An email address alone is therefore not a complete opportunity-deduplication rule.
Begin by naming the object the report counts. Use stable source identifiers for delivery retries and event records where available. Link related interactions to a person and opportunity, preserving their original timestamps and source context. Merge only when the evidence and the written business rule support it.
When you correct a duplicate, retain an explanation of the change so a later review can understand why totals moved. Test both directions: repeated delivery must not create new outcomes, while a real second project must not disappear. If the evidence is ambiguous, flag it for review instead of silently choosing the result that improves the dashboard.
Test these four cases
- The same form delivery is retried with the same source identifier.
- A form and a phone call refer to the same open project.
- An existing customer starts a separate project.
- Two people share contact information or submit on behalf of the same organization.
Preserve history while fixing the counting rule
Keep the activities that explain what happened. A person may submit a form and call later because they have not received a response. The call is valuable workflow evidence even when the report counts one acquired inquiry.
For an illustrative project, record one inquiry, two calls, one quote and one confirmed booking. A report can show those activity counts separately. It should not add them together and call the total five leads.
Test repeated and uncertain delivery
- Define the stable identity of each counted event.
- Send the same controlled event twice and check the intended result.
- Simulate a retry after an uncertain response using the supported test method.
- Check a genuine new inquiry from the same person.
- Verify that corrected or cancelled outcomes follow their own documented rules.
The test must cover both false duplicates and missed duplicates. A rule that prevents all repeated records can still be wrong if it blocks legitimate repeat business. Keep uncertain matches visible for review rather than applying an irreversible merge by guesswork.
Reconcile the reporting impact
After a repair, document the effective date and whether historical reports were restated. A sudden drop in conversion count may reflect corrected counting rather than a decline in demand. Compare genuine inquiries and later outcomes to understand the business effect.
Growth Control scopes duplicate handling across intake, CRM and the supported measurement path. The goal is a reliable definition and a process that preserves customer context, not simply a smaller number in one dashboard.
Questions and answers
Should identical emails always merge?
Not automatically. The same person may have multiple legitimate inquiries or projects. Matching contacts and counting inquiries are separate decisions.
Is a retry always a duplicate?
A retry may repeat an already accepted event or complete a previously failed delivery. Stable event identity and verified handling are needed to distinguish the result.
Can platform totals exceed actual sales?
Yes, separate platforms can claim the same sale, and event-counting rules can also differ. Review distinct business outcomes separately.
Should we rewrite historical numbers?
Only with a documented method and a clear note about the change. Preserve enough information to explain why the report differs from an earlier version.
Sources and further reading
Put the process into practice
Growth Control implements the tools, workflow and team handoff around an agreed business result.
Explore cRM and marketing automation built around your sales process