“Duplicate control is both a buyer-experience and measurement problem. Establish a stable identity, distinguish a new enquiry from a new event, and prevent parallel systems counting one action twice.
Diagnose the failure
The same person may submit twice after an error, use two channels, or be tracked through browser and server. Counting every record as a fresh opportunity inflates volume, burdens sales, and weakens source comparison. A duplicate may still be a useful new interaction, so deleting history is not the policy.
Use a decision framework
Separate contact identity, enquiry instance, and tracking event. Use a CRM matching rule with a review queue, and a unique event ID when browser and server describe one action. Meta says redundant Pixel and Conversions API setups need deduplication so overlapping events are distinguished. Keep a human exception path.
A hypothetical real estate example
Implement and measure
Document matching fields, retention rules, and manual exceptions; test known duplicates before launch. Report unique contacts, enquiries, and conversion events separately, with deduplication and unresolved-match rates. Investigate sudden changes after integration releases rather than attributing them automatically to demand. The operating goal is not zero repeats; it is an honest distinction between a repeated action and a genuinely new request. The metric should expose system behaviour, not punish a buyer for trying again. Review the rule after integration changes and keep the distinction visible to sales and analytics.
Put it to work
- Choose stable identity and event-ID fields.
- Test browser-and-server overlap with known records.
- Report unique contacts separately from interactions.
Sources and visual credits
Illustrative photograph: Computer keyboard placed on a black desk in a modern workspace. It does not depict the hypothetical example. Shixart1985 · CC BY 2.0 · Wikimedia Commons · CC BY 2.0