What is a duplicate quiz lead?
A duplicate quiz lead is not one universal record. It may be a repeated browser event, a retried webhook, two contact records for one person, two valid completions by the same person, or one completion that creates multiple assignments or messages. Each layer needs its own identity key and resolution rule.
Deduplication removes unintended repetition. It must not erase a later valid completion, overwrite a supplied answer with an inference, or silently merge people who share a mailbox or device.
Related: Define the CRM handoff contract · Trace questions to stored outcomes
Define four identities
Keep the keys visible in logs and records so a reviewer can trace a duplicate report back to the exact completion and action rule.
| Entity | Recommended identity | Do not use alone | Reason |
|---|---|---|---|
| Person/contact | Approved normalized identifier plus source | Browser cookie or name | Shared and unstable values collide |
| Completion | Generated immutable completion ID | Email address | One person may complete more than once |
| Event | Completion ID + event name + version | Timestamp | Retries can have new timestamps |
| Action | Completion ID + purpose + destination + version | Provider response ID | A response may be missing after acceptance |
Normalize conservatively
Trim surrounding whitespace and apply only transformations supported by the identity policy. Email-domain casing is generally safe to normalize, but provider-specific tricks such as removing dots or plus tags can merge distinct addresses. Phone normalization needs country context. Do not fingerprint people by combining extra fields merely to improve matching.
The ICO data-minimisation principle says personal information should be adequate, relevant, and limited to what is necessary. Document the purpose, access, retention, deletion, and correction behavior for every identity field. The ICO notes that this guidance is under review following the Data (Use and Access) Act, so recheck it before relying on the details.
Sources: ICO, Data minimisation principle
Choose merge and append rules
Update a contact only after a rule decides that the incoming record is the same person. Append every valid completion as a separate child record, preserving supplied answers, rule version, result, permission state, and event time.
| Situation | Person rule | Completion rule | Downstream action |
|---|---|---|---|
| Same completion retried | Resolve existing contact | Reuse completion ID | Reuse action keys |
| Same person completes later | Update approved contact fields | Append new completion | Create actions for the new completion |
| Shared address, different person | Escalate or keep separate | Keep separate | Do not auto-merge identity |
| Address corrected before finish | Update pending record with audit | One final completion | Send once to the corrected recipient |
| Address corrected after finish | Preserve evidence and add correction | Keep original completion | Audited resend if approved |
Make every downstream write idempotent
Before a CRM upsert, assignment, analytics event, or email, calculate an action key from the completion ID, purpose, destination, and relevant version. Store that key before or atomically with the request when the architecture permits. A retry must look up the key and continue from its existing state.
Do not equate a timeout with failure. A receiver may accept a request even when the caller never receives the response. Reconcile the prior request by action key or receiver lookup before creating anything new.
Run the duplicate injection matrix
Use synthetic records to test repetition, concurrency, correction, and legitimate repeat journeys before release.
| Test | Injection | Expected result | Blocking failure |
|---|---|---|---|
| Double click | Submit twice rapidly | One completion | Two IDs or actions |
| Reload | Refresh confirmation | Existing completion shown | New lead created |
| Webhook retry | Deliver one payload twice | One event and action | Duplicate assignment |
| Timeout after accept | Drop local response | Reconcile existing action | Blind resend |
| Concurrent workers | Process one event in parallel | One winning write | Race creates duplicates |
| Later valid completion | Repeat after a change | New completion under approved identity | History overwritten |
| Shared address | Two disclosed people use one inbox | Policy-specific review | Silent merge |
| Deletion request | Remove governed data | Aliases and merged records handled | Hidden copy remains |
Keep analytics denominator-safe
Track raw received events, accepted unique events, completions, unique people under the approved rule, and downstream actions separately. A deduplication rate needs both raw and accepted counts.
Google Analytics recommends lead-generation events such as generate_lead and qualify_lead, but names do not solve identity or retry behavior. Document when each event is emitted and how repeated emissions are rejected.
Related: Use the full quiz-funnel measurement model
Sources: Google Analytics, Recommended events
Worked example: preserve a real repeat journey
A participant double-clicks submit. Two requests carry the same client completion token. The first creates completion C-9021 and actions C-9021:crm-upsert:v2 and C-9021:result-email:v1. The second resolves to C-9021 and returns the existing state. Three weeks later, the same approved contact completes an updated quiz and receives C-9470, preserving both result histories.
This is a synthetic systems example, not a product test or performance benchmark.
Release checklist
Block release until identity, retry, correction, and deletion behavior are reproducible.
- Person, completion, event, and action identities are documented separately.
- Normalization avoids provider-specific or unverified assumptions.
- Legitimate repeat completions append instead of overwrite.
- Every downstream write has a deterministic action key.
- Double-click, reload, retry, timeout, and concurrent tests pass.
- Shared identifiers and correction cases have an explicit human-safe rule.
- Raw, accepted, duplicate, and action counts remain auditable.
- Retention, deletion, access, and correction cover aliases and merged records.
Sources: W3C, Validating input
Evidence
How to reproduce the method
The reproducible evidence object is a four-identity contract, merge-versus-append decision table, and eight-case duplicate-injection matrix. It can be run with synthetic records and no vendor account.
Limitation
Where this conclusion stops
This method reduces unintended repetition; it cannot prove that two records represent the same human, prevent every malicious submission, or define a lawful identity policy. Identity, retention, and deletion rules require context-specific privacy and legal review. No product performance or conversion claim is made.
Sources and verification
What this guide relies on
- The Lead Quiz Review editorial methodology
- Google Analytics, Recommended events
- ICO, Data minimisation principle
- W3C, Validating input
Sources and method checked September 25, 2026. External standards are linked to their primary publishers. Request a factual correction.