Pega CPDC cheat sheet

CDH delivers one-to-one customer engagement by combining real-time container data with predictive and adaptive analytics at every interaction point.

Next-Best-Action is the decisioning pattern: for each customer, actions are matched to the customer's context, scored, and the highest-value eligible action is selected and delivered.

Decisioning happens at the interaction (for example a web click or inbound call) and at outbound runs; inbound decisions are real-time, outbound decisions are batch-scheduled.

The decisioning lifecycle is: capture context, identify customer, determine eligibility, score actions, arbitrate, deliver, and learn from the outcome.

Adaptive models learn from responses continuously, while predictive models (scorecards) are built offline from historical data and refreshed on a schedule.

Three decision-management layers exist: business layer (actions, treatments, propositions), engagement layer (strategies, real-time containers), and data layer (customer profile, interaction history).

CDH is built on Pega Platform; business users change strategies and treatments in App Studio and Next-Best-Action Designer without modifying Java or rule-level code.

A proposition is the offer content; an action is the business intent that groups propositions and treatments; a treatment is the specific channel-specific presentation.

Value of an action in arbitration is generally the predicted propensity multiplied by the business value/weight of the action, so a low-propensity high-value offer can still win.

Customer profile data lives in the Customer class (Data-Customer or an application-specific class); interaction history lives in interaction classes such as Data-Decision-Request and Data-Decision-Outcome.

A strategy is a rule of type Strategy that passes data through shapes: Data Import, Data Transform, Filter, Group By, Set Property, and the strategy result output.

Strategy components are ordered and each shape receives a page list; the final shape's output becomes the strategy result (pxResults) that downstream components consume.

The Data-Decision-Request class stores the context of each decision (customer, channel, direction, timestamp); the outcome class stores the response used to train adaptive models.

Adaptive model predictors must be mapped to properties available on the customer page at decision time; a predictor that is null at decision time degrades model performance.

A data flow (real-time or batch) moves data between the operational datastore and external systems; real-time data flows serve individual decisions, batch flows run on a schedule.

The operational datastore (PegaDATA) holds customer and interaction data used by decisioning; it is not the same as the rules database.

Interaction history records which actions were offered and the outcome (impression, accept, reject); this feeds reports such as the Adaptive Model report and the arbitration analysis.

Strategy testing uses a simulation or a test run against a sample population; the strategy result must expose the properties arbitration needs (propensity, value, eligibility).

Next-Best-Action Designer is a guided, business-friendly interface that builds the decisioning strategy from three tabs: Engagement policy, Arbitration, and (optionally) Customer journey / channels.

The Engagement policy defines applicability: which actions are eligible for a customer based on conditions, audience, and issue/group hierarchy.

Actions belong to issues and groups; the issue/group hierarchy organizes the catalog and drives eligibility and reporting.

A treatment is attached to an action and specifies the channel and content; an action can have multiple treatments for different channels.

The NBA Designer output is a strategy (often named NBA_Strategy or similar) that can be inspected and extended in Dev Studio, but the Designer is the supported authoring surface.

Action-level constraints (such as maximum number of times an action can be offered per customer per period) are set in the Designer and enforced during arbitration.

The Designer supports 'contact policy' settings such as suppression, fatigue, and channel limits that restrict which actions can be offered.

Changes in NBA Designer are versioned and can be tested in simulation before being committed to production.

The Designer's arbitration tab configures the arbitration formula and the priority/weight of actions; the default arbitration uses propensity and value, with priority as a tiebreaker.

Arbitration selects the winning action(s) from the eligible, scored candidate set according to the configured arbitration formula.

The default arbitration formula is: priority (as a filter/ordering), then propensity × value, with tie-breaking rules; the exact formula is configurable in the arbitration strategy.

Arbitration components include: eligibility filter, propensity scoring, value calculation, priority, and the final selection (top N).

Priority is an integer on the action; a higher priority can be used to force an action ahead of higher-propensity actions, and priority is often applied before the value calculation.

The arbitration strategy produces a ranked list; the top-ranked action is offered, and the remaining ranked actions can be used as fallback or 'next best' alternatives.

Contact policy (suppression, fatigue, channel limits) is applied before or during arbitration and can remove candidates from the eligible set.

Arbitration can be configured to return multiple actions (for example, a bundle of offers) rather than a single winner.

The arbitration result is recorded in interaction history with the propensity and value used, enabling later analysis of why an action won.

A common failure mode is a missing or null propensity, which causes the action to be dropped or scored as zero; predictor mapping must be verified before go-live.

An adaptive model is a self-learning model that updates its predictors after each outcome; it does not require offline training to start.

Adaptive models are created per action (or per group of actions) and per channel/direction; the model predicts the probability of a positive response.

Predictors are properties from the customer context; each predictor is binned, and the model learns a weight per bin.

The model's performance is measured by AUC (area under the ROC curve); AUC near 0.5 means no discrimination, near 1.0 means perfect ranking.

A minimum number of outcomes (often around 100-200 positive responses) is needed before an adaptive model's AUC is considered meaningful; below that, treat scores as unreliable.

Adaptive model learning rate controls how quickly new outcomes change the model; a high learning rate adapts fast but is noisier, a low rate is stable but slow.

Adaptive models can be monitored in the Adaptive Model report, which shows AUC, performance by predictor, and the number of responses.

Predictors with little variation or high null rates should be removed; they add noise and can degrade AUC.

Adaptive models are used in arbitration to supply the propensity component of the value formula; their outputs are combined with business value to rank actions.

Simulation testing runs a strategy or NBA configuration against a sample of historical or synthetic data to estimate outcomes before production.

A simulation uses a sample population (for example, a random sample of customers) and applies the candidate strategy to produce predicted offers and responses.

Simulation results report the distribution of winning actions, estimated acceptance rate, and the lift versus the current production strategy.

Simulation does not change production data; it runs in a sandbox and its results are for analysis, not for actual customer delivery.

The simulation sample must be representative; a biased or too-small sample produces misleading lift estimates.

Simulation can compare multiple strategy versions side by side, which supports A/B-style evaluation before committing a change.

Adaptive model scores used in simulation come from the model's current state; if the model is immature, simulated lift may not reflect future performance.

Simulation is distinct from a test run: a test run executes the strategy for real on a limited set of interactions, while simulation uses historical/synthetic data with no customer impact.

Common simulation pitfalls include using a sample that excludes the target audience and ignoring contact policy, which can overstate the number of offers.