From our matching pipeline

How to deduplicate listings without merging different homes.

The same home can appear with different prices, descriptions, coordinates, and agents. Two different units can share the same address, layout, images, and marketing copy. That is why our pipeline separates candidate generation from the final match decision.

How our matching works

Our four-stage deduplication pipeline.

01

Source offers

Portal A · Portal B · Agency feed

02

Normalized candidates

Address · location · facts · media

03

Evidence decision

Match · review · keep separate

04

Canonical property

One asset · every offer retained

01

Compare like with like before scoring anything

We normalize URLs, address tokens, coordinate precision, phone numbers, currencies, typed areas, bedroom counts, and property categories before asking whether two records match. We retain both the original input and the applied rule so the comparison can be reproduced later.

Missing values never become convenient defaults. A missing unit number is not unit zero; an unspecified furnishing state is not unfurnished; a building centroid is not an apartment coordinate. Defaults create artificial agreement and push weak candidates over the merge threshold.

02

Generate a small, plausible candidate set first

We build candidate blocks from geography, address tokens, development name, category, and compatible area or bedroom bands. This is not only a performance optimization. It stops unrelated records from accumulating enough weak similarities to look like a match.

Candidate rules vary by inventory shape. A detached house can tolerate a wider coordinate band than a tower with hundreds of nearly identical units. Dense developments need unit, floor, or other unit-level evidence before automation is safe.

03

Score evidence, then keep an explicit review band

Our score can combine address agreement, coordinate distance, area tolerance, bedroom and floor compatibility, contact overlap, description fingerprints, and media similarity. The weights belong to a market and source pair because coordinate quality, address structure, and content reuse differ materially between portals.

We use three outcomes: automatic match, review, and keep separate. Thresholds should be calibrated on labeled examples and inspected by error type; a global accuracy number can hide a damaging pocket of false merges in one city or source pair.

04

Audit the errors the aggregate score hides

Track precision, recall, false merges, missed duplicates, cluster size, review rate, and the share of matches supported by more than one independent signal. Break every measure down by market, source pair, property type, and confidence band.

Re-run the labeled set after a source redesign, parser change, geocoder change, or schema migration. Those changes can shift the evidence distribution while the matching code—and its headline score—stays exactly the same.

  • Inspect false merges separately from missed duplicates.
  • Watch unexpected cluster growth and cluster churn.
  • Recalibrate per market and source pair.
  • Treat parser and source redesigns as matching-model changes.

Evidence matrix

Where each signal helps—and where it can mislead.

SignalUseful whenWatch for
Address + unitStructured and completeFormatting gaps; missing units
CoordinatesPrecision is source-qualityRounded pins; building centroids
Property factsArea, floor and beds agreeSimilar units in one development
DescriptionCombined with stronger evidenceShared agency and project copy
MediaImages are property-specificStock renders; reused photography

Evaluation dashboard

The four measures we inspect before accepting matches.

01

Precision

How many proposed matches are truly the same property

02

Recall

How many real duplicates the system successfully finds

03

False merges

Distinct properties incorrectly collapsed together

04

Cluster shape

Unexpectedly large or unstable property groups