Handling Multiple Push Providers (SDK-first) in Customer.io

Overview

If you’re running Customer.io and you’ve ended up with more than one push provider (Firebase + another vendor, legacy provider during a migration, separate stacks for iOS vs Android), the real work isn’t “adding a provider”—it’s keeping device identity clean so your retention automations don’t misfire. If you want a second set of eyes on the tracking and orchestration before you scale sends, you can book a strategy call and we’ll pressure-test the setup the way we do for most D2C retention programs.

In practice, multiple push providers usually shows up during a migration, after an acquisition of a second app, or when a team adds web push on top of mobile push. The risk is simple: duplicate tokens, mismatched users, and “ghost devices” that inflate sends while hurting conversion rate reporting.

How It Works

Customer.io doesn’t magically reconcile multiple push ecosystems for you—your SDK implementation and identity strategy does. The goal is to ensure every device token is attached to the right person profile at the right time, and that you’re consistently emitting events that Customer.io can use to trigger retention flows (cart recovery, replenishment, winback) without cross-provider duplication.

• Device registration is the source of truth. Each push provider issues a device token (or subscription token). Your app needs to pass that token into Customer.io as a device on the correct person profile.
• Identity stitching happens at identify-time. Anonymous browsing/usage often happens before login. Once the user authenticates (or provides email/phone), you need to call identify so Customer.io can merge the device onto the known customer record.
• Event tracking drives retention automation. Push only performs in retention when your SDK sends the right events with the right properties (e.g., Added to Cart, Checkout Started, Order Placed, Viewed Product). If you’re splitting providers, the events still need to land on the same person profile as the device token.
• Provider selection becomes an orchestration problem. If you’re truly sending through multiple providers at once (not just migrating), you need deterministic rules so a person only receives one push per message (or per campaign), not one per provider.

Step-by-Step Setup

Before you touch campaigns, lock down the SDK behavior. Most issues with multiple push providers aren’t “Customer.io problems”—they’re timing problems (identify called too late), token hygiene problems (old tokens never removed), or profile merge problems (same customer ends up as multiple people).

1. Map your provider reality (migration vs parallel sending).
   Decide whether you’re (a) migrating from Provider A to Provider B, or (b) intentionally running both. Your rules for token registration and message suppression depend on this.
2. Install and initialize the Customer.io SDK in each app surface.
   Do this for iOS, Android, and any web surface where you plan to send push. Keep environments separated (dev/staging/prod) so test tokens don’t leak into production audiences.
3. Implement a strict identify moment.
   Call Customer.io identify immediately after authentication (or after email capture if you do early capture). Pass a stable customer identifier (your internal user ID) and key traits you’ll segment on (email, phone, acquisition source, first_order_date, etc.).
4. Register device tokens from each push provider to the same person.
   When your app receives/refreshes a token from Provider A or Provider B, add/update the device in Customer.io for the currently identified person. If the user is anonymous, store the token locally and attach it right after identify.
5. Handle token rotation and logout cleanly.
   Tokens rotate. Users log out. If you don’t remove or reassign devices, you’ll send cart recovery pushes to the wrong person (common on shared devices). On logout, either disassociate the device from the person or re-identify to an anonymous profile depending on your policy.
6. Standardize event names and properties across platforms.
   Make sure iOS and Android emit the same event schema. Retention flows break when Android sends add_to_cart and iOS sends Added To Cart. Pick one naming convention and enforce it.
7. QA with real-world edge cases.
   Test: install → browse anonymous → add to cart → login → abandon → reinstall → token refresh. This is where most multi-provider setups fall apart.

When Should You Use This Feature

Multiple push providers is usually a means to an end: you’re protecting deliverability during a migration, adding a new channel surface (web push), or trying to improve reliability. The retention win comes when you keep messaging consistent while the infrastructure changes underneath.

• Push provider migration without losing revenue. Keep cart recovery and browse abandonment running while you transition tokens over time.
• Running mobile push + web push with different stacks. A customer might browse on desktop and purchase on mobile—your identity stitching needs to unify that so you don’t double-notify.
• International expansion or deliverability constraints. Some teams keep a second provider as a fallback in regions where delivery is spotty.
• D2C scenario: cart abandonment during a migration. You’re moving from a legacy push vendor to Firebase. A shopper adds a $120 bundle to cart on iOS, logs in, then closes the app. If you haven’t attached the new token to the identified profile (or you’ve duplicated devices), you’ll either miss the push entirely or send two pushes—both outcomes hurt conversion and trust.

Operational Considerations

Once you have multiple providers, the hard part becomes segmentation and orchestration: deciding who is eligible for which provider, preventing duplicates, and keeping reporting believable.

• Segmentation: define “pushable” at the person level, not the device level. Build segments like “Has at least one active push device” and “Opted in to marketing push” and keep them consistent across iOS/Android/web.
• Data flow: don’t rely on last-known traits for identity. Use a stable user ID for identify. Email changes; phone changes; user IDs shouldn’t. This reduces duplicate profiles when the same customer signs in with Apple ID one day and email the next.
• Orchestration: pick a single ‘winner’ when both providers are present. In most retention programs, we’ve seen teams accidentally send the same message through two pipelines because “both tokens exist.” Decide rules like: prefer Provider B if token exists; else Provider A. Or prefer the most recently updated token.
• Frequency control: duplicates look like over-messaging. If you cap pushes at 2/week but send via two providers, you effectively cap at 4/week unless you centralize limits in Customer.io logic.
• Measurement: attribute outcomes to the campaign, not the provider. During migration, keep your campaign IDs consistent and track provider as a property so you can compare deliverability and conversion without splitting reporting across two systems.

Implementation Checklist

If you want this to behave like a clean retention channel (not a noisy infrastructure experiment), treat the checklist below as your minimum bar before scaling sends.

• Customer.io SDK installed and initialized in all relevant clients (iOS/Android/web)
• identify called immediately after auth with a stable internal user ID
• Device tokens from each provider captured and attached to the identified person
• Token refresh handled (update device on refresh)
• Logout handled (device disassociated or moved to anonymous per policy)
• Unified event schema across platforms (names + required properties)
• Segment definitions for push eligibility documented and enforced
• Deduplication rule defined when both providers exist for a person
• QA plan covers anonymous → identify → token refresh → reinstall flows

Expert Implementation Tips

Most teams get “a push” working quickly. The teams that print revenue from push are the ones who make identity and token hygiene boringly reliable.

• Attach tokens after identify whenever possible. If you attach tokens to anonymous profiles and forget to merge, you’ll strand devices and lose reach on your highest-intent flows (cart, checkout).
• Track a push_provider device attribute or event property. This makes it easy to segment, troubleshoot delivery issues, and run controlled migration rollouts (10% → 50% → 100%).
• Use “most recent token wins” logic. In practice, this tends to break when a user reinstalls and you keep the old token active. Prefer the latest updated token and expire stale ones.
• Instrument a ‘delivered push’ callback if you have it. If your provider supports delivery receipts, pass that back as an event so you can separate “sent” from “actually delivered” when diagnosing drops in cart recovery performance.

Common Mistakes to Avoid

These are the issues that usually show up two weeks after launch—right when the team starts blaming creative instead of plumbing.

• Calling identify too late. If you identify after you register tokens or after key events fire, you’ll split activity across profiles and your journeys won’t trigger correctly.
• Letting one customer become multiple people. This happens when you identify sometimes by email, sometimes by user ID. Pick one canonical identifier and stick to it.
• Double-sending because both providers are eligible. If both tokens exist, you need a deterministic selection rule—or a suppression step—inside your orchestration.
• Not handling logout/shared devices. D2C apps see shared tablets and family phones. If you don’t disassociate devices, you’ll send reorder nudges to the wrong person.
• Inconsistent event schemas across platforms. Your cart recovery flow should not depend on whether the user is on iOS vs Android.

Summary

Multiple push providers is manageable as long as you treat device identity as a first-class retention dependency. Get identify timing, token updates, and deduplication rules right, and your cart recovery + reactivation programs stay stable through migrations. If you can’t confidently answer “which provider will this customer receive from and why,” you’re not ready to scale sends.

Implement Multiple Push Providers with Propel

If you’re juggling multiple providers, the biggest operational lift is usually keeping identity stitching, segmentation, and suppression rules consistent while you iterate. Working alongside Customer.io, we’ll typically help teams standardize the SDK event schema, set a clean provider selection policy, and QA the edge cases that quietly kill retention performance. If that’s the stage you’re in, book a strategy call and we’ll map the safest rollout path without breaking cart recovery or repeat purchase flows.