Offer deduplication within NBAM UpgradeIPhoneStrategy
Doing the Pega Marketing Essentials course, I don’t understand how Offer deduplication is managed; ie what prevents a customer from being selected more than once? As a customer can be eligible for SMS, Email and DirectMail; in the UpgradeIPhoneStrategy they may ‘pass though’ all three channel variants of the offer. The Prioritize Properties shape selects pxPriority (previously set to prioritise the channel) and is set to Output Top 3 (not Top 1)?
Question: How does the deduplication work, to ensure a customer only receives one message regardless of how many channels they are eligible for capable of being contacted in?
Thanks
Owen
Pegasystems Inc.
NL
Owen
Offer deduplication takes place in the Constraint Optimization stage of the Program execution (if Volume Constraint is used). Only one Offer (or an Offer variant to be precise) for a customer is selected based on the value of pxPriority.
A couple of points on how the value of pxPriority affects Offer deduplication:
1) If pxPriority is set to the same value for all Offers/Offer variants, then deduplication of Offers still takes place, but you don't have control over which Offer/Offer variant gets selected for a customer.
2) If pxPriority is not set or set to a non-numeric value, then pxPriority is considered as '0' (zero) and the Offer deduplication will not take place.
Regards
Guru
Comet Global Consulting
GB
So there is ‘real’ dependency – is there a validation check?
I don’t know how important a validation check might be, if you assume pxPriority is always used and is always numeric, then it’s not important. I guess you need to weigh up the likelihood of exceptions to this? The answers is probably yes, there could be exceptions, for example in a simple (quickie) outbound program scenario using very minimal logic.
It would be sensible in future training material to be clearer on these points; to avoid some idiot (like me) from discovering this in a live situation… if a Strategy is used in a program with volume constraints then pxPriority must be set and must be numeric greater than zero.
Does pxPriority need to be a positive numeric?
The other question, is with optimisation constraints I assume the highest numeric pxPriority is always selected, so you must always design logic that increases pxPriority in favour of the NBO (or Best Offer variation) ie high = high; you can’t reverse it and say low = high.
Thanks for your help Guru
Pegasystems Inc.
NL
Owen
A validation is not important in a purely decisioning application. However in NBAM it’s a good idea to have some sort of warning/reminder while submitting the program. Unfotunately, there is none at the moment.
Positive vs negative values must be veried. But we can safely assume that since pxPriority is a decimal property, negative values will be considered as having lesser priority than positive values and -1 would be higher priority than -3.
Yes, high=high, you can’t reverse it.
Regards
Guru