Pega Marketing Consultant common mistakes
Pega Marketing Consultant · Understand the traps and how to avoid them.
When asked to design an arbitration or next-best-action flow, the candidate draws only a single proposition or action per customer, ignoring that arbitration is meant to select the best set of actions from multiple propositions and channels, and fails to place the arbitration component correctly after eligibility and suitability.
Candidates memorize the NBA lifecycle as a linear list of stages and treat 'arbitration' as a synonym for 'pick one offer', so they never internalize that arbitration balances multiple candidate actions against each other and against contact policy and capacity constraints across channels.
What to do instead
Rebuild the lifecycle from the decision data model outward: eligibility filters candidates, suitability scores them, and arbitration selects a ranked set while respecting constraints. Practice sketching a flow where three propositions compete for one customer across email and web, and explicitly show where each stage trims or ranks the candidate list.
The candidate treats the Next-Best-Action Designer as a place to configure business rules directly, hand-editing strategies inside the designer instead of building reusable decision components and referencing them from the designer's engagement policies and arbitration settings.
The designer's UI presents engagement policies, arbitration, and contact policies in a single wizard-like surface, which makes it look like a rule-authoring tool. Candidates who learned the platform by clicking through the UI mistake configuration surfaces for development surfaces.
What to do instead
Learn the separation of concerns: reusable strategies and decision data flows are built and unit-tested independently, then wired into the designer. In any design answer, state which logic lives in a reusable component and which is a designer-level policy, and justify the boundary.
When designing a decision strategy, the candidate chains components without specifying the input and output shape at each boundary, so a component that expects a page list receives a single page or a scalar, and the strategy cannot be validated.
Candidates focus on the business logic of each component (a filter, a score, a prioritization) and treat the data passing between them as an implementation detail, because the strategy canvas visually connects components and hides the type mismatch until validation fails.
What to do instead
Before drawing any strategy, write down the candidate population shape at entry and the required shape at each component boundary. Practice reading a component's property configuration to confirm whether it consumes a page, a page list, or a single value, and annotate every connection in your design answers.
The candidate builds a strategy that scores and ranks actions but never applies contact policy, suppression, or fatigue rules, and then cannot explain why the output differs from what the business expects in production.
Scoring and ranking are the visible, satisfying part of decisioning, while contact policies are configured elsewhere in the designer and are easy to overlook. Candidates who practice only in a clean test environment never see suppression fire.
What to do instead
Treat contact policy as a mandatory stage in every NBA design. In practice, seed the customer with prior outbound contacts and verify that suppressed actions disappear from the final output. In written answers, explicitly name which policies apply at which stage and in what order relative to arbitration.
The candidate cannot distinguish adaptive models from predictive models and answers questions about learning, model refresh, and performance monitoring as if both behaved the same way.
Both appear as 'models' in the strategy canvas and both produce propensity-like scores, so candidates collapse them into one concept and lose the distinctions around data requirements, learning behavior, and monitoring.
What to do instead
Build a comparison table covering data requirements, when the model is trained or updated, how it responds to new data, and how each is monitored. Practice explaining which model type suits a cold-start scenario and which suits a mature, high-volume proposition, and state the tradeoff explicitly.
The candidate designs an adaptive model or predictive model but never specifies the outcome definition, the positive versus negative labeling, or the performance metric used to judge it, so the model cannot be evaluated.
Candidates treat model creation as a configuration task (pick a model, pick a proposition) and skip the analytical framing, because the platform's UI lets you create a model without ever forcing you to articulate what success means.
What to do instead
For every model in a design answer, state the outcome being predicted, how positive and negative responses are captured, the time window for attribution, and the metric used to judge performance. Practice writing this framing in two sentences before touching any configuration.
The candidate answers architecture questions by listing platform components without describing how data flows between the customer data layer, the decisioning layer, and the delivery channels, and cannot explain where real-time versus batch processing occurs.
Architecture questions reward breadth, so candidates name components they recognize from training material and stop there, never having traced an actual decision request from channel to response.
What to do instead
Trace one end-to-end decision: a customer opens a channel, a decision request is assembled, the strategy runs, and the response returns with the selected actions. Draw this path and label each hop as synchronous real-time or asynchronous batch, then explain what happens when the decisioning layer is unavailable.
The candidate treats the customer profile and interaction history as a single undifferentiated store, so designs that depend on real-time behavioral data are answered as if the data were already aggregated and available at decision time.
Training material often presents customer data as one conceptual 'profile', and candidates never separate reference data, aggregated history, and streaming events, so latency and freshness assumptions go unexamined.
What to do instead
Classify each data element a strategy needs as reference data, aggregated history, or real-time event, and state its expected freshness at decision time. Practice identifying which parts of a strategy would break if the freshest data were delayed by minutes.
The candidate writes a strategy that produces correct results in a single test case but never considers volume, performance, or how the strategy behaves when a component returns no candidates or an error.
Practice environments have small data sets and happy-path test data, so candidates never encounter empty candidate lists, timeouts, or degraded components, and therefore never design for them.
What to do instead
For every strategy, enumerate the failure branches: empty input, all candidates filtered out, a component error, and a timeout. State the expected fallback for each (for example, a default action or a graceful empty response) and include these branches in design answers.
The candidate describes testing as 'validate the strategy' and never distinguishes unit testing of individual components, strategy-level testing with representative data, and business-level validation of NBA outcomes against contact policy and business objectives.
The platform offers a validation action that gives a green check, and candidates equate that check with testing, so they never build a layered test plan or describe what evidence proves the design works.
What to do instead
Define a three-layer test plan: component-level tests with crafted inputs, strategy-level tests with realistic candidate populations, and business validation comparing selected actions against expected policy outcomes. In answers, name the specific data you would seed and the specific output you would assert.