BaU refers to business as usual or the ongoing operations after go live. It is actually not "as usual" because a digital transformation has taken place! But this should become the new normal.

These are generally configured to run daily.

You can define the propensity threshold. If offers for a customer fall below the threshold, then the customer will be counted as underserved. By default, Value Finder assigns a threshold of the bottom 95%, but this value can be customized if required.

Most large clients move their Interaction History (IH) data on a daily basis to their inhouse DB and they can retain this data based on their corporate strategy/policies. 

Eligibility is defined as when you will be eligible to get an offer (e.g. You need to be 18+ for getting a credit card). Applicability is defined as when a specific action/offer can be made to a customer (e.g. location based offers, customer meets account balance criteria etc.). Suitability ensures empathy in the actions (e.g. you don't want to offer loan or a credit card to someone with bad credit).

Not every rule type is supported by Ops manager.  Data transforms and section rules should be handled by enterprise pipeline.

Yes they can.  Adaptive models can be used at the action and treatment level to optimize for both.

If you have daily releases, then you can run the forum daily.

@sundm

Limited Availability (LA) Releases indicate that the capability has passed the Preview Release phase, and we intend to take it to a GA status – we just aren’t there yet. It comes with the following caveats:

It fully solves for a base (minimal) number of valuable use cases. However, it is premature in some GA hardened capabilities (e.g. UI errors/warnings, usability, Devops/revision management scripts, implementation & upgrade guides, etc.).

If a client intends to use it in production, we ask that this be discussed with the Customer Decision Hub product team to ensure we can support the intended use case and upgrade path which may involve manual steps, special work, etc.

Presently, we do support analysis of action performance in production VBD, but our long term vision is to shift reporting to the Business Operations Environment (BOE) so customers should start planning for this. In fact, we are targeting some new operational action performance reporting in the BOE for v8.7.

Action and Treatment creation should be taken care of by the NBA Execution forum. Once related parties analyze and scrutinize each new Action request, they would be able to control the growth of Action amount. That's the power and responsibility of the forum.

By default, there isn't any time to live value for IH Summary data sets and it's not required. These data sets aggregate interaction history in real-time to limit and refine the data that strategies process. For example, you can create a data set that groups all offers that a customer accepted within the last 30 days and use that data set in your strategy. The rule itself, last 30 days, filters IH responses in run-time automatically. Thus, there isn't any need to define a retention policy.

A few things to keep in mind:

- To begin with, make sure that business expectations are discussed and based on those outcomes the BOE is rightly sized.  - Always work with sample data sets i.e. avoid running simulations against the entire customer base. - Do not run simulations for every single change request, instead run the simulation for the entire revision package.  - Avoid running multiple simulations simultaneously.  - Conduct a performance test of the environment before going live and verify if number of threads, partitions, core and memory utilizations are as expected.

- Run multiple test cases to find the most optimum values for your environment / hardware.

Such activities are taken care of by Pega Cloud and Global Customer Service teams in Pega cloud. On prem implementations can create a separate tablespace for IH schema and apply partitioning on the Fact table based on their corporate needs.

The data in Business Operations Environment (BOE) should not be masked since BOE, by its definition, is an environment in production zone and must contain real customer data to run accurate simulations. 

Yes, propensity can be calculated separately for every treatment. For example, if a customer is most likely to interact with a push notification, an action which has a push notification treatment is most suitable for that customer. The Customer Decision Hub is configured to calculate the propensity for each treatment. This NBA-Designer feature will automatically determine the best treatment for the customer. On top of that custom Adaptive models can always be built to measure channel lift.

Yes. Scenario Planner is configured to run in the Business Operations Environment (BOE), supported by data that is moved from production to the BOE via the Data Migration pipeline.