MatchingSettings Property Usage
EngineSettings.MatchingRules.*Level.Constraints…
There are different copies of each of the properties below; one for each of the different matching levels (Business, Family, Household and Individual). For Example, Settings.MatchingRules.IndividualLevel.Constraints.MustMatchGender would be set differently to Settings.MatchingRules.FamilyLevel.Constraints.MustMatchGender.
MustMatchGender
When this property is set to True, potential matches will be disregarded if their genders differ. If however the gender is unknown in one or both of the records, the records will potentially be classed as a match.
MustMatchLocation
When this property is set to True, potential matches will be disregarded if their address locations differ. In detail, this means that the postcodes in the two records (if present) must achieve at least a probable match with the address score at least a Possible match, or the address score must be at least a Likely match irrespective of the postcodes, or the postcodes must achieve a Sure match irrespective of the address. This is to prevent false matches where there is some match on address, but where the addresses are clearly not the same, for example "10 High Street, Bookham", and "10 High Street, Alford". Switch this constraint off if you want to match people or companies in different locations; you may want to match on items of data that are independent of location, such as date of birth or bank account. See also the topic "What matching weights should I use for my data?" in the matchIT API Frequently Asked Questions.
MustMatchPremise
When this property is set to True, potential matches will be disregarded if their premise numbers differ. If however the premise number is unknown (e.g. one record or both records may contain a premise name), the records will potentially be classed as a match.
NoOneEmptyPremise
When this property is set to True, potential matches will be disregarded if one of the addresses is missing a premise and/or flat number.
AllowFuzzyPremiseMatch
When both this and MustMatchPremise are set to True, then potential matches will be disregarded if the premises are not exact matches (for example, 71 and 71) or if they’re not fuzzy matches (for example 71 and 71A, 45 and 54, or 71 and 7). Note that this property has no effect if MustMatchPremise is set to False because, in that case, fuzzy premises are always allowed.
MustMatchSuffix
When this property is set to True, potential matches will be disregarded if their suffixes differ. If however the suffix is unknown in one or both of the records, the records will potentially be classed as a match.
MustMatchDirectional
When this property is set to True, potential matches will be disregarded if both addresses (i.e. typically US) have a pre- or post-directional (e.g. N, North, E, etc.) but they don’t match. For example, with this constraint enabled, “N Washington Ave” and “S Washington Ave” will not be matched.
MustMatchNumericStreetName
When this property is set to True, potential matches will be disregarded if both addresses (i.e. typically US) have a numeric street name but they don’t match. For example, with this constraint enabled, “5th Ave” and “15th Ave” will not be matched.
MustMatchJointNames
When this property is set to True, potential matches will be disregarded if one record has a joint name but the other doesn’t. For example, normal behaviour will match “Mr & Mrs J Smith” with “Mr J Smith”; setting this property to True will prevent such matches.
MustMatchBuilding
When this property is set to True, potential matches will be disregarded if their building names differ. If however one or both addresses do not contain a building name, the records will potentially be classed as a match.
NoOneEmptyBuilding
When this property is set to True, potential matches will be disregarded if one of the addresses is missing a building name.
EngineSettings.MatchingRules.*Level.Weights.#...
Where * is one of Individual, Family, Household, Business, or Custom and # is one of Name, Organization, Address, Postcode, Telephone, Email, or DateOfBirth.
For each of the four following methods/properties, there is a different copy of the method/property for each of the five different matching levels.
SetMatrixWeights( )
Regenerates the current name or organization matching matrix using the supplied sure, likely, and possible weight values.
SetWeights( )
Sets the sure, likely, and possible weights that are used to score compared items (NB: not names and organizations, use SetMatrixWeights( ) instead).
Sure specifies the maximum score to be returned when the two compared items match. If they’re not identical, but similar, then either likely or possible will be scored depending on the field being compared and the data being compared.
BothEmptyScore
This property specifies the score to be returned when both compared items are empty.
OneEmptyScore
This property specifies the score to be returned when one of the two compared items are empty.
EngineSettings.MatchingRules.*Level.Thresholds.#
Where * is one of Individual, Family, Household, Business, or Custom and # is one of Name, Organization, Address, Postcode, Telephone, Email, or DateOfBirth.
Thresholds are applied in this order, to prevent two records from matching when the cumulative total score fails to reach any threshold (all default to 0).
For example, suppose the postcode threshold is set at 100, the weights for name, address, and postcode are set at 60, 30, and 35 respectively, and that the three components are each scoring Sure. The name threshold (0) will be checked with a cumulative score of 60, the address threshold (0) will be checked with a cumulative score of 90, and the postcode threshold (100) will be checked with a cumulative score of 125. All three thresholds are reached. However, should the names score 25 (Possible), then the cumulative score will be 25, 55, and 90 at the same three points; the postcode threshold (100) will therefore not be reached, thus the two records will score 0.