> For the complete documentation index, see [llms.txt](https://docs.hackle.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hackle.io/en/crm-marketing/user-journey-guide/example.md).
# User Journey Examples
A user journey is a feature that creates an automated flow by combining **entry conditions**, **wait time**, **branches**, and **message channels**.
When designing your first journey, it is better to start with a flow that has a clear conversion goal rather than a complex scenario.
For detailed setup instructions, see [Creating a User Journey](/en/crm-marketing/user-journey-guide/create-user-journey.md).
### 1. Send welcome messages to new users
This is suitable when you want to drive the first action right after sign-up.
For example, you can configure it as follows.
* **Entry Condition**: Sign-up completed
* **Wait Time**: Immediately after sign-up or 10 minutes later
* **Message**: Introduce core service features, coupon information, first-purchase benefits
This flow is effective at reducing early drop-off, because it can immediately tell users what to do right after signing up.
It is often used for goals such as the following.
* Driving the first app launch
* Encouraging profile completion
* Driving the first purchase or first booking
{% hint style="info" %}
Welcome messages can become less effective the more information they contain. Drive only one action at a time.
{% endhint %}
### 2. Cart abandonment customer reminder
This is a scenario for bringing back users who had purchase intent but did not complete payment.
For example, you can configure it as follows.
* **Entry Condition**: Add-to-cart event occurs
* **Wait Time**: 1 hour or 24 hours
* **Branch Condition**: Drop off if purchase is completed during the wait
* **Message**: Reminder of cart items, low-stock notice, coupon offer
The key to this flow is **preventing unnecessary sends**. Set up an exit condition together so that messages are not sent to users who have already purchased.
When operating it, it is good to look at the following metrics together.
* Purchase conversion rate after the reminder send
* Difference in efficiency depending on whether a coupon is offered
* Difference in performance by send timing
### 3. A/B test by message channel
This is useful when you want to verify which channel the same audience responds to better.
For example, you can configure it as follows.
* **Entry Condition**: Entry into a specific cohort or occurrence of a specific event
* **Branch Method**: A/B test branch
* **Message Channel**: Push Message vs Alimtalk vs Text Message
Even for the same campaign goal, open rates and conversion rates can differ by channel. You can quickly identify customer groups with different channel preferences.
It is especially useful in the following situations.
* When the push opt-in rate is low
* When an urgent announcement must be delivered more reliably
* When you need to compare the cost efficiency of the same message
{% hint style="info" %}
When comparing channels, keep the message content and send timing as identical as possible. This allows you to see the differences of the channels themselves more accurately.
{% endhint %}
### 4. A/B test by message send time
Even for the same message, when you send it can significantly change performance.
For example, you can configure it as follows.
* **Entry Condition**: A specific action occurs
* **Branch Method**: A/B test branch
* **Wait Time**: Send after 1 hour vs after 2 hours vs after 3 hours
This scenario is suitable for finding the optimal send timing. You can check whether an immediate response is better, or whether a reminder one day later is more effective.
Common comparison methods to test are as follows.
* Immediate send vs next-day send
* Morning send vs evening send
* Weekday send vs weekend send
Send-time tests can produce different results depending on the type of message. It is better to verify purchase-driving messages and re-visit-driving messages separately.
### 5. Continue sending through an alternative channel on send failure
This is a scenario for increasing reach by continuing to send through another channel when a send fails on one channel.
It is especially useful when send conditions differ by channel — for example, when there is no push token, the user is not a Kakao channel friend, or there is no phone number.
For example, you can configure it as follows.
* **First Send**: Send a push message
* **Failure Branch**: Branch only users whose push send failed
* **Second Send**: Send an Alimtalk or text message
* **Exit Condition**: End immediately when the goal action is completed
This flow is suitable for **messages that must be delivered**, such as important announcements, payment notices, and benefit-expiration notices.
An example flow is as follows.
1. A user who triggered an event enters the journey.
2. First, a push message guides them to retry payment.
3. If the push send fails, an Alimtalk guides them again.
4. If the Alimtalk cannot be sent either, a text message provides the final notice.
When operating it, check the following metrics together.
* Send failure rate by channel
* Final reach after conversion to the alternative channel
* Cost efficiency of conversions from adding channels
{% hint style="info" %}
Keep the alternative-channel flow short. Using too many channels in a row can increase duplicate exposure and fatigue.
{% endhint %}
{% hint style="warning" %}
Do not send all channels in a row to all users. It is better to move only users whose send failed to the next channel, and to have users who completed a goal action such as a purchase or click drop off immediately.
{% endhint %}
***
### Get started this way
At first, designing in the following order lets you check performance quickly.
1. Choose one scenario with a clear goal.
2. Define the entry condition and exit condition first.
3. Verify the send timing and branch logic before the message content.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.hackle.io/en/crm-marketing/user-journey-guide/example.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.