Custom Push Payloads in Customer.io

Overview

Custom push payloads in Customer.io let you pass extra data inside a mobile push notification, so your app can react intelligently when someone taps. For D2C brands, this is the difference between a generic “Come back” push and a tap that lands a shopper on the exact cart, PDP, or order status screen that moves revenue.

If you want these payloads to map cleanly to your app’s deep links and your merchandising priorities, Propel can help you design the event and payload schema so it scales across campaigns in Customer.io. If you want to pressure test your cart and post-purchase mobile flows, book a strategy call.

How It Works

Custom push payloads in Customer.io work by attaching key-value pairs (often JSON) to a push message, alongside the visible title and body.

When the push is delivered, the mobile OS hands your app both the notification content and the custom payload. Your app code reads the payload and decides what to do, most commonly deep linking to a specific destination (cart, checkout, PDP, collection, order tracking) and optionally logging an analytics event like push_opened with the same identifiers.

In practice, you set the payload in your push message (campaign or transactional push) using static values and dynamic variables from event data, person attributes, or objects. Then your iOS and Android teams implement a consistent contract, meaning the same payload keys always trigger the same in-app behaviors. This is where Customer.io becomes a reliable revenue channel instead of a one-off push tool.

Step-by-Step Setup

Custom push payloads in Customer.io are easiest to roll out when you start with 2 to 3 high-impact destinations and a strict payload naming convention.

1. Align on your mobile destinations that directly drive revenue (cart, checkout, PDP, collection, order tracking, subscription management).
2. Define a payload schema your app will support (example keys: deep_link, screen, sku, variant_id, cart_id, order_id, offer_id, utm_campaign).
3. Have engineering implement payload handling in iOS and Android (read payload, route to the correct screen, handle fallbacks if data is missing).
4. Standardize deep links (one format) and decide what happens if the product is out of stock or the cart no longer exists (fallback to collection, best-sellers, or cart overview).
5. In Customer.io, create a push message and add the custom payload fields your app expects (use dynamic variables from the trigger event where possible).
6. Trigger the message from a real commerce event (example: checkout_started, cart_updated, product_viewed, order_shipped), and pass identifiers in the event data so you can inject them into the payload.
7. QA on device, not just in previews (validate payload keys, deep link routing, and analytics events on open).
8. Launch with a single journey first (abandoned checkout or post-purchase), then templatize the payload for other pushes.

When Should You Use This Feature

Custom push payloads in Customer.io are the right move when a push tap should land a shopper in a specific buying context, not a generic home screen.

• Abandoned cart recovery on mobile: Send a push 30 to 90 minutes after cart activity with cart_id and a deep_link straight into the saved cart.
• Price drop or back-in-stock: Payload includes sku or variant_id so the app opens the exact PDP variant, not a search page.
• Post-purchase cross-sell: After order_delivered, payload routes to a curated “pairs well with your purchase” collection tied to the purchased category.
• Subscription or replenishment: For consumables, payload opens subscription management or a one-tap reorder flow keyed by last_purchased_sku.
• Reactivation with personalized discovery: For lapsed buyers, payload opens a personalized collection (best-sellers in their last purchased category) rather than a blanket promotion.

Operational Considerations

Custom push payloads in Customer.io require tight coordination between segmentation logic, event instrumentation, and app routing to avoid broken experiences that waste sends.

• Data contract: Treat payload keys like an API. Version them if needed (example: payload_version) so app changes do not break old campaigns.
• Event completeness: Cart and checkout events must include durable identifiers (cart_id, line items, currency, total) so you can build payloads without brittle Liquid logic.
• Deep link fallbacks: Define what happens if an item is OOS, a cart expired, or a user is logged out. Your payload can include both a primary and fallback link.
• Segmentation guardrails: Only send cart-link pushes to people with a recent cart event and a valid device token. Add frequency caps so you do not burn push permission.
• Measurement: Log push_opened and downstream events (viewed_cart, checkout_started, purchase) with the same IDs from the payload to attribute revenue accurately.

Implementation Checklist

Custom push payloads in Customer.io work best when you operationalize them like a repeatable template, not a one-off campaign tweak.

• Payload schema documented and agreed with mobile engineering
• Deep link format standardized across iOS and Android
• Cart, checkout, product, and order events include required identifiers
• Fallback behavior defined for missing or invalid payload values
• Push open tracking implemented with payload identifiers
• At least one journey templatized (abandoned cart or post-purchase)
• QA process includes on-device testing for each app release
• Frequency caps and suppression rules added for recent purchasers

Expert Implementation Tips

Custom push payloads in Customer.io become a revenue lever when you treat the payload as the bridge between message intent and in-app conversion.

• In retention programs we’ve implemented for D2C brands, the biggest lift comes from pushing shoppers into the exact step they abandoned (cart or checkout) rather than a PDP. Start there before you get fancy with personalization.
• Keep payload keys stable and simple. A small set of keys like deep_link, campaign_intent, and one identifier (cart_id, sku, order_id) usually outperforms a complex payload that breaks during app updates.
• Use intent-based payloads for reporting. Add campaign_intent values like cart_recovery, post_purchase_cross_sell, back_in_stock so you can compare performance across journeys without relying on message names.
• Pair payload routing with offer logic. For example, only include a discount code in the payload after the shopper ignores the first cart push, then route them to the cart with the code pre-applied.

Common Mistakes to Avoid

Custom push payloads in Customer.io can quietly underperform when execution details are off, even if the creative looks great.

• Sending people to the home screen: If your payload does not deep link, you lose the “momentum” that push is meant to capture.
• Missing identifiers in events: Teams often trigger cart pushes from a generic event that lacks cart_id or line items, then try to patch it with brittle logic.
• No fallback logic: Expired carts and OOS products are common. Without a fallback link, taps create dead ends and reduce future opt-in rates.
• Over-personalizing too early: A complicated payload that depends on many attributes increases QA burden and breaks more often than it helps.
• Not instrumenting push opens: If you cannot connect payload IDs to downstream purchase events, you will underinvest in a channel that is actually working.

Summary

Use custom push payloads when you need push taps to land shoppers in the exact cart, product, or order context that drives conversion. Done well, it improves cart recovery, repeat purchase, and reactivation because the app experience matches the message intent in Customer.io.

Implement with Propel

Propel helps D2C teams design payload schemas, event instrumentation, and journey logic so Customer.io push drives measurable revenue, not just opens. book a strategy call.