> 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/crm-marketing/user-journey-guide/example.md).
# 사용자 여정 활용 예시
사용자 여정은 **진입 조건**, **대기 시간**, **분기**, **메시지 채널**을 조합해 자동화 흐름을 만드는 기능입니다.
처음 설계할 때는 복잡한 시나리오보다, 전환 목표가 분명한 흐름부터 시작하는 편이 좋습니다.
자세한 설정 방법은 [사용자 여정 만들기](/crm-marketing/user-journey-guide/create-user-journey.md)에서 확인할 수 있습니다.
### 1. 신규 사용자 대상 웰컴 메시지 발송
회원가입 직후 첫 행동을 유도하고 싶을 때 적합합니다.
예를 들어 아래처럼 구성할 수 있습니다.
* **진입 조건**: 회원가입 완료
* **대기 시간**: 가입 직후 또는 10분 후
* **메시지**: 서비스 핵심 기능 소개, 쿠폰 안내, 첫 구매 혜택 안내
이 흐름은 초반 이탈을 줄이는 데 효과적입니다. 가입 직후 사용자가 무엇을 해야 하는지 바로 알려줄 수 있기 때문입니다.
다음과 같은 목표에 자주 사용합니다.
* 앱 첫 실행 유도
* 프로필 작성 유도
* 첫 구매 또는 첫 예약 유도
{% hint style="info" %}
웰컴 메시지는 정보가 많을수록 효과가 떨어질 수 있습니다. 한 번에 하나의 행동만 유도하세요.
{% endhint %}
### 2. 장바구니 이탈 고객 리마인드
구매 의도가 있었지만 결제를 완료하지 않은 사용자를 다시 데려오는 시나리오입니다.
예를 들어 아래처럼 구성할 수 있습니다.
* **진입 조건**: 장바구니 담기 이벤트 발생
* **대기 시간**: 1시간 또는 24시간
* **분기 조건**: 대기 중 구매 완료 시 이탈
* **메시지**: 담아둔 상품 안내, 재고 임박 안내, 쿠폰 제공
이 흐름의 핵심은 **불필요한 발송을 막는 것**입니다. 이미 구매한 사용자에게는 메시지를 보내지 않도록 이탈 조건을 함께 설정하세요.
운영할 때는 아래 기준을 함께 보는 것이 좋습니다.
* 리마인드 발송 후 구매 전환율
* 쿠폰 제공 여부에 따른 효율 차이
* 발송 시점별 성과 차이
### 3. 메시지 채널별 A/B 테스트
같은 대상에게 어떤 채널이 더 잘 반응하는지 검증할 때 유용합니다.
예를 들어 아래처럼 구성할 수 있습니다.
* **진입 조건**: 특정 코호트 진입 또는 특정 이벤트 발생
* **분기 방식**: A/B 테스트 분기
* **메시지 채널**: 푸시 메시지 vs 알림톡 vs 문자 메시지
같은 캠페인 목적이라도 채널에 따라 오픈율과 전환율이 달라질 수 있습니다. 채널 선호도가 다른 고객군을 빠르게 찾을 수 있습니다.
특히 아래 상황에서 자주 활용합니다.
* 푸시 수신 동의율이 낮은 경우
* 긴급 공지를 더 확실히 전달해야 하는 경우
* 동일 메시지의 비용 대비 효율을 비교해야 하는 경우
{% hint style="info" %}
채널 비교 시에는 메시지 내용과 발송 시점을 최대한 동일하게 맞추세요. 그래야 채널 자체의 차이를 더 정확히 볼 수 있습니다.
{% endhint %}
### 4. 메시지 발송 시간별 A/B 테스트
같은 메시지라도 언제 보내는지가 성과를 크게 바꿀 수 있습니다.
예를 들어 아래처럼 구성할 수 있습니다.
* **진입 조건**: 특정 행동 발생
* **분기 방식**: A/B 테스트 분기
* **대기 시간**: 1시간 후 발송 vs 2시간 후 발송 vs 3시간 후 발송
이 시나리오는 최적 발송 타이밍을 찾는 데 적합합니다. 즉시 반응이 좋은지, 하루 뒤 리마인드가 더 효과적인지 확인할 수 있습니다.
자주 테스트하는 비교 방식은 아래와 같습니다.
* 즉시 발송 vs 다음 날 발송
* 오전 발송 vs 저녁 발송
* 평일 발송 vs 주말 발송
시간대 테스트는 메시지 종류에 따라 결과가 달라질 수 있습니다. 구매 유도 메시지와 재방문 유도 메시지는 따로 검증하는 편이 좋습니다.
### 5. 발송 실패 시 대체 채널로 이어서 발송
한 채널에서 발송에 실패했을 때, 다른 채널로 이어서 보내 도달률을 높이는 시나리오입니다.
특히 푸시 토큰이 없거나, 카카오 채널 친구가 아니거나, 전화번호가 없는 등 채널별 발송 조건이 다른 경우에 유용합니다.
예를 들어 아래처럼 구성할 수 있습니다.
* **1차 발송**: 푸시 메시지 발송
* **실패 분기**: 푸시 발송 실패 사용자만 분기
* **2차 발송**: 알림톡 또는 문자 메시지 발송
* **이탈 조건**: 목표 행동 완료 시 즉시 종료
이 흐름은 중요한 공지, 결제 안내, 혜택 소멸 안내처럼 **반드시 도달해야 하는 메시지**에 적합합니다.
예시 흐름은 아래와 같습니다.
1. 이벤트가 발생한 사용자가 여정에 진입합니다.
2. 먼저 푸시 메시지로 결제 재시도를 안내합니다.
3. 푸시 발송이 실패하면 알림톡으로 다시 안내합니다.
4. 알림톡도 보낼 수 없으면 문자 메시지로 최종 안내합니다.
운영할 때는 아래 기준을 함께 확인하세요.
* 채널별 발송 실패율
* 대체 채널 전환 후 최종 도달률
* 채널 추가에 따른 비용 대비 전환율
{% hint style="info" %}
대체 채널 흐름은 순서를 짧게 유지하세요. 너무 많은 채널을 연속으로 사용하면 중복 노출과 피로도가 높아질 수 있습니다.
{% endhint %}
{% hint style="warning" %}
모든 사용자에게 모든 채널을 연속 발송하지 마세요. 발송 실패 사용자만 다음 채널로 넘기고, 구매나 클릭 같은 목표 행동을 완료한 사용자는 즉시 이탈시키는 것이 좋습니다.
{% endhint %}
***
### 이렇게 시작해보세요
처음에는 아래 순서로 설계하면 빠르게 성과를 확인할 수 있습니다.
1. 목표가 분명한 시나리오 1개를 선택합니다.
2. 진입 조건과 이탈 조건을 먼저 정합니다.
3. 메시지 내용보다 발송 시점과 분기 로직을 먼저 검증합니다.
---
# 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/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.