Test your push implementation (SDK)

Overview

If you’re running mobile push through Customer.io, “push not sending” is almost never a messaging problem—it’s usually an SDK identity or device-token problem. Before you scale cart recovery or replenishment pushes, you want a tight test loop that proves: the device is registered, the user is identified, events are arriving, and the right profile owns the right device.

If you want a second set of eyes on your tracking and identity stitching (the stuff that quietly breaks retention), you can book a strategy call and we’ll pressure-test your push data flow end-to-end.

How It Works

Customer.io push delivery depends on a clean chain of custody between the device and the person profile. In practice, the “test” isn’t just sending a push—it’s verifying that the SDK created/updated a device record, that record is attached to the right person, and your key retention events land on that same person so campaigns can target them.

• Device registration: Your app gets a push token from APNs (iOS) or FCM (Android) and the SDK registers it with Customer.io. If the token isn’t registered (or is stale), nothing downstream matters.
• Identify + identity stitching: The SDK needs to associate the device with a known person ID (or a stable identifier strategy). Most retention programs break here when users browse anonymously, then log in or check out—events end up on an anonymous profile while the device is attached to a different profile.
• Event tracking: Your app sends events (e.g., Product Viewed, Added to Cart, Checkout Started, Order Placed) with consistent properties. Campaign triggers and segments depend on these being predictable.
• Targeting: Customer.io sends push to the devices associated with the person who qualifies for the campaign/segment. If the person qualifies but has no device, you’ll see “eligible” users who never receive.

Step-by-Step Setup

When we test push, we run a controlled scenario on a real device and confirm each link in the chain inside Customer.io. Don’t skip steps—most teams jump straight to “send test push” and miss that the profile/device association is wrong.

1. Confirm SDK install and push permissions on a physical device
   Use a real device (not a simulator) and make sure push permission is granted. If permission is denied, you can still register a profile, but you won’t get a deliverable token.
2. Register the device token with Customer.io
   Verify your app obtains the APNs/FCM token and hands it to the Customer.io SDK. If you rotate tokens (common on reinstall), ensure you update the token in the SDK.
3. Call identify at the right moment (and only when you truly know the user)
   Tie the device to a stable person identifier (commonly your internal customer ID). Do this on login/account creation and again after checkout if guest checkout later becomes a known account.
4. Track a controlled event sequence from the app
   Trigger a realistic flow (example below) and send events from the device:
   • Product Viewed with sku, product_id, category
   • Added to Cart with cart_id, items, value
   • Checkout Started with cart_id, value
5. Validate in Customer.io that events landed on the same person who owns the device
   Open the person profile in Customer.io and check:
   • Recent events show the ones you just fired
   • The profile has an associated mobile device
   • The device looks current (not an old token from a previous install)
6. Send a targeted test push to that person
   Use Customer.io’s push testing tools to send directly to the profile/device you just validated. If it fails, you now know whether it’s a delivery/channel issue vs. a data/identity issue.
7. Test identity stitching with an anonymous-to-known transition
   Do one run where you browse anonymously, add to cart, then log in. Your goal: those pre-login events should still be usable for post-login messaging (or you should intentionally accept they won’t be, and adjust your strategy).

When Should You Use This Feature

Push testing is most valuable right before you rely on push for revenue-critical retention moments—because once you flip journeys live, silent tracking bugs create “ghost” audiences that look eligible but never receive.

• Cart abandonment push: You’re triggering Added to Cart but conversions are flat. Testing usually reveals the device is attached to an anonymous profile while the cart event is on a known profile (or vice versa).
• Post-purchase cross-sell: You want a push 7 days after Order Placed to recommend accessories. If Order Placed is server-side but devices are only registered app-side, you need to confirm both map to the same person ID.
• Reactivation: You’re building a “no purchase in 60 days” segment for push. This breaks when uninstall/reinstall creates a new device record that never re-attaches to the original customer profile.
• Back-in-stock or price-drop alerts: These are high-intent pushes. If you mis-stitch identities, you end up notifying the wrong person or nobody at all.

Operational Considerations

Push reliability is an orchestration problem: app SDK data, server-side purchase events, and segmentation logic all have to agree on identity. The teams that win retention treat this like a system, not a channel.

• Segmentation depends on device presence: Build a “push-addressable” segment (people with at least one active mobile device) and use it as a guardrail in push journeys. Otherwise you’ll inflate eligible counts and misread performance.
• Data flow split (app vs server): Many D2C stacks send Order Placed from backend/Shopify while browse/cart events come from the app. If person IDs differ (email vs customer_id), you’ll fragment profiles. Pick one canonical ID strategy and enforce it everywhere.
• Anonymous browsing is a fork in the road: Decide whether you will merge anonymous activity into known profiles. If you don’t, then cart recovery based on pre-login events won’t work for logged-in targeting—and you should design around that (e.g., trigger from server-side cart creation tied to email/phone).
• Frequency + deliverability: Push isn’t “free.” If your test users receive duplicates because you accidentally registered multiple devices per person (or created duplicate profiles), you’ll see opt-outs climb fast.

Implementation Checklist

Before you call push “done,” you want a checklist that confirms the basics under real user behavior (install, browse, login, checkout, reinstall). This keeps retention from chasing phantom issues later.

• SDK installed and initialized correctly on iOS/Android (or your cross-platform wrapper)
• Push permission prompt implemented and tested (allow + deny paths)
• APNs/FCM token captured and passed to the Customer.io SDK
• identify called with a stable person ID at login/account creation
• Anonymous-to-known stitching behavior confirmed (merge or intentionally separate)
• Key retention events tracked with consistent naming and required properties
• Person profile in Customer.io shows both: recent events + an active device
• Test push successfully delivered to a real device
• Push-addressable segment created and used as a journey filter

Expert Implementation Tips

Most retention programs we’ve seen don’t fail because the push provider is down—they fail because identity and event semantics drift over time. These tips keep your push channel stable as your app evolves.

• Standardize event names early: Pick one convention (Added to Cart vs add_to_cart) and lock it. Changing names later breaks triggers silently.
• Send a “debug breadcrumb” event in QA builds: A lightweight event like SDK Debug with app version/build number helps you confirm which app build produced which data when you’re testing identity issues.
• Guard against duplicate profiles: If marketing uses email as the identifier but the app uses customer_id, you’ll create two people. Decide the canonical ID and map the other as an attribute.
• Test reinstall behavior: Uninstall/reinstall is common in D2C (storage cleanup, new phone). Make sure the new token replaces the old one and reattaches after login.
• Use campaign filters that reflect reality: For cart recovery pushes, filter for “has device” + “has not purchased since cart event” + “cart value above X” so you don’t waste sends.

Common Mistakes to Avoid

These are the mistakes that create the classic symptom: “Customer.io says they entered the campaign, but they didn’t get the push.” Fix these and your push performance usually snaps into place.

• Identifying too late: If you only call identify after purchase, all your pre-purchase browse/cart events won’t be usable for cart recovery or product discovery pushes.
• Using different identifiers across sources: App sends events under customer_id, backend sends purchases under email. Now your LTV segmentation and reactivation logic are split across profiles.
• Not validating device association on the person profile: Teams look at event logs and assume push will work. If there’s no device on the profile, you’re done before you start.
• Assuming simulators represent reality: Push tokens and delivery behave differently. Always confirm on physical devices.
• Over-registering devices: If every app open registers a new device record instead of updating, you’ll create duplicates and inflate reach while hurting user experience.

Summary

If your SDK is registering devices, your identify strategy is consistent, and your events land on the same profile that owns the device, push becomes a dependable revenue lever for cart recovery and repeat purchase.

If any of those are shaky, fix the data chain first—otherwise you’ll spend weeks tuning journeys that can’t deliver.

Implement Test Push with Propel

If you’re validating push in Customer.io and want to avoid the usual identity and device-token traps, we can walk through your exact app flow (anonymous browse → login → checkout) and confirm the profiles, devices, and events line up the way your retention journeys need.

Bring one real scenario—like “Added to Cart but no purchase in 2 hours”—and book a strategy call to sanity-check the implementation before you scale spend and volume.