Handling Multiple Push Providers with Customer.io SDKs

Overview

If you’re running Customer.io push and you have more than one push provider in the mix (common during migrations, multi-brand apps, or “we inherited this SDK” situations), the real job is keeping device identity clean so sends don’t fragment or double-tap customers. If you want a second set of eyes on how to structure this without breaking cart recovery or winback flows, book a strategy call and we’ll pressure-test your tracking plan.

In most retention programs, multiple providers isn’t the hard part—stitching tokens to the right person at the right time is. If you get the identity layer wrong, your “abandoned cart push” turns into “random push to the wrong device,” and your performance readouts become noise.

How It Works

When you have multiple push providers, you’re effectively dealing with multiple token sources and sometimes multiple “device identity” concepts. Customer.io needs a consistent way to associate each device token to a single person profile, then choose the right delivery path when you send push.

• Device tokens are the source of truth for delivery. On iOS this is the APNs token; on Android it’s typically an FCM registration token. Third-party providers may wrap these, but the underlying token still needs to land in the right profile.
• Identity stitching is what keeps retention flows stable. Your SDK identify call connects an app session (and its device token) to a known customer (email/phone/customer_id). If you delay identify until after checkout, you’ll miss the highest-intent window (browse → cart → abandon).
• Multiple providers usually means one of these patterns:
  • Migration: old provider still installed for legacy flows while Customer.io is being rolled out.
  • Multi-app / multi-brand: shared Customer.io workspace, different push stacks per app.
  • Feature split: one provider for transactional pushes (order updates), another for marketing pushes (cart, replenishment).
• Routing is operational, not magical. You’ll end up using segmentation rules (device platform, app version, push-enabled flags, provider flags) so campaigns target only the devices that can actually receive the message via the intended provider.

Step-by-Step Setup

The goal here is simple: every time a token changes, and every time a user becomes known, Customer.io should receive the updated device state quickly. That’s what prevents missed sends and duplicate pushes when multiple providers coexist.

1. Install Customer.io’s mobile SDK alongside your existing push provider.
   Don’t rip the old provider out first. Run them in parallel until you can prove token capture, delivery, and attribution are stable.
2. Call identify as soon as you have a stable user identifier.
   Do this at login and after account creation. If you support guest checkout or anonymous browsing, plan for an anonymous-to-known transition (see step 5).
3. Register push permissions and capture tokens on app start and token refresh.
   Tokens rotate. Treat “token refresh” as a first-class event in your app lifecycle and ensure the Customer.io SDK receives the latest token state.
4. Track explicit push opt-in state as an attribute.
   Store something like push_opt_in=true/false and push_permission_status (authorized/denied/provisional). This becomes your guardrail for not blasting users who can’t receive pushes anyway.
5. Handle anonymous activity, then merge on identify.
   This is where cart recovery lives. Track events like Product Viewed, Added to Cart, Checkout Started even when the user is anonymous. When they log in or provide email/phone, merge that activity into the known profile so the cart flow can fire correctly.
6. Add provider-level flags so you can segment cleanly.
   Set an attribute like push_provider=customerio vs push_provider=legacy (or push_provider=[both] during migration). This prevents duplicate sends when both SDKs are active.
7. QA with real devices, not just logs.
   Test iOS + Android, fresh install + upgrade, logged out → logged in, and token refresh scenarios. Most push bugs only show up in those transitions.

When Should You Use This Feature

Multiple push providers is rarely a “nice to have.” It usually shows up because the business is changing faster than the stack can be cleaned up. The key is to use the overlap period to protect revenue-driving programs while you migrate safely.

• Push provider migration without losing cart recovery.
  Scenario: you’re moving from a legacy push tool to Customer.io. You keep the old provider for order updates while you validate Customer.io marketing push. Your segmentation ensures “Abandoned Cart” only targets devices confirmed on the Customer.io path.
• Multi-app D2C portfolio.
  Scenario: you own two apps (core brand + outlet brand). One app still uses the old provider, the other is on Customer.io. Provider flags and app identifiers prevent cross-app contamination and keep reactivation campaigns accurate.
• Transactional vs marketing separation.
  Scenario: order status pushes must remain with an existing provider integrated with your OMS, but you want Customer.io to own repeat purchase and replenishment nudges. You route campaigns based on message intent and device eligibility.

Operational Considerations

This is where teams usually get tripped up: the SDK work “functions,” but orchestration breaks because segmentation and data flow weren’t designed for a dual-provider reality.

• Segmentation needs provider-aware eligibility.
  Build segments that include push_opt_in=true, valid device presence, and push_provider alignment. Otherwise you’ll see inflated audience counts and under-delivery.
• Decide a single source of truth for opt-in.
  If the legacy provider tracks opt-in separately, you’ll get mismatches. In practice, we’ve seen best results when the app writes permission state once (from OS status) and both systems consume it.
• Event timing matters more than event volume.
  For retention, “Added to Cart” arriving 10 minutes late is worse than missing a low-value browse event. Prioritize real-time delivery of cart and checkout events.
• Identity collisions show up as duplicates.
  If you identify with email sometimes and customer_id other times, you’ll create split profiles and both may hold tokens. Standardize identifiers and enforce them in the app code.
• Campaign orchestration should include suppression logic.
  If your legacy provider still sends some marketing pushes, add suppression in Customer.io (or vice versa) to prevent double sends during the overlap window.

Implementation Checklist

If you run through this list before you scale sends, you’ll avoid the classic “it worked in QA but not in production” push migration failure.

• Customer.io SDK installed and initialized on app launch
• identify called consistently with a single canonical identifier (and updated on login/logout)
• Push permission status captured and stored as person attributes
• Token registration + token refresh wired to update Customer.io device records
• Anonymous events tracked for browse/cart/checkout and merged on identify
• Provider flag attribute implemented (push_provider or equivalent)
• Segments built for provider-aware push eligibility
• Parallel-send suppression plan documented (who sends what, when)
• Device QA completed across install/upgrade/login/token refresh edge cases

Expert Implementation Tips

The difference between “push works” and “push drives repeat purchase” is usually a handful of small operational choices that keep your audiences clean and your timing tight.

• Gate cart recovery on both intent and deliverability.
  For example: send “Abandoned Cart” only if Added to Cart happened in the last 2 hours and the profile has a valid token for the Customer.io provider. Otherwise route to email/SMS.
• Version your migration.
  Add app_version and use it to ramp: first target vX.Y+ where you’re confident token capture is correct.
• Log token/provider changes as events.
  A lightweight event like Push Token Updated with properties (provider, platform) makes debugging delivery drops much faster.
• Design for logout.
  If users log out on shared devices, make sure tokens don’t remain attached to the wrong person. This is a common source of “why did my partner get my cart push?” complaints.

Common Mistakes to Avoid

Most issues aren’t deep technical failures—they’re consistency failures. A few bad edge cases can quietly wreck your holdouts, attribution, and customer trust.

• Identifying too late.
  If you only call identify after purchase, you’ve already missed cart recovery and most product discovery nudges.
• No provider flag during migration.
  This is how you end up with duplicate pushes: both providers think they own the device.
• Using multiple identifiers for the same person.
  Email in one place, phone in another, internal ID elsewhere—this creates split profiles and token duplication.
• Assuming token = opt-in.
  A token can exist even when notifications are effectively disabled (platform nuances, provisional permissions). Always store and check permission state.
• Not testing upgrade paths.
  Fresh installs are easy. Upgrades are where old tokens, old identifiers, and cached states collide.

Summary

If you’re running multiple push providers, treat it like an identity and segmentation problem first, and a delivery problem second. Get identify, token updates, and provider-aware eligibility right, and your cart recovery and repeat purchase flows stay reliable during migrations.

Implement Multiple Push Providers with Propel

If you’re juggling multiple push providers inside Customer.io, the fastest wins usually come from tightening the app-side identity and building provider-aware segments that prevent duplicates. If you want help mapping your current SDK state to a clean migration plan (without pausing revenue-driving push like cart recovery), book a strategy call and we’ll walk through your token/identify flows and orchestration rules.