How To Use A/B Split Nodes In Automation Journeys

An A/B split node is a branching point in an automation journey that deliberately sends comparable people down different paths. One group follows the existing route (the control); the other follows an alternative (the variant). The aim is to learn whether a change to the journey itself improves an agreed outcome.

That distinction matters. A conventional email A/B test might compare two subject lines within one send. A journey split can test whether a reminder should arrive after one day or three, whether a second email helps or simply adds pressure, whether a push notification is a useful substitute for an email, or whether a different sequence produces more completed applications, renewals or first purchases.

Most automation platforms implement this through a random-sample condition or a dedicated experiment activity. The names vary, but the mechanics are similar: eligible contacts are assigned to a path using a stated probability. A 50/50 split means each entrant has an independent chance of reaching either branch; it does not promise a perfectly even count in a small cohort. Salesforce makes the same point in its guidance on random splits: observed proportions become more likely to approach the configured allocation as the number of contacts grows. Salesforce’s explanation of random-split distribution (Salesforce source)

Start by choosing the right type of split

“Split node” can describe several different tools. Using the wrong one is a common reason that a journey test produces an answer that cannot be trusted.

Random split: for a controlled experiment

Use a random split when the question is causal: does this alternative journey work better than the current one? Random assignment helps make the two groups broadly comparable, so that a difference in outcomes is more plausibly related to the path rather than an attribute the contacts already had.

Examples include:

• sending a cart reminder 24 hours after abandonment versus 48 hours after abandonment;
• testing a two-email renewal sequence against a one-email sequence;
• testing an educational onboarding path against a shorter, action-led path;
• testing whether a reminder is better sent by email alone or by email followed by an opted-in SMS.

Keep the entry rules the same for every path. If one version begins only after a customer has viewed a pricing page, while the other includes all trial users, it is a segmentation comparison, not a clean A/B test.

Decision split: for relevance, not experimentation

A decision split routes people according to known data or behaviour: country, subscription preference, product ownership, whether a payment failed, or whether they clicked a previous message. It is valuable journey logic, but it is not an A/B test because the people in each branch are intentionally different. Salesforce describes a decision split as evaluating journey data and sending contacts down paths based on configured filter criteria. Salesforce’s split and join documentation (Salesforce source)

You can combine the two. For example, first use a decision split to identify UK customers who have consented to SMS, then randomly assign those eligible contacts between two message sequences. This protects relevance and consent while retaining an experimental comparison within the eligible group.

Holdout split: for testing whether to send at all

A holdout is a deliberately withheld group. It answers a harder and often more useful question: is this automation creating incremental value, or would the customer have converted anyway?

For a low-risk lifecycle message, a small holdout may be appropriate. For essential service communications, payment notices, security alerts and other genuinely transactional messages, it usually is not. The customer need takes precedence over the experiment.

A holdout should not mean ignoring the people placed in it. They should still receive communications that are necessary for the service, and must continue to be removed promptly when they unsubscribe, hard bounce, complain or become ineligible.

Write the experiment before drawing the branches

The journey canvas makes it easy to build first and think later. Reverse that order. A short experiment brief prevents a split node becoming a permanent fork with no clear purpose.

Define:

• The audience: exactly who can enter, including exclusions.
• The hypothesis: a specific expected relationship, such as “a 48-hour delay will reduce repeat-email fatigue without reducing completed checkout rate”.
• The single primary outcome: for example, verified purchase, completed setup, renewal or booked appointment.
• Guardrail measures: unsubscribes, complaints, hard bounces, customer-service contacts, refunds or cancellation, depending on the journey.
• The attribution window: how long after exposure an outcome can reasonably be credited to the journey.
• The decision rule: what result would justify rollout, continuation, further testing or stopping the test.

Use the business outcome rather than an easily available message metric whenever possible. Opens are especially weak as a decision metric: email clients can generate them automatically and Google explicitly says it does not track open rates or verify figures reported by third parties. Google’s email sender guidelines (Google’s sender guidance) A higher click rate may be useful diagnostic evidence, but it can also mean that a message created curiosity rather than value. For an abandoned-basket flow, completed order value is normally more meaningful than clicks. For onboarding, completion of the key product action may be the better measure.

Change one meaningful journey variable at a time

A split-node test can accommodate very different paths, which is precisely why it can become ambiguous. If path B has a new subject line, a different offer, an extra message, a shorter wait and a different channel, a better outcome will not tell you which decision mattered. It may also conceal a costly increase in pressure.

Choose the smallest useful intervention. For a timing test, use identical content and alter only the wait. Klaviyo’s flow-testing guidance makes this practical point: timing tests should use the same content in both paths, while tests of message count should keep other elements as similar as possible. Klaviyo’s guidance on testing timing and message frequency in flows (Klaviyo source)

That does not mean every test must be microscopic. Sometimes the decision is genuinely about two complete strategies: for example, a concise three-step activation series versus a longer education-led programme. Treat that as a strategy test, document all the differences, and resist making fine-grained claims about why one won.

Place the split where the paths can still diverge cleanly

Position determines what the test can measure. Place the node immediately before the first deliberate difference. Any shared steps before that point should truly be identical, including suppression checks, data updates and waits.

In a trial-conversion journey, a sensible structure might be:

1. Entry: a person starts a trial and has marketing permission for the relevant messages.
2. Global exclusions: unsubscribed, bounced, already converted, account closed, or currently in a support-sensitive state.
3. Shared welcome message and initial wait.
4. Random split.
5. Path A: product-use prompt after two days.
6. Path B: the identical prompt after four days.
7. Shared exit condition: conversion removes the person from both paths.

The exit condition is as important as the split. Contacts should not receive a reminder after completing the action that made the reminder relevant. Nor should a person be able to re-enter the same experiment repeatedly unless repeat exposure is intentional and accounted for in the analysis.

Where a platform supports a join, use it only when the paths are genuinely complete and subsequent treatment should be identical. A join does not erase what happened earlier. Keep path membership available in reporting so that later outcomes can still be attributed correctly.

Set allocation according to risk and traffic

A 50/50 allocation is straightforward and often appropriate for two viable versions. It gives both routes meaningful exposure and does not favour a path before there is evidence that it deserves more traffic.

Other allocations have legitimate uses:

• Small challenger allocation: use a limited share for a materially different or less proven path, especially if it increases message frequency or changes an offer.
• Small holdout: reserve a proportion for no promotional intervention when measuring incrementality is important.
• More than two paths: use sparingly. Every additional branch divides the available volume and complicates interpretation.

Do not confuse allocation with a sample-size plan. A 50/50 split is not automatically capable of detecting a meaningful difference. Before launch, estimate whether the expected journey entries and outcome rate can support a useful decision in the planned period. If the volume is too low, simplify the comparison, run it longer where seasonality permits, or treat the exercise as exploratory rather than conclusive.

Also decide whether assignment is persistent. In most lifecycle experiments, a person should remain in their assigned path if they pause, requalify or are evaluated again. Switching someone between variants can contaminate the experience and make the exposure history impossible to interpret.

Protect the customer experience and sender reputation

Journey experiments are still live communications. They must comply with the same permission, preference and suppression rules as every other send. Do not use a split node to bypass frequency caps, re-message an unsubscribe, or keep sending after a person has converted or asked for help.

Contact pressure needs to be evaluated across the whole programme, not only inside the tested automation. A customer in a welcome flow may also qualify for a promotion, browse reminder, replenishment series and service notice. If the test path adds an email, check the person’s total recent exposure and make sure global frequency controls still apply.

Deliverability guardrails should be part of the experiment read-out. For promotional email, track sends, deliveries, hard bounces, unsubscribe events and complaints by path, while taking care not to over-read tiny numbers. Where volumes make the data available, review mailbox-provider signals at an aggregate level as well. Google advises senders to monitor spam rate and domain and IP reputation through Postmaster Tools; it also recommends that bulk senders keep the reported spam rate below 0.10% and avoid reaching 0.30% or higher. Google’s sender guidance on reputation and spam rate (Google’s sender guidance)

For marketing and subscribed messages at Gmail bulk-sender scale, one-click unsubscribe is required. More broadly, an experiment should never make opting out harder. Google’s guidance says promotional senders should make unsubscribing easy and notes that one-click unsubscribe applies to marketing and subscribed messages sent at more than 5,000 messages per day to Gmail accounts. Google’s sender requirements FAQ (Google’s sender guidance)

If a new path increases complaints, unsubscribe rate or negative support signals, do not wait for a neat statistical conclusion before investigating. Pause the path if the risk is material, verify that the journey’s content and eligibility logic are correct, and review whether a broader reputation issue is affecting results. This is where deliverability monitoring and contact-pressure controls matter more than a dashboard’s declared winner.

Measure people and outcomes, not just sends

Build reporting around the number of people assigned to each branch, rather than only delivered messages. People may be suppressed after assignment, convert before a later step, or leave the journey. Those events are often informative.

A useful path-level report includes:

• contacts assigned, eligible to receive and actually reached;
• each message’s delivery and engagement measures;
• the primary outcome within the agreed window;
• time to outcome, if speed matters;
• unsubscribe, complaint and bounce rates;
• total messages per recipient and the number of people stopped by frequency controls;
• outcomes by important pre-defined segments, such as new versus returning customers, only where volumes support interpretation.

Avoid repeatedly checking early results and changing allocations whenever one path appears ahead. Day-to-day fluctuations are normal, especially for low-volume automations. Agree the evaluation date or minimum exposure beforehand. If your platform offers automatic winner selection, understand precisely what it optimises, how long it waits and what happens to people still moving through the journey. Salesforce’s Path Optimizer, for example, can evaluate multiple paths using email engagement or allow a manual choice, with a configurable evaluation period. Salesforce’s Path Optimizer configuration guidance (Salesforce source)

Automatic selection can be convenient, but it is rarely a substitute for judgement. A winner based on opens may not be the winner on revenue, retention or complaint rate. Where the meaningful outcome occurs outside the automation platform, manual evaluation using joined-up data is usually safer.

End the test without stranding people

Concluding an experiment involves more than declaring a winner. Decide what happens to:

• future entrants, who should be directed to the selected route;
• contacts waiting in the losing path, who may need to finish that route, be safely moved, or be excluded from a next step;
• contacts who have already received different treatment, whose history should remain available for later analysis.

Do not simply delete the unsuccessful branch while people are queued in it. Platform behaviour varies. Klaviyo, for example, advises changing the random-sample allocation rather than deleting the unused path, because people already waiting there can continue through it; the unused messages can be moved to draft after that queue has cleared. Klaviyo’s guidance on ending a flow-branch A/B test (Klaviyo source)

Record the result in a concise test log: the hypothesis, audience, dates, allocation, path definitions, primary outcome, guardrails, decision and any limitations. This stops teams from retesting the same idea unknowingly and gives future journey owners the context behind a design choice.

When a split node is not the answer

Do not create an A/B split simply because a journey has a node available. A decision split is better when the correct treatment clearly depends on consent, locale, customer status or behaviour. A simple message-level test is better when the only change is a subject line or creative element. And if the question is whether the automation has a place in the programme at all, a properly designed holdout may be more revealing than choosing between two sending patterns.

Most importantly, a journey experiment should improve the experience for people who asked to hear from you. Testing a less frequent sequence, clearer expectations or a more useful moment to communicate can be as valuable as testing a more aggressive conversion tactic. The best split-node programmes turn that principle into a repeatable operational discipline: clear eligibility, controlled assignment, measured outcomes, reputation safeguards and a clean decision at the end.

Frequently asked questions

What is the difference between an A/B split node and a decision split?

An A/B split node randomly assigns comparable eligible contacts to alternative paths so you can test the effect of the path. A decision split uses known conditions, such as country, consent or product ownership, to route different people to the appropriate experience.

Should A/B journey splits always be 50/50?

No. A 50/50 allocation is often the simplest choice for two viable paths, but a smaller allocation can be sensible for a higher-risk challenger or a holdout. The allocation should be chosen alongside the expected traffic, risk and measurement plan.

Can I test email frequency with a split node?

Yes. Create equivalent paths and vary the number of messages or the delay between them. Keep content and other variables as consistent as possible, then assess the primary customer outcome alongside unsubscribes, complaints and overall contact pressure.

What should happen to contacts in the losing branch when a test ends?

Plan this before launch. Route future entrants to the selected path, but handle people already waiting in the other path safely. Depending on platform behaviour, they may need to complete the queued steps, be moved to a compatible next stage or be suppressed from further promotional messages.

Sources and further reading

• Google email sender guidelines — Google
• Google email sender guidelines FAQ — Google
• How to A/B test flow branches — Klaviyo
• How to A/B test flow SMS messages — Klaviyo
• Path Optimizer Test Activity in Journey Builder — Salesforce
• Configure a Path Optimizer Test Activity — Salesforce
• Results of Journey Builder Random Split Didn’t Distribute as Expected — Salesforce