EngineSettings.Compare…
The following settings are used when the matchIT API compares two records:
EngineSettings.Compare.Address.DefaultThoroughfareLine
(See Settings.Generate.Address.DefaultThoroughfareLine, above.)
EngineSettings.Compare.Address.LooseFuzzyPremiseMatch
When enabled, this will cause two premises to match if one premise starts with the other but contains extra trailing characters (for example, 88 and 88/2 will match, but 88 and 887 will not match).
EngineSettings.Compare.Address.MatchBoxNumberAndPostcode
If this setting is enabled, then two compared addresses score Sure if they contain matching postal box numbers and postcodes (i.e. the remainder of the addresses are ignored).
EngineSettings.Compare.Address.MatchDeliveryPoints
When enabled, this will prevent two addresses from matching when both contain two postal codes but different delivery point codes (for example, DPS codes in the UK, DPV codes in the US) and the addresses score below the minimum threshold.
If either record is missing a delivery point, or either is a default, then the addresses will match regardless.
EngineSettings.Compare.Address.MatchDeliveryPointsThreshold
(See Settings.Compare.Address.MatchDeliveryPoints, above.)
EngineSettings.Compare.Address.DefaultDeliveryPoints
(See Settings.Compare.Address.MatchDeliveryPoints, above.)
EngineSettings.Compare.Address.IgnorePremiseSuffix
When enabled, this will cause two premises to be matched regardless of whether one or both has an apartment- or flat-type suffix (for example, 12 and 12a). Normally, such premises will cause the address score to be reduced because the addresses are considered different, which could prevent the two records being flagged as a match.
EngineSettings.Compare.Address.UsePremiseRange
When this setting is enabled, this will allow addresses to contain premise ranges. For example, if one record contains an address line of “11-15 Main Street” and the other “13 Main Street”, then the premises are considered a match with this setting enabled; otherwise, the premises will not be matched and, depending on constraints and weights, the addresses might not score a high enough score to be considered matching records.
EngineSettings.Compare.Name.FuzzyMatchNonNormalizedNames
When enabled (the default), this will cause additional matching checks to be performed on names using the non-normalized name matching fields. This can be useful when Settings.Generate.Name.UseEquivalentNames is enabled, which will allow Elizabeth and Lisa to match, but will not allow for some misspellings and typos such as Lsia to match.
EngineSettings.Compare.Name.OrganizationMatchingOnBlankNames
When two records contain no addressee names, this setting will allow the names to achieve a score depending on what’s available in the job title and company name fields. For example, if the two records contain job titles of Managing Director and company name of 360Science, then a positive name score will be given even though the records don’t contain an addressee.
0 - Off
1 - On if either name blank
2 - On when both names are blank
EngineSettings.Compare.Name.PreventMrsMatchingMiss
If this setting is enabled, then two compared names will not match if one has a title of Mrs and the other a title of Miss. For example, “Mrs J Smith” will not match “Miss J Smith” with the setting enabled (the default).
EngineSettings.Compare.Phonetic.Algorithm
There are two stages to the matching process that the matchIT API uses; the key stage and the scoring stage. The first stage creates standardized and phonetic keys based on the input data, which allows potential matches to be identified. The second stage scores each pair of potential matches, using phonetic and fuzzy matching. This property governs the phonetic algorithm that the API uses when scoring.
There are four choices available:
soundIT, loose soundIT, dynamic soundIT, and Soundex.
Read more about the algorithm's here: