Pega CPDC common mistakes
Pega CPDC · Understand the traps and how to avoid them.
Treating Next-Best-Action Designer as a single monolithic configuration object instead of recognizing the four distinct layers (Customer, Engagement policies, Decision data, Treatment/action hierarchy) and which layer owns which behavior.
Candidates study the NBAD landing page as a checklist and memorize tab names, but the exam tests where a given behavior is implemented. Without a layer map, every scenario question becomes guesswork.
What to do instead
Build a one-page map: Customer (context dictionary and hierarchy), Engagement policies (conditions, suitability, applicability), Decision data (action/group hierarchy and propositions), Treatment (treatment and channel wiring). For each practice scenario, write which layer changes before looking at answers.
Confusing applicability, suitability, and eligibility conditions and applying them at the wrong level of the engagement policy.
All three are 'conditions' in the UI and all can filter a proposition, so candidates memorize the labels without the semantic difference: applicability gates whether an action is considered at all in the context, suitability ranks/weights within what is applicable, and eligibility-style constraints are typically expressed as applicability rules on the group or action.
What to do instead
For each condition type, write one sentence on its purpose and one example, then classify ten sample business rules into the correct type. Pay special attention to which conditions live on the group versus the action.
Assuming the top-ranked proposition by propensity or score automatically wins, ignoring arbitration and the final decision logic that selects the output.
Candidates learn adaptive model scoring first and treat score as the decision. In reality the highest score can be overridden by arbitration, priority, or caps, so scenario questions about 'what gets offered' are answered with the wrong component.
What to do instead
Trace a single example end to end: model score, then any weighting or business levers, then arbitration, then final selection. Practice questions that ask 'why was action B offered instead of higher-scoring action A' and answer with the arbitration mechanism, not the model.
Mixing up the arbitration types (for example priority-based, weighted, and adaptive/propensity-driven) and which one is configured where in the strategy or NBAD.
Arbitration is the least intuitive area for candidates coming from campaign backgrounds; the names sound interchangeable and the configuration surfaces overlap, so they default to 'highest score wins' or 'first in the list wins'.
What to do instead
Create a comparison table: arbitration component, input it consumes, and the outcome it produces. Then answer questions by first identifying which arbitration component is active, then reasoning about inputs. Do not reason from score alone.
Believing adaptive models are trained offline like classic predictive models and expecting coefficients or a fixed model equation.
Candidates with data-science backgrounds look for a training step and interpretable weights. Adaptive models learn incrementally from outcome feedback, so there is no offline training job and no static equation, which breaks their mental model.
What to do instead
Reframe: adaptive models update per response using outcome labels, predictors are binned/grouped, and performance is judged by predictive performance metrics rather than coefficients. Practice explaining in one sentence how a single customer response changes the model.
Ignoring the predictor and outcome configuration when diagnosing weak model performance, blaming the algorithm instead.
Adaptive models only learn from what they are fed. Candidates skip predictor selection, binning, and outcome definition, so they cannot explain why a model has poor performance or why it never learns a behavior.
What to do instead
Memorize the dependency chain: outcome definition, then predictors available at decision time, then feedback loop that records the outcome. When a question describes a model that 'never improves', check outcome mapping and predictor availability first.
Treating simulation testing as a live A/B test and expecting it to change production behavior or require real customer traffic.
The word 'test' suggests deployment. Simulation runs against historical or synthetic data in a sandbox to compare strategies, so candidates misjudge what it can and cannot prove and pick answers implying production impact.
What to do instead
State the purpose precisely: compare alternative strategies or champion/challenger configurations against captured or sample data without affecting production. Learn the input requirements (data set, sample size, outcome data) and the output (comparative results per strategy).
Confusing simulation with adaptive model learning or with strategy testing in a non-production environment, and choosing answers that describe one as the other.
Both involve data and both are 'safe', so the boundaries blur. Candidates cannot distinguish comparing configured strategies from updating model state.
What to do instead
Write a two-line contrast: simulation compares outcomes of configured alternatives on a data set; adaptive learning updates model state from recorded outcomes. Then classify five exam-style scenarios into one bucket or the other.
Misreading the customer context and hierarchy, assuming all customers share one context or that context is only a data page.
The Customer layer defines the dimension along which data and strategies are resolved. Candidates treat it as a data source and then cannot answer questions about why a strategy resolved differently for a segment.
What to do instead
Learn context as the key that determines which data, strategies, and propositions apply. Practice questions that describe two customers getting different offers and identify the context/hierarchy as the cause before considering models.
Approaching overview-level questions as trivia about product modules rather than as the decisioning lifecycle, so answers about where a component fits in the flow are guessed.
The overview domain rewards understanding the end-to-end loop (data capture, next-best-action determination, arbitration, delivery, feedback), but candidates skim it to get to configuration details and lose easy conceptual points.
What to do instead
Draw the lifecycle loop from memory and place each component (data, NBAD layers, arbitration, adaptive models, simulation) on it. Answer overview questions by locating the component in the loop rather than recalling a definition.