Scenario Best Practices

This section summarizes experience-driven best practices that should help you get the most out of Bloomreach Engagement's scenarios.

Best Practices

Filter out irrelevant customers ASAP

When building the scenario flow, using non-personalized condition nodes filter out all irrelevant customers from the scenario as soon as possible after the scenario trigger. Let only the relevant customers flow through your scenarios.

Always condition after a trigger

After the scenario trigger 99.9% times comes at least one non-personalized condition node. This is in line with the best practice number 1. above.

Save progress frequently

When building and/or editing scenarios, save them frequently to avoid unpleasant surprises and loss of work.

Checking active scenarios

Check your active scenarios regularly to see if some might need attention or stopping.

Archive old scenarios

Archiving old scenarios can help reduce clutter

Waiting in wait nodes

Repeat all essential conditions of your scenario after any wait node. Anything might change for the customers flowing through your scenario at any time.

Consent setting and condition

If you are sending any marketing campaign to your customers, always use proper consent setting in the action node. In addition, filter out customers without appropriate consent also through a condition node. It will enhance the security of your scenario, reduce unnecessary suppressions and in case of AB testing it will prevent results distortion.

Frequency policy and condition

For action nodes, especially for campaigns ther are sent to real customers it is strongly recommended to always use some frequency policy setting. In other words, never use the "Unlimited" frequency policy when sending anything to real customers. The only exception is a strictly transactional communication, but also for transactional communication you can set a policy of for example maximum 1 communication per 1 minute. Frequency policy is also fail safe against multiple sent of the same communication to the same customer in very short time.

Static wait time

Do not use wait time longer than 7 days. Instead use Repeat trigger and condition that would check for events from time 7 (or more) days ago. In case you need to stop a scenario for any reason, or in case of certain technical errors, customers waiting in the wait node will be aborted from the scenario.

A/B split nodes position

In case of AB testing, try to put AB split nodes as close as possible to the action nodes. Avoid further filtering out customers after AB split nodes since it can distort your AB test results.

Naming scenarios and action nodes

Name your scenarios (tracked as campaign_name) and action nodes (tracked as action_name) consistently and use a set naming convention. This will enable you to filter and segment your campaigns and campaign actions easily and sustainably.

Naming condition nodes

Name your condition nodes in the form of a closed question (Yes or No answer).

Thorough checking

Always check your scenario thoroughly before the first start. Check all the nodes, filters, and settings multiple times. If possible let someone else to check the scenario after you as well.

Thorough testing

Always test your scenario as thoroughly as possible before starting it for real.

Close monitoring after start

Even thorough checking and testing might not uncover all mistakes/gaps/bottlenecks of your scenario. That is why it is important to observe the scenario after the start closely and run essential reports to verify one last time everything is ok.

Tracking scenario leavers

If you need to find out which customers are dropping off your scenario at specific nodes, connect an "Add event" node to your flow at that node and track a custom event for them.

Frequency capping

For almost every kind of communication regardless of channel it is important to include frequency capping conditions in the scenario flow that will ensure your customers get the communication "A" at most "X"-times in the period of "T" days/weeks/months.

Frequency capping of the control group

In case of AB testing it is important to exclude customers that have previously fallen into the control group in line with the frequency cap of the campaign variant(s). Ensure your customers will go to the same AB split node "A" at most "X"-times in the period of "T" days/weeks/months.

Bad Usage Examples

Too many on event triggers

Importing millions of events at once and allowing them to trigger "On event" scenarios.

Trigger and action without condition

Using a Now, Repeat, On date triggers with action nodes without any condition nodes that would filter out irrelevant customers

Too many or too frequent set attribute

Setting attribute values for too many customers at once or too frequently.

More than 1 dynamic wait in series

Using more than one dynamic wait time node in a series.