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

Overview

If you’re running Customer.io alongside another push provider (or migrating between providers), the real work is making sure device tokens, permission state, and user identity stay clean—otherwise your cart recovery and winback pushes quietly miss the user. If you want a second set of eyes on the tracking plan before you ship, book a strategy call and we’ll pressure-test the edge cases that typically break in production.

In most retention programs, multiple push providers show up for very practical reasons: you inherited Braze/OneSignal from a prior team, you use a separate provider for transactional push, or you’re mid-migration and can’t afford delivery gaps. The goal is simple: Customer.io should always know which device belongs to which customer, and which push token is actually reachable right now.

How It Works

When you use multiple push providers, the SDK layer becomes the source of truth for device identity. Customer.io needs a stable mapping between: (1) a person (your customer), (2) a device, and (3) the push token that Apple/Google assigns to that app install. The tricky part is that other providers also register tokens, and tokens can rotate—so “it worked in QA” doesn’t mean it’ll keep working after an OS update, reinstall, or logout/login.

• Each provider registers for a push token (APNs on iOS, FCM on Android). Your app receives the token and typically forwards it to each vendor SDK.
• Customer.io stores devices against a person based on SDK calls. If you don’t identify the person correctly (or at the right time), tokens end up attached to anonymous/incorrect profiles.
• Identity stitching is the retention unlock: once the user logs in (or you otherwise know who they are), you need to tie the current device token to that known profile so cart recovery, replenishment, and winback flows hit the right human.
• Multiple providers means multiple “sources of truth”. In practice, this tends to break when one SDK registers a new token and the other vendor never receives the updated token—or when logout doesn’t actually disassociate the device.

Real D2C scenario: A shopper adds items to cart on mobile, bounces, then logs in the next day to check order status. If your app identified them only after checkout historically, Customer.io may still have the device token tied to an anonymous profile. Your cart recovery push fires… and goes nowhere. Fixing the identify + token update timing usually lifts recovery without changing a single message.

Step-by-Step Setup

You’re aiming for two things: (1) Customer.io always gets the latest push token, and (2) that token is always attached to the correct customer profile. The exact method varies by SDK (iOS/Android/React Native/etc.), but the operational sequence is consistent.

1. Decide which provider “owns” push sending per use case (Customer.io vs the other provider).
   • If Customer.io is sending retention pushes (cart, browse abandon, replenishment), treat Customer.io as the system that must have the cleanest device map.
   • If another provider sends some pushes, still keep Customer.io device tracking accurate so segments and suppression logic remain trustworthy.
2. Instrument a single identity moment in the app.
   • Call identify as soon as you have a stable customer ID (login, account creation, or magic-link verification).
   • Do not wait for purchase. By then, you’ve already missed the highest-intent recovery windows.
3. Send the push token to Customer.io every time it changes.
   • Handle token refresh events (FCM token refresh, APNs token updates) and forward the new token to Customer.io immediately.
   • Don’t assume “token set once” is enough—reinstalls and OS changes will invalidate that assumption.
4. Track permission state and subscription status as attributes.
   • Update a boolean like push_enabled and optionally a timestamp like push_opt_in_at.
   • This keeps your suppression logic honest when users disable notifications at OS level.
5. Implement logout handling deliberately.
   • On logout, make sure you either reset the Customer.io identity (so future events don’t attach to the prior user) or explicitly manage device association based on your account-sharing rules.
   • Account sharing (common in households) is where teams accidentally send “your cart is waiting” to the wrong person.
6. Validate with real device testing, not just logs.
   • Test: install → browse → add to cart → close app → token refresh (simulate) → login → send test push from Customer.io → confirm delivery.
   • Repeat after reinstall. Reinstall is where stale token handling shows up.

When Should You Use This Feature

Multiple push providers isn’t a “nice to have”—it’s a reality when you’re scaling, migrating, or splitting responsibilities between transactional and retention. The key is deciding whether the complexity is worth it for your program right now.

• Provider migration without revenue risk: keep the legacy provider running while Customer.io ramps, then cut over once delivery + identity are stable.
• Cart recovery on mobile: if push is a top channel for recovery, you can’t afford token drift or anonymous-device issues.
• Repeat purchase & replenishment: subscription-like behaviors (supplements, skincare, pet) depend on accurate “reachable push audience” segments.
• Reactivation: winback pushes only work when you can confidently target lapsed buyers who still have an active device token.

Operational Considerations

The SDK work is only half the battle. The other half is how your data flows into segmentation and how you orchestrate sends so you don’t double-message customers across providers.

• Segmentation: separate “has app” from “push reachable”.
  • Build segments on push_enabled = true and “last token updated within X days” (if you track it), not just “has installed app.”
  • This prevents inflated audience counts that make push look weaker than it is.
• Data flow: treat token updates like critical events.
  • If token refresh events are delayed (background restrictions, batching), your sends will look randomly flaky.
  • In practice, we’ve seen teams fix “push deliverability” simply by forwarding refresh tokens reliably.
• Orchestration: avoid double sends across providers.
  • Decide which system sends which message types and enforce it with naming + tagging conventions.
  • If both systems can fire cart recovery, you need explicit suppression rules (e.g., only one provider sends if the other already sent in the last N hours).
• Identity stitching: one customer ID everywhere.
  • Use the same internal customer identifier across SDKs/providers so you can audit mismatches quickly.
  • When IDs differ (email in one system, numeric ID in another), debugging becomes guesswork.

Implementation Checklist

Before you call this “done,” lock in the basics that keep retention flows stable through app updates, token rotations, and user behavior changes.

• Customer.io SDK installed and initialized in the app (iOS/Android framework of choice).
• identify called immediately on login/account creation with a stable customer ID.
• Push token forwarded to Customer.io on initial registration and on every refresh.
• Permission status tracked (e.g., push_enabled) and updated on change.
• Logout behavior defined and implemented (reset identity or explicit reassociation rules).
• Segments created for “push reachable” vs “app installed.”
• Send ownership documented to prevent duplicate pushes across providers.
• Reinstall test passed (token rotates, identity still correct, push still delivers).

Expert Implementation Tips

This is where teams usually win or lose. The difference between “push works” and “push drives revenue” is almost always cleanliness of identity + token hygiene.

• Identify earlier than you think: if you have any authenticated moment (order lookup, loyalty, wishlist), stitch then—not at checkout.
• Track a token-updated timestamp: it gives you a simple way to exclude stale devices from high-stakes sends like winback.
• Use event-driven suppression: if another provider sends a push, track an event back into Customer.io (e.g., push_sent_external) so Customer.io journeys can suppress follow-ups.
• Household devices need rules: if your product is often shared (kids, pets, pantry staples), decide whether the device belongs to the last logged-in user or to a household account—and implement consistently.

Common Mistakes to Avoid

Most failures here don’t show up as obvious errors. They show up as “push underperforms,” “cart recovery is inconsistent,” or “we’re spamming people,” and then everyone debates creative instead of plumbing.

• Only sending the token once and ignoring refresh events—this quietly decays your reachable audience over time.
• Delaying identify until purchase, which strands high-intent pre-purchase behavior on anonymous profiles.
• No logout/reset handling, leading to cross-user messaging on shared devices.
• Assuming “installed app” means “push enabled”, which bloats segments and depresses reported conversion rates.
• Letting two systems run the same journey (two cart pushes, two winbacks) without hard suppression logic.

Summary

If you’re running multiple push providers, treat your SDK implementation like retention infrastructure: early identity, reliable token refresh forwarding, and clear send ownership. Once the device map is clean, Customer.io journeys become predictable—cart recovery hits the right device, and reactivation audiences stop being inflated by unreachable installs.

Implement Multiple Push Providers with Propel

If you’re juggling multiple push providers, the fastest path is usually tightening the SDK identity + token flow first, then aligning segmentation and suppression rules so journeys don’t collide. That’s typically where implementations drift over time—especially across app releases and vendor migrations.

If you’re building this inside Customer.io and want an operator’s review of your tracking and orchestration plan, book a strategy call. We’ll focus on the failure modes that impact revenue (missed cart recovery, broken winbacks, duplicate sends), not generic SDK setup.