Custom events in Customer.io (Data In): make retention triggers reliable

Overview

If you want Customer.io to drive repeat purchase, cart recovery, and reactivation, your custom events need to enter the platform cleanly and consistently—otherwise your segments drift and your journeys misfire. If you want a second set of eyes on your tracking plan and identity rules before you scale, you can book a strategy call.

Custom events are the backbone of retention orchestration: they’re the “proof” that a shopper viewed a product, started checkout, abandoned a cart, purchased, or churned. In most retention programs, the difference between a top-performing flow and a noisy one comes down to event quality, not copy.

How It Works

At a mechanical level, custom events are records you send into Customer.io tied to a person (or an anonymous profile that later merges). Journeys then use those events to trigger entry, branch logic, and segment membership—so the data model has to be stable.

• Event ingestion: Your app/site/server sends an event name (like checkout_started) plus a timestamp and properties (like cart value, items, currency). Customer.io stores the event on the person’s activity timeline.
• Identity resolution: Events need a consistent identifier so Customer.io can attach them to the right person. In practice, this tends to break when you track events anonymously on-site but don’t merge after login/email capture—leading to “ghost abandons” that never enter recovery flows.
• Data mapping: Event properties become the fuel for personalization and branching (VIP vs non-VIP, high AOV vs low AOV, category-based follow-ups). If the same property shows up as value in one place and cart_value in another, your triggers and filters silently stop matching.
• Segmentation + triggers: Segments can reference event behavior (e.g., “did product_viewed in last 7 days but no order_completed”). Journeys can trigger on “performed event” and then filter by properties. Trigger reliability depends on event naming consistency and predictable timestamps.

D2C scenario: A shopper starts checkout on mobile, abandons, then completes purchase on desktop after clicking a retargeting ad. If your checkout_started event is anonymous and your order_completed event is identified, Customer.io may treat them as two different people. Result: the shopper still receives abandonment messages after buying. The fix is identity + merge discipline, not more suppression rules.

Step-by-Step Setup

Before you send anything, align on a tracking plan that matches how you actually run retention (cart recovery, replenishment, post-purchase cross-sell). Then implement events so Customer.io can confidently attach them to the right profile and your team can build segments without guessing.

1. Define your event taxonomy (names + meanings).
   Lock a small set of canonical events (e.g., product_viewed, added_to_cart, checkout_started, order_completed, subscription_created). Write one sentence for what each event means and when it fires.
2. Choose your identity strategy (and be strict).
   Decide what identifier you’ll use to attach events to people (email, internal customer_id). If you track anonymous browsing, decide when you “identify” and how you’ll merge anonymous activity into the known profile.
3. Standardize required event properties.
   For commerce retention, you’ll almost always want: order_id, currency, value (or total), items (array), sku/product_id, category, and coupon. Pick one schema and keep it consistent across web + backend.
4. Send events into Customer.io via your chosen integration path.
   Most D2C teams send events via a server-side source of truth (backend/order system) for purchases, and client-side for browse/cart signals—then reconcile identity. The key is that the purchase event must be authoritative and timely.
5. Validate events in Customer.io activity logs.
   Spot-check real people profiles: confirm event names, timestamps, and properties look right. Pay attention to duplicated purchase events and missing item arrays—those are common sources of broken filters.
6. Build a “debug segment” for each critical flow.
   Example: “did checkout_started in last 2 hours AND has NOT done order_completed since.” If this segment doesn’t match reality, your recovery automation won’t either.
7. Only then: wire journeys to events.
   Use the event as the trigger, then apply property filters (AOV threshold, category, first-time vs repeat) rather than creating lots of near-duplicate events.

When Should You Use This Feature

Custom events are the right move whenever retention depends on behavior that isn’t captured cleanly as a static attribute. If the customer can do it multiple times (view, add, abandon, purchase), it should usually be an event.

• Cart recovery that actually suppresses after purchase: Trigger on checkout_started and exit on order_completed with a strict identity/merge setup.
• Repeat purchase and replenishment: Use order_completed with item-level properties to trigger replenishment windows by SKU/category (not just “purchased”).
• Product discovery follow-ups: Trigger on product_viewed or category_viewed with properties so you can recommend within the same category and avoid irrelevant upsells.
• Reactivation based on true inactivity: Build inactivity segments off “no order_completed in X days” plus “no site_visit or email_click in Y days” (events keep this honest).

Operational Considerations

Retention teams feel the pain of bad data as “weird journey behavior.” The root cause is usually segmentation mismatch, delayed event delivery, or identity fragmentation. Treat custom events like production infrastructure, not a one-time setup.

• Segmentation accuracy depends on timestamps: If events arrive late (batch jobs, delayed webhooks), “within the last 1 hour” segments won’t behave. Align your windows to your ingestion reality or fix the pipeline.
• Orchestration breaks with duplicate events: Two order_completed events for the same order can double-trigger post-purchase journeys or inflate VIP logic. Use order_id and enforce idempotency server-side.
• Event naming drift kills maintainability: If one team ships Checkout Started and another ships checkout_started, you’ll end up with parallel journeys and inconsistent reporting. Lock naming conventions early.
• Anonymous-to-known merges are non-negotiable for recovery flows: If you collect email at checkout, make sure the anonymous browsing/cart activity merges into the known profile immediately—or your abandonment triggers will miss the window.
• Property schema consistency matters more than property volume: A small, stable schema beats a huge set of half-populated fields that make filters unreliable.

Implementation Checklist

Use this as your “ship it” gate before you build or scale any event-triggered retention journey. If you can’t check these off, you’ll spend the next month debugging suppression and blaming deliverability.

• Event names are canonical, lowercase, and documented with firing rules
• Each key event includes required properties (value, currency, order_id, items where relevant)
• Identity strategy is defined (customer_id/email), and anonymous merge behavior is tested
• Purchase events are server-side authoritative and idempotent (no duplicates per order_id)
• Events appear on real profiles in Customer.io with correct timestamps
• Debug segments match real-world behavior (cart abandoners, recent purchasers, lapsed buyers)
• Journeys use event triggers + property filters rather than many redundant event variants

Expert Implementation Tips

These are the small operator moves that keep your triggers clean as you scale channels, products, and storefront changes.

• Prefer “source of truth” events for money: Track browse/cart client-side, but track order_completed from the backend/order system so refunds, partial captures, and payment retries don’t create phantom revenue.
• Design for exits up front: For any recovery journey, define the exit event first (usually order_completed) and test it before you write message #1.
• Use properties to avoid event explosion: Instead of added_to_cart_shoes and added_to_cart_socks, use added_to_cart with category or product_type.
• Build a “last seen commerce intent” attribute from events: Many teams derive a single attribute like last_intent_category using event properties, which makes reactivation personalization easier and reduces segment complexity.
• Monitor event volume shifts: A sudden drop in checkout_started is usually a tracking regression, not a conversion miracle. Put alerts on event counts if you can.

Common Mistakes to Avoid

Most issues show up as “people got the wrong message” or “the flow didn’t trigger.” These are the usual culprits.

• Sending purchase events from the browser only: Ad blockers and network failures create missing purchases, which breaks suppression and post-purchase branching.
• No idempotency on order events: Retries and webhook replays create duplicates, double-triggering journeys and polluting segments.
• Inconsistent identifiers across systems: If your ESP uses email but your events use internal IDs without mapping, you’ll fragment profiles and lose history.
• Property type mismatch: One system sends value as a number, another sends it as a string. Filters like “value > 100” quietly stop working for part of your audience.
• Overly tight time windows: “Abandoned in the last 15 minutes” sounds great until your ingestion runs every 30 minutes. Match windows to data latency.

Summary

If your retention program depends on behavior, custom events are the control plane—but only when identity and schemas are disciplined. Nail event naming, required properties, and merge rules first, then build journeys on top. If you’re seeing misfires, fix the data-in layer before you touch creative.

Implement Custom Events with Propel

When teams ask why cart recovery or post-purchase feels inconsistent in Customer.io, it’s almost always an event/identity issue hiding under the surface. If you want help pressure-testing your event taxonomy, merge rules, and “debug segments” so your triggers fire cleanly across devices and channels, you can book a strategy call and we’ll walk through it like operators.