Architect Journey Starter: On Past Behavior

This starter is the most capable starter that you can select in the journey. 'On Past Behavior' takes users into a journey based on the following segments:

This starter can take users from every platform such as web-site, mobile application, contact list, and also when there is data coming from the Upsert user data or offline environment. The same users can perform  events or can have attributes across the platforms. In this case, 'On Past Behavior' considers the last action or the last updated attribute of users. For example, you select a product page view event and also select purchase history as purchase count is 1 and the user visited the product page on the mobile app but made a purchase on the web site. The user will still enter the journey since the condition is met even if the user did this on different platforms.

'On Past Behavior' triggers users based on the selected trigger frequency. It can be a minimum of 60 minutes. Also, it starts to work at the nearest time to 8, 23, 38, 53 past o’clock according to your launch time.

Take, for example, a case where you select a 60 minutes trigger frequency in 'On Past Behavior'. You launch your journey at 10:05. 'On Past Behavior' will start working at 10:08 and the next iteration will be at 11:08 as you set the time period to 60 minutes. 

Let's say you aim to send an email message to a group of 850,000 users, and want all of them to receive the message at the same time (e.g. 10 am). To do this, you can use the Wait until a Time Slot element within your journey following the recommended practices below:

1. Adjust journey schedule: You can schedule your journey to start no later than 5 am. This allows you to allocate a maximum of 5 hours for user collection before the intended send time.
2. Set trigger frequency: You can set the trigger frequency of the On Past Behavior to 1 hour. This ensures that each segment of users, up to 200,000, is processed once per hour.
3. Incorporate Wait until a Time Slot element: You can place the Wait until a Time Slot element after the On Past Behavior starter and before the message you intend to send. Set the wait period to cover the desired send time window (e.g. 10 a.m. to 11 a.m.).
4. Achieve user group collection: Over the course of five hours, the On Past Behavior starter will process five segments of users, accumulating in the “Wait Until a Time Slot” element.
5. Simultaneous message sending: At the designated time (10 a.m.), the Wait until a Time Slot element releases the collected user group, sending them as a cohesive unit to the subsequent message element.

This way, you can ensure that the large user group is collected and engaged simultaneously, and achieve your goal of synchronized message delivery. While it requires careful planning and coordination, this approach maximizes the utilization of the current system and provides an efficient solution for targeting larger user segments.

How does reachability check work?

Architect automatically eliminates users from entering the journey if they will drop immediately after they enter due to not being reachable on the first channel they face for better and more precise reporting. However, you can make sure how many users will enter your journey in the launch step of the journey. You will see the estimated audience count and exact audience count on the Review and Launch Steps.

Click the Get Exact Audience button to see the exact count of users in your segment before launching your journey.

Below are some examples with respect to this logic.

Case A

Let’s say you have the Web Push channel in the first step, and multiple channels after that. If your user is not reachable on the Web Push channel but for Email or App Push, Architect will not let your user enter the journey as they will be dropped in the Web Push channel.

Case B

Let’s say you have App Push and Email channels in the first layer of your journey and your users will first face these channels during the flow. If your user is not reachable for App Push or Email but for Web Push, they will not enter the journey as they will drop in the first layer without receiving any messages. However if your user is eligible for App Push or Email, they will enter the flow. It is enough to be eligible for one of the channels in the first layer as the logic works with an OR connection.

Case C

Some exceptions apply to this logic. Let's say you have a journey with the Call an API channel, and it is placed before the first layer of the channel in the journey. Since the requests that will be sent through this channel might vary, this logic does not apply in this case. This means that all users will enter the journey. The same rule applies to the Update User Attribute and Update User Segment action elements.

Tips & Tricks

• Segmented users may come from Upsert User Data API or offline environment or any other source and might lack language information. That’s why we suggest selecting the “All Languages” option on the launch popup.
• You can use the Predefined Segments without the need of selecting any attributes.
• You can combine events with attributes.
• You can take users based on uploaded static segments.
• You can use event parameters to narrow down the segments and better target your audience. 
• You can use custom events in this starter. You can also create custom events manually.
• You can use Default, Custom, CRM, Mobile App attributes in 'On Past Behavior'.
• You can filter your users based on their channel reachability. This way, you do not need to take users who are not already reachable on the channel. 
• There is only one type of channel in the journey.
• There are different types of channels in the journey, but in the first branch there is the same type of channels.
• There are different types of channels in the journey, but until the first branch there is a channel element.

Use Cases

With the On Past Behavior starter, you can:

• Target users who didn't make a purchase in the last 30 days,
• Target users who clicked on an app push and also have high discount affinity,
• Target users who visited applications between 10.03-10.04 and visited more than 5 product pages,
• Target users who submitted the lead collection form and added items to their cart but didn't make a purchase,
• Target hibernating or potential loyalist users,
• Target users who are in the static or dynamic segment,
• Target users who are likely to purchase.

Requirements

• Insider Tag integration should be completed.
• SDK integration should be completed for mobile app data reading.
• Your website should be mapped by Insider.
• Events should be activated.
• Events should be sent from the web site, mobile app, Upsert User Data API or offline environment.