This section summarizes experience-driven best practices that should help any user get the most out of Bloomreach Engagement's scenarios.
- 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 CONDIION - 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 "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.
- AB 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 form of a closed question (Yes or No answer).
- THOROUGH CHECKING - Always check your scenario thoroughly before 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 nodes 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 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.
- 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 series.
Updated about 2 months ago