True/False Branches in Customer.io

Overview

True/False Branches in Customer.io help you route shoppers down different paths inside a Journey based on a single condition, like whether they started checkout, applied a discount, or purchased within a time window. In D2C retention, this is how you stop sending the wrong message to the wrong shopper, and how you keep cart recovery and post-purchase flows tight as behavior changes in real time.

If you want these branches to reflect real storefront behavior (and not just best guesses), Propel can help you map events and attributes into Customer.io so your Journeys make clean, revenue-driven decisions. If you want help pressure-testing your branching logic against your funnel, book a strategy call.

How It Works

True/False Branches in Customer.io evaluate a condition at the moment a person reaches the branch, then send them down the True path if they match, or the False path if they do not.

In practice, you use the branch to answer one question that matters for revenue, then orchestrate messaging differently based on the answer. Common inputs include:

• Person attributes (email opt-in status, VIP tier, first order date, last purchase date).
• Event activity (placed_order, started_checkout, added_to_cart, viewed_product) within a defined lookback window.
• Object data (latest cart, last order, subscription status) if you model commerce data as objects.

A realistic D2C scenario: a shopper enters your abandoned checkout Journey after started_checkout. Two hours later, you hit a True/False Branch that checks “Has placed_order occurred since entering?” If True, you suppress cart messaging and move them into a post-purchase cross-sell path. If False, you continue recovery with an incentive ladder. This is the difference between a recovery program that feels coordinated and one that annoys customers.

When you build this in Customer.io, treat the branch as a decision gate. Keep the question singular, then do the complexity in the paths that follow.

Step-by-Step Setup

True/False Branches in Customer.io are easiest to implement when you start from the decision you need to make, then work backwards to the data required.

1. Define the decision in plain language (example: “Did they purchase after starting checkout?”).
2. Confirm the data source for the condition (event vs attribute vs object), and verify naming consistency (example: placed_order event and order_id present).
3. Open the Journey where you need routing, and add a True/False Branch at the point the decision matters (often after a delay or wait).
4. Configure the condition with a clear lookback window (example: “has performed placed_order within the last 2 hours” or “since campaign entry,” depending on your structure).
5. Build the True path to handle the “success” state (example: exit recovery, start post-purchase education, request review later).
6. Build the False path to continue the “not yet” state (example: reminder, social proof, incentive, SMS fallback).
7. Add an exit condition or goal that prevents re-entry loops (example: if purchased, exit all recovery paths).
8. QA with real profiles (one who purchased, one who did not), and verify that the branch evaluates correctly at the time it is reached.

When Should You Use This Feature

True/False Branches in Customer.io are the right move when one behavioral check should change the next message, offer, or channel choice.

• Abandoned cart and checkout recovery: Branch on “purchased since entry” before each send so you do not keep pushing recovery after conversion.
• First purchase conversion: Branch on “viewed product category X” to personalize a discovery sequence (skincare routines vs bundles vs bestsellers).
• Repeat purchase acceleration: Branch on “bought consumable product” to route into replenishment timing vs non-consumable cross-sell.
• Discount governance: Branch on “has used welcome offer already” to protect margin and avoid training customers to wait for promos.
• Reactivation: Branch on “engaged in last 30 days” to separate truly dormant customers from low-open but active buyers.

Operational Considerations

True/False Branches in Customer.io work best when your data contracts and orchestration rules are explicit, otherwise you end up branching on incomplete signals.

• Event timing and delays: If your order confirmation event arrives late (common with some integrations), a branch placed too soon will misroute purchasers into recovery. Add a short delay before the branch or branch on a more reliable signal.
• Lookback windows: “Within the last X” can behave differently than “since entering the Journey.” Pick the one that matches your intent, and document it so the team does not “fix” it later.
• Identity resolution: If shoppers browse anonymously and only identify at checkout, make sure anonymous activity is merged properly, or your branch conditions will undercount intent signals.
• Segment overlap: Branches do not replace suppression strategy. If you run multiple recovery flows (cart and checkout), add global suppression rules so customers do not get double-tapped.
• Channel orchestration: Decide whether the branch changes content, channel, or both. For example, False path gets email first, then SMS only if no click.

Implementation Checklist

True/False Branches in Customer.io are straightforward to build, but the checklist below prevents the common revenue-impacting misroutes.

• Condition is a single clear question tied to a revenue outcome (convert, recover, upsell, reactivate).
• Event names and properties are standardized (no duplicate purchase events, consistent currency, consistent product IDs).
• Branch timing accounts for data latency (delay added where needed).
• Lookback window is intentional and documented.
• True path includes suppression or exit from conflicting flows.
• False path has a defined escalation plan (reminder, proof, incentive, channel shift).
• QA completed with at least two real customer profiles and one edge case (refund, partial payment, subscription renewal).
• Reporting plan exists (goal conversion, recovery rate, incremental lift vs holdout).

Expert Implementation Tips

True/False Branches in Customer.io become a profit lever when you treat them like decision points in your funnel, not just workflow plumbing.

• In retention programs we’ve implemented for D2C brands, the highest lift comes from branching before every recovery touch. A single “purchased since last step” check can cut complaints and improve deliverability while keeping revenue flat or up.
• Use branches to protect margin. For example, only show an incentive if the shopper has not clicked in the last 24 hours and cart value is above a threshold. That keeps discounts targeted to people who actually need the push.
• Keep the branch condition simple, then personalize downstream with Liquid. Example: branch on “has any cart items,” then in the False path, show bestsellers and category-specific social proof based on last viewed category.
• If you have multiple storefronts or currencies, branch on locale or currency early. It prevents mismatched shipping promises and improves conversion rate on recovery messages.

Common Mistakes to Avoid

True/False Branches in Customer.io can quietly hurt performance when the condition is correct on paper but wrong in execution.

• Branching too early: Checking for purchase immediately after checkout start, before the purchase event is reliably ingested.
• Using vague conditions: “Has done event in last 30 days” when the Journey is only 6 hours long, which makes the branch meaningless.
• No suppression on the True path: Customers convert, but still receive the next recovery message from a parallel flow.
• Over-branching: Stacking multiple True/False branches to approximate a multi-split decision. If you need 3 or more outcomes, use a multi-split strategy or simplify the decision model.
• Not accounting for returns and cancellations: Branching on “placed_order” without considering “refunded” can route customers into upsells that feel tone-deaf.

Summary

Use True/False Branches when one behavioral check should change the next message, offer, or channel. They are especially valuable for cart recovery and post-purchase routing, where timing and suppression directly impact revenue and customer experience. Build and QA them carefully in Customer.io.

Implement with Propel

Propel helps D2C teams design branching logic that matches real commerce behavior in Customer.io, then operationalize it with clean data and measurable lift. book a strategy call.