Matching is a powerful area of functionality and can be leveraged in various ways to support different needs.

The classic scenario is that of matching and merging entities (Profiles). Within the Reltio architecture, relationships that link entities can also and often does match and merge into a single relationship. This occurs automatically. Reltio matching can be used on profiles within a tenant to resolve duplicates. It is also used externally from the tenant on records in a file to identify records within that file that match to profiles within a tenant. And it is used within Reltio DTSS to match profiles stored within a Data Tenant to those within your tenant. Reltio match technology is used to suggest a relationship between two profiles rather than merging them. Reltio Match is quite versatile and ready to meet your business needs with agility and flexibility.

To understand matching in Reltio, It is important to discuss three topics - Match, Merge, and Survivorship together since they are so intimately related within the Reltio platform.

The Reltio match architecture is responsible for identifying profiles within the tenant that are considered to be semantically the same or similar. You will establish a match scheme using the match configuration framework. In it, you will create match rules. You will identify the attributes from your entity types you wish to use for matching. You will write a comparison formula within each match rule which is responsible for doing the actual work of comparing one profile to another. You will map token generator classes that will be responsible for creating match candidates. For basic match rule functionality, you can use the Match Rule Builder available within the Data Modeler of your Reltio Console. For more complex rules, you can utilize the Advanced Editor available within the Match rule modeler. You can use machine learning techniques to match profiles. For more information, see Train an ML model from scratch with Match IQ.

The Reltio merge architecture is responsible for merging two or more profiles while aggregating the crosswalks, attribute values, relationships and interactions from all the contributing profiles into the winning profile.

Unlike other systems, Reltio’s architecture is designed to operate in real-time. Prior to the match process and merge processes occurring, every profile created or updated is also cleansed on-the-fly by the profile-level cleansers. Thus the 3-step sequence of cleanse, match, merge are designed to all occur in real-time anytime a profile is created or updated.This behavior makes the Reltio platform ideal for real-time operational use within a customer’s ecosystem.

Lastly, the Reltio survivorship architecture is responsible for creating the classic “golden record”, but with Reltio it is a view, materialized on-the-fly. It is returned to any api call fetching the profile and contains a set of “Operational Values” from the profile, which are selected in real-time based on survivorship rules defined for the entity type.

IMPORTANT: A Reltio profile and a Reltio entity are subtly different, even though we tend to use the words interchangeably. An entity is a record; it has attributes (simple, nested and reference) and is treated as a node in the Reltio graph. A profile is a broader concept and refers to not only the entity of interest but all of the entities (nodes) connected directly to the entity via relationships, and all of the entity’s interaction data. So then a profile is really the 360 degree expression of an entity. We use the word profile a lot when discussing match rules because Reltio match rules easily leverage attributes from related entities via the reference attribute architecture.