Klaviyo Loyalty Events: One Event vs Seven Metrics
If you have tried to build a Klaviyo flow off a WooCommerce loyalty tool’s data and found yourself adding a trigger split before you could write a single email, the event model is why. Most loyalty tools model every loyalty change as one event, something like “Points Updated,” carrying a property that says what kind of change it was. A model built on seven distinct metrics instead removes that step entirely.
What “one event, many reasons” looks like in practice
A single-event model sends Klaviyo one metric no matter what happened: a purchase earned points, a refund took them back, a reward got redeemed, a balance expired. The event carries a property, often called something like reason or reason_title, that tells you which of those it actually was.
That single decision shapes every flow you build on top of it. Want a flow that only reacts to redemptions? You cannot trigger on “the event happened.” You have to trigger on the event, then add a trigger split or a conditional filter checking the reason property equals “redeemed,” before the flow does anything specific. Want a second flow for expiring points? Same event, same split, a different value to filter on. Every flow starts with the same piece of setup work, and every one of those filters is a place a typo or a mismatched value quietly sends the wrong email to the wrong audience.
What seven distinct metrics changes
Instead of one event with a property to filter, seven separate metrics exist: Points Earned, Points Redeemed, Points Revoked, Points Expired, Reward Unlocked, Points Milestone, and Program Joined. Each is its own trigger in Klaviyo’s flow builder.
The practical difference shows up the moment you open the flow editor. With a single-event model, “trigger on a redemption” is a multi-step setup: pick the event, add a split, set the condition, verify the value matches exactly what the plugin sends. With seven metrics, “trigger on a redemption” is one selection: Points Redeemed. There is no property to get wrong, because the trigger itself is the filter.
This also removes a specific kind of failure that is easy to miss until it costs you: a reason property renamed or restructured in a plugin update silently breaks every flow filtering on the old value, and nothing in Klaviyo tells you the filter stopped matching. A metric name does not get quietly restructured out from under a flow the same way an internal property value can.
A worked comparison
Say you want three flows: welcome a new member, nudge someone close to a reward, and win back someone whose points are about to expire.
Single-event model: three flows, each starting with the same event trigger, each needing its own trigger split and its own condition value checked against whatever the plugin documents as correct for that case. Three places to get a filter right, and three places a plugin update could quietly change the value you are filtering on.
Seven-metric model: three flows, each triggered directly on Program Joined, Points Milestone, and a segment built on the Points Expiring Soon profile property. No splits, no reason values to look up in documentation, no shared event to filter three different ways.
Where this actually lives
kind loyalty is built on the seven-metric model. The full reference, every metric, what fires it, and three complete flow recipes built on them, is on the Klaviyo integration page. If you are comparing this against a plugin-based loyalty tool specifically, see how the two approaches differ beyond just the event model, including where the loyalty logic itself runs.
The honest limit
This is specifically about event granularity, not about which platform has “better” Klaviyo support in general. A single-event model is not broken, and plenty of stores run one successfully; it just pushes filtering work into every flow you build, permanently, instead of doing that work once when the metrics are defined.
