Deduplicate a company lead export without treating DNS as mailbox proof

A spreadsheet can contain five contacts for one company and still look like five independent prospects. Before enrichment, decide whether the unit you want is a company or an individual. That decision determines which duplicates should disappear and which should survive into a separate contact table.

Lead List Cleaner normalizes heterogeneous lead rows and can run deduplication, email checks, domain checks and scoring. Its company-oriented deduplication prefers the normalized domain; email is the fallback when a domain is absent. Two people at one domain can therefore collapse into one lead. Keep the original export when individual contact identity matters.

Start with a bounded normalization experiment

The JSON below is adapted from the installed public example. The duplicate Shopify observation is deliberate. Selecting only dedupe and score isolates that part of the workflow: it does not request email or domain checks. The company names and websites illustrate the input shape; they are not an assertion of current contact quality.

{
  "items": [
    {
      "title": "Shopify",
      "categoryName": "Software company",
      "website": "https://www.shopify.com",
      "phone": "[phone]",
      "url": "https://www.google.com/maps/place/Shopify"
    },
    {
      "title": "Shopify Inc",
      "website": "https://shopify.com",
      "phone": "[phone]"
    },
    {
      "title": "Stripe",
      "categoryName": "Payment processor",
      "website": "https://stripe.com",
      "phone": "[phone]",
      "emails": [
        "[e-mail]"
      ]
    }
  ],
  "checks": [
    "dedupe",
    "score"
  ],
  "minScore": 0,
  "maxRows": 10
}

Preserve the raw row identifier in your own staging table before processing. A company-level key is useful for avoiding repeated research, while your source record remains the place to inspect alternative names, phone numbers and conflicting contacts. Deduplication is not a legal-entity resolution service, and a shared domain is not proof that every source row describes the same business unit.

Store check state beside the score

When the email stage runs, syntax and MX evidence support a bounded address assessment. They do not prove that a particular mailbox exists or that its owner will accept a message. A live DNS response likewise does not prove that a business is trading, suitable for your offer, or safe to contact. Keep role-address and disposable-domain flags as review evidence.

Disabled checks must remain distinguishable from completed negative checks. Otherwise, a cheap normalization pass can accidentally become a spreadsheet full of supposedly verified contacts. Give the staging table separate columns for requested checks, returned statuses, rejection reasons and the original source reference. Do not replace an unavailable status with a convenient Boolean.

Apply a cutoff only to a score that was measured

The installed classifier rejects dead email or domain statuses and rows without either contact signal. A score cutoff applies when scoring actually ran. That distinction matters when you deliberately disable scoring: a default numeric value is not an observed poor lead. The score is a workflow heuristic rather than a prediction of purchase or response.

For a small regression fixture, include two rows with the same normalized domain, one email-only row and one row containing only a company name. Check which identity survives deduplication and why the contactless row is rejected. Then change the enabled stages and verify that unchecked evidence stays unchecked. This fixture can be synthetic; running useful synthetic input through the real platform route may still incur charges.

Make the import reversible

Write cleaned leads to a staging destination before merging them into a CRM. Count accepted, rejected and duplicate rows separately, and retain the rejection explanations. If a source export contained several addresses for one company, review that information before treating the surviving row as the preferred person. A clean company queue solves repeated research; choosing the right contact remains a separate decision.

Price and verification scope

FREE-tier event prices read on 24 October 2026 are $0.005 for apify-actor-start and $0.01 for result-found. Start-event count can depend on allocated memory; other account tiers have their own rates. Check the listing's current billable unit and the platform's run spending limit before executing an example. Input row or result caps are separate from Max total charge. A free diagnostic does not necessarily remove the platform start charge.

This article is pinned to public latest build 0.3.1 (PHslDioacSvY6LxhN) at the recorded read time. Source, input and pricing were read from Apify; no new cloud build or run was started. The supplied example and any synthetic local checks do not establish current source facts, cloud delivery or customer outcomes.

Inspect the Actor's current contract and pricing.

AI-assisted writing. Source contracts and verification limits are documented above.

The installed contract gives the first 25 clean leads of each run no result-event charge; rejected and summary rows also request no result event. Preserve actual charged-event counters when reconciling a real run.