Best practices for creating decision models

For optimal results in decision models, we recommend these best practices. These guidelines are important when you are creating decision models and integrating various components into the variants.

Creating the layout

When you create the structure of a decision model variant on the decision canvas, it is important to build the decision model components starting from the bottom of the canvas and finishing at the top. The ultimate decision that the decision model variant is making is placed at the very top. There should only be one ultimate decision to ensure optimal performance. Having consistency in the layout of a decision model variant is also important because it enables any user to immediately identify the overarching decision just by looking at the top of the decision canvas.

The following image shows a sample decision model variant where the overall decision is Determine discount, which is placed at the top of the decision canvas.

Adding comments

It's best practice to add a comment to a decision model variant each time you save. To do this, in the top-right corner, click the arrow next to Save and then select Save with comment. When collaborating with team members, the comments can provide more context and clarity about each revision made.

To view the list of revisions and associated comments on a decision model variant, click Revisions. This helps you track and review changes, especially as the list of revisions gets longer.

Using naming conventions

To ensure consistent and easily identifiable names for decision model variants, we recommend the following naming conventions:

Returning early in JavaScript

When using JavaScript in a decision model component such as a programmable, returning early from a function means stopping the execution of the function as soon as the desired outcome is achieved. This prevents unnecessary computation, saving time and resources.

For example, when searching through a guest's sessions for a piece of data that's likely to be in a recent session, like the most recent page view, it's best practice to exit the function as soon as the page is found:

function getLastViewedPage() {
    for (var i = 0; i < guest.sessions.length; i++) {
        var currentSession = guest.sessions[i];
        for (var j = 0; j < currentSession.events.length; j++) {
            var currentEvent = currentSession.events[j];
            if (currentEvent.type === "VIEW"
            && currentEvent.arbitraryData
            && currentEvent.arbitraryData.page )
            {
                return currentEvent.arbitraryData.page;
            }
        }
    }
}

By returning the page early, you avoid unnecessarily iterating through the remaining events and sessions. This saves time, especially when working with large arrays.

Minimizing loops through the same data

When you need to retrieve multiple data points from the same dataset in your decision model using JavaScript, we recommend to do this in a single pass to avoid performance degradation that comes with multiple iterations.

The following function shows how to retrieve various custom values in one iteration over the sessions, enhancing efficiency by reducing the number of times the data is accessed.

function getLastViewedPage() {
    var customValues = {};
    for (var i = 0; i < guest.sessions.length; i++) {
        var currentSession = guest.sessions[i];
        for (var j = 0; j < currentSession.events.length; j++) {
            var currentEvent = currentSession.events[j];
            if (currentEvent.type === "CUSTOM_EVENT_1")
            {
                customValues.firstValue = currentEvent.customValue;
            }
            else if (currentEvent.type === "CUSTOM_EVENT_2")
            {
                customValues.secondValue = currentEvent.customValue;
            }
            else if (currentEvent.type === "CUSTOM_EVENT_3")
            {
                customValues.thirdValue = currentEvent.customValue;
            }
        }
    }
    return customValues;
}

Using the entity object

When creating decision models for triggered experiences, it is often necessary to identify and interact with the object that triggered the experience. This might be a guest, an event, a session, or an order. This object is stored in the entity object at the top level of the guest context.

The entity object contains only the top-level attributes and does not include all nested values, for example, session events. To obtain the full original object and use it in a decision model, you need to search through the guest context using the object reference.

Here's a function that shows how to retrieve the session object that triggered the experience, using the reference stored in the entity object:

function getTriggerSession(){
  var sessionRef;
  if (entity && entity.ref !== 'undefined') {
    sessionRef = entity.ref;
  }
  var triggerSession;
  for (var i = 0; i < guest.sessions.length; i++) {
    var session = guest.sessions[i];
    if (session.ref === sessionRef) {
      triggerSession = session;
      break;
    }
  }
  return triggerSession;
}

Retrieving custom values in interactive experience requests

Interactive experiences often require dynamic decision-making, which often involves passing custom values with the requests to these experiences. These values are important for personalizing the interaction based on user input. To access these values, you can use the request variable. By convention, custom values are stored in the request.params.

Here's a function that retrieves a customValue from request.params:

function getRequestCustomValue(){
  if (request && request.params && request.params.customValue) {
    return request.params.customValue;
  }
}