A simple way to understand where customer data should live and how it can be used across segments, campaigns, flows and personalisation.

When sending data into Klaviyo, one of the first decisions is where that information should live.

Some data describes what is currently true about a customer.

Other data describes something that happened at a particular moment.

Klaviyo handles these differently:

Customer / profile properties describe the customer’s current state.

Event properties describe the context around an action or event.

Understanding the difference makes segmentation, automation and personalisation much easier.

Customer properties: what is true now?

Customer properties live on the Klaviyo profile.

Think of them as attributes Klaviyo currently knows about that person.

For a subscription business, these might include:

• has_active_subscription
• has_ever_subscribed
• subscription_status
• subscription_product_name
• subscription_next_billing_date

For other businesses, they could be things like:

• loyalty tier;
• preferred language;
• customer type;
• favourite category;
• membership status;
• lifecycle stage.

The useful question is:

What do I currently know about this customer?

Event properties: what happened?

Events record actions.

For example:

Placed Order

Viewed Product

Subscription Created

Subscription Status Updated

The properties attached to an event tell Klaviyo more about that specific action.

A Subscription Status Updated event might contain:

• previous status;
• new status;
• product;
• contract ID;
• date of the change.

The useful question here is:

What happened, and what was true when it happened?

Why does the distinction matter?

Because the two types of data are useful for different jobs.

In practice, good CRM architecture often uses both.

Using them in segments

Customer properties are particularly useful when you want to build an audience based on who somebody is now.

For example:

Active subscribers

has_active_subscription = true

Former subscribers

has_active_subscription = false

and:

has_ever_subscribed = true

Events are useful when the audience is based on something somebody did.

For example:

Customers who cancelled recently

People who triggered:

Subscription Status Updated

where the new status was cancelled.

So a useful shorthand is:

Profile properties = state

Events = behaviour

Using them in campaigns

Profile properties are very useful for controlling who should receive a campaign.

For example:

A subscription acquisition campaign could exclude:

has_active_subscription = true

because those customers already subscribe.

Event data can help you create more behavioural campaign audiences.

For example:

Customers who purchased a certain product.

Customers who cancelled recently.

Customers who viewed something but haven't bought.

Both can contribute to campaign targeting, but they're answering slightly different questions.

Using them in flows

Events are particularly useful when you want something to happen because an action just occurred.

For example:

Subscription Created

↓

Start subscriber onboarding.

Or:

Subscription Status Updated

↓

Customer cancelled.

↓

Start the cancellation journey.

Customer properties then help Klaviyo understand the customer’s current state as the journey continues.

That matters because customers change.

Someone may trigger a cancellation event today and resubscribe next week.

Their cancellation still happened, but their current subscription status is now active again.

Using them for personalisation

The same principle applies to dynamic content.

Customer properties

Useful when the message refers to something currently known about the recipient.

For example:

• current subscription product;
• loyalty tier;
• preferred category;
• language;
• membership status.

Event properties

Useful when the message refers to the specific thing that just happened.

For example:

Your subscription to Product A has been cancelled.

or:

You left Product B in your basket.

The event provides the context for that particular action.

A simple subscription example

Imagine a customer cancels their subscription.

You might send Klaviyo an event:

Subscription Status Updated

containing:

• previous status;
• new status;
• product;
• contract ID.

At the same time, you update their profile:

has_active_subscription = false

has_ever_subscribed = true

subscription_status = cancelled

Now Klaviyo knows two things:

What happened

The customer cancelled.

What's true now

They're a former subscriber.

That combination gives you much more flexibility than storing either one alone.

The easiest rule to remember

When deciding where data should live, ask:

Do I need to know what happened?

Use an event.

Do I need to know what is true about the customer now?

Use a profile property.

Do I need both?

Store both.

That simple distinction solves a surprising number of CRM architecture problems.

Want to see a practical example?

I use this structure when passing subscription-app data from Shopify into Klaviyo.

Read:

How to Send Shopify Subscription Data to Klaviyo Using Shopify Flow

It shows how subscription data can be structured so Klaviyo understands active, paused, cancelled and former subscribers.

Want to go deeper?

I'm building the Brutish Subscription Segmentation & Lifecycle Guide, covering how to turn this data into useful:

• segments;
• campaign audiences;
• lifecycle flows;
• exclusions;
• subscriber onboarding;
• cancellation;
• reactivation;
• winback;
• personalisation.

Join the waitlist to be notified when it's available.