It's possible that a Real-time Data Grid node is not behaving properly. This service is crucial to capturing Next-Best-Action customer journey data. If the nodes are not configured properly, no journey data will be recorded.

1. In the header of Dev Studio, in the Configure menu, click DecisioningInfrastructureServicesReal-time Data Grid.
2. Ensure that all nodes are reporting NORMAL status.
3. If a node status is not NORMAL, click the Execute menu in that node's row, and then select the Start option to make the node operational again.

In the Journey Visualizer, there is a series of controls that allow you to configure the timeframe for the journey data that you want to view. The options are Current Quarter, Last Quarter, and This Year. By default, Current Quarter is selected.

Ensure that the selected timeframe is applicable for the date and time captured in the responses that should be shown.

1. Open Next-Best-ActionDesigner
2. Click Channels.
3. Locate the channel that you want to check from the list of available channels. If the Channel switch is toggled to the left, the channel is not enabled. In this case, click Edit, and then turn on the Channel switch.
4. Click Save.

There are a number of Decision Data Rules that are used to support customer journey functionality. When you have problems with the customer journey results, the specific rules are:

• Group-level DDRs (one DDR for each Group defined in the hierarchy, named according to the Group's name and in the SR class path)
• NBA_Journey, located in the <SR Class>-NBA_Journey-NBA_Journey class

Each of these rules should have pyJourney and pyStage on the Form tab as form fields. If the property is not defined on the tab, journey data will not be saved properly to the necessary data sets, and the data will not be reflected in the Journey Visualizer.

If these properties are not present on the Form tab, they will need to be added manually:

1. Click Check out for the DDR, if checkout is required for the environment.
2. At the bottom of the property list on the Form tab, click the Add field button, and add fields for pyJourney and pyStage.
3. Click Save, and then click Check in.
   If this DDR has been moved from a previous environment (or will be moved to another environment), it is very important that the pyEditElement circumstanced section that is associated with the DDR is moved with it. It is also worth checking that the associated pyEditElement is configured as expected.

Each customer journey stage allows for configuration of detailed filtering. If an interaction does not meet the entry criteria for a stage, it will not be considered for that stage in the journey. If an interaction doesn't qualify for at least one stage in the journey, then the interaction will not be reflected in the Journey Visualizer at all.

1. Open Next-Best-ActionDesigner.
2. Click Engagement Policy.
3. In the Business structure section, choose the customer journey that you want to check.
4. Click the More icon on the specific stage that you want to check.
5. Select View entry criteria (in read-only mode), or Edit stage entry criteria (in editable mode).
6. Ensure that the expected interaction meets at least one stage's criteria, and either update the criteria or revise the interaction to reflect the desired behavior.
   It is possible for more than one journey stage to be applicable for any given interaction. In this scenario, the backing logic will generally attempt to place the interaction in the furthest right applicable stage. This includes the Complete (last) stage. If the interaction is not showing up where it is expected to be applicable, ensure there are no other stages that are also applicable.

It is possible to configure eligibility, applicability, and suitability conditions at the Action, Group, and All Groups levels, to control how an action is prioritized. Unlike with the journey criteria, which only determine whether an interaction is applicable to the journey, this potentially means that certain actions will never be presented to the customer if the conditions are not met. If there is an action for which an interaction is expected, it is important to check that the relevant conditions for that action are not preventing it from being presented.

The action conditions can be checked directly on the action rule form. It is also possible to see any inherited conditions from the Group-level criteria.

The Group-level conditions can be viewed on the Engagement policy tab of the Next-Best-Action Designer. Be sure to check the All actions conditions, as well as the conditions for the context in which the action is defined.

Lastly, the All Groups conditions can be checked on the All groups node on the Engagement policy tab of Next-Best-Action Designer. Check conditions defined for the context in which the action is defined.

If the interaction with the action in question meets all of the criteria in these locations, it should be considered for presentation to the customer.

It is possible for multiple actions to be returned in some circumstances. It is then important to determine whether the customer journey-associated action in question is the top-ranked action output.

When the Container service is called, it may return more than one applicable action as part of the response. Determine whether the action in question is being returned with a pxRank value of 1.

A lot of understanding of the situation can be gained by checking the Interaction History table to determine what data has been written for the interaction in question.

This can be found in the pr_data_ih_fact table in the pegadata schema of the database. By using pzjourneyid, it is possible to determine what customer journey information is associated with the interaction because it is joining on to the pzid of the pr_data_ih_dim_journey table. This will provide the pyJourney and pyStage values that were recorded. Similar action can be taken with the pzchannelid column in the fact table, to determine the pyChannel value stored in the pr_data_ih_dim_channel table.

Whether the interaction is being verified in a container REST response or in the Interaction History, it is important to confirm that pyJourney and pyStage match the journey and stage IDs for the expected customer journey. If they do not, their data will not be reflected in that journey and stage.

For more information, see Cause: JourneyActions Decision Data Rule is misconfigured.

If an action does not have treatments associated, it will not be output for channels that do not have treatments. Add at least one treatment to each channel for which the action should be considered, then save and Check in the action. Then, re-process the interaction.

For more information, see Cause: Treatment configuration.

On the Channels tab of Next-Best-Action Designer, ensure that the channels for which the action has treatments (or the channels that should be active in general) are toggled on. Any channels that are off will not be considered for Next-Best-Action output.

For more information, see Cause: The action’s Channel is not active.

Behind the scenes, each customer journey and stage is given an identifier that is used to tie all of the configurations together and support runtime processing. If for any reason, these values have gotten out of sync, proper functionality will be disrupted.

In the <Model Name (usually NBA)>_Journey DDR, there should be a row for each stage of each customer journey associated with the model. Each row should have the convention <Model Name><JourneyID><StageID>. That is, if there is a customer journey called “Platinum Cards” with a “First Awareness” stage and a “Complete” stage, there should be a row that is likely called NBAPlatinumCardsFirstAwareness and a row called NBAPlatinumCardsComplete.

These rows should match the proposition values in the JourneyEligibility proposition filter, where conditions are stored under <Model Name>_JourneyIssue and <Model Name>_JourneyGroup. If there is not a row in the proposition filter for each proposition row in the DDR, data has fallen out of sync and the customer journey may need to be re-saved.

Model maturity is a feature that impacts the back-end processing of interactions that may result in newer actions being suppressed until the model has had a number of interactions processed. This can be a factor in why a particular action is not promoted, even if all conditions and criteria are met. It is possible to toggle this feature off for development and testing purposes, but this is definitely not recommended in any customer environments, as this behavior is intended in real-world scenarios.

For more information, see Check whether outbound model maturity is enabled.

Next-Best-Action Contact Policy will impact how many times a particular entity can receive an action in a given time frame. The applicable Contact Policy can be checked by selecting the Constraints tab of Next-Best-Action Designer, and viewing the Customer contact limits section.

The backing Contact Policy rule can also be accessed by clicking Edit on the Constraints tab. An Edit customer contact policy link will appear beneath the Customer contact limits section. This link does not appear in read-only mode.

For more information, see Cause: Contact Policy suppression.