Hi @sumansinha, the recommended way to handle Prospects in CDH is through a flag/indicator on the customer class which designates this individual as a prospect instead of a full customer. What is your use-case that you are trying to use Propects?
As per our usecase, some Offers would be displayed to the Anonymous user (who would provide some very basic details like name, mobile number , mail id ,age ) in the React based portal. This React based UI would call Pega OOTB REST api to display relevant offers (configured inside NBA) to the prospect. We will capture the impression also when prospect will click on the offer using OOTB REST api.
Since Prospect could be configured inside Context Dictionary along with Customer, so we are thinking to store Prospect data into a separate table. Our assumption was that since SAVING of Context Dictionary will create many CDH specific rules in the backend , so it will create some Prospect related rules as well in Prospect data class which we could leverage later on.
However if Pega is recommending to handle Prospects in CDH through a flag/indicator on the customer class, we should be fine for this approach.
Posted: 1 year ago
Posted: 30 Aug 2021 12:53 EDT
Seth Robinson (SethRobinson)
Director, Product Management, Next Best Action
@sumansinha If an anonymous user could also be a customer which hasn't been identified then treating them as a customer will also allow you to take advantage of a merged history of their behavior from anonymous to identified.