Klaviyo flow filter vs trigger filter: what each one checks, and when

This is for Shopify founders setting up or fixing their own Klaviyo flows who keep seeing all three options and aren't sure which one to reach for.

Klaviyo flow filter vs trigger filter: what's the difference?

Here's how Klaviyo's help center describes the three tools, side by side.

The short version: the trigger filter is a gate at the front door that checks the event. The flow filter is a gate in front of every email that checks the person. The split is a fork in the road.

What is a Klaviyo trigger filter?

Per Klaviyo, trigger filters evaluate the data coming in from the event that starts the flow. They don't look at profile properties. Only flows triggered by an event (a metric), plus custom object and price drop flows, have them.

Typical uses: a Placed Order flow that should only run for orders containing one product category, or a Viewed Product flow that should only run for items over a certain price. Both are facts about the event, so they belong in a trigger filter.

The thing to remember: Klaviyo's "Getting started with flows" page says trigger filters aren't checked again at send time. (Custom object trigger filters are the exception; Klaviyo checks those at every step.) Whatever was true about the event when someone came in is what counts for the rest of the flow.

What is a Klaviyo flow filter?

Klaviyo's help center now calls these profile filters. They check whether someone qualifies based on properties about them, or on things they've done before, like placing an order.

They're checked when someone enters and again before each action. If someone fails on entry, they never come in. If they fail later, Klaviyo skips that action, and it shows up in the flow's Recipient Activity as "Skipped: Fails Profile Filters."

Klaviyo's own example is the most useful filter you'll ever add: on an abandonment flow, a filter for people who've placed an order zero times since starting this flow. The moment they buy, every remaining message is skipped. Nobody gets "you forgot something" an hour after they paid.

Where does a split fit?

A split is a fork in the road, not a gate. Klaviyo is rolling out multi-branch splits in phases: each one supports up to 20 paths, 19 you configure plus "Everyone else." Your existing conditional and trigger splits keep working as they are. Per Klaviyo, when someone reaches a split, the paths are checked in order and they go down the first one they match. Anyone who matches nothing goes down "Everyone else."

Klaviyo's flow branching page puts the difference plainly: filters keep the people who match and remove the rest, while splits don't remove anyone. Everyone keeps going, just on different paths.

That gives you one simple rule. If someone should never get this email, filter. If they should get a different email, split.

Which one should you use for common flow setups?

Here's how the three tools map to the jobs founders usually need them for.

Customers vs non-customers: split. Right after the trigger, split on whether someone has placed an order at least once, over all time. Customers go one way, everyone else goes the other. A customer already trusts you and needs a reason to reorder. A non-customer needs trust and a first order. Those are different emails, so it's a split, not a filter. I walk through that setup in customer vs non-customer email flows.

Buyers out of abandonment flows: flow filter. On abandoned checkout, anyone who places an order should be out. On abandoned cart, anyone who starts checkout or places an order should be out, so they don't get both sequences. The rule underneath it: every abandonment flow exits anyone who moves closer to buying. Why cart and checkout should be two flows is in abandoned cart vs abandoned checkout.

One product category only: trigger filter. If a Viewed Product or Placed Order flow should only run for one category or above a price point, that's a property of the event, so it's a trigger filter. It only needs checking once.

Not hitting the same person too often: re-entry criteria. This used to be a "has been in this flow" filter. Per Klaviyo, re-entry criteria now replace those filters: you choose whether people enter only once, re-enter whenever they qualify, or re-enter only after a minimum time period. Setting a minimum time period keeps someone who abandons three carts in a week from getting the same sequence three times. That's especially worth setting on lower-intent flows like browse abandonment, where people trigger the flow over and over.

Large-quantity buyers: keep them out. Someone ordering in bulk usually shouldn't get emails written for one person's order. In my birthday flows, for example, I exclude large-quantity buyers and split the rest into customer, non-customer and VIP paths. Details are in my birthday email flow post.

One more setting that isn't a filter but acts like one: Smart Sending. I turn it off on automations, so people don't miss critical reminders. If you've ever wondered why an abandonment email shows skips you didn't set up, check that first. More in Klaviyo Smart Sending.

What are the most common Klaviyo filter mistakes?

These are the ones worth checking first in any account.

A filter that removes everyone. One condition that's slightly off can mean almost nobody qualifies. If a flow shows people triggering it but almost no sends, open Recipient Activity and look for "Skipped: Fails Profile Filters." A big number there points straight at the filter.

Using a trigger filter for a purchase exit. A metric-based trigger filter is only checked on entry. Someone who buys an hour later still matches it and keeps getting emails. Purchase exits go in a flow filter.

Filtering on the wrong event. Added to Cart, Started Checkout and Placed Order aren't the same thing. If your cart flow only exits on Placed Order, people who already started checkout get both the cart and the checkout sequence.

The wrong time window on a split. When you split on Placed Order, check the time window on the condition. Per Klaviyo, the default window is "in the last 30 days," not "over all time," so if you leave it, a customer from four months ago gets treated like a stranger.

Using a split when you meant a filter. A split only looks at someone when they reach it. If you want buyers out at any point, a split near the top won't catch someone who buys on day three. A flow filter will, because it's checked again before each message.

Filtering on opens. Opens are a shaky signal. Across 4 consumable brands and 2,897 campaigns, Apple auto-opens pushed some segments' open rates past 85%. A filter built on "opened" lets in a lot of people who never actually read anything. Klaviyo doesn't let opens or clicks trigger a flow at all, which tells you something.

If you want the full list of what to check, it's in my Klaviyo audit checklist.

How do you test a new filter without emailing the wrong people?

Use Manual status. Per Klaviyo, a message set to manual is active in the flow, but nothing sends automatically; people queue up in Needs Review instead. Set the new messages to manual, let the flow run for a day, then look at who's waiting in Needs Review and who was skipped in Recipient Activity. Once the right people are getting through, switch the messages to live. Klaviyo notes that switching to live doesn't automatically send the messages already sitting in Needs Review, so decide what to do with those separately.

Avoid testing with Draft. Per Klaviyo, a draft message in a live flow is simply skipped, so you learn nothing about who would have gotten it.

Where these numbers come from

The open rate figure comes from 4 consumable brands I work with: 2,897 campaigns and $17.7M in email revenue. It's a small sample, so treat it as directional. For how brands compare more broadly, see my CPG email marketing benchmarks.

FAQ

WRITTEN BY Jack White

Founder of Bardown Digital, a Chicago-based Klaviyo email and retention agency for Shopify brands. He's worked with brands doing $500K to $100M a year, with $100M+ in email-attributed revenue across them.

Instagram @jackintheinbox LinkedIn