PEGA CDH & Digital Transformation – The need of focus towards Decisioning & Marketing daily Operations

The adoption of data analytics is one of the greatest drivers of digital transformation, as businesses seek greater data-driven insights. Customer Analytical Records (Customer360 OR CARs) Data acts as a source of truth that helps teams focus on the critical factors that determine business resilience. Businesses are acutely aware that they must become more resilient by using technology especially with PEGA where PEGA CDH adopted as Brain for Centralized Decision Hub to recommend Next Best Actions/Offers/Contents/etc.

Companies are using daily customer data & real-time data to their advantage to advance their operations, enhancing the applications, and closing the loop by feeding key business applications. This helps to enable optimization of the cost, Investment, enhanced analytics, and modeling/simulation – and this ultimately means improvements in business efficiency across the entire operations.

This has been particularly true for the enterprises, where data has had a significant impact in five key areas:

§  Real-time operational information is increasingly being used to understand what is happening in real-time and enables the condition management of Marketing and operations lifecycles. For example, a dashboard displaying the acceptance/Rejections and fulfillment of the offers in real-time understanding of the Marketing Operational behavior and state. It will help us to quickly react to the change introduced to the system when a new Marketing Offer. Tools like ELK stack can be integrated with the PEGA Decisioning flow to visualize the offers & its performance in Real-Time to understand the Real-Time Operational Information.  

§  Historical operational information form Interaction History Table helps organizations to understand what has happened in the past to create intelligence around operational behavior of Marketing Offers. Through operational trends, display of KPIs and dashboards, you can create abstracted views of operational states. For example, a graph may be displayed on a dashboard showing the Marketing offer Accepted/Rejects majority of the time. This can be compared to the real-time Offer Acceptance, creating intelligence on the Marketing Offers long-term operational trends.

§  Simulation & Predictive analytics is used for what-if type modeling. Integrating real-time and historical data enables your team to assess potential outcomes of operational states and behaviors, even accounting for tertiary variables. Deterministic or non-deterministic models can then be applied for open-loop simulation and predictive analytics. For example, you can now estimate how many customers might accept/Reject the newly launched offer. Other Marketing ControlParameters can be tweaked & run the Simulation including Predictive analytics to forecast the Accept rate for various Control Parameter combinations.

§  Prescriptive analytics describes what’s needed to optimize Marketing Offer  and operations lifecycles. Scenario-based guidance is created and delivered through learning elements and closed-loop algorithms to enable your team to calibrate planning and scheduling across the entire enterprise value chain. For example, using a unified Marketing model, scenario-based calculations can be used to optimize maintenance schedules and performance, minimizing impact to your operations.

§  Enhanced Marketing Investment achieved through a combination of real-time Marketing Operations Monitoring, reacting the data quickly through Rapid deployment process and forecasting the Impact of the Marketing Offer Acceptance will help organizations to make better Marketing Investment.

 

Be bold, reflect and evolve

Businesses require intelligent Marketing software like PEGA CDH along with additional Real-time Offer performance monitoring tool like ELK stack (if applicable) to address Marking pain points for value creation, productivity improvement, insight discovery, risk management, and cost optimization. With the right technology, businesses can be incredibly agile to manage costs, boost efficiency and avoid costly mistakes. The combination of digitization, automation and data driven insights, with a focus on sustainable business can be a key differentiator and a propelling force to help ensure businesses meet their goals of today and tomorrow.

Happy Learning!

Nanjundan Chinnasamy | PEGA Lead Decisioning Architect

Tracking effectiveness of the PEGA Marketing Campaign & real-time Decisioning response through UTM Parameters with CallToAction URL

Often enterprises having difficulties in understanding the campaign drives the maximum traffic and business to their website. Since many large scale enterprises started moving towards PEGA Centralized Decisioning Hub (Unified Marketing tool to send hyper personalized contextual, timely marketing message to the customer) to serve the marketing message, it is most important & critical for them to analyze & measure the RoI for the investments they have made.

One easy way to measure & track the effectiveness of the Marketing message sent to from PEGA for both Inbound & outbound channels is using UTM parameters to their CallToAction link.

UTM parameters come into play to analyze & measure the marketing campaign that drives maximum traffic. Organizations can plan their investment based on the historical performance in a Omni Channel Marketing environment.  

By tagging your URLs with UTMs (Urchin Tracking Module), you can understand how your visitors interact with your website/app/outbound campaign like SMS/Email.

Here’s how these UTM parameters appear at the end of your URL:

https://www.jio.com/recharge_singleclick?

planId=1008395&utm_source=NE&utm_medium=SMS&utm_campaign=Plan_expiry

Adding UTM parameters in all the CallToAction link provide extremely valuable insights from Analytics perspective to measure the effectiveness of the Offer & RoI . You can uncover a goldmine of behavioral data to help boost our sales and refine your overall marketing strategy (Offers, Channels etc). 
x

 

What Are UTM parameters?

Here’s a succinct and super helpful definition from Kissmetrics:

“UTM parameters are simply tags that you add to a URL. When someone clicks on a URL with UTM parameters, those tags are sent back to your Google Analytics for tracking.”

As a PEGA Decisioning Consultant can plan & keep all the UTM parameters in a proposition catalog & finally build the CallToAction target link from proposition metadata.

There are five UTM parameters that you can attach to your links:

UTM source: Encapsulates the traffic source that in most of the cases is the platform on which you shared the link, for example, Google, LinkedIn, Twitter and Gmail.

UTM medium: Includes the marketing medium that is closely related to the source. For instance, if you use Google as a source, PEGACDH, Adwords etc.

UTM campaign: Underlines the campaign that you used to share the URL. You can name the campaign as you like, for example, “PlanExpiry“ for outbound campaign and “Inbound” for real time inbound call to offer recommendations from PEGA Decisioning engine.

UTM term: In most cases, this parameter is used for advertising and seizes the term you bid on for sharing your URL. For example, you might bid on the term “Drip Marketing,” and consequently, “drip marketing” will be the UTM term.

UTM content: A parameter that is used to determine the content that collected interaction when multiple elements from your ad promotion led to the click. This is especially useful if you A/B test more versions of your content.

Only UTM parameters are sufficient to measure the PEGA Decisioning performance?

NO. We can add as many custom parameters to track the marketing effectiveness (URL can have max 255 chars including params. We could add only relevant url parameters to measure the effectiveness).

Below is on the example where the CallToAction link contains the InteractionID (URL param is IxID), OfferName(URL Param O), ContentID (CONID)

https://www.pega.com/webinars/customer-engagement-series?IxID=-1055117343767813309&O=CXUnified_InsNOutsOf11Engagement_NBA500_ES1_EM181438&utm_source=LMMS&utm_medium=email&utm_campaign=Engagement_NBA&utm_content=20DE_CE_NA-NA_EM%28EM-181438%29_EM1_CI_OT_NBACDHWBSERIESREPLAYVIDEO_NA&CONID=CON-8314620

 

Why UTM Parameters Matter for PEGA Decisioning CallToAction Links?

By using UTM parameters we can gauge the types of marketing messages/offers that work and provide us with the insight needed for the ones that didn’t. Basically, there are 5 major benefits from using UTM parameters for your campaigns:

Cross-Channel Tracking: You’ve just created a dedicated landing page Or Offer message to the Market. How to measure RoI for this? What if 99% of your traffic comes from Inbound Web channel and only 1% from SMS campaign? With UTM parameters, you’ll know exactly which channel brings you long-term profits.

Improving Your Channel Campaigns: When you track the channel’s ROI and monitor the campaign’s impact, you’ll have a clearer picture of what provides you with the best outcome. Now, you’ll be able to focus on improving the channel’s impact.

A/B Testing: If you want to test two different CTAs because they both lead to the same link, you can use a UTM parameter. You can compare the engagement for both of your CTAs and determine where your target customers respond better.

Influencer Marketing: When you pay a social media influencer to market your product, you want to know if he/she really gets clicked on or it’s just a person with a fake followers count. Creating a custom URL with UTM tags can help you track their ROI efforts.

Finally,
Adding UTM parameters in all the CallToAction link provide extremely valuable insights from Analytics perspective to measure the effectiveness of the Offer & RoI . You can uncover a goldmine of behavioral data to help boost our sales and refine your overall marketing strategy (Offers, Channels etc). 

Happy Learning!
Nanjundan Chinnasamy | PEGA Lead Decisioning Architect

Moving PEGA Adaptive Model learning between environments

There might be a use case, we may need to copy/move the ADM learning from PRODUCTION environment to other lower environments to simulate the results OR Reproduce Some scenarios referring to ADM learning from Production environment.

The following steps should be sufficient to import learning to a target system even if that system has previously had ADM models itself. However, they assume that you want to completely replace any ADM data on that target system with data from the source system, not merge the two. It is also assumed that your Cassandra cluster is not set up for Active/Active, across multiple datacenters.

In the source system

1. Export the pyADMFactory dataset from the source System.

In the Target system

1.     Ensure the adaptive rules are present.

2.     Decommission all ADM nodes.

3.     Navigate to the pyADMFactory dataset and run truncate operation.

4.     If the target system has any model reporting data in the following tables, these should also be manually truncated to prevent misleading reports.

a.     pr_data_dm_admmart_mdl_fact

b.    pr_data_dm_admmart_pred_fact

c.     pr_data_dm_admmart_pred (this may not exist depending on the version of Pega)

5.     Connect to Cassandra on one of the DSS nodes

a.     Remove the ADM model’s response lifecycle event data

drop keyspace adm_commit_log.

b.    Remove the rest of the ADM Data

drop keyspace_null_adm and/or drop keyspace adm - which ever present

6.     Navigate to the pyADMFactory data set and run the import data using the data exported from the source system.

7.     Decommission ADM nodes (the first node to start will create scoring models from the imported factory data).w

8.     When the ADM nodes have status NORMAL, check the Adaptive Model Management landing page. Model data should now reflect what was imported

PEGA Decisioning - Decision Table to be defined on the Strategy Result (SR class) or a Customer class? How to Deciside?

One common design question usually asked by many of our Decisioning Architects is, where should i define my Decision Table? Whether the Decision Table to be defined on the Strategy Result (SR class) or a Customer class? How to choose the Applies to Class while creating my Decision Table in my Decisioning application. 

The Decision Table can be defined on the Strategy Result, SR class, or a Customer class. The choice often depends on where the properties used in the Decision Table are located. Let us discuss the following three design options:

If the Decision table is using the properties from the Customer Class and Decision Table returns result from Decision Table OR result of the Decision Table directly sets the property available in the same customer class, you should create Decision Table in a Customer class. 

If the Decision table is using the properties from the Customer Class, if you want to refer the very few computed properties from SR class, creating Decision Table in Customer Class OR SR class OR both options are valid. The design decision here could be, if you want to set result of the Decision Table to a specific property directly from the Decision Table. If you want to set the result of DecisionTable to a SR class, Create the Decision Table in SR class. If we want to set the result of DecisionTable to a Customer class, Create the Decision Table in Customer class. If the Decision Table returns the result and result of the Decision table referred using pxSegment result property, creating DecisionTable in Customer,SR class both valid. 

 

Let us take an example below. Customer CreditScore is a derived property from SR class. OutstandingLoanAmount is a Customer class property. Based on these two property values, Decision Table returns RiskScore.  

Decision Table to compute the RiskScore

Creating the table requires two condition columns. First is the Principal Loan, which is the property in the data model representing the outstanding loan amount. 

The Operator represents the condition applied to the column. In this case, greater than, which allows you to express the Outstanding loan amount condition from the requirement.

The second condition column is the Credit Score property. The Credit Score is a parameter, so you need to use the Param.PropertyName construct.

The Use Range checkbox groups the credit scores together.

Fill in the bank’s requirements and specify a Return value for each row in the table.

Filter credit cards based on the calculated risk segment

Configure two Filter components to ensure that you identify High Risk and Low Risk customers.

Based on the Customers in the risk category, we can compute the customers eligiblity. The pxSegment Strategy property contains the output of the Decision Table.

Still confused with the Desion option to Define the Decision Table in a PEGA Decisioning application? Feel free to reachout to me.

Happy Learning, 

Nanjundan Chinnasamy 

PEGA Decisioning - Managing the Business Rules(Revision Management) for quick Production deployment

PEGA Decisioning - Managing the Business Rules(Revision Management)

AppOverlay & Decision Manager Portal configuration:

·         Decision Manager portal mainly used for PROD Simulation & PROD. Use an applicationOverlay for development

·         Business sandbox & AppOverlay env & Direct deploy for Decision Data update

·         Need to configure ADM monitoring, IH, VBD

Building An app overlay application:

·         Create New App Overlay wizard and create an app

·         Define the accessgroup & list of available rules to expose to AppOverlay to make the changes. Primarily on Decision data.

·         Default application Overlay will be created after Landing opage. The name of the overlay starts with ‘RTC-‘.

·         Start the Application Overlay wizard via the Decisioning > Infrastructure > Revision Management->Application Overlays landing page.

·         Define the AppOverlay applicaiton, Revision ruleset, accessgroup & the Rules to be included as part of AppOverlay

·         Selet the rules to make available for the revision Management, select the rules and click "Include for Revision Management"

·         Review the AppOverlay and credit the AppOverlay application

·         Setup new accessgroups & their roles and the required operator IDs to use.

Managing the Business Rules(Revision Management):

Has 3 envs in PROD (build-Sandbox, test-sandbox and prod).Revision Management enabled business users to make the change with the limited rules.

Post every release, AppOverlay reset will be done in the dev environment (PROD-AUTH). ie, new version of the app overlay will be created. Post creation, completed package will be deployed in business sandbox (Simulation) followed by PROD like regular BAU release.

·         AppOverlay release & package deployment as part of BAU release has to be explored.

·         The process to create a version & export is based on the dynamic case management process

·         As part of Revision management, CRs will be created by Revision Manager and the change will be implemented by Strategy Designer. Revision manager will approve/Reject the CR

New AppOverlay version will be installed like below:

·         The System Architect can use the revision activation landing page which can be found at Decisioning -> Infrastructure -> Revision Management -> Revisions.

·         These revisions are primarily used to implement the config parameter to alter the decision application behavior

·         To sendback the CR to the RevisionManager, use SendBack CR option incase any additional RuleSet access required.

·         Once you submit the Revision, jar package file will be generated. We need to download them.

·         To implement the changes in pre-prod & Prod environment, Decisioning -> Infrastructure -> Revision Management -> Revisions->Import revision

·         Select the Operator from the available list to test the changes for the selected operators before promoting the change.Decisioning -> Infrastructure -> Revision Management -> Revisions->"Activate" the change. Change will be activated to all the users. We can roll-back if needed

·         After activating the package, we need to logout and login again

Working with the Revision Management is 2 set process. 1. Create Revision. 2. Create CR. We can have more than 1 CR in a given Revision. Once Revision Submitted, Jar will be generated. If the change is not working, we can revert the change by doing "Roll-back", otherwise activate the Revision.

More details about app overlay setup is available at https://community.pega.com/knowledgebase/articles/decision-management-overview/applying-changes-business-rules

Happy Learning!

PEGA Decisioning (DSM) - Strategy Design Patterns

Avoid Redundant Product Offers in PEGA Decisioning Strategy

To avoid the same product recommendation which customers own already, from PEGA we need to define the data relationship using DataFlow. For example, to cater to a use case where a customer owns multiple products and details of all products are available in a Product master table. So, there is a one-to-one relationship between the ProductHoldings and Product entities.

Now to implement the business case discussed (Filter the products already owned by the customer), you must filter out the products already owned by the customer. For this, you use a strategy pattern that is composed of three components: Data Import, Data Join and Filter, we can filter out the products which customer is holding already.  DataImport+DataJoin+Filter is the Strategy design pattern used to achieve.

 

Making NBA more relevant using Interaction History - Learn from IH (Interaction History)

Update the Strategy to include a component that retrieves Interaction History data for previous phone offers. We then filter out phone offers for customers that have accepted a phone offer in the past. We can of course make the filtering process much more sophisticated by considering phone upgrades, etc. But for the sake of our demonstration, we will keep the strategy simple; anyone who has been made a phone offer within the last 120 days will not be made another phone offer of any kind. IH+GroupBy+Filter is the Strategy pattern used to prevent Redundant offer recommendation in PEGA Strategy logic.

Interaction History Data model in PEGA7 & Extending the IH Data Model

Interaction History users STAR schema (Inherited from Cordiant framework) uses 1 FACT table and 8 Dimensions table. DIM table always has non-duplicate reference records which can be referred in FACT table using PK-FK relationship. IH table stores all Interactions in IH Tables through pegaDATA schema.

For more details, refer the PDN article- https://community.pega.com/knowledgebase/articles/decision-management-overview/interaction-history-data-model-pega-72-73

 

We can also extend the PEGA’s IH table. Below PDN reference article has all the needed information - https://community.pega.com/knowledgebase/articles/decision-management-overview/extending-interaction-history

 

The process of extending the Interaction History layer in your application consists of the following steps:

1.        Adding columns in a database table

a.        Write a alter sql statement to alter the IH Table

2.        Adding extensions in application rulesets

a.       Perform the following actions to extend Interaction History with the HandleTime property for the call center application:

                                                               i.      Add a new property HandleTime of type Integer to the Data-Decision-IH-Fact data model in the application ruleset of the call center application.

                                                              ii.      Add the HandleProperty to the SR class of the call center application.

                                                            iii.      Override the pyInteractionHistoryConfiguration data transform in Data-Decision-IH-Configuration for the call center ruleset:

1.        Add a Set action and set Primary.pyFactProperties(<APPEND>) to "HandleTime".

2.        Add a Set action and set Primary.pyMeasurements(<APPEND>) to "HandleTime". This step is necessary so that you can use the property as a KPI.

3.        Enable the Call superclass data transform setting.

 

Happy Learning!