How does PEGA Marketing/Decisioning Strategy work? Understanding the PEGA Marketing/Decisioning Strategy execution through “Marketing funnel”

I have come across the scenarios where Marking team is finding difficulties in understanding how does PEGA Marketing/Decisioning Strategy work. As a technical guy, I found bit difficult in explaining the PEGA’s complex Decisioning Strategy logic in non-technical terms where all Markers can understand the complex logic.

I would like to explain the PEGA Strategy logic with the “Marketing Funnel”. Yes, PEGA Strategy rules filters the offers using Marketing Funnel technique. All The eligible offers will send over to the top level strategy and each strategy has logic to filter the offers (applying rules) similar to the Marketing funnel. PEGA Strategy has many pre-built Strategy components & uses the same to select offers and send to next stage.

A Marketing funnel is a way for us to track the Offer eligibility of customers. By understanding where in the funnel, or where in the customer’s eligibility, Marketers can decide what kind of marketing message to send them.

The marketing funnel is simply a visual representation of a sometimes difficult subject to visualize. Think of it as a map of your businesses marketing and sales processes, procedures and strategies.  Left of the funnel includes your broadest marketing efforts and is narrowed as potential Offers move through it. The breadth the funnel goes the more focused your potential Offers become. Eventually you will weed out all the Offers that are not willing to recommendations and left with the most valuable sales qualified Offers. 

Marketing funnels are so effective is because it makes you take a hard look at exactly how our business recommendations various offers based on the context. What eligibility criteria to adjust to recommended the offer to balance customer needs & business objective.

Defining Engagement Policies:

Defining Engagement policies in PEGA7 done by when rules & set of PropositionFilter. All the criteria's are classified as Eligibility/Hard rules.  

Defining Engagement policies in PEGA8 simplified with NBA Designer. PEGA8 NBA Designer uses E(Eligibility), A(Applicability) and S(Suitability)– Rules by clearly separating engagements.  

• Eligibility rules, which are strict rules representing what it is possible to offer.
• Applicability rules, which represent business practices that limit what to offer based on a customer’s current situation. These are not as strict as eligibility rules.
• Suitability rules, which represent what the business should and should not do ethically and empathetically. These are the least strict rules.

Pega Decision Management combines business rules (Engagement policies- specify the conditions under which an offer or group of Offers is available for a customer), predictive and adaptive analytics with real-time Decisioning to initiate and adjust processes based on the business criteria we have established. Inbuilt PEGA Decisioning rules help us to select the right offer ensuring the right decision for the right customer at the right time.

Pega Decision Management makes defining complex decision strategies simple and efficient to help organizations:

• Dramatically improve customer experience in every channel with strategies based on real-time, actionable insight into operational and behavioral data.
• Rapidly deploy intelligent processes with pre-built business accelerators to create and maintain comprehensive decision strategies without the need for any coding.
• Make dynamic changes to decisions, processes and interactions based on real-time customer data and feedback.
• Leverage adaptive and predictive capabilities to make the best possible decisions based on historical and real-time responses.
• Seamlessly integrate existing applications and processes to improve operational efficiencies and respond to customers across all channels.

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.

PEGA Decisioning - Predicting Customer Behavior Using Real-time Data

·         Applying adaptive analytics to your strategies will enable them to detect changes in customer behavior as they occur and act on them immediately

·         Adaptive Decision Manager is a closed-loop system that automates the model creation, deployment, and monitoring process. It can manage a large number of models without human intervention.

·         ADM can capture and analyzing response data in real-time. cases where data is available for offline modeling, predictive models can be used as an alternative, or in conjunction.

·         ADM models to be created under Customer class, Decisioining, Adaptive Model

·         Any Single value Property from Customer class can be a predictor. It can be added under Predictors tab. It can be either symbolic/Numeric. PEGA ADM will automatically remove the unused predictors

·         Define Positive & Negative Outcomes under Outcome Tab

·         On the Settings tab of the Adaptive Model rule instance, you can define values that will fine tune the behavior of a model as a whole. For example, the ‘Performance threshold’ value is a limit that indicates that any predictor performing below this threshold will not be used to predict customer behavior.

·         When you configure an adaptive model record no models are created. The models are created on-the-fly, once there is demand for a given model. When it evaluates the Adaptive Model component, it requests the propensity for each single proposition or channel combination that is dictated by the component inputs. If the models do not exist, they are created at this time

·         It is strongly recommended that you set both the channel (.pyChannel) and the direction (.pyDirection) properties in your strategies before you use adaptive models. The channel and direction settings enable you to make decisions based on customer behavior in a specific channel.

·         Adaptive Model Outputs - Propensity, Performance, and Evidence

Propensity – This is the predicted likelihood of positive behavior. Such as, the likelihood of a customer accepting an offer.  The propensity for every proposition starts at 0.5 or 50% (the same as a flip of a coin) because in the beginning the model has no response behavior on which to base its predictions.

Performance: This is how well the model is able to differentiate between positive and negative behavior. Again, the initial value for each model is 0.5, with 1.0 being perfect performance. Therefore, the performance value should be somewhere between 0.5 and 1.0. Performance is generally used to differentiate between two models relating to the same proposition.

Evidence: – The number of responses used in the calculation of the Propensity.

In strategies, model propensity is automatically mapped to the strategy property called .pyPropensity. 

There is no automatic mapping for the Performance or Evidence outputs. But they can be manually mapped to any of the strategy properties under the Output mapping tab (ModelEvidence, ModelPerformance).

Smoothened Propensity: To reduce the ADM Propensity error in early days.

(@divide(.StartingEvidence, (.StartingEvidence + .ModelEvidence+1.0),3) * .StartingPropensity) +

 (@divide(.ModelEvidence, (.StartingEvidence + .ModelEvidence+1.0), 3)*.pyPropensity)

Where: Starting Evidence and Starting Propensity are proposition properties representing the assumed values for evidence and propensity.

Pega Decision Management uses “Coefficient of Concordance” (CoC) to measure the performance of predictors and models.

 

 

 

Trend Deduction:

·         How to measure the performance of the new Proposition using Adaptive, Trend Deduction.

·         Define the required Predictors, Outcome (keydown will prompt IH Data options) and memory settings (Run analysis after 500 records)

How to define More than one ADM for the same propositions?

·         Define the 2 diff ADMS using different Memory settings

·         Add 2 ADMs and add GroupBy Proposition (pxIdentifier) with the highest performance. Now, we should able to select the highest performance Proposition.

 

All ADM models Management options can be found under ADM Management.

o    Clear Model - Clears the model responses

o    Delete Model - Removes the physical model

o    View Model Properties - see the settings of an Individual Model parameters

o    Upload Responses will allow you to import the Historical data. upload the CSV file and map the outcome.

Monitoring the Adaptive Models:

·         DS->Decisioining->Monitoring->Adaptive Models Reporting

·         You can analyze the Behavior report under Reports to analyze the Active/Inactive predictors. Also the Classifier allows you to analyze the propensity.

·         Performance Model allows you to analyze the performance of the ADM

·         The Predictors overview will enable you to analyst the various predictors defined

The implementation of the Next-Best-Action mechanism is a staged process with each stage refining the proposition selection process.

PEGA Decisioning - Avoiding Loan Default with Predictive Analytics

For predictive analytics algorithms to work we must have access to historical data which exhibits known customer behavior. We must also know what problem we are trying to solve in our case probability to default.

These fields are called predictors and are combined into a predictive model which you can use in your business processes.

Predective Model involves 5 Steps:

Data preparation, Data analysis, Model development, Model analysis, Model export

Predictive analytics director supports two types of models:

·         Scoring Models - for the prediction of binary behavior

·         Spectrum Models - for the prediction of continuous behavior

Scoring Models:

The value calculated by the model, known as the score, places a case on a numerical scale. High scores are associated with better business (good behavior) and low scores are associated with worse (bad behavior). Typically, the range of scores is broken into intervals of increasing likelihood of one of the two types of behavior. Scoring models require behavior to be classified into two distinct forms like positive and negative. Classic examples of such behavior are:

·         Responding to a mailing or not

·         Repaying loans or going into arrears

Spectrum Models:

Spectrum models extend the ideas of scoring models to the prediction of continuous behavior

·         Likely purchase value of responders to a direct mail campaign

·         The likely eventual write-off of cases recently falling into arrears

Model Template:

In the Predictive Analytics Director portal we have defined a number of model templates which you can use. These include Risk, Retention, Recruitment, and Recommendation.

 

Select the appropriate Model Template and start working on the Project

1) Model Creation:

·         Select source as CSV file or DB

·         Set the Sampling size using % & tot. cases. Define the properties to be used and the type of the property

·         You identify the field which you are trying to predict. In this example, the field is behavior. The field exhibits binary characteristics (N/Y) so the scoring model is the most appropriate.

·         Now define Good & Bad behavior under Outcome definition.

2) Data Analysis:

·         Predictive Analytics Director facilitates automatic discovery of correlation patterns of individual predictors and their ability to predict the outcome. Any unique identifiers will not be a valid predictors. customer ID appears to be a reasonably well performing predictor. However, since we know that customer ID is a random number or a member of a sequence, it cannot have any impact on the good or bad behavior. Thus we remove IDs from the candidate list for predictors. Any property which is common to use to differentiate the good and bad behaviors can go as a predictor

·         So data analysis involved in defining the properties & Binning (Split the data into Buckets) and then grouping by predictors.

3) Model Development:

·         Predictive Analytics Director provides a rich model factory supporting industry standard models such a regression and decision tree models.

·         The system automatically creates two models: the Regression and the Decision Tree-CHAID model. At this stage, you can create additional models if required.

·         We can group the predictors into Group,. Which means either Predictor A/B/C outcome will be considered. Eg. HouseOwner/Rented etc.

·         Also look at the scorecard representation model to check the scores of the predictor and define the weight of the predictor from 0-1000

4) Model Analysis:

·         Model Analysis is to enable you to create a shortlist of models and then select the best model for your use case. At this stage, you also group the scores into statistically significant set of score bands; firstly, let’s examine the relative performance of individual models.

·         A very important aspect of each model is its performance, i.e. how good is a model or a given predictor in predicting the required behavior. We use a term “Coefficient of Concordance” or (CoC) for the measure of the performance of predictors and models. You could describe CoC as a measure of how good the model is in discriminating between good cases from bad cases. The value of CoC ranges between 50%: a random distribution, and 100%: the perfect discrimination.

·         Analyze the Models created and select the models where how good the model is in discriminating between good cases from bad cases.

·         There are following steps in Model analysis: Score Comparison, Score Distribution and Class Comparison.

5) Model Export:

·         In the final stage, you can produce the reports about the model and export the model into a model file or an instance of the Predictive Model rule. Check the customer properties and the predictors created in the model under input mapping.

·         The report contains:

1.     A project summary

2.     A visualization of the whole Decision Tree

3.     The sensitivity of the model for each of the input fields

4.     Model segmentation

5.     Detailed insight in the analysis, grouping, and validation of each of the attributes

6.     Date when the model was developed and by