Scenario FAQ section helps with answers on the most common questions and help with solving the most common issues. For any additional help with debugging, contact Engagement Support.
- What Happens if I Edit a Running Scenario?
- How to Check Scenario Changes History?
- How to Check Where and Which Customers are Dropping Off Scenario Flow?
- What Happens When a Customer Fails in a Campaign Node?
- How to Investigate Errors in the Action Nodes?
- How to Check the Activity of a Scenario on a Timeline?
- How to Debug Issues with Scenario Triggering?
- Why Am I Unable to Copy & Paste Nodes in the Scenario?
- How to Monitor and Check What Dynamic Content is Sent to Customers?
- In What Time Zone Do Scenarios Run and Why?
- What Time Zone is the Frequency Policy in?
- What is the Ideal API for Scenario Webhooks?
- Channel-Specific Campaign FAQs
Updating a node - the current users in the node (usually a very small number except wait nodes) finish the scenario with the old version, and all new customers coming to that node (no matter where they're coming from) will flow according to the new version.
Deleting a node stops the execution of all unprocessed customers in the node, e.g., customers in the wait nodes will be lost. They won't continue to the next node.
Creating a new node or modifying node connection applies immediately, e.g., modifying outgoing connection from a wait node means that existing customers in the node will use the updated connection once they are finished waiting.
After saving, starting and stopping of a scenario a new version of scenario is saved in "Scenario history". See Scenario History of Versions for more info.
The first source of information for "Where are my customers dropping of my scenario flow?" is the EVALUATE tab of your scenario. When hovering with your mouse over the nodes in your scenario, you see how your customers flew through it, how many were processed successfully and should problems occur, how many customers aborted the flow with an error. For condition nodes, when hovering over them you can check how many customers matched and how many customers did not match the conditions.
Should you need a precise information for customers that are dropping off loose ends of your scenario flow, you can track a custom event when that happens. Simply add an "Add event" node, and connect it to the loose end of your condition node. See "Scenario Operators" for how to add an "Add event" node.
When a customer fails in a campaign node (email, push notification, SMS), the customer does not proceed in the flow of the scenario. The exception to this is webhook which has two outputs: success and fail.
You may encounter an error message in action nodes in the scenario evaluation tab. That applies to action nodes, such as email, browser push, mobile push, webhooks, etc.
As an example, let’s investigate these webhook error messages.
To effectively investigate error messages, follow these steps:
- Create a Detailed Report:
Generate a report that reveals the nature of the encountered error. To begin, decide on the time frame for the report. If you're unsure about when the errors started, you can select the Lifetime option.
- Set Up Report Rows:
campaign > messagesin the report rows. This section comprises various messages, including error messages, providing insight into the reasons behind the errors. Ensure that grouping is set to Auto. Choosing None might overwhelm you with excessive error messages. For this discussion, we'll use the Top(4) option to focus on the four key error messages.
- Configure Metrics:
count > event > campaignmetric and specify the campaign ID associated with the error-generating messages. Also, indicate the action_id, which corresponds to the node number producing errors. In this example, it's number 9 (you can verify this using the webhook image). If you're interested in all error messages from a particular scenario, you can omit the action_id.
- Choose the Right Metric Settings:
Set the metric to All. Although First could work, it would only represent each error once per customer profile. Opting for All is useful when dealing with numerous errors and needing an overview of their overall distribution.
- Identify Error Sources:
Now, the sources of error messages are visible. You can delve into the root causes of these errors. This webhook in our example has an invalid header name, incorrect authentication, and no access key provided. Remember, these are just sample error messages for this webhook. You can encounter various error messages based on the action node type.
To check the activity of a scenario on a timeline, the best way is to use a report. With any timeline report the easiest approach is to
Add timestamp to the report
Rows. Choose format for the timeline as you wish (month/day/hour granularity). This will be the base timeline for your report.
Afterwards add a count event campaign metric. Afterwards you may further filter the metric based on what particular scenario events you are interested, or drill down the report in the report
Columns, for example by campaign
status attribute. This report based on the level of drilldown and specificity of the metrics can give you topline or detailed view on what has been happening with your scenario.
If the event-triggering mechanism relies on imported data, ensure that you've correctly set up the “trigger on-event campaigns” option in the import that imports data that are supposed to trigger scenarios.
If you discover that you haven't selected this option, enabling it won't retroactively activate all previous events. Instead, it will initiate the activation of scenarios from now on.
Sometimes, imported data might not automatically align with existing scenarios. Double-check that the imported event data matches the trigger conditions outlined in your scenarios.
It's easy to import events with current, past, and future timestamps. This section explains the consequences of importing an event with a future timestamp in the context of triggering a scenario.
Events will launch an on-event trigger upon arrival on the platform regardless of their timestamp. If we select such events in the 'On event' trigger without any date filter, then once these events are associated with the customer profile, they will trigger the scenario.
When utilizing any date filter in the ‘On event’ trigger, then it will trigger only events with timestamps in the past.
As an example, use the filter below with the ‘On event’ trigger:
In this example, the ‘abr’ event was imported with a timestamp in the future, but these events did not trigger using the above trigger, because of the filter condition. When using a date filter in an 'On event' trigger and importing events with a future timestamp, the imported time will not match the scenario trigger.
Please note that reimporting the same events will result in deduplication, but deduplicated events will still trigger scenarios if they pass the trigger filter.
For events added through scenarios, make sure to review the "allow triggering" option. If this option is not enabled, the trigger might not activate even if the event conditions are met. Verify that the "allow triggering" setting is appropriately configured for each scenario-added event.
Triggers rely on active scenarios to function correctly. Check whether the scenario associated with the trigger is active during the time of the trigger event. If the scenario is inactive, triggers tied to it won't fire. Ensure that the scenario is enabled and operational.
Triggers must be also set to active to fire. Make sure that all triggers you want to activate are active before launching the scenario. Inactive triggers will be grayed out, you can set them to active by clicking on the reset trigger button.
A subtle reason for non-triggering scenarios could be changes in trigger node conditions over time. If the conditions specified in the trigger node of the scenario have evolved or been updated, they might not align with historical events. Review the conditions set at the time of the trigger event and cross-reference them with the current scenario configuration.
You should make sure that event data is consistent, and that there is no data type mismatch or corrupted values (for example a list imported as a string). Ensure that the event payload structure aligns with the trigger conditions and data requirements, especially if events are coming from different sources.
as trigger conditions are consistent regardless of the event source.
There are certain types of events that do not trigger scenarios. Check if you are not using one of such events.
In some cases, a node that follows a trigger on an event node with less than 30 second delay will return a "no longer exists error" for the profiles created by the tracking of the trigger event. If you encounter such an error, increase the trigger delay, to allow a customer profile to be fully created by the time of the scenario triggering.
Maybe customer profiles did not reach the active node because of some filter node before it. If a scenario has a limit node make sure that it was not reached.
Make sure that the "clipboard" permission is enabled (following example is from Google Chrome, other modern browser should have a similar setup)
When you are located in the scenario navigate to top left corner and click on the lock icon.
Here you can quickly observe if the permission has been enabled.
If you for some reason fail to locate this permission there, navigate to browser settings, and proceed under privacy and security.
There are multiple ways how you can monitor what is actually being sent to your customers when you are using personalization. For tracking the most important elements and parts of content the best way is to use Custom campaigns tracking feature. This feature will allow you to track specific personalized values (usually results of personalization using Jinja) directly in the campaign events as custom attributes.
Alternatively, especially handy when testing campaigns with complex personalization, the helpful approach is to use real personalized content of your real customers in a test campaign. This usually involves using a webhook, which has the possibility to send information from one profile (real customer) to another profile (your testing profile) and provide real inputs for the testing.
The Scenarios and Email Campaigns always run in UTC-0 so you do not need to worry about time offsets due to different time zones.
The rationale behind the scenarios running in UTC-0 is that when a user triggers the scenario we want it to not depend on time zone (so that whether someone triggers the scenario in the US or in Europe, the same customers will flow through the condition).
if you use relative filters like THIS month, THIS day, etc., keep in mind that some things in the platform are adjusted based on your user time zone setting but scenarios are always evaluated and executed in UTC-0 to avoid inconsistent behavior if multiple people from different time zones work on the same scenario.
By avoiding a partial day filter like ‘today’ and setting a static period, you can make the most out of a relative filter. What we mean by static here is e.g. 1 hour before 7 days or 26 hours before 14 days, as required based on your target customer base location.
What does this mean for me if I am creating conditions using absolute time ranges elsewhere in the platform e.g. in Segmentations and want to use these in the scenario as conditions?
The time zone that you have selected will be calculated for the date times everywhere inside the project apart from the scenario. The scenario is looking at those date times from the UTC-0 perspective.
The frequency policy is always going to have the same definition for time as the absolute time filter, that if you filter last 1 day you will get last 24 hours.
The only exclusion to this would be the relative time filter. If you select one day on the relative time range as the frequency policy, you would get the range only since 00.00 in the time zone selected in your user settings.
What do weeks ago and months ago mean in the relative time filter? Would that be a week as in seven calendar days, months as in 30 calendar days as opposed to the same day in previous month and years in 365 days as opposed to the same date but last year?
We use the relative delta approach in the frequency policy. It adds months and years etc. such as adding literal years, so it also follows with leap years
So those are exactly 30 calendar days and 365 days in the respective relative time filters.
Our webhooks expect the API on the other side to work within certain standards. If you want to connect Bloomreach Engagement to your RESTful system, have a look at this article to prepare your API endpoint.
Updated about 2 months ago