You can use the CONF_SKIP_SECONDARY configuration to determine whether to skip using secondary identifiers when merging user data. If enabled, the system will not use secondary identifiers when a matching user is found; instead, it will only consider the primary identifier.

The section below explains the scenarios when the configuration is enabled and disabled.

Terms

• Campaign user - An individual whose identifiers are present in Capillary's Campaign users' list, used for sending campaign messages.
• Loyalty user: An individual who is already a customer and enrolled into a loyalty program.
• Incoming transaction: An incoming transaction from a new or existing customer.

CONF_SKIP_SECONDARY is disabled

When CONF_SKIP_SECONDARY is disabled, the campaign user will merge with the loyalty user based on matches with the primary identifier or any other identifier.

Example 1:

Primary Identifier - Mobile

Primary Identifier (Mobile) Match:

• The system compares the Mobile identifiers.
• Campaign User has Mobile (M1) and the incoming request has Mobile (M2).

Merge Decision:

• The Campaign User's existing details (Email: E1, Mobile: M1) will be updated to Email: E1, Mobile: M2.
• Depending on the payload passed, this updated user will be considered a loyalty or non-loyalty user.

Example 2:

Primary identifier - mobile

Matching Process:

Primary Identifier (Mobile) Matching:

• The system compares the primary identifier (Mobile).
• Campaign User has Mobile: M1, but the request has Mobile: M2.
• Loyalty User has Mobile: M2, which matches with the request.

Secondary Identifier (Email) Matching:

• Incoming user data's Email (E1) matches the Campaign User's Email (E1).
• However, the merge is primarily driven by the primary identifier (Mobile).

Merge Process:

• Since CONF_SKIP_SECONDARY is disabled, the merge considers both primary and secondary identifiers.
• Campaign User (Email: E1, Mobile: M1) and Loyalty User (Email: NULL, Mobile: M2) are merged.

Result:

• Campaign user's Email remains NULL, and Mobile remains M1: Email(NULL), Mobile(M1).

• Loyalty user's Email is updated to E1, and Mobile remains M2: Email(E1), Mobile(M2).

  After Merging

📘

Note

• If the survivor user's email or mobile is Null (Loyalty user), then the victim (Campaign user) user's email or mobile will merge into a survivor.

Example 3:

Primary identifier - mobile

Primary Identifier (Mobile) Match:

• The system compares the Mobile identifiers.
• Campaign User has Mobile (M2) and the incoming request has Mobile (M2).

Merge process

The merge occurs because the mobile (M2) of the campaign user matches the corresponding data in the incoming transaction user data(M2), and the email (E1) of the loyalty user matches the corresponding data in the incoming transaction user data(E1).

After Merging

📘

Note

• If the survivor (Loyalty user) user's email or mobile is null, then the victim (Campaign user) user's email or mobile will merge into the survivor.
• The loyalty user’s email remains the same as E1 and mobile changes to M2 because the victim details will be merged into a survivor.

CONF_SKIP_SECONDARY is Enabled

When CONF_SKIP_SECONDARY is enabled, the system skips secondary identifiers during the merging process of campaign and loyalty users. In this scenario, merging will not happen based on secondary identifier matches alone. Instead, merging relies on primary identifier matches between campaign and loyalty users.

Example 1:

Primary Identifier - Mobile

Matching Process:

• Since CONF_SKIP_SECONDARY is enabled, the system ignores the secondary identifier (Email) and only considers the primary identifier (Mobile).The Campaign User has Mobile: M1, which does not match the incoming request's Mobile: M2.

Merge Process:

• No existing user with Mobile: M2 is found in the database.
• Since the primary identifier (Mobile) does not match any existing user, no merge happens with the Campaign User.
• A new loyalty user is created with the provided primary identifier (Mobile: M2).

Result:

• Campaign User: Remains unchanged: Email: E1, Mobile: M1.
• New Loyalty User: Created with: Email: NULL, Mobile: M2 (since the incoming request's primary identifier is M2, and secondary identifiers are ignored).

After Merging

Example 2:

Primary Identifier - Mobile

Matching Process:
Primary Identifier (Mobile) Matching:

The system looks at the primary identifier (Mobile).
Customer 3 has Mobile: M2, which matches with the Loyalty User's Mobile: M2.

Secondary Identifier (Email) Matching:
Even though CONF_SKIP_SECONDARY is enabled, Customer 3's Email: E1 matches the Campaign User's Email: E1.
However, the merge is primarily driven by the primary identifier (Mobile).

Merge Process:
Since CONF_SKIP_SECONDARY is enabled, the merge is based on the primary identifier.
Customer 3 (Email: E1, Mobile: M2) matches with both the Campaign User (Email: E1, Mobile: M1) and the Loyalty User (Mobile: M2).

Result:
The merge happens because the primary identifier (Mobile) matches. Campaign User (Email: E1, Mobile: M1) and Loyalty User (Mobile: M2) are merged.

After Merging

📘

Note

If the survivor user (Loyalty User) has NULL in either email or mobile, the corresponding field from the victim user (Campaign User) will be merged into the survivor.
In this case, since the Loyalty User's Email was NULL, it is updated to E1 from the Campaign User.

Example 3:

Primary Identifier - Mobile

Primary Identifier Matching:

• The primary identifier is Mobile.
• Customer 3 has Mobile: M2, which matches Customer 1's Mobile: M2.

Secondary Identifier Matching:

• Customer 3 has Email: E1, which matches Customer 2's Email: E1.
• Since CONF_SKIP_SECONDARY is enabled, secondary identifiers should generally be ignored. However, in this case, secondary identifiers still cause a conflict due to the match.

Merging process:

• The system identifies that Customer 3's Email (E1) matches Customer 2's Email, and Mobile (M2) matches Customer 1's Mobile. The system gives preference to the Loyalty user (Customer 2).
• The attempt to add Customer 3 fails because there is a conflict with existing users, and preference is given to the Loyalty user where the primary identifiers are not a match.

Result:

Example 4:

Primary Identifier - Mobile

Matching Process:

Primary Identifier (Mobile) Matching:

• The system considers the primary identifier (Mobile).
• Customer 3 has Mobile: M2, which matches with the Loyalty User's Mobile: M2.

Secondary Identifier (Email) Matching:

• Despite CONF_SKIP_SECONDARY being enabled, Customer 3's Email: E1 matches the Campaign User's Email: E1.
• However, the merge primarily relies on the primary identifier (Mobile).

Merge Process:

• Due to CONF_SKIP_SECONDARY being enabled, the merge is based on the primary identifier.
• Customer 3 (Email: E1, Mobile: M2) matches both the Campaign User (Email: E1, Mobile: M1) and the Loyalty User (Mobile: M2).

Result:
The merge occurs because the primary identifier (Mobile) matches. The Campaign User (Email: E1, Mobile: M1) and the Loyalty User (Mobile: M2) are merged.

After Merging

📘

Note

If the survivor user (Loyalty User) has NULL in either email or mobile, the corresponding field from the victim user (Campaign User) will be merged into the survivor.
In this case, since the Loyalty User's Email was NULL, it is updated to E1 from the Campaign User.