Object Types in Customer.io

Overview

Object types in Customer.io help you model the non-person data that drives D2C revenue, like products, variants, carts, orders, and subscriptions, then use that data to personalize messages and segments beyond basic customer attributes. When your catalog and commerce activity live as structured objects, you can send sharper abandoned cart recovery, post-purchase replenishment, and cross-sell journeys without cramming everything into event properties.

If you want object modeling that lines up with your merchandising strategy and your ESP roadmap, Propel can help you implement it cleanly in Customer.io, then pressure test it against real revenue flows, book a strategy call.

How It Works

Object types in Customer.io work by defining a schema for a kind of thing that is not a person (for example Product, Variant, Cart, Order), then creating object records and linking them to people through relationships so campaigns can reference the right items at send time.

In practice, you set up:

• An object type (the blueprint), including the attributes you will store and use for segmentation and personalization.
• Object records (the instances), like SKU-123, Order-98765, or Cart-abc.
• Relationships between a person and one or more objects, like “person has cart,” “person purchased order,” or “person viewed product.”

Once relationships exist, you can pull object attributes into message content (like product title, price, image URL, category, subscription interval) and you can build segments based on object data (like “has an active subscription object with next_charge_date in the next 7 days”). You can also use objects inside campaigns so each customer gets the right set of items instead of a generic recommendation block. If you are orchestrating across email, SMS, and push, this structure keeps personalization consistent across channels in Customer.io.

Step-by-Step Setup

Object types in Customer.io are easiest to set up when you start from the revenue use case (cart recovery, replenishment, cross-sell), then work backward into the schema.

1. Pick your first two revenue-critical object types. For most D2C brands, start with Product (or Variant) and Order. Add Cart next if you want true abandoned cart personalization.
2. Define the object attributes you will actually use. Keep it tight. For Product or Variant, common attributes include sku, title, price, compare_at_price, image_url, product_url, category, tags, inventory_status. For Order, include order_id, order_total, currency, purchased_at, discount_total, shipping_method.
3. Decide the relationship model. Example: Person “purchased” Order, Order “contains” Variant(s). For cart recovery: Person “has” Cart, Cart “contains” Variant(s).
4. Standardize IDs and naming. Use immutable IDs from your commerce platform (Shopify product_id, variant_id, order_id). Avoid human-readable titles as identifiers.
5. Import or sync initial objects. Load your catalog (products and variants) first so messages can reference items immediately. Then backfill recent orders if you want post-purchase journeys to have history on day one.
6. Create relationship sync rules. Ensure that when a cart is created or updated, the person-to-cart relationship updates, and cart-to-variant relationships reflect the latest line items.
7. QA in a real scenario. Use a test customer who views a product, creates a cart, and purchases. Confirm that the person profile shows the expected related objects and that message previews render correct product details.
8. Deploy one campaign that proves the model. Launch an abandoned cart email that loops through cart line items, then a post-purchase cross-sell email that references categories purchased.

When Should You Use This Feature

Object types in Customer.io are worth the effort when you need dependable, item-level personalization tied to commerce behavior, not just “last product viewed” as a single attribute.

• Abandoned cart recovery with exact line items. Show the products left behind, include images, sizes, and dynamic pricing, and suppress items that went out of stock.
• Post-purchase cross-sell that matches what they bought. Use the purchased Order object to recommend complementary items based on category, collection, or tags.
• Replenishment and replenishment reminders. If you store subscription or replenishment objects with next_charge_date or estimated_run_out_date, you can trigger reminders with accurate timing.
• Winback with product discovery context. Segment customers who only bought from one category, then send discovery content for adjacent categories using your Product object attributes.
• High LTV orchestration. Build segments like “customers with 3+ orders containing premium category variants” and route them into VIP replenishment, early access, or higher-touch flows.

Operational Considerations

Object types in Customer.io introduce a data layer that your retention program will depend on, so you need to treat schema and relationships like production infrastructure.

• Schema discipline. Every attribute you add becomes something teams will ask to use later. Keep attributes purposeful, and document which team owns each field (merchandising, retention, data).
• Update frequency and freshness. Cart objects need near real-time updates to avoid sending stale items. Catalog objects can update less frequently, but pricing and inventory fields should be reliable if you plan to message off them.
• Segmentation performance. Object-heavy segments can get complex. Build “helper” attributes where it makes sense (like last_purchased_category) but do not replace the object model with a pile of attributes.
• Orchestration across journeys. Decide whether cart recovery references the Cart object or an event payload. In retention programs we have implemented for D2C brands, using objects for carts reduces template chaos because the same looping logic works across email and SMS landing pages.
• Data QA and fallbacks. Your messages should gracefully handle missing image_url, missing compare_at_price, or deleted products. Add fallbacks so your cart recovery does not break during catalog changes.

Implementation Checklist

Object types in Customer.io go live smoothly when you validate the data model before you build the creative.

• Defined 2 to 4 object types tied to immediate revenue flows (Product or Variant, Order, Cart, Subscription)
• Confirmed immutable IDs and consistent naming conventions
• Documented required attributes for personalization and segmentation
• Mapped relationships (person-to-cart, cart-to-variant, person-to-order, order-to-variant)
• Synced initial catalog objects and verified update cadence
• Backfilled recent orders (optional but recommended for post-purchase and LTV segmentation)
• Built one message that renders object attributes (title, image, price, URL) correctly
• Built one segment that uses an object condition (example: has cart with 1+ items)
• Added message fallbacks for missing attributes and out-of-stock scenarios
• Set monitoring for object sync failures and relationship drift

Expert Implementation Tips

Object types in Customer.io pay off most when you design them for reuse across multiple journeys, not as a one-off for a single campaign.

• Start with Variant, not Product, if you sell sizes or bundles. Cart recovery breaks down when the customer chose “Medium” but you only stored the parent product. Variant-level objects keep the message accurate.
• Model cart as its own object when you want true cart state. Events are great for “added to cart,” but they do not represent what is still in the cart at send time. A Cart object with line item relationships solves this.
• Use objects to control merchandising logic. In retention programs we have implemented for D2C brands, tagging products with category, margin tier, or “hero SKU” inside the Product object makes it easier to steer cross-sells without rebuilding segments every time merchandising priorities shift.
• Build a single reusable line-item component. Create one template pattern that loops through related variants and renders image, title, price, and CTA. Reuse it in cart recovery, back-in-stock, and post-purchase emails.

Common Mistakes to Avoid

Object types in Customer.io can quietly underperform when the data model is technically correct but operationally messy.

• Overstuffing objects with rarely used fields. It slows down decision-making and increases the chance of stale attributes.
• Using non-unique IDs. If sku changes or titles are reused, relationships break and personalization becomes untrustworthy.
• Relying on event payloads for cart recovery while also building Cart objects. Pick one source of truth, otherwise two customers with the same behavior can receive different content.
• Not handling deleted or unpublished products. Catalog churn is normal in D2C. Without fallbacks, your highest-intent emails can render broken images or empty blocks.
• Ignoring relationship direction. Make sure you can traverse from person to the objects you need at send time. If the relationship only exists between objects, your campaign may not be able to resolve the items for a customer.

Summary

Use object types when you need dependable product, cart, and order context to personalize high-intent journeys like abandoned cart and post-purchase cross-sell. The payoff is cleaner templates, stronger segmentation, and more accurate messaging in Customer.io.

Implement with Propel

Propel helps teams design the right object schema, sync strategy, and reusable templates so your Customer.io journeys stay accurate as your catalog and customer behavior change. If you want to move fast without breaking data foundations, book a strategy call.