We've collected various findings around decision models and programmable nodes working with Sitecore Personalize.
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!
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.
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.
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.
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.
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.
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.
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.
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:
It's easy to start working with us. Just fill the brief or call us.