Preventing multiple email sends in event-triggered scenarios
One common issue when implementing event-triggered scenarios is the potential for multiple email sends in quick succession when closely tracked events are involved. It can lead to unnecessary emails, overwhelm customers, and create inefficiencies in your campaign.
This article provides a solution for effectively using event timestamp checks to ensure your scenarios behave predictably and avoid redundant sends.
The problem
Imagine a scenario where an event, such as cart_update. Triggers an email campaign. If the customer makes multiple updates to their cart within a short time frame, the scenario might trigger numerous times, sending several emails. This behavior can confuse recipients and harm your metrics and reputation.
The solution: using event timestamp conditions
To address this issue, we recommend implementing a condition that checks for the most recent event timestamp. Ensuring the scenario processes only the latest event prevents multiple triggers from enqueuing redundant campaigns.
Here's how this safeguard works:
Add a Timestamp Condition: Use a condition to compare the event timestamp with the last recorded timestamp. It ensures that the scenario processes only the most recent event.
Example condition:
last cart_update.timestamp equal to {{ event.timestamp }}last cart_update.timestamp
It references the timestamp of the most recent cart update.
- created as an aggregate, then used in the condition:{{ event.timestamp }}
It uses the trigger event's timestamp for comparison in the scenario:
- Enable Personalization for the Condition: Ensure the condition uses Jinja syntax as shown in the screenshot.
- Test the Condition: Verify that the scenario processes only the most recent event by simulating multiple cart updates within a short time frame.
Example scenario: cart reactivation email campaign
To illustrate, let's consider our cart reactivation email campaign. The goal is to email users who updated their cart, but only for the latest update.
Follow these steps:
- Create the Scenario: Define the event-triggered scenario for
cart_update. - Set Up the Timestamp Condition: Add the condition to compare the event timestamp as outlined above.
- Test and Launch: Validate the setup by testing with multiple cart updates to ensure only one email is sent per user.
Customize the Scenario for Different Events: If you need it, you can adapt this solution to other types of events by replacing
cart_updatethe relevant event name in the scenario and the expression as well. The principle remains: compare the event timestamp to process only the latest occurrence.
Why this works
By incorporating a timestamp condition, the scenario filters out older events and processes only the most recent one. It prevents redundant triggers without limiting the scenario's handling of valid events.
Complementary solution using frequency policies
While the timestamp check is an effective first line of defense, the condition (last cart_update.timestamp equal to {{ event.timestamp }}) can fail if two trigger events happen within an exact second. If the timestamps are rounded when processed (for example, losing millisecond data), two separate events will trigger the campaign twice, and the aforementioned condition won't prevent this.
This is why Frequency Policies, applied directly to the Action Node (email, SMS, and more), are the critical, standard complement for limiting sends and preventing customer fatigue.
A Frequency Policy sets a minimum time interval between sends of the same campaign.
How it Works: You define a cooldown period (for example, "1 per 1 day"). The policy is checked right before the email is sent from the Action Node. If a customer qualifies to enter the scenario but has recently received a campaign using this policy, the send will be suppressed, and the customer will exit the flow.
Benefit: The frequency policy acts as a guaranteed final barrier against over-sending, regardless of how close the trigger events were.
Note:- When using a "Set recipient manually " option in an email node, Frequency Policies are not applied. As a result, emails sent to Custom Recipients may bypass Frequency Policy suppression and continue to be sent even when a Frequency Policy is configured.
Conclusion
Handling multiple event-triggered scenarios efficiently is critical for maintaining customer trust and engagement. By implementing a Dynamic Timestamp Check and reinforcing it with a Frequency Policy, you can ensure your campaigns are precise, effective, and well-governed.
This layered approach enables your scenario to dynamically adapt to customer actions, preventing both redundant, near-instant emails caused by technical latency and overall message fatigue. Start implementing these changes today for a smoother, more reliable event-triggered campaign experience!