Objects and Relationships in Customer.io

Overview

Objects and relationships in Customer.io help you personalize messaging using non-person data like products, carts, orders, subscriptions, and back-in-stock inventory, then tie that data to a shopper profile through relationships. In practice, this is how you stop sending generic blasts and start sending messages that reflect what someone browsed, added to cart, or bought, which is where most D2C revenue lift comes from.

Anonymous messaging in Customer.io is not the point here, the win is building a product and order data model that makes every message feel like it was written for that specific shopper.

If you want this implemented fast with a clean data model that your team can actually maintain, Propel can help you get it live inside Customer.io, you can book a strategy call.

How It Works

Objects and relationships in Customer.io work by storing structured records (objects) and linking them to people (relationships), so campaigns can reference the right product, cart, or order at send time.

Think of it like this: a person is the shopper, an object is the thing you want to talk about (a cart, an order, a product), and a relationship is the join that tells Customer.io which cart belongs to which shopper, or which products belong to an order. Once that structure is in place, you can use object attributes in segmentation, triggers, and Liquid personalization across email, SMS, and push.

For example, you can model:

• A Cart object with attributes like cart_total, currency, last_updated, checkout_url
• A Cart Item object with sku, product_name, variant, price, quantity
• Relationships that connect a person to their cart, and a cart to its cart items

Then your abandoned checkout flow can pull the exact items, show the current total, and suppress the message if the cart is stale or already purchased. This is the kind of setup we typically build when brands say, “Our cart recovery is running, but it is not converting.” You can orchestrate all of it in Customer.io.

Step-by-Step Setup

Objects and relationships in Customer.io setup is mostly a data modeling exercise first, then a campaign build second.

1. Define the object types you need for revenue journeys. Start with Cart, Order, Product, and optionally Subscription (if you have replenishment) and Inventory (for back-in-stock).
2. Standardize IDs and keys. Pick a single source of truth ID for each object (cart_id, order_id, sku). Avoid “sometimes Shopify ID, sometimes internal ID” because it breaks joins later.
3. Choose the relationships you will rely on in campaigns. Common ones are person → cart, person → orders, order → order_items, cart → cart_items, product → variants.
4. Send objects into Customer.io. Import objects via your integration or API, and ensure required attributes are present (totals, timestamps, URLs, status fields).
5. Send relationships into Customer.io. Create the links between person and objects, and between parent and child objects (like cart to cart_items).
6. Validate in a real profile. Open a known customer profile, confirm you can see the related cart or order objects, and confirm attributes are populated correctly.
7. Use objects in campaign content. In your message, pull object attributes into Liquid (items, totals, product names, images, URLs).
8. Add safety filters. Filter out carts older than X hours, exclude if an order exists after cart_updated_at, and exclude if items are out of stock.
9. QA edge cases. Test multi-item carts, discount codes, partial refunds, split shipments, and customers with multiple open carts.

When Should You Use This Feature

Objects and relationships in Customer.io are worth the effort when personalization needs to be based on changing commerce data, not static customer attributes.

• Abandoned cart recovery that needs item-level content. Show the exact products left behind, current price, and a working checkout link, then suppress if the cart converts.
• Post-purchase cross-sell based on what was bought. If someone buys a cleanser, recommend the moisturizer that pairs with that product line, not a generic bestseller grid.
• Replenishment and repeat purchase timing. Use order items and purchase dates to time “running low” reminders based on the product’s typical usage window.
• Back-in-stock and price-drop messaging. Trigger when inventory status changes on a product object, then target people who viewed or added that SKU.
• VIP and CLV building journeys. Segment based on order_count, total_spend, category affinity, and recent product interactions stored as objects.

Operational Considerations

Objects and relationships in Customer.io only perform when the underlying data stays fresh, consistent, and campaign-friendly.

• Data freshness windows matter. In cart recovery, a 15 minute delay vs a 4 hour delay changes conversion rate, but only if cart_updated_at is reliable and updated on every cart change.
• Handle “multiple carts” intentionally. In retention programs we’ve implemented for D2C brands, the most common failure is messaging the wrong cart because the relationship points to an older cart_id. Decide whether you store one active cart per person or allow many and mark one as active.
• Normalize product data for messaging. Store product_title, image_url, and PDP_url at the object level so templates do not depend on external lookups.
• Orchestration across channels. If email and SMS both pull the same cart object, coordinate frequency and suppression so you do not double-tap the same shopper within minutes.
• Segmentation strategy. Use object attributes to create segments like “High AOV carts,” “First-time buyers of category X,” or “Orders with subscription_eligible = true,” then tailor offers and creative accordingly.

Implementation Checklist

Objects and relationships in Customer.io go smoothly when you lock the data contract before building the campaigns.

• Object types defined (Cart, Cart Item, Order, Order Item, Product, Variant as needed)
• Consistent IDs and naming conventions documented
• Relationship map documented (person → cart, cart → cart_items, person → orders, order → order_items)
• Required attributes present (timestamps, totals, URLs, status fields)
• Data update rules agreed (when cart_updated_at changes, when cart is closed, when order status changes)
• Liquid templates tested with multi-item carts and multiple variants
• Suppression logic added (purchased, stale cart, out-of-stock, refunded)
• Channel coordination rules set (send order, cooldowns, frequency limits)
• Reporting plan in place (revenue attribution, goal events, holdouts)

Expert Implementation Tips

Objects and relationships in Customer.io become a revenue lever when you design them around the decisions shoppers make, not around your database tables.

• Model for the message you want to send. If you want a cart email with a clean product grid, store image_url and short_title directly on cart items. Do not rely on “we can look it up later.”
• Create a single “active cart” relationship. In retention programs we’ve implemented for D2C brands, defining one current_cart relationship per person reduces wrong-cart sends and makes campaigns easier to maintain.
• Use status fields to simplify filters. A cart_status like active, converted, abandoned is easier than stacking multiple timestamp conditions everywhere.
• Separate “order” from “fulfillment.” If you send shipping and delivery messages, consider fulfillment objects so your post-purchase flow does not break when an order ships in multiple packages.

Common Mistakes to Avoid

Objects and relationships in Customer.io can quietly underperform when execution details are off, even if the campaign looks correct.

• Using inconsistent IDs across systems. If cart_id changes between your storefront and your event stream, relationships will mismatch and personalization will fail.
• Not updating objects on every change. Cart totals, discounts, and item quantities change often. If you only send the cart once, you will message stale data and hurt conversion.
• Forgetting to expire or close carts. Without a clear rule for when a cart is no longer active, you will keep targeting people who already purchased.
• Over-personalizing without fallbacks. Always include a fallback state for missing images, missing URLs, or empty item arrays, otherwise you risk broken messages at scale.
• Building templates before the data contract. Teams often design emails first, then realize the object attributes they need do not exist.

Summary

Objects and relationships are the foundation for cart, product, and order-aware messaging that drives higher conversion and repeat purchase. Use them when you need item-level personalization, cleaner suppression, and more reliable orchestration inside Customer.io.

Implement with Propel

Propel helps D2C teams implement Customer.io objects, relationships, and the campaigns that depend on them, from cart recovery to post-purchase upsells. If you want a clean build that your team can operate long-term, book a strategy call.