SAP Hybris Marketing Cloud – Twitter Profile Enrichment With Gigya User Identity

Background 

SAP provides out-of-box package contains integration flow (iflow) to import tweets into SAP Hybris Marketing Cloud via Twitter search query API. The API however sends only twitter Id and limited data (no email) even user registered twitter via email or phone number.

The tweets sentiments collected by integration iflow can be valuable for analyzing sentiments insights, but has limited capability for campaign execution due to lacking of other communication channel data.

To address this limitation, an additional Id origin like application registration service contains both Tweeter Id and other communication data (especially email or phone) has to be used to match for the purpose of enriching marketing tweeter contacts.

In this blog, it demonstrate technical feasibility on how Gigya as RaaS (Registration as a Service) can be used for this purpose.

Standard iflow: Twitter Integration With Marketing

Standard iflow use Twitter standard edition search API for tweets import to create interaction contact, interaction and search term tagging into marketing.

An example of the Twitter standard search API response is as below, the highlighted fields are sent to marketing, and does not contain email or phone number. This limits the ability to match and merge with other origin source data (commerce, ERP, CRM etc.). Campaign running on mail or phone channel will also be restricted.

Gigya as RaaS

Gigya as RaaS provide very convenient way to register user identity base on social media accounts. As only minimum data entry is required on registration, it promote quick and easy registration process which in terms drives higher registration rate.

The registered Gigya identity can be queried by provided REST API, which contains additional useful details, especially email of twitter Id (nickname) is also available.

Working with Gigya API

API User Registration and Getting API key

To access Gigya API, site user base on email registration will be sufficient. This API user does not required linking to social media registration.

Disclaimer: For the purpose of demonstrating API technical feasibility at here, test API user will be created for testing. You shall consult Gigya as necessary for using appropriate user.

To create test API user, go to link RaaS documentation, then scroll down to section See it in Action to register API user with email address.

Still on RaaS documentation, test login with browser developer tools on. This will capture HTTP communication to Gigya which shows api-key as part of the URL.

REST APIs

The api-key will be required for all the REST call to Gigya. There are basically only 2 REST API required.

1. Accounts.login: Request a new login session id, subsequently used it to call for the next search REST API.                                                                                            https://{{gigya_Host}}//accounts.login?apikey=${property.ApiKey}&loginID=${property.LoginId}&password=${property.password}
2. Accounts.search: This is REST API that return the Gigya identity (user) detail                            https://{{gigya_Host}}/accounts.search?apikey=${property.ApiKey}&login_token=${property.LoginToken}&query=${property.QuerySql}&querySig=&expTime=${property.ExpTime}.

Where ${property.xxx} are placeholder of URL parameter value to be filled by scripting implementation during iflow run-time.

Example:

As shown above, QuerySql parameter is very similar to database SELECT statement. The WHERE clause can be built dynamically base on the Twitter ID sent by Open Channel custom logic to include Twitter ID.

Marketing Open Channel Implementation

In marketing, Open Channel campaign enable high flexibility to send contacts details Export Definition, which is base on the Best (Golden) Record (table CUAND_CE_IC_ROOT).

Twitter ID however are kept in facet table (CUAND_CE_IC_FCET), and not directly comes from Best Record. Hence, Open Channel implementation must be enhanced to include additional attribute by facet data reads.

Sample Implementation steps are defined from Extensibility application under tab Custom Logic:

Step 1: Define New Implementation name (Open Channel: Define Implementations), example Z_GIGYA_TW_EXPORT.

Step 2: Define New Header Attribute (Open Channel: Define Global Setting for Execution), example ‘GET_TWITTER_ID’ to flag reading twitter facet ID at next step Enhance Payload.

Step 3: Enhance Payload (Open Channel: Enhance Payload for Data Transfer) when header attribute GET_TWITTER_ID flagged, then perform facet reads using helper class (CL_CUAN_INTERACT_CNTCT_HELPER) to fetch TW facet for Twitter Id to be included as additional field in Export Definition.

Technical Integration Overview

Process flow:

1. Twitter user registration on Gigya (note that this is different from Gigya API user), then post tweet contains query string configured in standard iflow.
2. Standard Twitter integration iflow trigger on timer scheduler to pull tweets base on query string, then send OData import request to create Interaction Contacts etc.
3. Design segmentation model base on ID Origin=Twitter, and Interaction Date (this is purely business decision) then create dynamic target group
4. Implement custom logic enhancement to include additional export definition field contain Twitter Id (as described above: Marketing Open Channel Implementation)
5. 6. 7. 8. Create new custom iflow to enable Accounts.login and Accounts.search REST API call, then map to target import Odata in json format for update into marketing. (see next session: Cloud Platform Integration: Gigya custom iflow)

Cloud Platform Integration: Gigya Custom iflow

Process flow:

1. The iflow provide a HTTP sender for receiving Open Channel’s Export Definition in json.
2. Gigya Account.login REST API is called to obtain a new login session ID.
3. The session ID is read and save as ${property.LoginId}. The json file received by HTTP sender is now also read to built dynamic QuarySql contain Twitter Id list.
4. Base on session ID and QuarySql, Gigya Accounts.search REST API is called.
5. The result from Gigya are mapped into marketing OData json format.
6. The mapped import json sends to marketing for update.

Sample Mapping and Target Format: 

• Gigya profile data is always created as marketing Main Facet ID
• Gigya identities will be created as marketing additional Facet ID (TW, EMAIL)
• If Identities contain email not the same as Profile email, additional EMAIL id will be created as well under additional EMAIL Facets

Testing

Before Gigya Import

Post a Tweets with expected query string configured in standard Twitter iflow, this will be pulled by iflow once executed. This create interaction contacts and facet with Twitter ID. (no email facet created)

After Gigya Import

More detail updated (first name, last name etc provided by Gigya) into Best Record.

Additional Facet (GIGYA_ID, EMAIL) are also created.

GIGYA_ID, EMAIL captured here can then be potentially used for ID match with other ID Origin (ERP, CRM, etc) to enrich Twitter user with wider context. On the other hand,  other ID origin matched will be able to leverage sentiments captured by Twitter.

Conclusion

This blog demonstrated how Gigya can be complements to Marketing for enriching contacts.

Technically, any RaaS product (like Gigya) which provides API for extracting social media ID with other additional communication details (email, phone etc.) can be used for enriching yMkt contacts.