Profile matching is used with integrated systems sending profile data to OPERA Cloud ; ensuring existing OPERA Cloud profiles are matched to prevent the creation of duplicate profiles.
In order to match profiles you configure profile matching rules.
Note:
If OPERA Cloud and the external system share their internal profile numbers and always have an ideal match, you can select not to enable profile matching for the interface.Internal Entry Match Criteria
The OXI Profile Matching module has an internal entry criteria matching system that checks for a primary match based on hard-coded, predefined columns in the name table and its child tables. These entry criteria are not configurable and not visible. For example in OPERA Cloud there is a guest profile with client id 1234. and the external system is sending a company profile type with client id 1234. This will not find the match due to internal merge criteria client id and name type, which is similar to configuring merge rule on "name code". This is the base rule for every following weighing point matching activity. If the entry criteria match fails, no further weighing point match is attempted and the profile is either created newly or rejected based on Interface Controls settings for this interface ID in OXI. Note: This process also applies to an accompanying profile (as well as the primary guest profile). When a reservation change occurs, when only the first and last names of a profile for either a primary or accompanying profile associated with the reservation are sent with the reservation, duplicate profiles are not created. The Profile Match process is not included. Instead, OXI will update the profiles according to the internal name_ID of the profile in OPERA Cloud that is linked to the reservation, without applying any further matches (based on the profile's same first and last name).
Table 25-1 Guest / Contact Profile Types
| Message Displayed to the User | Internal Matching Criteria |
|---|---|
|
Matched on Name Code |
Matches on Client ID and Name Type |
|
Matched on Membership Number |
Matches on the Membership Number |
|
Matched on Credit Card and Name |
Matches on the Credit Card Number and the Last Name Note: When the Credit Card Vault functionality is active, credit card numbers are replaced with a Unique ID which will be communicated between OPERA Cloud and OXI. |
|
Matched on Passport Number |
Matches on the Passport Number Note: Id type role should be PASSPORT |
|
Matched on Email |
Matches on Communication Type Email. Note: This match will be made even when an email type other than EMAIL is used. |
|
Matched on Last and Phone |
Matches on the Last Name, Phone Number (stripped of all non-numeric characters), Phone Type |
|
*Matched On Last, Address1, City |
Matches on Last Name, Address line 1, and City |
|
*Matched On Last and Address1 |
Matches on Last Name and Address line 1 |
|
*Matched On Last and Postal Code |
Matches on Last Name and Postal Code |
|
*Matched On Last and City |
Matches on Last Name and City |
Table 25-2 Travel Agent / Company / Source / Group Profile Types
| Message Displayed to the User | Internal Matching Criteria |
|---|---|
|
Matched on Name Code |
Matches on Client ID (Name Code) and Name Type |
|
Matched on Credit Card and Name |
Matches on the Credit Card Number and the Last Name |
|
Matched on Company and Phone |
Matches on the Company Name and the Phone Number (stripped of all non- numeric characters), Phone Type |
|
*Matched on Company, AR number |
Matches on Company Name and AR number |
|
*Matched on Company and Address1 |
Matches on Company Name and Address line 1 |
|
*Matched on Company, Postal Code |
Matches on Company Name and Postal Code. |
|
*Matched on Company, City |
Matches on Company Name and City |
Note:
The internal Interface Controls (hidden in normal Interface Controls table) DATABASE_SIZE has a default value of Large. For a large property, only match criteria without the asterisk will be used for internal entry match. If the Interface Controls DATABASE_SIZE is set to Small, for smaller properties that can afford a more accurate match without adding performance overhead, all match criteria including the ones with asterisk * will be evaluated. Contact profiles will also go through Match and Merge rules. No additional setup is required in OXI for Profile Merge rules.Examples of Entry Match Criteria
When a profile is sent to OPERA Cloud through OXI it will search the internal entry match criteria based on the above-mentioned hard coded requirements. When a profile does not meet any of these entry match criteria, it will automatically be created newly if the Interface Controls PROF_CREATION is turned ON. If that Interface Controls is turned off, the profile match will fail and the profile will not be created.
Entry Match Criteria NOT successful:
Example: If a profile is sent with only a first name and last name, it will not even proceed to the weighing points match criteria, as the first name and last name are not sufficient for the entry match criteria. A new profile will be created if the Interface Controls PROF_CREATION is turned ON. If that Interface Controls is turned OFF, the profile match will fail and the profile will not be created. An exception to the rule: We are preventing the duplication of profiles in case only last/first name are sent for a reservation change. OXI skips the profile match entirely in this case. It searches for the name_ID (internal ID number) of the profile in OPERA Cloud that is linked to the reservation sent, and if that profile has the same last and first name as the profile sent as part of the reservation change, OXI will update the same profile without applying any further matches.
Entry Match Criteria successful:
Example: If a profile comes with a last name and a membership number, it will pass the entry match criteria and proceed on to the weighing points match criteria. From here, the weighing points configured in the OXI profile matching module decide whether the profile will be merged with an existing OPERA Cloud profile or not.
Definable Weighing Points Match Criteria
Once the internal entry match was successful, the system will continue matching on the defined weighing points. The configuration of merge rules and weighing points can be done individually for each interface ID/OPERA Cloud property combination in OXI. Each profile type can be configured separately within an interface ID/OPERA Cloud property combination. You have to consider the best possible approach for distributing weighing points to the merge rules, as these may differ by profile type, geographical location of the property, data accuracy sent by external system, etc. All merge rules selected must add up to, or be above the threshold set. This means if the threshold is set to 1000 points, weighing points must be distributed to merge rules of columns or column combinations to add up to at least 1000 points in total. Otherwise no successful profile match will be made.
Table 25-3 Available fields for setting up Merge Rules
| Merge Attribute | OPERA Cloud Field |
|---|---|
|
ADDRESS1 |
Address1 within Address |
|
TELEPHONE |
Telephone number |
|
CITY |
City within address |
|
COMPANY |
Company Name related to account profile type |
|
COUNTRY |
Country field within address |
|
|
Email address |
|
FIRST |
First Name of Guest or Contact Profile |
|
LAST |
Last Name of Guest or Contact Profile |
|
MEMBERSHIPS |
Membership Number on a profile |
|
NAME_CODE |
Client ID of a profile (IATA Code / CORP id for Account Profile) |
|
PASSPORT_NO |
Passport Number |
|
POSTAL_CODE |
Postal Code within address |
|
STATE |
State within address |
|
AR_NUMBER |
Accounts Receivable Number on profile |
Fields
Profile Type. The profile type for which merge rules and weighing points are configured. Options are guest, company, travel agent, source, and group.
Merge Rule. The 'Threshold' is the initial merge rule that is set automatically when a new interface is being configured. The 'Match' merge rules need to be set manually by you, and can consist of either one data field or a combination of data fields that need to be met to obtain your defined weighing points.
Type. OXI will automatically prompt 'Threshold' first in case no entries have been made into the profile matching setup yet. Once the threshold is set, all other types will become 'Match' as they apply to the merge rules.
Points. Weighing points for the threshold will be the minimum points a profile has to achieve in order to be matched. Weighing points for the matches are defined by you, and would be set according to the data field/combination of data fields that you select.
Example: Assume the threshold for minimum points is set to 1000. When you define a merge rule with a single data field entry of Last Name, this will never be eligible to make the full match of 1000 points, so you would probably only give a part of the points to it (e.g., 300). Then you will want to add the next merge rule for another data field that makes the 1000 points complete – like Memberships - where you would give the remaining 700 points to. You can also opt to add another several merge rules consisting of Address 1 and City, for example, and give respective weighing points to these in order to make the 1000 points complete.
One of the easiest options will be to define a combination of data fields that would meet the necessary 1000 points within the same merge rule, as shown in the sample screen above.
Apply. The activation flag for the merge rule. This must be checked for the merge rule to be applied. A merge rule can also be created and then temporarily be deactivated by blanking out this flag.
Setting up Merge Rules
The merge rules can be configured either as merge rules for individual data fields or for data field combinations, where the weighing points will only apply if all components in that combination match. When setting the merge rules, note the following:
For Direct Guest merge rules use LAST for the Last name.
For Travel Agent merge rule uses COMPANY for the TA name and NAME_CODE for the IATA number.
For Group merge rule use LAST for the group name.
For Company merge rule uses COMPANY for the company name and NAME_CODE for the Corporate ID.
For Source merge rule use LAST for the source name.
OXI Interface Controls and Profile Matching
The following OXI Controls determine the profile matching results:
PROF_MATCHING. Profile matching only occurs when set to Y. When PROFILE_MATCHING is active, OXI will validate the incoming profile message before executing the match and merge process to verify that the data contained in the message is sufficient to exceed the threshold points. If the data is not sufficient an optional warning will be generated indicating there is not sufficient data to meet the threshold and the match and merge process will not be executed.
Note:
Profile matching can be set to N if , prior to system cut-over, the two systems are synchronizing data with the profiles sent from OPERA Cloud to the external system and the external system returning a unique ID. OPERA Cloud then stores this ID for primary match and merge. This process renders the use of match and merge a duplicate effort and therefore inefficient and not required.PROF_CREATION. This Interface control determines whether a new profile should be created if the profile match was not successful. This must be set to Y for all interfaces that transmit reservations. If set to N, any non-matching profiles will be rejected and not created newly.
OXI Interface Controls and Profile Update in OPERA Cloud
Table 25-4 Several OXI Interface Controls determine how the profiles are updated in OPERA Cloud:
|
IND EXT SYS OVER |
Profile overwrite priority for guest profiles.
|
|
TA EXT SYS OVER. |
Profile overwrite priority for travel agent profiles.
|
|
CORP EXT SYS OVER |
Profile overwrite priority for Company / Agent profiles
|
|
SOURCE EXT SYS OVER |
Profile overwrite priority for source profiles
|
|
GROUP EXT SYS OVER. |
Profile overwrite priority for group profiles
|
|
PHONE/ADDR EXT SYS OVER |
Profile overwrite priority for phone and address collections. This parameter determines how the phones/addresses received from the external system update the phones/addresses in OPERA Cloud and which OPERA Cloud records are included in the outbound messages. This parameter will supersede the Delta setting of the interface. A = If received, replace OPERA Cloud values with the received values. If not received, remove the values from OPERA Cloud. B = If received, replace OPERA Cloud values with the received values. If not received, do not remove the values from OPERA Cloud. C = If received, merge the received values with OPERA Cloud values. If not received, remove the values from OPERA Cloud. D = If received, merge the received values with OPERA Cloud values. If not received, do not remove the values from OPERA Cloud . E = If received, replace only those OPERA Cloud values configured in conversion with the received values. If not received, remove only those OPERA Cloud values configured in conversion. In outbound messages, send only those records with converted types. N = Ignore the phone/addresses received. Do not touch the values in OPERA.INTEREST EXT SYS OVER. If set to Y, interests in the OPERA Cloud profile will always be overwritten by external system interests. If set to N, external system interests will be appended to existing OPERA Cloud ones. |
|
PREF EXT SYS OVER. |
This parameter is applicable only if the profiles are allowed to be updated in general. This means at least one of the parameters IND EXT SYS OVER, CORP EXT SYS OVER, TA EXT SYS OVER, SOURCE EXT SYS OVER, or GROUP EXT SYS OVER should be turned ON. If this parameter is set to Y or N and the interface is configured as 'Delta Changes = Y' and no preferences are received in the profile message, existing preferences in the OPERA Cloud profile will remain untouched. Otherwise, if this parameter is set to 'Y', existing preferences in OPERA Cloud profile will be replaced with the preferences received in the message, if set to 'N', preferences received in the message will be added to the existing preferences in OPERA Cloud profile, if set to 'C', OPERA Cloud profile preferences configured in 'Guest Preference' conversion will be replaced with the preferences received in the message. |
|
PROFCOMMENTS EXT SYS OVER |
This parameter is applicable only if the profiles are allowed to be updated in general. This means at least one of the parameters IND EXT SYS OVER, CORP EXT SYS OVER, TA EXT SYS OVER, SOURCE EXT SYS OVER, or GROUP EXT SYS OVER should be turned ON'. If this parameter is set to Y or N and the interface is configured as 'Delta Changes = Y' and no comments are received in the profile message, existing comments in the OPERA Cloud profile will remain untouched. Otherwise, if this parameter is set to 'Y', existing comments in OPERA Cloud profile will be replaced with the comments received in the message, if set to 'N', only those comments in OPERA Cloud profile last updated by this interface will be replaced with the comments received in the message, all other comments will remain unchanged, if set to 'C', OPERA Cloud profile comments configured in 'Comment Type' conversion will be replaced with the comments received in the message. |
|
NEGRATES EXT SYS OVER |
If you allow profiles to be overwritten in general. This means at least one of your parameters IND EXT SYS OVER, CORP EXT SYS OVER, TA EXT SYS OVER, SOURCE EXT SYS OVER, or GROUP EXT SYS OVER have to be turned ON. The functionality of this parameter is further determined by the 'mode' of your interface. If it works with delta changes set to 'yes' (interface configuration->edit interface), the external system can send profile changes only and does not need to send the full profile every time a small change to a profile occurs. OXI will then only update the changed data and not touch the additional data that was found in the OPERA Cloud profile. This also means that the external system needs to indicate intended deletions clearly with deletion indicators in the message. Sending simply blanks will not lead to data deletion if OXI works in 'delta mode'. The deletion indicators can be configured in interface configuration->edit interface. If your interface is set to delta changes 'no', OXI expects a full overlay of all profile data in every profile message, even if the external system only changes very little of the entire profile. Here is how the parameter works: If your interface is setup as 'Delta Changes = Y' and no negotiated rates are sent by the external system in the profile message, this parameter is ignored and the existing OPERA Cloud profile negotiated rates remain untouched. Otherwise the following parameter rules apply: If 'Y', negotiated rates sent by external system will overwrite existing OPERA Cloud profile negotiated rates. If 'N', negotiated rates sent by the external system will be appended to existing OPERA Cloud profile negotiated rates. |
Parent topic: Interface Setup