A clearer view of your duplicates.

Strong candidates. Exact personal email plus exact first and last name. Probable candidates use nickname or similar-name evidence with email, phone, company, or a full street and locality. Email domains, company names, ZIP codes, and shared addresses alone do not match people.

Review flags. Shared inboxes, conflicting names or suffixes, and repeated CRM identities need investigation. Common nickname aliases are heuristic and are never proof of identity. A blank or conflicting name never receives a strong match.

Expected sync links. A Marketo record and Salesforce record with the same valid Salesforce Lead / Contact ID are listed separately. Salesforce 15- and 18-character IDs are normalized with their checksum. Account IDs are company context and never person IDs.

Recency. Each source row is counted, including linked and candidate records. A populated Last Activity Date takes precedence over Updated At / LastModifiedDate. Blank activity dates fall back to modified dates. Invalid populated activity dates are flagged rather than replaced. Dates accept YYYY-MM-DD with optional time, or US MM/DD/YYYY; future dates are separate. Date-only age uses calendar days.

Coverage and scale. Blocking narrows comparisons using email, person ID, phone, name + company, and name + street / locality. Fuzzy matching needs a common first initial and first three last-name characters within a company, so some typos are missed. Blocks over 250 rows are skipped; runs stop at 1.5 million comparisons or 100,000 evidence pairs. Any such limit is shown as partial coverage. “No candidates” is not proof that a database is clean.

Validation. Start with the included 16-row sample, then a 50,000-row export. Check known duplicate pairs and false positives against your existing identity work. Match counts depend on rules and export coverage. Email syntax is checked locally; deliverability, consent, account relationships, and live CRM status are not verified.