Test your push implementation (Mobile SDK)

Overview

If push is part of your retention mix, you want to know one thing fast: are devices registering correctly and are messages landing on the right person record in Customer.io? Most “push isn’t working” issues aren’t creative problems—they’re identity and device-token problems that only show up when you run a real end-to-end test.

If you want a second set of eyes on your tracking and stitching before you scale cart recovery or winback, book a strategy call and we’ll walk through a practical test plan and what to fix first.

How It Works

Customer.io push delivery depends on a clean chain: the app receives a valid push token from APNs/FCM, the SDK registers that token to a Customer.io person, and your Journeys target that person/device at send time. When any link in that chain breaks, you’ll see classic symptoms like “sent” but not delivered, pushes going to an old phone, or cart flows firing for anonymous profiles.

• SDK registers the device: On app install/launch, the SDK collects the push token and registers the device with Customer.io. If the token never makes it to Customer.io, nothing else matters.
• Identity stitching happens at Identify: The moment you call identify (and keep it consistent), the device gets associated with the correct person profile. If you delay identify until after checkout, your browse/cart pushes often attach to an anonymous profile instead of the buyer.
• Events drive eligibility: Your retention triggers (e.g., Product Viewed, Added to Cart, Checkout Started, Order Placed) need to be tracked from the app with the right IDs and timestamps so segments and Journey triggers match reality.
• Delivery is device-specific: Even if the person is eligible, Customer.io can only send to devices that are registered, opted-in, and not stale. Testing should validate the device record, not just the person profile.

Step-by-Step Setup

Don’t start by building a Journey. Start by proving that one real device can receive one real push tied to one real person, then expand to events and segmentation. This sequence keeps you from debugging three systems at once.

1. Install the Customer.io mobile SDK (iOS/Android/React Native/etc.) and confirm it initializes on app start.
   • Use a debug build and enable SDK logging if available.
   • Confirm you’re using the correct site ID/API key for the workspace/environment.
2. Configure push credentials (APNs for iOS, FCM for Android) and verify the app can obtain a push token.
   • On iOS: ensure push capability + APNs key/cert are correct for the bundle ID.
   • On Android: ensure the correct google-services.json and FCM sender/project match the app.
3. Register the device with Customer.io via the SDK push setup.
   • Trigger the OS permission prompt and accept it on a test device.
   • Confirm the device shows up on the person profile once identified (next step).
4. Call identify as early as you can once you have a stable user identifier.
   • Best practice: identify at login/account creation, not at purchase completion.
   • Use a durable ID (e.g., your internal customer ID). Avoid email as the only identifier if it can change.
5. Track a minimal event set from the app to validate your retention triggers.
   • At minimum: Product Viewed, Added to Cart, Checkout Started, Order Placed.
   • Include key properties you’ll segment on: sku, category, cart_value, currency, order_id.
6. Send a test push to that exact person/device and verify receipt.
   • Confirm delivery on-device (not just “sent” in the UI).
   • If it doesn’t arrive: check token freshness, permission status, and that the device is attached to the identified profile.
7. Run an end-to-end retention scenario (cart recovery is the fastest signal).
   • On the device: view product → add to cart → close app.
   • In Customer.io: confirm the event landed on the same identified profile and triggers your test Journey.

When Should You Use This Feature

Testing push implementation isn’t a “launch checklist” item—it’s something you revisit anytime you change login flows, attribution, app releases, or how you build segments. In practice, most retention programs lose revenue quietly when identity or device registration drifts over time.

• Cart abandonment push: Before you scale a “left items in cart” push, validate that Added to Cart events attach to the logged-in profile and that the device token updates after app reinstalls.
• Back-in-stock or replenishment: If you’re targeting “last purchased SKU = X,” you need confidence that the same person has the active device and that purchase events aren’t splitting across duplicate profiles.
• Reactivation: Winback push usually targets “no session in 30 days.” If sessions are tracked anonymously and only stitched later, you’ll under-target or spam the wrong cohort.
• Post-purchase cross-sell: Testing ensures Order Placed fires once (not multiple times) and that the push lands on the correct device, not an old tablet from 18 months ago.

Operational Considerations

Push tends to fail at the seams between app tracking, identity stitching, and Journey orchestration. The teams that win treat push testing like a data pipeline: define what “correct” looks like, then monitor drift.

• Segmentation depends on identity hygiene: If you have both anonymous and identified activity, decide when you merge and what ID is authoritative. Duplicate profiles will wreck cart recovery frequency caps and inflate audience counts.
• Event naming consistency: If mobile tracks add_to_cart and web tracks Added to Cart, your “omnichannel cart abandon” segment will always be wrong unless you normalize.
• Token churn is real: Tokens rotate. Users reinstall. Devices change. Make sure your SDK updates device tokens and that you’re not holding onto stale device records for targeting.
• Orchestration reality: If you run push + email cart recovery, confirm the same event powers both and that your suppression/exit logic uses the same purchase signal. Otherwise, you’ll keep pushing after conversion.

Implementation Checklist

Use this as your “green light” list before you trust push for revenue-driving flows like cart recovery and winback.

• SDK initializes successfully in the correct environment (dev/stage/prod).
• APNs/FCM configured and the app consistently receives a push token.
• Push permission prompt shown and accepted; opt-in status is captured.
• identify is called with a durable customer identifier (and not only after purchase).
• Device appears on the correct Customer.io person profile after identify.
• Core retention events tracked from app with required properties (SKU, cart value, order id).
• One test push is received on-device from a controlled test send.
• One end-to-end scenario (e.g., cart abandon) triggers the expected Journey entry and message.

Expert Implementation Tips

These are the small operator moves that prevent weeks of “it works on my phone” debugging and protect your segmentation as you scale.

• Identify earlier than you think: For D2C apps with “guest browse,” add a lightweight account capture (email/SMS) before checkout and identify immediately. That’s the difference between saving a cart and losing it to anonymous activity.
• Track a “Session Started” event: Reactivation and engagement segments are cleaner when you have an explicit session signal rather than relying on page views or sporadic events.
• Send a silent/internal QA push: Maintain a hidden QA campaign that sends to an internal segment. When a release ships, you validate delivery in 60 seconds.
• Standardize event payloads across platforms: If web and app both contribute to revenue, align properties like sku, product_id, and price so “viewed but not purchased” segments behave predictably.

Common Mistakes to Avoid

Most push issues aren’t “push issues”—they’re identity, token, or event-quality issues that show up downstream as bad retention performance.

• Calling identify with an unstable ID (like a device ID that changes) and then wondering why users duplicate.
• Delaying identify until after checkout, which strands browse/cart events on anonymous profiles and breaks cart recovery targeting.
• Assuming “sent” means “delivered”. Always validate on-device receipt and check permissions/OS-level delivery constraints.
• Not handling token refresh, leading to pushes going nowhere after reinstall or OS updates.
• Event double-firing (especially Order Placed) which causes premature exits, wrong holdouts, and messy attribution.

Summary

If you can’t reliably map a real device to a real person and prove one end-to-end scenario, push will underperform no matter how good your Journey logic is. Validate device registration, early identify, and clean event tracking first—then scale cart recovery, replenishment, and winback with confidence.

Implement Test Push with Propel

When teams tighten up push, the biggest lift usually comes from fixing identity stitching and event consistency—not rewriting campaigns. If you want a practical QA plan (device registration → identify → event → segment → send) tailored to your app and retention flows inside Customer.io, book a strategy call and we’ll pressure-test your implementation before you scale spend or volume.