Multiple Push Providers (Mobile SDK) in Customer.io: How to Track, Stitch Identity, and Keep Push Reliable

Overview

If you’re running push at any real scale, you’ll eventually end up with more than one provider in the mix—Firebase/APNs for core delivery, maybe another vendor for in-app/push orchestration, maybe a legacy integration you haven’t fully retired. The good news is Customer.io can handle multiple push providers, but in practice the retention impact comes down to whether your SDK tracking stays clean and your identity stitching doesn’t break. If you want a second set of eyes on the data flow before you ship, book a strategy call.

For D2C, this matters most in cart recovery and post-purchase repeat purchase—push is often the fastest channel, but it’s also the easiest to “silently fail” when tokens, profiles, and providers aren’t aligned.

How It Works

Multiple push providers usually means your app can receive (and sometimes register) push tokens through more than one SDK or service. Customer.io’s role is to map device tokens to the right person profile so Journeys can target the right device at the right time—even if the user logs in later, reinstalls, or switches devices.

• Device registration is the foundation. Your app collects a push token (APNs on iOS, FCM on Android) and passes it into the Customer.io SDK so Customer.io can associate that device with a profile.
• Identity stitching is what keeps retention working. If a user browses anonymously, then logs in, you need the SDK to identify the user and merge the device/token into the authenticated profile. If you don’t, your “cart abandon” push goes to an anonymous profile that will never convert.
• Provider selection is mostly an app concern. Customer.io can send push, but if you’re also using another provider for certain message types (or migrating), you need clear rules: which provider owns which sends, and which SDK owns token registration.
• Events drive orchestration. The SDK should track the events that actually power retention logic—Product Viewed, Added to Cart, Checkout Started, Order Completed, Push Permission Granted, etc.—so Customer.io can segment and trigger the right journeys.

Step-by-Step Setup

The goal here isn’t “make push work.” The goal is: tokens register once, profiles stay deduped, and every retention journey can trust the data. Set this up like you’re going to debug it at 2am after a revenue drop—because you will.

1. Pick the token source of truth per platform.
   Decide which SDK/service is responsible for obtaining the push token (APNs/FCM) and when it’s handed to Customer.io. If two SDKs both try to manage tokens, you’ll see churny device records and inconsistent deliverability.
2. Install and initialize the Customer.io mobile SDK.
   Initialize as early as practical in app launch so device registration happens consistently. Late init is a classic reason “some users never get push.”
3. Implement identify() immediately on login/signup.
   When the user authenticates, call the Customer.io SDK identify method with your stable customer identifier (not email if you can avoid it; use your internal customer ID). This is where anonymous browsing becomes targetable retention.
4. Handle anonymous-to-known transitions deliberately.
   If your app supports guest browsing, track browsing/cart events anonymously, then on login ensure the SDK merges/associates the existing device token with the identified profile. If you skip this, your cart recovery push will miss the exact users you care about most.
5. Register the push token with Customer.io after permission + token refresh.
   Tokens rotate. Users reinstall. iOS permission prompts get deferred. Make sure your app updates Customer.io when the token changes—not just on first install.
6. Track retention-grade events from the SDK.
   At minimum: Product Viewed, Added to Cart, Checkout Started, Order Completed, and a push opt-in signal (Push Enabled or an attribute like push_opt_in=true). These events are what you’ll filter and throttle on in real programs.
7. Validate in Customer.io: device present, profile resolved, events arriving.
   Before you build journeys, confirm a test user shows the right device(s), the right identifier, and the right event stream. Most “push is broken” tickets are actually “identity is broken.”

When Should You Use This Feature

Multiple push providers isn’t a “nice-to-have.” It shows up when you’re migrating vendors, running regional stacks, or you’ve got a legacy provider you can’t rip out yet. The retention win is keeping push revenue stable while you change infrastructure.

• Provider migration without revenue dips. Keep your existing provider live while you ramp Customer.io push, then cut over once deliverability and conversion look stable.
• Cart recovery push that actually reaches logged-in users. If users browse anonymously and log in at checkout, you need identity stitching to avoid losing the highest-intent segment.
• Reactivation after uninstall/reinstall. Users reinstall and get a new token. If your app doesn’t re-register correctly, your winback audience shrinks quietly over time.
• Multi-brand or multi-app setups. If you operate multiple storefront apps, you may have different push configs but want consistent Customer.io orchestration and segmentation rules.

Operational Considerations

Once you’re beyond a single provider, the main risk is data drift: tokens registered to the wrong profile, duplicate people, and journeys firing based on partial event streams. Treat this like a data pipeline, not a marketing toggle.

• Segmentation depends on clean device state. Build segments that explicitly require a deliverable device (e.g., “has active mobile device + push opt-in”). Otherwise you’ll inflate audience size and understate push performance.
• Define ownership of token lifecycle. In practice, this tends to break when “SDK A registers token” but “SDK B handles refresh,” and Customer.io only hears about one of those. Pick one path and standardize it.
• Event parity across providers. If one provider is sending pushes that drive app opens, make sure app-open/deeplink events still flow into Customer.io so you can measure and suppress follow-ups correctly.
• Orchestration realities: suppressions and frequency. If two systems can send push, you need a shared suppression strategy. Otherwise customers get double-tapped (cart push from provider A, promo push from provider B) and your opt-out rate climbs.
• Identity strategy must be consistent across channels. Use the same stable identifier for email/SMS/push in Customer.io so your “purchased” event suppresses all channels—not just one.

Implementation Checklist

If you want this to hold up under real traffic (and not just QA devices), walk through this checklist before you ship and again after you migrate any provider.

• One clear system owns push token capture and refresh per platform
• Customer.io SDK initialized early enough to consistently register devices
• identify() called on login/signup with a stable customer ID
• Anonymous browsing/cart events are stitched to the identified profile after login
• Token refresh and reinstall flows re-register the device with Customer.io
• Core retention events tracked from the app (view → cart → checkout → purchase)
• Segments require deliverable device + opt-in (avoid “ghost audiences”)
• Cross-provider suppression/frequency rules documented and enforced

Expert Implementation Tips

In most retention programs, the difference between “push drives revenue” and “push is noisy” comes down to identity timing and token hygiene—not copy or creative.

• Identify earlier than you think. If you have any persistent account concept (even “shopper ID”), identify as soon as it’s known. Waiting until checkout is how you lose cart recovery targeting.
• Track a dedicated push status attribute. Don’t infer opt-in from “has token.” Track an explicit push_permission state so you can segment accurately and avoid sending to users who denied permission.
• Use event-driven suppression to prevent double sends. Example: if a user receives a cart push from provider A and then completes purchase, ensure Order Completed is tracked and used to exit/suppress any Customer.io cart journey steps.
• Instrument deep link outcomes. Track Push Opened and ideally the destination (PDP, cart, collection). It’s the fastest way to spot provider misconfiguration and measure real lift.

Common Mistakes to Avoid

These are the issues that show up after launch—usually when you’re trying to explain why cart recovery revenue dipped even though sends stayed flat.

• Registering tokens before identity and never re-associating. The device ends up stuck on an anonymous profile, so your logged-in journeys miss.
• Letting two SDKs fight over token updates. You’ll see intermittent delivery and “missing device” problems that are painful to reproduce.
• Using email as the primary identifier. Email changes, gets aliased, or differs across checkout vs account. Use a stable internal ID and store email as an attribute.
• Building segments on events without device constraints. You target “Added to Cart in last 4 hours” without requiring push eligibility, then wonder why conversion rate looks low.
• No plan for uninstall/reinstall. Tokens change. If you don’t re-register, your reachable audience decays month over month.

Summary

If you’re running multiple push providers, treat Customer.io SDK setup like identity infrastructure: register tokens reliably, identify users early, and stitch anonymous behavior into known profiles. Once that’s stable, cart recovery, repeat purchase, and winback journeys become straightforward—and measurable.

Implement Multiple Push Providers with Propel

When teams juggle multiple push providers, the work is rarely “turn on another integration”—it’s aligning SDK identity, token ownership, and journey suppression so customers don’t fall through the cracks. If you’re building or migrating this inside Customer.io and want an operator’s take on the cleanest path (especially for cart recovery and post-purchase flows), book a strategy call.

That usually surfaces the same handful of fixes: earlier identify calls, stricter device-eligible segmentation, and one clear token lifecycle owner per platform—so push performance doesn’t wobble every time the app ships an update.