1. What was the intention behind this (see title)? I would like to know the thoughts of Pega product engineering. The product usage documentation that would allow me to work with prospects (see all questions from me and from the linked post) seems to be insufficient. Could a kind soul come to rescue please?

The Pega Marketing Implementation Guide version 8.2 instructs users to create the prospect class with applies to <YOURAPP>-Data-Customer-Prospect. This causes the Prospect class to stop saving into the out of the box prospect DB table, and to start saving into the customer table.

2. So why the product points to one prospect DB table out of the box? And 3. why it is made to point to another during the implementation? 4. And why would one stay with the out of the box config; or move to save prospects in the customer table as instructed? See some performance considerations above

5. This saving into the customer table also causes to have pre-existing customers listed as prospects when one double clicks the customer class to view the list of instances. How to prevent this, also for the datasets and strategies? 6. Or this is not an issue as the customer for a strategy would be searched by key anyway?

7. Is there a field to differentiate customers from prospects? I searched for a database column with name prospect and there was none. Is this field present also in the customer table? Will it prevent prospects entered in the table from listing as customers? 8. The PegaMKT-Data-Customer table also has no field such as isProspect, nor are we instructed by the guide to create it.

Before I do something stupid and get a guardrail warning. 9. What is your recommendation to work with prospects loaded daily via files?

10. WHat is your recommendation to work with prospects in real time. People visiting the website and generating leads (such as by filling out a form with their personal details)? I cannot put them quickly in the prospect table as this is the same as the customer table and is therefore loaded with the CAR daily from the datawarehouse. I could have considered calling an activity to create a new object in the old prospect class (out of the box config).

I read the whole documentation on the implementation guide. I read the whole identity matching documentation. I read this whole post: https://community1.pega.com/community/pega-support/question/difference-between-prospect-and-customer

And like Mr. Duarte on the post above, I am still left without answers to very simple and direct questions (mine and his). I don't think anybody answered his question.

Could some kind soul please advise us? I have done identity matching before, but I have not done prospect marketing before, and am interested in doing it now as a prototype. The documentation that would allow me to trail a best practices path is insufficient. I know I have many questions, but these are all product usage questions, nothing out of the ordinary to ask.

11. Assume I want to do decisioning for website visitor banners (my website) using variables such as vistor browser type; visitor referrer (i.e. website URL that referred browser to us). I could pass these in the container call context (rest section in container call, sectioning containing a list of context variables), that works. THis could be passed to the adaptive model.

12. Now suppose I want to keep the website browser visitor data late-on as prospect data and put it into the CAR as the initial browser and http referrer the person used to land at our site (quite useful to link acquisition to retention). 13. What would the recommended approach be using Pega? I know I can do all this with servlets on the website, and with some ad-hoc tables saving browser data and later loading them via an association in the strategy, but assume Pega allows to create some website visitor data. I think an activity with object-new could create a prospect in the old out of the box prospect table. 14. Also how to run decisioning if there is in principle no customer id, no customer, no prospect, just a cookie id and a visitor data (referrer and browser type). This is important for marketing as depending on the referrer it may be best to advertise one product that referrer talks about; and if it is another referrer I may want to advertise another product.

I thought about creating a view that would join website visitor data with prospect data (SQL union) and then use identity matching to match cookie id from website visitors to newly created customer ids.

15. If the number of unique visitors to the website is large; this would bring my customer table browsing to its knees (saving all visitors there). So one more reason to keep the prospect table browsing separate. But then, 16. should we save visitors as prospects? Is it intended for that?

Again. Your thoughts as product engineers? I will make it worth a lunch and a beer in Amsterdam Zuid if the answer gets extended and I need to hear it again. Just being nice!

Thanks in advance, Andre'