Skip to Content
Author's profile photo Jonathan Schlotz
Jonathan Schlotz
October 17, 2016 5 minute read

The Main ID Origin Customizing Settings for Contacts in SAP S/4HANA Marketing and SAP Hybris Marketing

+++ Concerns the releases: 1602 / 1605 / 1608 / 1611 / 1702 +++

< Read the previous blog (prerequisite)

Before you start to load contact data into SAP S/4HANA Marketing/SAP Hybris Marketing, you should have set up customizing of the ID Origins as this has a wide impact on the mapping and merging logic between contacts. So, it’s really important to know what kind of data you get from the connected source systems. This blog should help you to understand what can go wrong and why – and most importantly – how to prevent undesirable behavior.

What are the key parameters?

In addition to the Priority parameter, whose function I’ve described in my previous post, there are two more key parameters. Since it should be possible for several contacts to share the same facet – for example a landline phone number shared by all family members in the household – the Shareable parameter was introduced in release 1602.

Furthermore, a One Per Contact parameter was introduced, which specifies whether contacts can have more than one ID of the same origin or not. Therefore this parameter can prevent the system from merging contacts that would otherwise be merged because of matching IDs. For example, if we think of a social security number or a personal identification number (mainly for taxation purposes), it is clear that every person can have only one ID of these origins.

ID Origins Customizing in S/4HANA Marketing

    1. Click on the tile Manage Your Solution.
    2. Click on the link Configure Your Solution.
    3. Click on the Start button of the Origins of Contact ID app.
    4. Configure your ID Origins.

ID Origins Customizing in SAP Hybris Marketing

  1. Enter transaction SPRO.
  2. Expand the structure SAP Hybris Marketing > Contacts and Profiles > Interaction Contacts and execute Define Origins of Contact ID.
  3. Configure your ID Origins.

What will happen if the ID Origin customizing doesn’t fit your current scenarios / data needs?

In the worst case, the system creates…

  • duplicate contacts and
  • container records (not any longer in 1702!)

if the One Per Contact parameter for an ID Origin of a source is set to true and the data coming from this source contains real duplicates.

An Example

Let’s assume there is a customer who has two accounts in a web shop and has given the same mobile number for both. If we import this data into S/4HANA Marketing/SAP Hybris Marketing using standard customizing (Web Shop – One Per Contact = true; Mobile – non-Shareable), the mobile facets would match, but the configuration of the ID Origin Web Shop would not allow a merge. So, the ID Origin Web Shop is treated similarly to a social security number and the system regards both of these imported records as two distinctly different contacts.

But which contact will keep the mobile facet? Since the ID Origin of this facet is defined as non-Shareable, the system allows only one contact to own it and takes it away from both. Additionally, a container record is created with the mobile number as the only attribute (and accordingly facet). This example is also illustrated in the next part of this post (example for case (1) + (2)).

An overview of the different combinations for the settings for Shareable and One Per Contact

    ID Origin configured as Non-Shareable:

  • A given facet (= ID Origin + ID) can belong to only one single contact.
  • Matching criterion: ID Origin+ ID are the same.

    • ID Origin configured as Shareable:

  • A given facet can belong to multiple contacts.
  • Matching criteria:
    1. ID Origin + ID are the same
    2. Full names are the same or empty.
    Note: ID Origins configured as Non-Shareable are considered first for matching!
    ID Origin configured as One Per Contact = false:

  • A contact can have multiple facets of this kind (same ID Origin, different IDs)

    • ID Origin configured as One Per Contact = true:

  • A contact can have only one facet of this kind and it may prevent the system from merging contacts!

Example for case (1) of the Settings Overview table

Two source records with the same mobile facet – whose ID Origin is defined as non-Shareable – are imported from the two connected source systems, web shop and ERP.

The source records match via the mobile facet and are merged to one resulting contact record which gets the two main facets of the ID Origin Web Shop and ERP with the corresponding mobile facet.

Example for case (1) + (2) of the Settings Overview table

Before 1702

Two source records, corresponding to two accounts from a web shop, with the same mobile facet are imported.

The source records match via the mobile facet – whose ID Origin is defined as non-Shareable – but, the One Per Contact = true configuration of the ID Origin Web Shop prevents the system from merging them. The resulting contact records don’t have the mobile number any more, instead an additional container record is created with that mobile number and a corresponding facet.

As of 1702

Two source records, corresponding to two accounts from a web shop, with the same mobile facet are imported.

The source records match via the mobile facet – whose ID Origin is defined as non-Shareable – but, the One Per Contact = true configuration of the ID Origin Web Shop prevents the system from merging them. The resulting contact records still keep the mobile number. On another contact import which includes this mobile number, the corresponding mobile facet is considered as a Shareable facet although its ID Origin is still configured as non-Shareable.

Example for case (3) of the Settings Overview table

Two source records with the same email facet – whose ID Origin is defined as Shareable – are imported from the two connected source systems ERP and CRM.

The source records match via the email facet but the second matching criterion (based on full name) is not fulfilled. Each of the resulting contacts has this email facet due to its Shareable setting.

Standard logic vs. Business-Add-In logic

The behavior described here is valid for the default logic without the implementation of further Business-Add-Ins (BAdIs). Via the implementation of the map/merge BAdI method (IMP_IA_IC_MERGE_BY_FACET) you can merge contacts even if customizing settings would be violated and you can also prevent the merging of contacts, which the system would normally merge (due to matching criteria).

I hope this post provided you an understanding of the ID Origin customizing in order to set up the ID Origins appropriate to your scenario with regard to the data coming from the connected source systems.

Assigned Tags

      7 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Thanks a lot. This document really gives an insight into the Contact Match/Merge behaviour.

      Author's profile photo Antonio Morais
      Antonio Morais

      Hi Jonathan,

      Thank you for the detailed explanation on the merge behaviour.

      I have a question regarding the possibility of using multiple ORIGINS, within the same uploaded record, for the determination of Merge. In our scenario a Contact should only be Merged if they share the same EMAIL and MOBILE number, so EMAIL is not enough criteria to merge the two records. Because the decision on Merge is performed by ORIGIN at a time, first EMAIL and if not match then MOBILE, can the decision on merge be hold till the EMAIL and MOBILE Origins are verified?
      What we notice is that if we make a DROP decision on EMAIL Origin, the EMAIL gets dropped from the OLD contact and added to the NEW contact, but MOBILE Origin is never checked as the Merge decision was already performed. If no decision is made, sap standard merge logic is applied and merge is performed on base that emails match. In our scenario both EMAIL and MOBILE are set as non  sharable as FULL NAME is not a valid match criteria.

      example:
      Fist Uploaded Record -> New Contact Created

      Result:

      Our objective is to be able to merge a record only if EMAIL and  MOBILE match, otherwise a new record should be created without Dropping or Spitting the facets from the Old or New Contact. Can this be achieved?

      Other issue that we currently have is related to the standard validation against the FULL NAME for Sharable ORIGINS. Can the FULL NAME validation be changed without having to change the imported value of field FULL NAME? I mean, could this check be performed only on SURNAME?

      Thank you again for the brilliant explanation,
      Antonio

      Author's profile photo Jonathan Schlotz
      Jonathan Schlotz
      Blog Post Author

      Hi Antonio,

      first of all, the following things are important to know (not only for you – also for other people interested in this answer):

      • The full name is always considered as the second criterion in case of Shareable Facet matching and so far there is no possibility to change this behaviour via a BAdI method directly (but anyways, I’ll describe, how you can achieve the behaviour you desire).
      • The following is only applicable for SAP Hybris Marketing (on premise) – not for SAP S/4HANA Marketing Cloud!
      • You can implement the Map/Merge BAdI method in a way that it generally rejects the Hybris Marketing proposed merge of an existing contact with an imported contact  (Hybris Marketing proposes the merge if both contacts have the same non-Shareable facet OR if they have the same full name and at least one identical Shareable facet). Further you would suggest Hybris Marketing to merge an imported contact with an existing contact that meets your own specific merge criteria if you implement them in the Find BAdI method. Additionally you would need to confirm this merge again in your Map/Merge BAdI method when this is called a second time.
        • The first time this method is called after the Shareable Facet matching is finished and a contact was found. Not only because of the full name as the second matching criterion, this match would not be suitable in your case.
        • Then, this method is called a second time after the execution of the Find BAdI method (which is only called if there is no match found via the Hybris Marketing standard logic before or if the proposed merge is rejected).


      Steps to do in short with sample coding

       

      1. Implement your custom logic in the Find BAdI method to identify an appropriate contact.
      • In your case, you search for an existing contact on the data base which has the same email address, the same mobile phone number and the same surname.
      • An approach would be to search for the EMAIL/MOBILE Facet in the Facet table. If you’ve found a contact having both Facets, you check the surname of this contact in the Golden Record/Root table.
      1. Implement the Map/Merge BAdI method.
      • For the first call you disagree all merges via a Shareable facet. You may check this via the fields ID_ORIGIN (check if this is an ID Origin which you’ve defined as Shareable) and BADI_FOUND_MATCH (is initial in this case) of the structure IS_FACET.
      • For the second call you agree the merge (the field BADI_FOUND_MATCH is then flagged with ‘X’), because the contact was found based on the criteria you defined in the Find BAdI method.

      Sample code for the Map/Merge BAdI method as follows:

        METHOD if_cuan_ce_ic_update_sp7~imp_ia_ic_merge_by_facet.

    CLEAR: ev_merge,
           ev_split_facet,
           ev_drop_facet.

    IF import_typ_ic1 EQ 'IA'.

*     imported contact data are coming via Interaction.
*      => let Hybris Marketing decide whether to merge or not.
      RETURN.

    ELSEIF import_typ_ic1 EQ 'IC'.

*     Interaction Contacts are imported.

      IF is_facet-badi_found_match EQ abap_true.

        ev_merge = abap_true.        " we accept the merge with the contact found by Find BAdI.

      ELSEIF is_facet-id_origin EQ 'EMAIL'  OR " match by a shareable facet
             is_facet-id_origin EQ 'MOBILE' OR " match by a shareable facet
             is_facet-id_origin EQ 'PHONE'  OR " match by a shareable facet
             is_facet-id_origin EQ 'FAX'.      " match by a shareable facet

        ev_split_facet = abap_true.  " we reject the merge ( shareable facets will not be taken away from the 2 contacts! )

      ENDIF.

    ENDIF.

  ENDMETHOD.

      Hope this answer covers your questions and gives you the necessary input to achieve your objective!

      Author's profile photo Antonio Morais
      Antonio Morais

      Hi Jonathan,

      First of all,thank you so much for your detailed answer to my question. And second, sorry for my late reply.

      We have implemented your suggestion and it works perfectly.

      Thank you once more for all your help.

      Kind Regards,

      Antonio

      Author's profile photo Krishnendu Laha
      Krishnendu Laha

      Excellent Blog, thanks a lot for sharing. Cheers.

      Author's profile photo Former Member
      Former Member

      Hi, at first… great blog entry about the data management. Makes stuff lot more clear.

      One question about data management and golden records for different “brands” / “tenants” if you like.

      The challenge:
      In the S/4HANA 1610 ERP we have three different organizations which don’t share customer data. Means every brand have their own customer basis. Me as a customer of “brand 1” and “brand 2” gets two different business partners / debtors. But it’s still one S/4HANA ERP.

      We’re going to replicate the customer data via SAP LT to SAP Hybris Marketing (on Prem).

      In Hybris Marketing we need to differentiate these three customer wether he has the same mail adress or not.

      Do you have any recommendation how to cope with this use case?

      EDIT:

      Other variant: Make use of different tenants, but than you can't segment / analyze over the whole customer basis.

      BR Damian

      Author's profile photo Former Member
      Former Member

      Hi Jonathan,

      thanks a lot for your post, it's really helpful.

      I have a question related to a specific requirement to manage container records generated by Hybris Marketing (1605). In our configurations we do have ID Origins EMAIL and MOBILE set 'One per Contact' and 'not sharable', hence when there are two or more contacts in conflict with their ID Origins, system will create a container record.

      My question is: is it possible by standard to manage somehow container records? Is there any BAdI that can be used for our purposes? Another option could be to delete the container records, is there any standard report that include the selection of container records in order to delete them?

      Thanks a lot in advance

      Kind regards

      Marialuisa