First name tokens are not personalisation, Klaviyo custom events are

A first name in the subject line is courtesy, not personalisation

A client asked us last month to make her emails feel a bit more personal. Maybe use first names more. We already did, on every single send, and it was doing almost nothing for her conversion rate. A first name token in the subject line has been table stakes for years.

It's not personalisation, it's just good manners. Real personalisation is Klaviyo already knowing that Sarah finished your skin type quiz, told you she has combination skin, and has viewed the same serum three separate times without buying it. All of that is sitting on her profile right now, timestamped and waiting for a flow to ask.

Klaviyo already knows enough about your customers. What almost no account has is a single flow built to use what it knows.

Your account is logging more than your flows ever ask about

Every account tracks a set of default events from the moment the tracking script goes live. Most quiz, sizing and preference tools push their own custom event into Klaviyo the second somebody finishes, usually under a metric name like Quiz Completed or Skin Assessment Submitted, and the event arrives carrying properties: skin type, hair concern, sometimes a budget preference if the quiz asks for one.

• Viewed Product, Viewed Category, Added to Cart, Started Checkout and Placed Order, tracked by default on every account
• Custom events pushed by quiz and preference apps, each under its own metric name
• Properties riding on those events, such as the skin type a customer chose
• Profile properties written permanently, queryable long after the event itself fired

None of it needs a developer to switch on, because it's already firing. You can see it today under Analytics, in the Metrics view, event by event and property by property. Most brands never open that screen, so one browse abandonment flow built from the default template ends up carrying the whole personalisation strategy.

One quiz answer should change everything the email says

Take the scenario sitting in your account today. A customer completes a skin type quiz, gets tagged as combination skin, then views the same serum three times without buying. Most brands send her a generic still thinking it over email, identical whether she viewed a serum, a cleanser or a hairbrush, with her first name dropped in at the top.

The data is telling you to send something else entirely. Open by naming the product. Answer the question combination skin customers actually ask, whether it clogs pores and how it behaves on an oily T-zone, and pull in a review from a customer who gave the same answer if your review data is segmented that way. Three views of one product is hesitation, not a reminder opportunity.

The build difference between those two emails is small: one conditional split and one frequency condition on the trigger. The output difference is the part that moves conversion.

Use every custom event twice, once now and once forever

Once a quiz app pushes its event into Klaviyo you've got two separate ways to use it, and most accounts only ever use one. That's the whole reason a quiz can look clever and change nothing.

First, trigger a flow straight off the event. Somebody finishes the quiz, a flow fires within minutes, and it delivers their result and a recommendation tied to the answer they just gave. They're warm, they've just told you something about themselves, and the email has to land while that's still true.

Second, use the property the event left behind as a standing filter everywhere else. That same skin type value belongs as a conditional split in your welcome flow, your winback flow and your campaign segments, and it never expires. Most brands do the first, ignore the second, and let the quiz earn its keep for exactly one email.

Decide between a new flow and a split inside the one you have

The commonest failure we find in the accounts we take over is a flow that looks like it branches and splits on nothing useful. Every subscriber who enters gets the same three emails, whatever they viewed or answered. That's still first name personalisation, just with extra steps.

The fix is a conditional split right after entry, on the property that arrived with the triggering event or already sits on the profile. Split by product category, by the quiz answer, or by the price band viewed, then let each branch send genuinely different content instead of one static template. A customer who has only ever browsed haircare should never land in a branch showing her a serum.

The decision worth making out loud is when a signal deserves its own flow. Our rule: a separate flow when the trigger event is genuinely different, quiz completion against product view, and a split inside an existing flow when the trigger is the same and only the content needs to diverge.

Open the metrics screen before you build anything new

Open Klaviyo, go to Analytics, then Metrics, and read the full list of events actually firing into your account. Find your quiz or preference event, click into it, and look at the properties attached. That inventory is the first thing we do inside any account we take on, before a single flow gets touched.

The flows report names the triggering metric under every flow, which keeps the audit honest. Check whether a single live flow uses your custom event as a trigger, or its property as a split, anywhere in its logic. For most accounts the answer is no, and closing that gap needs no new tool and no developer. Just somebody in the flow builder, or a team that lives there, which is what we do inside Klaviyo.