Within implementation projects, a comprehensive understanding of the Golden Record concept serves as a basis for all inbound integrations to SAP Hybris Marketing. For this reason, the following blog post describes how the golden record of an interaction contact is created in release 1605. The first part explains fundamental terminology and the golden record concept. Secondly, merge and split examples are given. The third section describes related customizing activities. The given examples are derived from my project experience.

GOLDEN RECORD PREREQUISITES

The entity interaction contact represents consumers, contacts or corporate accounts. Each interaction contact owns one golden record. The golden record covers the most valuable master data for each interaction contact unified from different data sources. These data sources are illustrated as facets that are assigned to the interaction contact. For instance, a consumer might own a SAP Hybris Commerce facet, a Website facet and a Facebook facet as part of a business-to-consumer (B2C) scenario. Apart from the channel related facets, basic facets derived from an email address, phone number or mobile number are created as additional keys that identify an interaction contact. These additional facets are used when assigning additional activities represented as interactions to an existing record.


Each facet consist of an origin that defines the data source as well as the ID as a unique identifier of an interaction contact related to the origin. The interaction contact is active within source systems generating master and transactional data. Master data is influencing the interaction contact itself. This data is assigned to the so called facet data or common data of the main facet. The golden record is build based on this facet data. The related facet priorities are defined in the customizing of your SAP Hybris Marketing solution. The greater the priority is, the more reliable the master data of this facet is. Several facets can be created within one request that don’t have facet data or are assigned to the same data using a group key.

Transactional data is affecting the entity Interactions. They are assigned to existing interaction contacts based on the interaction main facet. Interactions can also be send through the interface at first. In this case, a pure contact with empty facet data is created.


Since release 1602, facets can be customized as unique or shareable. A unique facet explicitly identifies an existing contact whereas a shareable facet such as a Cookie ID might be attached to several interaction contacts. Therefore, this customizing has wide impacts on the matching logic within the solution. Examples are explained in the next part of this blog post.

Facetts_Resized.jpg

MERGE AND SPLIT SCENARIOS

Different rules apply for contacts having shareable and unique facets attached. Especially, when using shareable facets the integration might become more complex.


The easiest scenario only uses unique facets. This is the unique to unique merge scenario. Contacts or interactions are created and assigned using a unique main facet. An example scenario might look as follows:

Step

Description

JSON Structure

1

Contact created

Unique facets SAP_HYBRIS_CONSUMER and SAP_HYBRIS_MKT_IC created.

Shareable facets COOKIE_ID and EMAIL created.

SAP_HYBRIS_CONSUMER as main facet with master data created.

{

      “Id” : “”,

      “Timestamp” : “/Date(1461655821713)/”,

      “UserName” : “USER”,

      “SourceSystemType” : “EXT”,

      “SourceSystemId” : “HYBRIS”,

      “Contacts” : [{

                  “IdOrigin” : “SAP_HYBRIS_CONSUMER”,

                  “Id” : “Scenario1”,

                  “Timestamp” : “/Date(1461655821713)/”,

                  “FirstName” : “Scenario1”,

                  “LastName” : “Klein”,

                  “FullName” : “Scenario1 Klein”,

                  “EMailAddress” : “Scenario1@ymkt.de“,

                  “Facets” : [{

                                “Id”: “Scenario1_12345”,

                                “IdOrigin” : “COOKIE_ID”,

                                “Timestamp” : “/Date(1461655821713)/”

                        }]

            }]

}

2

Interaction commerce sales order created and assigned using unique main facet.

{

      “Id” : “”,

      “Timestamp” : “/Date(1461655821713)/”,

      “UserName” : “USER”,

      “SourceSystemType” : “EXT”,

      “SourceSystemId” : “HYBRIS”,

      “Interactions” : [{

                  “ContactId” : “Scenario1”,

                  “ContactIdOrigin” : “SAP_HYBRIS_CONSUMER”,

                  “CommunicationMedium” : “ONLINE_SHOP”,

                  “InteractionType” : ” SHOP_CHECKOUT_SUCCES”,

                  “Timestamp” : “/Date(1461655821713)/”,

                  “Amount” : “37.50”,

                  “Currency” : “EUR”

            }]

}


More complex scenarios are using shareable facets such as a shared email address. The behavior of the system depends on whether only one contact or multiple contacts exist using this shared facet. A new incoming contact with a shared main facet gets merged when only one contact persistently exists that already owns this shared facet. Please keep in mind that the email address is always converted to a basic facet information. The following scenario can be named as shareable to unique merge.

Step

Description

JSON Structure

1

Contact created

Unique facet SAP_HYBRIS_MKT_IC created.

Shareable facets COOKIE_ID and EMAIL created.

EMAIL as main facet with master data created.

{

      “Id” : “”,

      “Timestamp” : “/Date(1461655821713)/”,

      “UserName” : “USER”,

      “SourceSystemType” : “EXT”,

      “SourceSystemId” : “HYBRIS”,

      “Contacts” : [{

                  “IdOrigin” : “EMAIL”,

                  “Id” : “Scenario2@ymkt.de“,

                  “Timestamp” : “/Date(1461655821713)/”,

                  “FirstName” : “Scenario2”,

                  “LastName” : “Klein”,

                  “FullName” : “Scenario2 Klein”,

                  “EMailAddress” : “Scenario2@ymkt.de“,

                  “Facets” : [{

                                “Id” : “Scenario2_12345”,

                                “IdOrigin” : “COOKIE_ID”,

                                “Timestamp” : “/Date(1461655821713)/”

                        }]

            }]

}

2

Contact merged with already existing contact, because only one persisted contact using the same shareable EMAIL facet.

Additional unique facets SAP_HYBRIS_CONSUMER created.

SAP_HYBRIS_CONSUMER as main facet enriched with master data.

Golden record updated because of higher facet priority and more valuable data

{

      “Id” : “”,

      “Timestamp” : “/Date(1461655821713)/”,

      “UserName” : “USER”,

      “SourceSystemType” : “EXT”,

      “SourceSystemId” : “HYBRIS”,

      “Contacts” : [{

                  “IdOrigin” : “SAP_HYBRIS_CONSUMER”,

                  “Id” : “4711”,

                  “Timestamp” : “/Date(1461655821713)/”,

                  “FirstName” : “Scenario2”,

                  “LastName” : “Klein”,

                  “FullName” : “Scenario2 Klein”,

                  “EMailAddress” : “Scenario2@ymkt.de

            }]

}

If two contacts own a shared facet, the system can’t explicitly assign an interaction. In this case a pure container contact is created without facet data. The interaction is assigned to that contact as part of the unique to shareable split scenario.

Step

Description

JSON Structure

1

First contact created

Unique facets SAP_HYBRIS_MKT_IC, SAP_HYBRIS_CONSUMER created.

Shareable facet EMAIL created.

SAP_HYBRIS_CONSUMER as main facet with master data created.

{

      “Id” : “”,

      “Timestamp” : “/Date(1461655821713)/”,

      “UserName” : “USER”,

      “SourceSystemType” : “EXT”,

      “SourceSystemId” : “HYBRIS”,

      “Contacts” : [{

                  “IdOrigin” : “SAP_HYBRIS_CONSUMER”,

                  “Id” : “Scenario3-1”,

                  “Timestamp” : “/Date(1461655821713)/”,

                  “FirstName” : “Scenario3-1”,

                  “LastName” : “Klein”,

                  “FullName” : “Scenario3-1 Klein”,

                  “City” : “Test City”,

                  “EMailAddress” : “Scenario3@ymkt.de

            }]

}

2

Second contact created

Unique facets SAP_HYBRIS_MKT_IC, SAP_HYBRIS_CONSUMER created.

Shareable facet EMAIL created.

SAP_HYBRIS_CONSUMER as main facet with master data created.

{

      “Id” : “”,

      “Timestamp” : “/Date(1461655821713)/”,

      “UserName” : “USER”,

      “SourceSystemType” : “EXT”,

      “SourceSystemId” : “HYBRIS”,

      “Contacts” : [{

                  “IdOrigin” : “SAP_HYBRIS_CONSUMER”,

                  “Id” : “Scenario3-2”,

                  “Timestamp” : “/Date(1461655821713)/”,

                  “FirstName” : “Scenario3-2”,

                  “LastName” : “Klein”,

                  “FullName” : “Scenario3-2 Klein”,

                  “City” : “Test City”,

                  “EMailAddress” : “Scenario3@ymkt.de

            }]

}

3

Interaction Marketing Opt-In created, but can’t be assigned to a specific contact. Pure container contact created without facet data.

{

      “Id” : “”,

      “Timestamp” : “/Date(1461655821713)/”,

      “UserName” : “USER”,

      “SourceSystemType” : “EXT”,

      “SourceSystemId” : “HYBRIS”,

      “Interactions” : [{

                  “ContactId” : “Scenario3@ymkt.de“,

                  “ContactIdOrigin” : “EMAIL”,

                  “CommunicationMedium” : “WEB”,

                  “InteractionType” : “MKT_PERM_OPTIN”,

                  “Timestamp” : “/Date(1461655821713)/”

            }]

}

CUSTOMIZING ACTIVITIES

The relevant customizing for interaction contacts can be found under the reference tree item SAP Hybris MarketingData ManagementInteraction Contacts. The most important activity is called Define Origins of Contact ID. In this Customizing activity, you define all relevant facet settings. First of all, the Origin of Contact specifies the source system of an interaction contact. Basic facet information such as the email address or a phone number is defined as well. A description is assigned to each origin. The checkbox One per Contact determines whether an interaction contact is allowed to have more than one items of a specific facet type. The attribute Shareable defines that multiple interaction contacts can own the same facet. For example, multiple family members might use the same email address. Anonymous facets do not have master data assigned as facet data. The golden record of an interaction contact requires the Priority of each facet. The lower the numeric number is defined, the higher the priority of a facet is. Finally, the SAPUI5 Icon Name is assigned. This icon is shown in the facet overview of the contact fact sheet.

I hope this short tutorial helps within your projects. Please do not hesitate to contact me in the case of questions.

Raphael Schmitz

Raphael Schmitz
Business Processes Consultant, Consumer Industries Services, SAP Global Services and Support

SAP Hybris Marketing, SAP S4/HANA Marketing Cloud, SAP Cloud for Customer

SAP Deutschland SE & Co.KG, Hasso-Plattner-Ring 7, 69190, Walldorf/Baden, Germany

E raphael.schmitz@sap.com

To report this post you need to login first.

8 Comments

You must be Logged on to comment or reply to a post.

  1. Christian Langmann

    Thanks a lot for your excelent article.
    Would have one question to scenario 3:

    If two contacts own a shared facet, the system can’t explicitly assign an interaction. In this case a pure container contact is created without facet data. The interaction is assigned to that contact as part of the unique to shareable split scenario.

    How can an MKT optin be assigned to the right contact, if the interaction MKT_PERM_OPTIN allways needs to have the ID_ORIGIN = EMAIL and the ID = mailaddress?

    (0) 
    1. Nico C.

      Alone with this information (email address, if set to shareable) – if you have multiple contacts sharing the email, you won’t be able to do it. It might find something, if you provide a first and last name.

      Otherwise – if you use standard functionality and generate a link containing the contact key (the GUID) in the URL, by means of origin id and key, the contact will be uniquely identifiable.

      (0) 
      1. Christian Langmann

        Hi Nico!

        Thanks for your response.

        Regarding the “Data Management Inbound Interface” guide, the ID_ORIGN for the IA_TYPE NEWSLETTER_SUBSCR must be EMAIL.  So you mean in this case it would be enough to to add additional information like first or last name to the interaction?

        Maybe it is necessary to do the assignemtn of an communication category on an other way:
        1. Create a new Interaction Type: Z_NEWSL_SUBSCR

        • ID_ORIGIN: SAP_HYBRIS_CONSUMER
        • ID: Consumer Id

        2. Assign communication category based on Interaction Contact:


        {

        “Id” : “”,

        “Timestamp” : “/Date(1406014140922)/”,

        “UserName” : “USER”,

        “SourceSystemType” : “EXT”,

        “SourceSystemId” : “HYBRIS”,

        “Contacts” : [

        {

        “Id” : “4711”,

        “IdOrigin” : “SAP_HYBRIS_CONSUMER”,

        “MarketingPermissions” : [

        {

        “Id” : “otto.normalverbraucher3@company.de“,

        “IdOrigin” : “EMAIL”,

        “Timestamp” : “/Date(1406014140601)/”,

        “OptIn” : “Y”,

        “OutboundCommunicationMedium” : “EMAIL”

        }

        }

        ]

        }

        Or is there also a problem with the IdOrigin within MarketingPermissions?

        (0) 
        1. Nico C.

          For interactions – yes, if possible provide first and last name, if email is shareable.

          For your json-example – no, there’s no problem with it, since you’ve packed the permission under a fully identifiable contact (SAP_HYBRIS_CONSUMER = 4711).

          (0) 
  2. Isa Bevilacqua

    Hi Raphael,

    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

    (0) 

Leave a Reply