How to test next best action strategy for a single customer in multiline decisioning context

How to test next best action strategy for a single customer in multiline decisioning context

Description	This wiki design pattern describes how to run efficient diagnostics at the strategy layer for a single customer and answer the question “Why does customer X not get action Y?”.
Version as of	8.5
Application	Pega Customer Decision Hub
Capability/Industry Area	Next Best Action

Use case examples

It is crucial that you can find out at which stage of the next-best-action strategy framework execution a single customer is filtered out. If you are getting “Why customer X doesn’t get action Y?” type questions in your user acceptance tests, or in production environment, or in both, this article will enable you to efficiently run diagnostics at strategy layer for a single customer.

Before you begin

• Configure your Context Dictionary definitions according to your project requirements.
• Make sure to fully understand how multilevel decisioning works.

For more information, see Understanding multilevel decisioning and the Context Dictionary on Pega Docs.

Verify Context Dictionary Definitions

In multilevel decisioning, customer/subscriber class must be defined as your primary context. At a database tier, there is a one-to-many relationship between Account data and Customer Data entity. Therefore, you should associate the same customer/subscriber class with the Account class.

Customer/subscriber class must be defined as primary context and the same customer/subscriber class has to be associated with Account class.

Create a customer/subscriber data flow

1. In Dev Studio, create a new data flow in your Primary customer class, ideally at Artifacts ruleset.
2. Implement the following structure: a) Make the Primary context customer/subscriber class as your first entity in the data flow. You can see the same pattern in auto generated campaign data flows as well.
   

   Creating a customer/subscriber data flow.

b) Use the inbuilt Exclusion List data set under PegaMKT-Data-ExclusionDefault class to mimic production environment behaviour.

c) Add a new Compose shape.

d) Use the out-of-the-box ExclusionList property and join by using CustomerID property.

e) In the following shape, filter out these customers by a Filter rule condition e.g. @LengthOfPageList(.ExclusionList)=0

f) Then in the Convert shape, select Top-Level option, convert to DDRC (Data-Decision-Request-Customer) class, check Field mapping and join from pySubjectID to CustomerID (or SubscriptionID).

g) Import the auto generated Subscription/Customer data class under Account class. This out-of-the-box data flow will create the mandatory Account and customer properties which will be used by next best action strategy in runtime.

Compose property is the Account property under Data-Decision-Request-Customer class, which is a single page. Join condition is from SubscriptionID/CustomerID to pySubjectID.

Importing autogenerated subscription/customer data class.

g) Request Payload properties is an optional data transform element in the data flow. If you are testing an Inbound request or an event use-case, you can populate the data transform as per your test input.

Request Payload properties in data transform.

h) Finalize the data flow rule with an Abstract implementation and click Check in.

Result

Now, you are ready to test next-best-action framework strategy with your custom data flow.

1. In Pega Customer Decision Hub™ portal, search and open Trigger_NBA_TopLevel strategy.
2. In Test run pane, in Single case tab, call your data flow after enabling the Data flow option.
3. Provide the required customer/subscriber identifiers e.g. Subscription id, MSISDN, and AccountID fields. These are the selectable keys of your primary class i.e. may vary depending on your implementation.
4. Click the Run button and start your diagnostic processes.

Trigger next best action top level strategy.

Subscriptions are a way of notifying developers and users of actions that are related to an application, a report, or an event. Notifications are sent to subscribers by using an RSS feed, an email, or a notice on a dashboard.

Subscriptions are a way of notifying developers and users of actions that are related to an application, a report, or an event. Notifications are sent to subscribers by using an RSS feed, an email, or a notice on a dashboard.