Strategy Returns Duplicate Rows for the Same Customer
A retail bank uses Pega CDH to rank 12 card and loan propositions for 2.1 million online banking customers. The decision strategy is built as Data > Filter (eligibility) > Group By (customer segment) > Prioritize (top 3 by propensity) > Map. The real-time container is configured to return one offer per customer per session. After a release, the container started returning two or three offers for 18% of customers, and the call-center desktop shows the same customer with different offers in the same minute. The strategy test output shows 12 rows per customer before Prioritize and 3 rows per segment after Prioritize, but the customer ID is not the group key. The bank also reports that a new balance-transfer adaptive model has a flat propensity of 0.50 for all customers after six weeks, despite 220,000 impressions and 1,100 responses.
1. Diagnose the duplicate-offer symptom. What is wrong with the strategy logic, and what change would guarantee one row per customer?
Read the worked answer
The Group By is on customer segment, so Prioritize selects the top three actions per segment, not per customer. Every customer in a segment is treated as one group, and the strategy can emit multiple rows for the same customer. The container expects one row per customer, so it returns duplicates. Grouping by segment also makes the Prioritize result meaningless for individual personalization.
Change the strategy to Group By on the customer identifier, then Prioritize top 1 per customer, then Sort by score. Use segment only in Filter or as a weight, not as the grouping key. If the strategy runs on the customer page and joins produce multiple rows, the Group By on customer ID deduplicates them. Validate with a test customer set and assert exactly one row per customer. Also confirm the container's offer-count setting matches the strategy output shape.
2. The adaptive model for balance transfer is stuck at 0.50. Explain the likely cause and the corrective actions, including how to validate outcome capture.
Read the worked answer
The response rate is about 0.5%, which is low but not necessarily too low to learn. A flat 0.50 after six weeks usually means the model is not receiving labeled outcomes, is not in learning mode, or its score is being overwritten. Check that the real-time container returns a response event containing the model ID and action ID, and that the data flow writes that event to the adaptive model's outcome dataset. Without positive and negative outcomes, the model cannot learn.
Check the Adaptive Model reports for response counts and predictor values. If the model is included in the strategy, confirm that its propensity is mapped to the score and not replaced by a decision table. Validate that predictors are populated; null predictors also prevent learning. Corrective actions: fix outcome capture, enable exploration such as 10% random selection, verify negative outcomes are recorded, and use a predictive model as a cold-start fallback. Rerun the strategy test and monitor the model's performance report.
3. What testing would you require before promoting the revised strategy to production?
Read the worked answer
Require a strategy test with synthetic customers covering every segment, null values, duplicate customer records, and missing predictors. Assert exactly one row per customer and the expected top offer per segment. Add a contract test that calls the real-time container with a sample request and validates the response shape and offer count.
Run a load test at production-like peak volume and measure p95 latency. Shadow-run the revised strategy in production and compare offer distribution and response capture against the current version. Use revision management to promote the same revision, keep a rollback plan, and monitor row counts and model response rates after release.