NovProject aliases need one identity without merging distinct phases
How project aliases can improve discovery while preserving the separate identity, history and facts of distinct phases and related entities.
This article reflects the named expert’s practical perspective. See NovAsia’s editorial policy for how material is prepared and reviewed.
A property project rarely keeps one perfectly stable public name. A developer may use a long formal title, agents may shorten it, an older brochure may use a previous spelling, and buyers may search for whatever version they remember. Treating those variants as unrelated records creates noise. Treating every similar-looking name as the same record creates a more serious problem.
The useful product goal is narrower: aliases should help a buyer reach the same underlying project when the underlying project really is the same. They should not erase the boundaries between phases, towers or other parts that have their own facts. A search convenience should never become a reason to mix two sets of property information.
An alias answers “what else is this called?”
Imagine a hypothetical project called Harbor Residence. Older material refers to it simply as Harbor, while newer pages use Harbor Residence Phnom Penh. If both names point to exactly the same project identity, the site should not force the buyer to choose between duplicate records. Search, saved links and references can all recognise the aliases and resolve them to one project.
That is a straightforward case because the alias changes the wording, not the thing being described.
Now add Harbor Residence Phase 2. The shared brand is meaningful, but it does not prove that every fact is shared. The second phase may have a different completion state, a different set of available homes, its own documents or a different relationship to the common facilities. Even if some imagery and marketing language overlap, a buyer may need to know which phase contains the actual property being considered.
If the system resolves all three names into one undifferentiated record, the interface can remain visually convincing while the meaning deteriorates. A status from one phase may appear beside another. A saved property can return under a broader label and lose its original context. A review, image or update date can look as though it applies to the whole development when it only described one part.
Related entities are not duplicate entities
This is where I would separate identity from relationship. Two phases can belong to one development family without becoming the same entity. A product can express both truths at once: these records are related, and these records must retain separate histories.
That distinction matters because deduplication is usually described as a cleanup task. In practice, aggressive deduplication can destroy information just as easily as weak deduplication can create clutter. The question is not “how many records can we merge?” It is “what real-world thing does each record represent, and which names are only alternate ways of referring to that thing?”
There should also be room for uncertainty. If a newly imported name looks similar to an existing project but the relationship is not established, leaving it unresolved is better than silently merging it. A temporary duplicate is visible and repairable. A mistaken merge can spread mixed data into search, comparison, saved lists and downstream pages before anyone notices.
The buyer should experience continuity, not the identity machinery
A buyer does not need to see internal identifiers or an entity-resolution diagram. They need three simpler things. First, the name they know should find the right project. Second, meaningful sub-entities such as phases should remain distinguishable. Third, changes in naming should not cause their saved context to disappear.
A good test is therefore behavioural. Search using an old alias: does it reach the current project? Save a property in Phase 1 and then update the project’s display name: does the saved item remain attached to Phase 1? Compare two homes from different phases: are the phase differences still visible? Change a label in one record: do images, dates or statuses leak into its sibling record?
The opposite failure is fragmentation. If the same project is represented by separate technical copies for different languages, sources or historical spellings, the buyer may see several partial versions. One page has the status, another has the correct name, a third appears in search. That is not safer than over-merging; it is simply a different form of broken identity.
The product should therefore keep one durable identity where reality is one, and distinct identities where reality is distinct. Aliases are a navigation layer over that model, not a substitute for it.
The best outcome is almost invisible. A buyer can type the name they remember, arrive at the correct project, understand which phase a property belongs to and continue from an old saved link without noticing the technical work underneath. That is what I want from identity handling: the platform absorbs naming variation while preserving the distinctions that still belong to the buyer’s decision.