Handling Multiple Push Providers (SDK Execution Guide for Retention Teams)

Overview

If you’re running Customer.io alongside another push provider (or migrating between providers), the hard part isn’t “sending push”—it’s keeping device identity clean so your retention automations don’t spray duplicates or miss the right device. If you want a second set of eyes on the stitching and orchestration, book a strategy call and we’ll pressure-test your tracking plan before you scale sends.

In most retention programs, multiple push providers show up during migrations (Braze/Firebase → Customer.io), when product teams ship a new messaging layer, or when you’re splitting transactional vs marketing push. The goal is simple: one user, one (or correctly managed) device record, and predictable routing so cart recovery and winback flows don’t break.

How It Works

When you use multiple push providers, you’re really managing three things: (1) which SDK registers the device token, (2) which system “owns” the token for sending, and (3) how you tie that device to the right person in Customer.io at the right time.

• Device registration is token-based. On iOS/Android the OS issues a push token (APNs/FCM). Each SDK typically tries to register that token with its own backend. If two SDKs both register and you don’t control routing, you’ll often see duplicate sends or mismatched attribution.
• Identity stitching is the retention-critical part. Customer.io needs a stable person identifier (id in their data model) and a device mapped to that person. If you register a token before you identify the user (login/checkout), you risk anonymous devices that never get stitched—or worse, stitched to the wrong profile later.
• Event tracking drives orchestration. Your push provider choice doesn’t matter if the events feeding Customer.io are late, inconsistent, or missing key properties (cart value, SKU, inventory status). In practice, “multiple providers” becomes a data quality problem long before it’s a channel problem.

Real D2C scenario: You run cart abandonment push through Provider A today. You want to migrate to Customer.io for unified orchestration (push + email + SMS). During the migration window, both SDKs live in the app. If you don’t gate which provider is allowed to register/send for a given user cohort, some customers will get two “You left something behind” pushes—one from each system—while others get none because the token is only registered in the provider you aren’t sending from.

Step-by-Step Setup

The cleanest multi-provider setup starts on the app side. You’re aiming for deterministic identity, deterministic device registration, and explicit routing rules during any overlap period.

1. Decide the “system of record” for push tokens.
   Pick one provider to own marketing push tokens at any given time (even if another provider still exists for transactional). Write this down—this becomes your migration and QA checklist.
2. Install the Customer.io mobile SDK alongside your existing provider.
   Keep the integration minimal at first: initialize the SDK, confirm it can receive a token, and confirm you can send a basic test push to a test device.
3. Implement a strict identify moment (and don’t wing it).
   Call Customer.io’s identify as soon as you have a stable user ID (login, account creation, or post-checkout account link). If you have guest checkout, decide whether you’ll create a durable ID at checkout or wait until account creation—both can work, but you need one consistent rule.
4. Register devices only after identity is known (whenever possible).
   If your app requests push permission on first launch, you’ll often get a token before you know who the user is. In that case, store the token locally and only “attach” it to Customer.io after identify. This is where multi-provider setups tend to break: token gets registered to Provider A anonymously, then later attached to Customer.io under a different user.
5. Track the retention events Customer.io will actually orchestrate from.
   At minimum for D2C retention: Product Viewed, Added to Cart, Checkout Started, Order Completed. Include properties you’ll segment on (price, category, cart_value, currency, SKU, inventory flags, discount eligibility).
6. Control routing during migration with a feature flag.
   Use a remote config/feature flag to decide which provider sends marketing push for a user/device. Roll out Customer.io push to internal users → 5% cohort → 25% → 100%, while Provider A is either disabled for those cohorts or restricted to transactional only.
7. Validate token churn and logout behavior.
   On logout, make sure you’re not leaving the device token attached to the prior user in Customer.io. If shared devices are a thing for your audience (family iPads, etc.), this matters more than teams expect.

When Should You Use This Feature

Multiple push providers isn’t a “nice to have” setup—it’s usually a transitional state or a deliberate split between transactional and marketing. The retention win comes from avoiding duplicate sends and keeping orchestration stable while you change infrastructure.

• Push provider migration without pausing revenue flows. Keep cart recovery and post-purchase replenishment pushes running while you move orchestration into Customer.io.
• Splitting transactional vs marketing push. For example: keep order/shipping pushes in your existing provider (owned by engineering), but run browse/cart/reactivation in Customer.io where the retention team iterates weekly.
• Geo or platform-specific deliverability differences. Some brands keep a backup provider for specific regions or OEM Android quirks. If you do this, you need deterministic routing per device.
• App + web push coexistence. If you already use a different tool for web push but want mobile push in Customer.io, you still need consistent identity rules so the same person doesn’t get double-tapped across channels.

Operational Considerations

This is where retention teams feel the pain: segmentation gets messy when identity isn’t clean, and orchestration gets unpredictable when tokens drift between systems.

• Segmentation: treat “has a reachable device” as a first-class attribute. Build segments that explicitly require a valid mobile device registered in Customer.io before you rely on push as the primary channel. Otherwise, your cart recovery journey will silently under-deliver and you’ll misread performance.
• Data flow: watch event timing vs token timing. If Added to Cart fires before the device is attached to the identified profile, your push step may evaluate before the user is push-addressable. In practice, add a short delay or a “wait until device exists” condition for push-first flows.
• Orchestration: define channel fallback rules. For cart abandonment, decide what happens when push isn’t available: fall back to email/SMS, or hold until push becomes available. Don’t let this be implicit.
• Attribution: expect messy overlap windows. During migration, you’ll see double influence (two pushes, one conversion). Use holdouts and cohort flags to keep measurement honest.

Implementation Checklist

If you want this to work without weeks of whack-a-mole QA, treat it like a mini data migration project: identity, devices, events, and routing all need explicit acceptance criteria.

• Customer.io SDK initialized and receiving APNs/FCM tokens in dev and prod
• identify implemented at a single, consistent moment (login/checkout/account creation)
• Device token attachment happens after identify (or token is stored locally until identity exists)
• Logout behavior defined (detach token / reset user) and tested on shared devices
• Core retention events implemented with required properties (SKU, category, cart_value, currency)
• Feature flag/routing logic determines which provider sends marketing push per cohort
• Customer.io segments created for “push reachable” vs “push unreachable”
• Cart recovery and winback journeys include push fallback logic (email/SMS) where needed
• Migration measurement plan: cohorts, holdouts, and overlap window expectations

Expert Implementation Tips

The difference between “it’s integrated” and “it prints money” is usually token hygiene and event discipline. These are the operator moves that keep retention stable.

• Delay push steps until the device is definitely attached. For app-first flows (cart abandonment), a 5–15 minute delay often improves deliverability because identity/device stitching catches up—especially if login happens after browsing.
• Use a migration cohort attribute everywhere. Stamp users with something like push_provider = cio vs push_provider = legacy. Use it in segments, journey entry, and reporting. This prevents “mystery duplicates.”
• Normalize event names and properties before you migrate logic. Don’t rebuild cart recovery in Customer.io until the event payload matches what you’ll segment on. Most teams rush the journey and then spend weeks patching edge cases.
• Handle guest checkout explicitly. If guests convert without creating an account, choose an ID strategy (order-based ID, email-based ID with verification rules, etc.) so post-purchase push doesn’t disappear into an anonymous profile.

Common Mistakes to Avoid

Most multi-provider push issues aren’t “bugs”—they’re ambiguous ownership and inconsistent identity. Fix the rules and the problems usually vanish.

• Letting both SDKs register and send marketing push to the same cohort. This is the fastest path to duplicate cart recovery pushes and opt-out spikes.
• Calling identify too late. If you only identify on a deep screen (like account page), most of your high-intent sessions (browse → cart → bounce) never get stitched correctly.
• Not resetting identity on logout. Shared devices will get the wrong person’s winback and post-purchase flows. It’s a brand trust issue, not just a metric issue.
• Assuming event delivery is real-time. Mobile networks drop events. Add retries, queueing, and sanity checks—especially for Order Completed and Checkout Started.
• Building journeys that require push without a fallback. If 30–60% of users haven’t opted into push, your “push-first” design quietly underperforms.

Summary

Running multiple push providers is manageable when you treat identity and device registration as the core problem—not message creation. Nail identify, control token ownership with routing, and build segments that reflect real push reachability.

If you’re migrating, roll it out by cohort and measure like you expect overlap noise—because you will get it.

Implement Multiple Push Providers with Propel

If you’re orchestrating push across more than one provider, the work is mostly in the seams: identity stitching, token ownership, and making sure Customer.io journeys only target devices that are actually reachable. In practice, this tends to break during migrations and app releases—right when you’re trying to scale cart recovery and winback.

If you want an operator to sanity-check your SDK tracking plan and routing logic (before you discover duplicates in production), book a strategy call.