DEV Community

Cover image for Sitecore Personalize: tips & tricks for decision models and programmable nodes
Anna Gevel for ByteMinds

Posted on • Originally published at byteminds.co.uk

Sitecore Personalize: tips & tricks for decision models and programmable nodes

While working with Sitecore Personalize, I've collected various findings around decision models and programmable nodes. Some of them were the result of a human error, while others were just specific rules and conventions I discovered while using the platform. So I'm sharing these tips and tricks in the hope that they prove as valuable to you as they did to me.

1. Remember to return a value from programmable nodes

Starting with a fundamental tip: when creating custom programmable nodes, ensure you include a return statement at the end of the JavaScript function. It's easy to overlook, but without it, your decision model might return unexpected results.

When I added my very first custom programmable node to a decision model, it took me a while to find why the model was working incorrectly. It turned out my programmable node was calculating everything correctly, but there was no return statement after calling an internal function. I don't know how I expected Sitecore Personalize to know which value to use! 😅

The "return" statement at the end of the programmable node is important


2. Set the correct return type in programmable nodes

Specify the correct return type in programmable nodes, aligning it with the decision table's comparison rules. Whether it's integer, long, double, string, boolean, date, or map, choosing the right type is necessary for seamless integration with the decision table.

This is the data type we will be using later for comparing values in the decision table


3. Avoid leaving empty lines in decision tables

They are not as empty as I thought! Beware of seemingly harmless empty lines in decision tables. A forgotten line can lead to hit policy errors or produce incorrect output, because hyphens in input columns act as wildcards. For instance, in the example below, the first row applies to all guests of "customer" type, irrespective of their page views count.

Line #4 is not empty, it will match guests of any type and with any number of events


4. Name decision table output columns carefully

When naming output columns in decision tables, remember that output of the decision models can be used in Freemarker templates for web or full stack experiences. Opt for output reference names without spaces or special characters for easier integration later.

Make sure the output reference is Freemarker-friendly


5. Pay attention to workflow in decision model

Before using a decision model, move at least one variant to the production state. Once in production, the variant becomes non-editable so make sure to test it before moving it to production. But don't worry, if any changes are required further down the line, you can always duplicate the live variant and update the newly created draft.

Keep at least one variant in the Production column for get decision model results


6. Save decision model versions with comments

When making significant changes to your decision model variant, choose the "Save with comment" button. Comments will be visible in the revision log, making it easier to track changes. They will also help finding the right version to revert to if that's required.

Comments will help to find the right version in the revision table


7. Use the right case in input columns

Be cautious with the values in decision model input columns as they are case-sensitive. Inconsistent cases may lead to unexpected behaviour, so ensure you are using the right values, especially when copying them from other sources.

Input column values are case-sensitive


8. Use decision templates

If there is a programmable node that you or your marketing team will likely reuse, then consider saving it as a decision template. Decision templates allow adding configurable parameters that will be displayed as a user-friendly form and you won't need copying the same JavaScript code from one decision model to another.

Friendly UI of decision templates


9. Watch executionTime in test canvas

This is probably the most important recommendation from me: optimise performance of your decision models. Regardless of the type of experience and integration approach you use, long execution times will negatively affect user experience on the website and all other channels connected to Sitecore Personalize.

To ensure the most efficient performance, Sitecore Personalize imposes data limits on the amount of data that is available in decisioning and conditions. In addition to this, you can apply the following techniques to improve execution time of programmable nodes and decision models:

  • Look only at the data that you need by limiting the number of sessions and events you check
  • Break the loops and return values from functions as soon as you have found what you need to avoid accessing and iterating through unnecessary data
  • Leverage batch segments and user data extensions where possible to make decisions based on already calculated and saved data
  • Reduce the number of elements and connections on the decision canvas
  • Limit the number of programmable decisions on the canvas to three or four as recommended by Sitecore. If multiple programmable decisions use the same data, consider combining them into one element.
  • Keep the number of external data systems and AI models minimal in a decision model. Sitecore recommends to include one or two data systems and/or AI elements.
  • Reduce the number of rows and columns in decision tables. Where possible, combine conditions by using hyphen (-) to eliminate unnecessary checks.
  • Ensure that the model returns only one decision

Watch execution time of the model and its individual elements in the test canvas


I hope these insights ease your journey with Sitecore Personalize. Feel free to share your own tips or ask questions in the comments!

Top comments (0)