When Do Klaviyo Custom Objects Actually Make Sense?

Custom Objects become useful when one customer can have several related things, each with its own information and changing status.

A customer can own two vehicles, hold several bookings or manage multiple subscriptions. Flattening all of that into a single “next date” or “current product” property creates ambiguity. Which booking does the date refer to? Which subscription paused? Which vehicle should the recommendation fit?

The decision is not whether a richer data model sounds sophisticated. It is whether the model helps the brand make a useful customer decision that simpler data cannot support reliably.

Start with profiles, events and objects

A profile describes the person or customer record. A property can hold a preference or current attribute.

An event records something that happened, such as an order, product view or subscription change. Event data is useful for understanding a particular action and its context.

An object represents an entity with its own properties and relationships. For example, a booking can have an identifier, departure date, destination and status. One person can be associated with several bookings.

Klaviyo’s getting-started guide explains the model and account limits. Current documentation specifies access requirements, so confirm availability and limits in the account before scoping implementation. Do not assume every free account includes the same capabilities.

The practical decision test

Consider an object when the entity has its own identity, can exist more than once per customer, changes over time and needs to be referenced consistently in marketing.

Then name the decision it enables. “We want cleaner data” is too broad. “We need to send preparation guidance for each upcoming booking without confusing two trips” is concrete.

If the data only describes one completed action, an event may be sufficient. If it is one simple current preference, a profile property may be sufficient. Use the least complex model that preserves the information required for the decision.

Example 1: several subscriptions

Imagine a customer has two subscriptions with different products and renewal dates. One is active and one is paused.

A single profile property called subscription_status cannot describe both accurately. A subscription object could hold a stable subscription ID, product, status, next renewal date and relationship to the customer.

The useful treatment might be a renewal reminder for the active subscription while avoiding a replenishment message for the paused one. The implementation still needs rules for cancellations, date changes and duplicate updates.

This is an illustrative design, not a claim that every subscription integration automatically supplies these fields.

Example 2: product ownership and compatibility

An automotive customer may own two vehicles. A recommendation suitable for one vehicle can be wrong for the other.

A vehicle object could contain the verified fitment attributes and the customer relationship. A product recommendation must then use the correct vehicle context and a dependable compatibility source.

The object stores context; it does not prove that a product fits. Catalogue data and compatibility logic still need an owner and validation.

See our automotive parts lifecycle guide for how fitment confidence shapes the wider journey.

Example 3: bookings and appointments

A person may have several future appointments or bookings, each with different dates and requirements.

Objects can help preserve those separate records. A date-based journey can then refer to the relevant booking instead of overwriting one profile-level date whenever a new reservation appears.

A cancellation should change the treatment. A reschedule should update timing. A completed booking should move the customer into an appropriate follow-up.

Klaviyo documents object-based flow usage, including date-triggered flows and splits. Check the supported behaviour against your specific use case before committing to a design.

When Custom Objects are unnecessary

A straightforward apparel brand may not need an ownership object for every T-shirt. Order events, product data and well-governed profile properties may already support the required journeys.

Likewise, creating an object for every transient marketing label can make the account harder to maintain without improving decisions.

Ask what would break if the object did not exist. If the answer is only that the data would look less elegant, reconsider the implementation.

The same discipline applies to segmentation. More fields do not automatically create more relevant experiences. Read our practical segmentation guide before expanding the model.

Write the commercial specification first

Document the entity, stable identifier, relationship to the customer, authoritative source and update rules.

Next define the customer decision, eligibility, exit conditions, channel treatment and success metric. Include what happens when the data is missing, late or contradictory.

For a booking, the specification might require a confirmed status and future departure date before preparation messages can begin. Cancellation ends the journey. A missing destination produces a safe generic fallback rather than an incorrect recommendation.

These rules are the strategy. The object schema is one part of the implementation.

Plan updates and deletion carefully

Decide which system owns the truth. Avoid manually correcting a marketing record that will be overwritten by the next sync.

Use stable identifiers and a clear approach to updates. Define how deleted, cancelled or merged source records should be reflected. Include relationships and customer identity resolution in testing.

Klaviyo’s Custom Objects FAQ provides implementation guidance, including updating the original data source and syncing the revised object. Follow the supported API or integration path and review current limits.

Do not collect additional sensitive information simply because the object model can store it. Keep the data necessary for the defined experience.

QA with multiple entities, not just one

A test containing one customer and one booking is insufficient. Test one customer with two active objects, one active and one cancelled object, missing dates, changed dates and duplicate source updates.

Check that the correct object supplies the message content. Validate fallback text and ensure a change to one entity does not incorrectly end or trigger the journey for another.

Klaviyo’s template guidance explains how object data is used in messages. Preview the actual context available in the relevant campaign or flow.

Measure the decision the object enabled

The return on implementation comes from better customer outcomes or reduced operating risk. Track the behaviour the model was designed to improve, such as relevant renewals, completed preparation or fewer inappropriate reminders.

Use a controlled comparison where practical and include implementation and maintenance costs. A richer database is not itself evidence of retention lift.

If you are considering Custom Objects, book a Thrivelia consultation. We can help define the customer decision, assess whether objects are necessary and scope a model the team can operate reliably.

Continue with Klaviyo technical support and our lifecycle services.