Using Objects in Liquid in Customer.io

Overview

Using Objects in Liquid in Customer.io is how you turn your product catalog, orders, subscriptions, and loyalty data into message content that actually changes what a shopper does next. Instead of generic personalization like first name, you can pull in the exact product a customer browsed, the shade they bought last time, or the replenishment window for their last order and render it directly in email or SMS.

A common D2C scenario is a skincare brand that wants a post-purchase routine email to show the customer’s exact cleanser and moisturizer, plus the next best add-on based on the routine they purchased. Objects in Liquid makes that dynamic, so the same automation works across thousands of SKUs without building new templates every time.

If you want this kind of dynamic merchandising without your team getting stuck in Liquid edge cases, Propel can help you implement it cleanly inside Customer.io, then pressure test it against revenue goals. If you want help mapping Objects to your highest-impact journeys, book a strategy call.

How It Works

Using Objects in Liquid in Customer.io works by referencing non-person data (Objects) that you have connected to a person through relationships, then printing fields from those objects inside your message template.

Think of Objects as structured records like Product, Variant, Order, Subscription, or Store Location. A person profile can be related to one or many of these objects. In your message, Liquid can access the related objects and their attributes, then you render specific fields (like product title, image URL, price, or reorder date) or loop through a list (like last 3 ordered items).

Operationally, this is how you stop hardcoding merchandising blocks. Your cart recovery email can render the exact cart items, your post-purchase flow can render the exact products purchased, and your winback can render the most relevant category based on historical orders, all from the same template logic. For hands-on builds and QA, we typically implement this in Customer.io with a tight data contract so marketers can safely reuse components without breaking Liquid.

Step-by-Step Setup

Using Objects in Liquid in Customer.io is easiest when you treat it like a data project first, then a creative project second.

1. Define the Object types you need for revenue journeys. For D2C, start with Product (or Variant), Order, and Subscription (if you have replenishment). Add Review, Loyalty Tier, or Back-in-Stock only if you will actually use them in messaging.
2. Decide the relationships to the person. Examples include “person has many orders,” “person has last_order,” or “person has many viewed_products.” Keep relationships intentional, because they determine what Liquid can access easily.
3. Import Objects and relationships. Sync from your warehouse, Shopify data layer, or integration. The key is consistency in IDs and timestamps so “latest” is truly latest.
4. Confirm the Object fields you will render in messages. Typical fields include product_name, variant_name, image_url, price, compare_at_price, handle, category, and inventory_status. For orders, include order_id, items array (or relationship to order_items), order_total, and order_date.
5. Build a message component that reads from Objects. Create a reusable product card block that prints title, image, price, and link. This becomes the core building block for cart recovery, cross-sell, and replenishment.
6. Add Liquid safeguards. Use conditional checks so the message still renders if a relationship is empty (for example, no viewed products). Always include a fallback block like “Shop bestsellers.”
7. QA with real profiles. Test against at least 10 profiles covering edge cases: first-time buyer, repeat buyer, high AOV, out-of-stock item, multiple-item order, and no browsing history.
8. Launch in one high-impact flow first. Cart recovery or post-purchase cross-sell are usually the fastest payback. Once stable, reuse the same components across other journeys.

When Should You Use This Feature

Using Objects in Liquid in Customer.io is the right move when message relevance depends on data that is not a simple person attribute, especially when you want to scale personalization across a large catalog.

• Abandoned cart recovery with item-level accuracy. Show the exact items left behind, including variant details (size, color), and prioritize the highest-margin item first.
• Post-purchase cross-sell that matches what they bought. Render “Complete the set” recommendations based on product type or routine, not generic bestsellers.
• Replenishment and repeat purchase. Use last order date plus product-level replenishment windows to send smarter reorder nudges (for example, 21 days after a 30-day supply).
• Back-in-stock and price drop messaging. Trigger off an inventory or price object update and render the exact product the shopper cared about.
• Reactivation with category-level personalization. If the shopper’s last two orders were in “protein” and “hydration,” lead with that category rather than a broad discount email.

Operational Considerations

Using Objects in Liquid in Customer.io tends to succeed or fail based on data hygiene and how you operationalize template reuse.

• Data freshness matters. Cart and browse objects need near real-time updates. If your sync runs every 12 hours, your “left in cart” block will be wrong and conversion will suffer.
• Relationship design is a performance lever. If you only relate a person to “all orders,” pulling “last order” in Liquid gets messy. Create explicit relationships like last_order or last_purchased_products to keep templates simple.
• Standardize naming and field types. Price fields should be consistent (cents vs decimals). Image URLs should be complete and stable. A single inconsistent field can break rendering.
• Template governance. If multiple marketers touch Liquid-heavy messages, use components and lock down the core logic. Let marketers edit copy and layout, not the data plumbing.
• Measurement alignment. Tie each Object-powered block to a goal (repeat purchase within 30 days, attach rate, AOV lift). Otherwise you end up with sophisticated personalization that does not move revenue.

Implementation Checklist

Using Objects in Liquid in Customer.io goes smoother when you treat this as a checklist-driven rollout.

• Object types defined (Product, Variant, Order, Subscription, etc.)
• Person-to-object relationships mapped (including “latest” relationships where needed)
• Field dictionary documented (names, types, formatting rules)
• Sync cadence confirmed (cart and browse near real-time, orders at least hourly)
• Reusable Liquid components built (product card, order summary, recommendation row)
• Fallback logic added for empty relationships and missing fields
• QA test set created (10 to 20 real profiles covering edge cases)
• UTM and attribution conventions applied consistently to object-driven links
• Flow-level KPI defined (conversion, revenue per recipient, repeat purchase rate)

Expert Implementation Tips

Using Objects in Liquid in Customer.io gets powerful when you design for merchandising outcomes, not just personalization.

• Start with one “money flow.” In retention programs we’ve implemented for D2C brands, cart recovery is the fastest place to prove value because the shopper intent is already high. Use Objects to render items, then iterate on incentives and urgency.
• Build a recommendation hierarchy. Do not rely on a single data source. For example, try: cart items first, then recently viewed, then last purchased category, then bestsellers. Liquid can handle this with simple conditional logic and keeps the email relevant even when one dataset is missing.
• Merchandise for margin, not just popularity. If you store margin band or inventory pressure as object fields, you can bias recommendations toward higher contribution margin or overstock categories.
• Control the number of items you render. Too many products reduces clicks. A tight 2 to 4 item block usually outperforms a long grid, especially on mobile.

Common Mistakes to Avoid

Using Objects in Liquid in Customer.io can quietly underperform when execution details are off.

• Rendering the wrong “latest” object. If timestamps are inconsistent, “last order” might not be last. This breaks replenishment and post-purchase logic.
• No fallback when data is missing. A blank product block is a wasted send. Always include a default merchandising module.
• Over-personalizing too early. In retention programs we’ve implemented for D2C brands, teams sometimes build complex object logic before they have stable cart and browse tracking. Get the core events and relationships reliable first, then add sophistication.
• Ignoring deliverability and load time. If your object-driven images are heavy or unreliable, inbox placement and engagement can drop. Use optimized images and stable CDN links.
• Not QAing variant edge cases. Size and color mismatches are common when Product and Variant objects are not modeled cleanly. That leads to customer confusion and support tickets.

Summary

Using Objects in Liquid is worth it when your best-performing journeys depend on product, order, or inventory context that cannot live as simple person attributes. It is one of the cleanest ways to scale personalized merchandising across your automations in Customer.io.

Implement with Propel

Propel helps teams implement Objects in Liquid for Customer.io in a way that is reusable, QAed, and tied to conversion and repeat purchase outcomes. book a strategy call.