> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Read Journey Paths — cross-channel steps and drop-off

> Operator guide to the Customer Journey Paths surface: what the path view measures, how to read the stage flow and top-paths panels, common drop-off interpretations, a worked drip-campaign example, and export caveats.

# Read Journey Paths — cross-channel steps and drop-off

The **Customer Journey Paths** page (console route `/insights/journey-paths`) reconstructs the ordered touchpoint sequences customers actually walk across channels — chat → voice → email, SMS → WhatsApp — and shows where they stop between steps. It reads real customer traffic, not a design you drew: the path customers *took*, not the journey a marketer *designed*.

Two adjacent surfaces answer different questions, so pick the right one before reading numbers:

* A **delivery funnel** tracks one message from sent to delivered. It answers "did this send reach the handset."
* **Journey orchestration** on a campaign designs the journey — the steps you want customers to follow.
* **Journey Paths** aggregates the channels customers actually touched, in order. It answers "which sequence of channels do customers really move through, and where do they drop off."

Open the page from the dashboard sidebar under **Insights → Customer Journey Paths**. The surface is read-only analytics, so owner, admin, developer, and viewer roles can all use it.

## What the page shows

A control bar sits at the top of the page; every number below it is scoped to the window and filter you set there:

* **Time window** — 24h, 7d, 30d, or 90d. Defaults to 30d. Read the window before reading any number; a path shape over 24 hours says nothing about the same shape over 90 days.
* **Entry-channel filter** — restricts the view to journeys whose *first* touchpoint happened on one channel (e.g. only customers who entered on WhatsApp). The filter's options list every channel customers actually entered on in the window.

Four KPI tiles summarise the scoped view:

| Tile                  | What it counts                                                                                                                                                    |
| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Journeys (window)** | Distinct customers with at least one touch in the window.                                                                                                         |
| **Touchpoints**       | Rendered channel steps across all journeys. Each customer contributes at most the stage cap, so this is a bounded path-length count, not raw message volume.      |
| **Biggest drop-off**  | The stage where the most journeys ended, with its drop-off rate and stage number. An early stage wins ties, so the tile points at the most actionable drop first. |
| **Channels**          | Distinct channels observed across the rendered paths.                                                                                                             |

Below the tiles, two panels carry the analysis: the **Cross-channel path flow** and **Most-walked paths**.

## Reading the path flow

The path flow renders the journey as a row of stage columns, left to right, with the share that dropped off between them.

* **Stage 1** is the entry point — every journey starts here, on some channel. Each subsequent column is one hop deeper into the journey.
* Each column splits its reach **by channel**: a labelled bar per channel, sized relative to the busiest stage, with a count. Columns narrow left to right as journeys end, so shrinking bars are the visual signature of drop-off.
* Between two columns, an arrow carries the **drop-off percentage** — the share of journeys that reached the left stage but never continued past it.

Two conventions keep the flow honest:

* **Consecutive same-channel touches collapse into one stage.** A customer who opened your web chat three times and then called shows as Web → Voice, not Web → Web → Web → Voice. The flow records *channel hops*, not raw event counts.
* The flow is capped at **six stages** by default (you can request up to ten through the API). Journeys longer than the cap are truncated for display, so the last visible stage is where longer journeys pile up.

## Common interpretations

Three patterns recur when you read the flow and the top-paths list together.

**A drop-off concentrated at one step.** If the biggest drop-off tile names one stage and the flow confirms it, the journey has a single leak. A step where the channel changes (chat → email, SMS → voice) dropping hard usually means the handoff between channels is broken or slow — customers do not follow cross-channel prompts the way outbound-only steps do. Compare entry-channel slices: if the drop only appears for WhatsApp entries, the leak is in that channel's continuation, not the stage itself.

**Loop-backs.** Repeat visits on the same channel collapse into one stage, so a loop shows up as a channel appearing again at a *later* stage — chat → voice → chat. A heavy loop-back usually means the first contact did not resolve the issue: the customer re-enters on a familiar channel after the attempted resolution failed. Pair this with the Conversation Intelligence or Topic Intelligence pages (linked at the bottom of the screen) to see what customers were trying to resolve.

**Preferred channel at each hop.** The per-channel bars inside each stage column tell you which channel carried each hop. If stage 2 is overwhelmingly voice whenever stage 1 was web chat, voice is doing the escalation work — staff and route it accordingly rather than trying to push the second hop onto messaging. Conversely, a channel that almost never appears past stage 1 is a terminal channel: customers arrive there and stop.

## Example: a drip campaign with SMS → WhatsApp fallback

A three-touch re-engagement sequence ships SMS first with WhatsApp as the fallback for non-responders. After two weeks on the 30d window you open Journey Paths and see:

1. **Stage 1** is dominated by SMS — customers enter on the outbound touch, exactly as designed.
2. **Stage 2's** bars show WhatsApp carrying most of the continuing traffic (the fallback path working) with a small slice of SMS replies.
3. **Stage 3** is nearly empty, and the biggest drop-off tile reads "42% at stage 2."

Read it as: the fallback hop is healthy — customers who engaged past the first touch mostly moved to WhatsApp — but **the journey ends at the reply point**, not at the conversion step. Forty-two percent of journeys reach the second hop and never produce a third touch. The next question is what customers *were replying about* before they stopped; that is the Conversation Intelligence surface, linked from the footer of the page. If the same window with the entry-channel filter set to `sms` shows the drop and `whatsapp` does not, the leak belongs to the SMS arm's continuation, and the fix sits in that step's content or timing — not in the journey shape.

## Drilling into step metrics

The page is an aggregate view — it shows paths and stages, not individual customers. To go deeper from a reading:

* **Narrow the slice, don't scroll.** Set the entry-channel filter and the smallest plausible window first. A 24h window on one entry channel isolates a single step's behaviour far better than paging through a 90d all-channel view.
* **Confirm against the per-stage drop-off.** The flow's per-stage percentages and the biggest drop-off tile come from the same stage rollup, so they always agree; if the tile says "40% at stage 2" the stage-2 column must carry the same number between stages 2 and 3.
* **Take the question to the detail surfaces.** Once you know *where* customers drop, the *why* lives per conversation — open Conversation Intelligence for per-conversation analysis or Topic Intelligence for what the dropped stage was about. Both are linked from the footer of the page.

The same aggregation is available over the API for dashboards and exports:

```bash theme={null}
curl -G "https://api.orbit.devotel.io/api/v1/analytics/journey-paths" \
  --data-urlencode "window=30d" \
  --data-urlencode "entry_channel=sms" \
  --data-urlencode "max_stages=6" \
  --data-urlencode "min_journeys=2" \
  -H "X-API-Key: $ORBIT_API_KEY"
```

`window` accepts `24h`, `7d`, `30d`, `90d`; `max_stages` accepts 2–10; `min_journeys` prunes transitions carried by fewer customers than the threshold. See the [Analytics API reference](/api-reference/analytics) for the full response shape.

## Export caveats

Journey Paths has no CSV export button — it is an aggregate path/Sankey view, not a row-level list, and a flattened export of a weighted path graph would lose the structure that makes it readable. Keep these in mind when you need the numbers elsewhere:

* **Pull the aggregate through the API.** `GET /api/v1/analytics/journey-paths` returns the same stages, top-paths, and drop-off figures the page renders, so scheduled reports or BI tooling can capture the numbers directly.
* **The response is already truncated by design.** Paths are capped at the stage cap and the most-walked list is a top-N slice; a long-tail path that matters on a quiet week can sit below the cut. Raise `max_stages` and lower `min_journeys` before concluding a path does not exist.
* **Percentages in the top-paths list are rounded to whole points** so they always sum to the displayed total; use the returned journey counts for arithmetic, not the rounded labels.
* **Low-traffic slices are unstable.** On a 24h window with an entry-channel filter, a handful of journeys can swing every percentage. Compare two windows before acting on a single reading.

## Troubleshooting

* **Empty page** — "No customer journeys in this window" means no qualifying cross-channel touches in the selected window. Widen the window first; then clear the entry-channel filter (an entry channel with no continuing traffic empties the whole view).
* **A channel is missing** — The view renders channels customers actually touched in the window. A channel with zero touches in the scoped window never appears; check a wider window before treating it as a data gap.
* **Numbers differ from a teammate's screen** — The page shares a 60-second cache. Both readers see the same figures within a minute; check the window selector before comparing readings.

## See also

* [Insights dashboards](/guides/insights-dashboards) — the full catalogue of Insights surfaces and where each one reads from
* [Search Analytics](/guides/search-analytics-reading) — the search-traffic counterpart, read the same way
* [Search every conversation and call in one list](/guides/interaction-search) — the row-level surface to drill into once a drop-off is located
* [End-to-end campaign setup](/guides/campaign-end-to-end) — designing the journeys that Journey Paths then measures