> For the complete documentation index, see [llms.txt](https://documentation.pushly.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://documentation.pushly.com/platform/journeys/split-testing-and-promotion.md). # Split Testing & Promotion ## Split Testing & Promotion A **split test** lets you compare variations of a journey path against each other on live traffic, then **promote** the variant that performs best so every new subscriber follows it. A split divides subscribers into 2–4 named variant paths by percentage; each path is its own sequence of notifications and waits, and all paths converge downstream so the journey continues as one flow afterward. ### Setting up a split test Add a **Split Test** step from the **+** on any edge, name each variant, and set each variant's percentage (all percentages must total 100%). You can have up to 4 variants; adding one redistributes the percentages evenly. Build each variant's path independently — click the **+** on a variant's edge to add waits, notifications, and other steps to that branch. All branches automatically converge at a shared join point downstream. For the basics of adding and configuring steps, see [Journey Builder](/platform/journeys/journey-builder.md).
### Reading variant performance Once a journey with a split is running, the builder shows performance for each variant in two places: * **On-canvas performance cards.** Each variant path shows a compact card at the fork with metrics for the **whole path** (every step in that branch, not just one send): **entrances, impressions, clicks, CTR**, and — when the journey records purchases — **purchases and purchase rate**. * **The Split Test Results drawer.** Click a variant's performance card to open the drawer: every variant appears as a row with the full metric set, side by side. This is also where you promote a winner. A few states to expect: * Until a variant has enough data, its rates show as **“—”** and no leader is suggested. * A **draft** journey shows no metrics — data appears once the journey is running. * Journeys that don't track purchases simply omit the purchase columns. ### Promoting a variant When you've decided, click **Promote** on a variant's row in the Split Test Results drawer. A confirmation dialog explains exactly what will happen. Promotion: * **Routes all new subscribers** down the promoted variant's path. The split is replaced by that single path going forward. * **Lets in-flight subscribers finish.** Anyone already in the journey — including on a path you didn't promote — completes their current path uninterrupted. Promotion never moves someone mid-journey. * **Keeps the losing variants in history.** They're removed from the live journey but preserved in the journey's revision history, where their results remain viewable.
Keep in mind: * **Promotion is irreversible.** It creates a new version of the journey; you can't “un-promote” back to the split (you would rebuild the test). * **Save first.** Promotion acts on the saved journey, so unsaved builder edits block it — save your changes before promoting. ### Viewing past revisions Promoting (and other structural changes) creates a new **revision** of the journey. Use the **revision selector** in the Journey Builder header to view any past revision **read-only**: the canvas shows that earlier version (for example, the original split), with a banner indicating you're viewing history and a **Back to current revision** button to return. On a promoted journey, the past revision marks the promoted variant with a **🏆**.
### Revision-aware Insights On the journey's **Insights** tab, a **revision scope** control lets you view reporting for **all revisions** (grouped into collapsible per-revision sections, each with its own subtotal) or scope to a **single revision**. This keeps before/after metrics comparable — for example, the split test's variant results stay attached to the revision that ran the test, separate from the collapsed journey's later performance. The **Split Test Variants** report defaults to the revision that held the split. On journeys with only one revision, no scope control appears.
--- # 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://documentation.pushly.com/platform/journeys/split-testing-and-promotion.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.