People change their minds all the time! Whether it's adding an item to cart and later removing it or changing the time of a dinner reservation, you know that users sometimes update or cancel after they've requested something from your brand. So how do you handle this in a journey?
To make sure users receive relevant messages based on the most up-to-date event data, you can set up checks in a journey to determine if an event has been updated after the user was added to the journey. Then, you can send users to the appropriate tile or journey depending on whether or not anything has changed.
NOTE
The solution presented in this article is one example of how to check for event updates in a journey, but it may not be the right approach for you. Depending on your use case and how your organization sends and receives event data, the best filtering criteria and journey setup for your organization may differ.
Example use case: Flight booking confirmation sequence
Let's say you work for a travel company called Fantastic Flights that helps users find and book flight deals. When a user books a flight, you probably want to send a few messages related to their itinerary:
- Booking confirmation (immediately after the user makes their reservation)
- Seat selection/upgrade nudge (one week before the departure date)
- Check-in reminder (24 hours before the departure date)
A journey is a great way to automate sending these messages to users who have active flight bookings. However, you don't want to message users incorrect information after they update or cancel a reservation! To prevent this, you can set up a filter before each message tile to ensure that the original booking is still active before users receive the message.
Let's assume that Fantastic Flights uses three custom events to track flight bookings, cancellations, and updates:
flightBooking
bookingUpdate
bookingCancellation
Since a user could change or cancel their booking before their departure date,
it's important to check throughout the journey that nothing has changed since
the booking was originally received. For this example, let's say the
flightBooking
custom event adds users to a journey called "Flight Booking
Confirmation Sequence." Here's what that journey might look like:
Removing users from the journey if they cancel a reservation
Since flightBooking
is the triggering event for this journey, you can
reference data from the flightBooking
event that added the user to the
journey using Handlebars
expressions. In this example, let's assume every flightBooking
, bookingUpdate
,
and bookingCancellation
event includes a data field called bookingId
.
In each filter tile, you'll need to set up a check to determine if any bookingUpdate
or bookingCancellation
events with the same bookingId
as the original
flightBooking
event have occurred since the user was added to the journey.
Here's what those filtering criteria might look like:
Note that you'll need to check the option Filter by: All events and user profile fields, since you're comparing multiple events in these filtering criteria.
When the user arrives at the filter tile, if there are no bookingUpdated
or
bookingCancelled
events with the same bookingId
as the original reservation,
the user will go down the No path (meaning nothing has changed with the
original reservation). This path connects to the message tile that sends the
check-in reminder message. If there is a bookingUpdated
or bookingCancelled
event with the same bookingId
as the original reservation, the user will go
down the Yes path (meaning the original reservation was updated or
cancelled). Leaving this path unconnected means users will exit the journey.
It's generally best to remove users from the journey at this point, since the original triggering event data is no longer relevant.
What about exit rules and Hold Until tiles?
You could set up an exit rule{{bookingId}}
to check if the triggering flightBooking
event and any
subsequent bookingUpdated
or bookingCancelled
events are related.
Adding users to a different journey if they update a reservation
The filters we set up in the "Flight Booking Confirmation Sequence" journey remove
users from the journey if a bookingUpdate
event with a matching bookingId
occurs (meaning the user's original flight itinerary was updated or cancelled).
If the itinerary is cancelled, you no longer need to send reminders for the user
to select seats or check in. But if the itinerary was updated, you still need
to send those messages — just for different dates or a different destination.
One way to do this is to set up a second journey (for example, "Updated Flight
Itinerary Sequence") that is triggered by the bookingUpdate
custom event. The
journey setup is almost identical to the "Flight Booking Confirmation Sequence"
journey, but it uses a different triggering event — which refreshes the event
data you can reference in the journey with the most up-to-date information.
TIP
To save time, consider using tilesets{{flightBooking.departureDate}}
to {{bookingUpdated.departureDate}}
).
Checking for the most recent instance of an event
Sometimes, it's helpful to know if the occurrence of an event is the most recent instance of its kind. For example, consider a traveler who's updated their flight reservation more than once. You may want to check if a given update to the flight reservation is the most recent one the user has made.
To do this, you can set up a check that looks at the custom event date for
the bookingUpdate
event and compares it to the createdAt
date captured
in the journey's triggering event. If there is a bookingUpdate
event with a
date after the triggering event's createdAt
date, this suggests that there
is a more recent instance of the event than the one that added the user to the
journey — so the triggering event data may no longer be relevant.
If a bookingUpdate
event is detected with a matching bookingId
and a date
that's after the createdAt
date captured in the journey's triggering event,
the user will go down the Yes path (meaning there is a more recent instance
of the event). Leave this path unconnected if you want users to exit the journey
at this point. If there aren't any bookingUpdate
events that match the bookingId
and have a date that's after the createdAt
date, the user will go down the No
path (meaning this is the most recent event of its type) and continue to the next
step of the journey.
NOTE
createdAt
is a standard Iterable event field that represents when an event
occurred. You can include this field in a POST /api/events/track