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

Overview

If you’re running Customer.io push alongside another provider (or migrating providers), the real job is keeping device identity clean so your cart recovery and repeat purchase flows don’t silently degrade. If you want a second set of eyes on the tracking and orchestration before you flip traffic, book a strategy call—this is one of those areas where “mostly working” still leaks a lot of revenue.

In most retention programs, multiple push providers show up because the app team already uses Firebase/APNs directly, a third-party SDK owns some notifications (support, shipping, loyalty), or you’re mid-migration and can’t cut over in one release.

How It Works

At a mechanics level, Customer.io can only send push to devices it knows about, and it only knows about devices when your app SDK registers them and keeps the token mapped to the right person. With multiple providers, the main failure mode isn’t “push doesn’t send”—it’s that tokens drift to the wrong profile, or you end up with duplicate device records that fragment your audience and kill frequency control.

• Device registration is the source of truth. Your app receives a push token (APNs on iOS, FCM on Android) and you must pass that token into the Customer.io SDK so it can register the device.
• Identity stitching happens at identify time. Anonymous app sessions collect events, but once a user logs in (or you otherwise know who they are), you need an identify call so Customer.io can attach the device token + events to the correct person profile.
• Multiple providers means multiple “owners” of the same token. APNs/FCM tokens are shared primitives; more than one SDK can read them. The trick is ensuring Customer.io always receives token updates and that your login/logout flows don’t leave tokens attached to the wrong customer.
• Event tracking is what makes push profitable. Provider setup is table stakes; the retention lift comes from app-side events (viewed product, added to cart, started checkout, purchased) that power segments and trigger journeys.

Step-by-Step Setup

Plan this like a migration even if you’re “just adding” Customer.io. The operational goal is: every active device has a current token in Customer.io, every token is attached to the right person, and your key commerce events fire consistently across app states.

1. Inventory your push providers and decide who sends what.
   Write down which provider owns which notification types (e.g., Customer.io = cart recovery + winback; Provider B = transactional shipping updates). This prevents duplicate sends and makes debugging sane.
2. Install and initialize the Customer.io mobile SDK.
   Do this in the earliest safe app lifecycle point so token registration and deep link handling work reliably.
3. Implement device token capture and pass it to Customer.io.
   On iOS, capture APNs device token updates; on Android, capture FCM token refreshes. Tokens rotate—treat refresh handling as required, not optional.
4. Call identify immediately after login (and on app relaunch when already authenticated).
   Use a stable customer identifier (your internal customer ID is ideal). This is where most multi-provider setups break: users log in, but the app never re-identifies after a token refresh, so the new token stays anonymous or attached to an old profile.
5. Handle logout explicitly.
   When a user logs out, reset the Customer.io identity in the SDK so the next user on the same device doesn’t inherit the previous person’s token association.
6. Track the retention-critical commerce events from the app.
   At minimum: product_viewed, added_to_cart, checkout_started, order_completed. Include identifiers like product SKU, cart value, currency, and category so segmentation isn’t guesswork.
7. QA token + identity stitching with real devices, not just logs.
   Use two test accounts on one device (login/logout), and one account across two devices. Confirm the right profile has the right device(s) and that pushes arrive once.

When Should You Use This Feature

Multiple push providers is rarely a “nice to have”—it’s usually a transitional state or a constraint from other teams. The key is deciding when it’s worth the complexity versus forcing consolidation.

• Migrating push without pausing revenue flows. Keep your existing provider live for transactional/ops notifications while Customer.io takes over retention sequences (cart recovery, replenishment nudges, browse abandon).
• Different teams own different notification classes. Support tooling or logistics platforms often ship with their own push. Customer.io can still run revenue-driving push as long as identity and token registration are clean.
• Channel resilience for high-value moments. For a D2C drop, you might keep a lightweight “system push” provider for critical alerts while Customer.io handles segmented launch messaging and post-drop winback.

Real D2C scenario: You run cart abandonment push 30 minutes after checkout_started. If the user logged in after adding items, but your app only calls identify on the login screen (not on app relaunch), their token might still be tied to an anonymous profile. Result: they never get the push, and your recovery rate looks “mysteriously” lower on iOS than Android.

Operational Considerations

Once you’re past basic SDK wiring, the operational risk is segmentation and orchestration drift—especially when two systems can both send push and both can record engagement differently.

• Segmentation depends on device eligibility, not just user intent. Build a “push eligible” segment that requires a recent device token and a known customer ID. In practice, this catches broken identify flows faster than any dashboard.
• Data flow timing matters for recovery windows. If added_to_cart fires client-side but arrives late (offline, background throttling), your 30-minute cart push can trigger at the wrong time. Consider sending “checkout_started” from server when possible, but keep app events for product discovery and browse behavior.
• Frequency control gets messy with two senders. If Provider B sends ops pushes and Customer.io sends marketing pushes, your user experiences it as “too many pushes.” Align on a shared suppression rule (e.g., don’t send marketing push within X minutes of any push) and enforce it in Customer.io segments where you can.
• Attribution and click tracking won’t match across providers. Decide what you’ll treat as the source of truth for “push opened” and downstream revenue, and make sure deep links include consistent parameters so your analytics doesn’t split campaigns by provider.

Implementation Checklist

This is the minimum bar before you scale sends. If any of these are “we think so,” you’ll pay for it later in under-delivery and noisy experiments.

• Customer.io SDK initializes reliably on app launch
• APNs/FCM token updates are forwarded to Customer.io (including refresh/rotation)
• identify runs after login and on subsequent launches for authenticated users
• Logout resets identity so tokens don’t stick to the wrong profile
• Key commerce events are tracked with consistent naming and required properties
• QA confirms: one user → multiple devices works; one device → multiple users doesn’t leak tokens
• A “push eligible” segment exists and matches expectations across iOS/Android

Expert Implementation Tips

This is where experienced retention teams squeeze reliability out of a messy multi-SDK environment.

• Re-identify defensively. Don’t assume identify only happens once. Re-run identify when the app becomes active and the user is authenticated—this fixes a huge share of “token registered but not attached” issues.
• Track a diagnostic event on token registration. Emit something like push_token_registered with provider, platform, and app version. Then segment on “registered token but no cart recovery sends” to spot gaps early.
• Standardize deep links across providers. If Provider B uses one deep link format and Customer.io uses another, you’ll fracture downstream conversion measurement and personalization logic.
• Gate marketing push on recent app activity for iOS. iOS delivery can be sensitive to permission and engagement. In cart recovery, we’ve seen better performance when you suppress users who haven’t opened the app in 30–60 days and route them to email/SMS instead.

Common Mistakes to Avoid

These mistakes don’t always show up as errors—they show up as “push underperforms,” which is harder to debug and easier to misattribute to creative.

• Only registering the token once. Tokens rotate. If you don’t handle refresh, your reachable audience decays over time.
• Identify only on the login screen. Users stay logged in for weeks. If you don’t identify on relaunch, you’ll miss token updates and background event stitching.
• Not resetting identity on logout. Shared devices (partners, family iPads) are common in D2C. This can cause cross-account push sends—worst-case, it’s a privacy issue.
• Letting two providers send the same “class” of message. Duplicate cart pushes are a fast way to train users to disable notifications.
• Building segments on “has push permission” but not “has a current token.” Permission alone doesn’t guarantee deliverability.

Summary

If you’re running multiple push providers, treat identity + token hygiene as the product. Get identify, token refresh, and logout behavior right, then layer in commerce events that actually drive cart recovery and repeat purchase.

If you can’t confidently answer “which profile owns this device token right now,” fix that before you scale journeys.

Implement Multiple Push Providers with Propel

When teams juggle multiple providers, the work usually isn’t the SDK install—it’s the operational stitching: consistent identity, clean eligibility segments, and orchestration rules that prevent double-sends. If you’re already using Customer.io and want a practical implementation plan (including QA cases and rollout sequencing), book a strategy call.

In practice, this tends to break during migrations and app releases—having a tight checklist and a monitoring segment saves you from finding out via a sudden dip in cart recovery revenue.