Klaviyo’s visual flow builder shows filters stacked top-to-bottom, but the platform evaluates them in reverse. If you’re wondering why subscribers who shouldn’t qualify keep entering flows—or why eligible contacts get blocked—the evaluation order is probably the issue.
Most operators assume Klaviyo reads filters like a book: top to bottom, left to right. It doesn’t. The platform processes conditional splits and trigger filters from the bottom of the stack upward, which means the last filter you add is the first one Klaviyo checks.
How filter evaluation actually works
When you build a flow in Klavivy, you add trigger conditions and conditional splits by stacking filters in the visual editor. A typical abandoned-cart flow might include:
- Trigger: Started Checkout
- Filter 1: Cart value greater than $50
- Filter 2: Has not placed an order in the last 7 days
- Filter 3: Email address contains “@gmail.com” (for a test segment)
You’d expect Klaviyo to check cart value first, then recency, then email domain. Instead, it evaluates Filter 3, then Filter 2, then Filter 1. If any condition fails, the contact exits the flow without triggering downstream checks.
This matters most when you’re using expensive API lookups, custom property checks, or time-based windows. A filter that queries your inventory API should run last in your logic chain—not first—so you’re only making the call for contacts who’ve already cleared cheaper, faster filters.
When reversed logic breaks flows
Reverse evaluation causes three common failure modes:
Premature exits. If you place a narrow, restrictive filter at the bottom of the stack (visually), Klaviyo checks it first. Contacts who would have qualified under your primary conditions get blocked before those conditions are ever evaluated. You’ll see low flow-entry counts and wonder why your segmentation isn’t working.
Wasted API calls. If your bottom filter pings an external service or checks a slow custom property, every single contact hits that check—even those who would’ve been disqualified by simpler conditions higher in the stack. At scale, this burns through rate limits and slows flow execution.
Confusing A/B test results. If you’re testing two versions of a flow and one includes a filter at the bottom that the other lacks, the two flows aren’t just different in content—they’re evaluating contacts in a different order. Your test measures filter-stack architecture, not messaging.
How to stack filters correctly
Build your filter stack in reverse priority. The condition you want Klaviyo to check first should sit at the bottom of the visual stack. The condition you want checked last goes at the top.
For an abandoned-cart flow, the correct visual order (top to bottom) would be:
- Cart value greater than $50
- Has not placed an order in the last 7 days
- Email address contains “@gmail.com”
Klaviyo will evaluate the Gmail filter first (fast, local check), then recency (medium-speed property lookup), then cart value (which may involve a Shopify API call depending on your integration setup).
If you’re using conditional splits mid-flow, the same rule applies. Klaviyo evaluates the bottom branch condition first. If you’re splitting on “opened email in last 3 days” versus “clicked link in last 3 days,” put the click condition at the bottom so engaged contacts get prioritized before the broader open check runs.
One non-obvious trick: use trigger filters to pre-qualify
Instead of stacking filters inside a flow, move your fastest, most restrictive conditions into the trigger itself. Klaviyo evaluates trigger filters before the flow even starts, which means contacts who don’t qualify never enter the flow queue. This keeps your flow analytics clean and reduces server load.
For example, if you only want to target customers with lifetime value above $200, add that as a trigger filter rather than a conditional split two steps into the flow. You’ll see accurate entry counts, and you won’t waste sends or delay timers on contacts who were never going to qualify.
Klaviyo’s documentation doesn’t foreground the reverse-evaluation behavior—most operators learn it by accident after a flow misfires. Once you know the pattern, you can design filter stacks that execute faster, cost less, and behave predictably.
Want more breakdowns like this? Subscribe to One Two Three Send for weekly deep-dives on the tools that run your online business—no fluff, just the mechanics that matter.