Objects in Customer.io

Overview

Objects in Customer.io help you model the non-person data that actually drives D2C revenue, like products, SKUs, carts, orders, subscriptions, and returns, then use that data to personalize messages and targeting at scale (without stuffing everything into person attributes). Objects in Customer.io are especially useful when you want campaigns to reference changing data, like cart contents, product availability, or a customer’s last order items.

If you want this set up cleanly across your catalog, cart, and order data so your flows stay maintainable as you scale, Propel can implement it end-to-end inside Customer.io, then pressure test it against real revenue journeys, book a strategy call.

How It Works

Objects in Customer.io work by storing records for things like products, carts, and orders, then linking those records to people through relationships so campaigns can pull the right context at send time.

In practice, you define an object type (for example, Product), send object records (like one record per SKU with price, title, image URL, inventory status), and define relationships (like a person “has” many orders, or a cart “belongs to” a person). Once the relationships exist, you can segment or personalize using the object data, like “customers with an order containing a specific collection” or “people with an active cart over $100.”

Objects become most valuable when your messaging needs to reference a variable set of items, not a single static field. That is the difference between a generic cart recovery email and one that dynamically lists the exact items, quantities, and total, then swaps recommendations based on what is in the cart. For implementation support, many brands work with an experienced Customer.io partner to get the data model and relationships right before they build journeys.

Step-by-Step Setup

Objects in Customer.io are easiest to roll out when you start from the revenue journeys you care about (cart recovery, post-purchase cross-sell, replenishment), then map backwards into the object types and relationships you need.

1. Choose the first revenue use case. Start with one, like abandoned cart recovery with dynamic line items, or post-purchase cross-sell based on last order contents.
2. Define the object types. Typical D2C object types include Product (SKU), Cart, Order, Subscription, and Return. Keep the first version minimal.
3. Decide the “source of truth” fields per object. For Product, that might be title, price, compare_at_price, image_url, product_url, category/collection, and availability. For Order, include order_id, total, currency, discount_total, items array, and purchased_at.
4. Create relationships between people and objects. Common patterns are Person to Order (one-to-many), Person to Cart (one-to-one or one-to-many if you want history), and Order to Product (many-to-many via line items, depending on your structure).
5. Send object records and relationship updates. Sync products on a schedule, create or update carts in near real time, and write orders immediately after purchase so post-purchase flows have accurate context.
6. Validate data in a staging segment. Build a segment that targets internal test profiles, then confirm object fields render correctly in email and SMS personalization.
7. Deploy one journey that depends on objects. Launch cart recovery or post-purchase first, then expand to browse abandonment, replenishment, and winback once the model is stable.

When Should You Use This Feature

Objects in Customer.io make the biggest difference when your retention program needs to reference products, carts, or orders in a way that stays accurate as those records change.

• Abandoned cart recovery with real line items. Send the exact items, quantities, and cart total, then suppress messages if the cart converts or the items go out of stock.
• Post-purchase cross-sell based on what they bought. If someone bought a cleanser, recommend moisturizer SKUs, not a generic “best sellers” block.
• Replenishment and reorder nudges. Use last order items and purchase date to time replenishment, then include one-click “buy again” links per SKU.
• Product discovery journeys. Build segments like “people who bought in category A but not category B” and push curated bundles or quiz-driven recommendations.
• VIP and high-LTV targeting. Use order history objects to identify repeat buyers, high AOV cohorts, or customers trending down in purchase frequency.

Operational Considerations

Objects in Customer.io only perform when the data model is disciplined, the sync cadence matches your journeys, and your team agrees on what fields are safe to use in segmentation and personalization.

• Model for change, not perfection. If your catalog changes weekly, keep Product objects updated on a schedule and treat price and availability as volatile fields.
• Sync timing matters for revenue flows. Cart and checkout events need near real-time updates, while product catalog updates can be batched.
• Define relationship rules. Decide whether you keep multiple carts per person (history) or only the latest active cart, because it changes how you segment and how you render content.
• Set suppression logic early. Cart recovery should stop on purchase, and post-purchase should suppress if an order is refunded or canceled (if that matters for your brand experience).
• Keep Liquid templates resilient. Expect missing images, discontinued SKUs, or empty carts, then add fallback blocks so you do not send broken emails.

Implementation Checklist

Objects in Customer.io are ready for production when the data is consistent, relationships are reliable, and your key journeys can render content without edge case failures.

• Object types defined for Product, Cart, and Order (start with the minimum needed)
• Field naming conventions documented (price, currency, image_url, product_url, purchased_at)
• Relationships created (Person to Cart, Person to Order, Order to Products or line items)
• Sync cadence set (real time for carts and orders, scheduled for products)
• QA segment built for internal profiles with test carts and test orders
• At least one object-powered journey launched (cart recovery or post-purchase)
• Fallback logic in templates for missing fields and empty arrays
• Reporting plan defined (conversion rate for cart recovery, repeat purchase rate post-purchase)

Expert Implementation Tips

Objects in Customer.io pay off when you treat them like your retention data layer, not just a personalization trick.

• Start with cart recovery, then expand. In retention programs we’ve implemented for D2C brands, cart is the fastest place to prove ROI because the object data maps directly to revenue and message relevance.
• Keep “latest order” as a relationship shortcut. You can store full order history, but also maintain a simple pointer to the most recent order for faster segmentation and easier Liquid rendering in post-purchase flows.
• Use objects to prevent bad sends. If inventory status is in the Product object, you can suppress or swap items in recovery emails when a SKU goes out of stock, which reduces refunds and support tickets.
• Design for merchandising control. Add fields like collection, margin tier, or “eligible_for_upsell” so marketing can steer recommendations without engineering changes.

Common Mistakes to Avoid

Objects in Customer.io can create messy journeys when teams rush the data model or rely on brittle templates.

• Overloading person attributes with catalog data. That approach breaks quickly as soon as you need multiple items, multiple orders, or changing prices.
• Building relationships inconsistently. If some carts are linked to people and others are not, your segments will quietly miss high-intent shoppers.
• Not handling edge cases. Empty carts, missing images, and discontinued SKUs happen constantly in D2C, your templates need fallbacks.
• Using slow syncs for time-sensitive flows. If cart updates arrive late, you will send recovery messages after purchase, which costs trust and deliverability.
• Trying to model everything on day one. Start with Product, Cart, and Order, then add Returns or Subscriptions once your core revenue journeys are stable.

Summary

Use Objects when you need campaigns tied to products, carts, and orders, not just static customer fields. They unlock more accurate cart recovery, smarter post-purchase, and higher repeat purchase rates inside Customer.io.

Implement with Propel

Propel can design your object schema, sync strategy, and object-powered journeys in Customer.io, then help your team operationalize it for ongoing merchandising and testing. If you want a clean build that scales past one flow, book a strategy call.