Handling Multiple Push Providers (SDK): How to Keep Push Tracking Clean in Customer.io

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, token freshness, and attribution clean so your retention flows don’t quietly degrade. If you want a second set of eyes on the data model and orchestration, book a strategy call and we’ll pressure-test your setup the same way we do for live D2C programs.

In most retention programs, multiple push providers show up for one of three reasons: you inherited a legacy provider, you need a fallback provider for deliverability/regions, or you’re splitting transactional vs marketing pushes. The risk is simple: the same customer ends up with multiple device records and inconsistent tokens, and suddenly cart recovery push goes to the wrong device—or doesn’t send at all.

How It Works

When you use multiple push providers, you’re really managing two parallel systems: (1) the OS-level device token lifecycle (APNs/FCM) and (2) Customer.io’s device registry and person identity graph. The SDK is where you win or lose this—because the SDK is the only place that reliably knows the current token, the current logged-in user, and the app state when permissions change.

• Each provider needs the same core inputs: a valid push token and a stable user identity. If either is missing or stale, your sends will drift.
• Customer.io needs a consistent identify call: the moment a user is known (login/account creation), you should identify the person and associate the device to that person. This is what prevents “anonymous device” fragmentation that breaks segmentation later.
• Token refresh must update everywhere: APNs/FCM tokens rotate. If you update the token in Provider A but not in Customer.io (or vice versa), you’ll see silent push failures that look like “low engagement” but are actually “bad token hygiene.”
• Event tracking is what makes push retention work: cart, product view, checkout started, purchase—these events need to be emitted from the app (or reliably forwarded server-side) so Customer.io can trigger and suppress the right messages across providers.
• Identity stitching is the guardrail: if you support guest browsing, you’ll typically track anonymous activity, then merge to a known profile on login. If you don’t stitch correctly, you’ll target the wrong person or miss the window for cart recovery.

D2C scenario: A shopper adds items to cart on mobile while logged out. They later create an account at checkout. If your SDK doesn’t (a) merge anonymous activity into the now-known profile and (b) register the latest push token to that profile, your “1-hour cart recovery push” either won’t fire or fires to an anonymous profile that can’t be messaged.

Step-by-Step Setup

The goal is to make Customer.io’s view of “who this device belongs to” match reality at all times, even if another provider is also registering tokens. Treat this like instrumentation, not messaging—because once it’s wrong, every downstream workflow becomes guesswork.

1. Decide the source of truth for identity.
   Pick one canonical user identifier (usually your internal customer ID). Use the same identifier in Customer.io identify calls across all app surfaces.
2. Install the Customer.io mobile SDK alongside your existing provider.
   Keep both SDKs in the app if you’re dual-sending or migrating. The key is avoiding “either/or” registration logic that leaves Customer.io without a token.
3. Implement identify immediately on login/signup.
   When the user becomes known, call Customer.io identify with your canonical ID and key attributes you’ll actually segment on (email, phone if used, country/region, marketing opt-in state).
4. Register the push token with Customer.io on every token change.
   Handle APNs/FCM token refresh callbacks and forward the latest token into Customer.io device management. Don’t assume “it only happens on install.”
5. Track retention-critical events from the app.
   At minimum for D2C: Product Viewed, Add to Cart, Checkout Started, Purchase. Include properties like SKU, category, cart value, currency, and item count so you can do smart suppression and prioritization.
6. Handle logout cleanly.
   On logout, reset the Customer.io person context (so the next user on the same device doesn’t inherit the previous user’s device association). In practice, this is where “shared iPad” edge cases create scary cross-user sends.
7. Validate device association in Customer.io before launching flows.
   Spot-check a handful of real devices: confirm the person profile shows the expected device(s), and that the latest token timestamp updates after reinstall or permission changes.

When Should You Use This Feature

Multiple push providers are rarely a “nice to have.” They’re usually a constraint you have to operate around. The retention win is making sure that constraint doesn’t leak into broken segments, duplicated sends, or missed recovery windows.

• Provider migration without losing revenue: keep legacy provider running while Customer.io ramps, then phase out once token coverage and deliverability are proven.
• Transactional vs marketing separation: some teams keep order updates in one system and run retention pushes (cart recovery, replenishment, winback) in Customer.io. This only works if identity and token updates are consistent.
• Regional deliverability or OEM quirks: if you have meaningful volume in regions/devices where one provider underperforms, dual-provider routing can protect reactivation performance.
• Experimentation and holdouts: if you’re measuring incremental lift, you need deterministic audience assignment and clean device identity—otherwise you’ll “prove” the wrong thing.

Operational Considerations

Once you’re beyond basic setup, the day-to-day issues are segmentation integrity, data flow timing, and orchestration across systems. This is where most teams think they have a push problem, but it’s actually a tracking problem.

• Segmentation depends on device truth, not just person truth: build segments that explicitly require an active mobile device and valid push permission state. Otherwise you’ll keep queueing journeys for people who can’t receive push.
• Event latency changes outcomes: cart recovery is time-sensitive. If app events arrive late (offline mode, batching, background restrictions), your “send after 30 minutes” becomes “send after 3 hours,” and conversion drops.
• Duplicate sends happen when providers aren’t orchestrated: if both providers fire a cart push, customers see two near-identical messages. Fix this with a single orchestration layer (Customer.io journeys) and a clear rule: only one system sends a given message type.
• Identity stitching must be deterministic: if anonymous-to-known merging is inconsistent, you’ll get fragmented carts and misattributed purchases. In practice, this tends to break when login happens in a webview or via SSO and the app doesn’t re-identify reliably.
• Device churn is real: users reinstall, switch phones, or toggle permissions. Plan for multiple devices per person and define how you want to handle “send to all devices” vs “send to most recent device.”

Implementation Checklist

Before you scale sends, you want confidence that tokens, identities, and events line up. This checklist is the minimum bar we use before turning on high-volume cart and winback pushes.

• Customer.io SDK installed and initialized in all app entry points (cold start, deep link, push open).
• Identify call fires on login/signup with a stable internal customer ID.
• Anonymous activity is either merged into the known profile or intentionally discarded (and you’ve chosen which).
• Push token registration updates on initial permission grant and on every token refresh.
• Logout resets person context to prevent cross-user device association.
• Core commerce events tracked with consistent naming and required properties (SKU, value, currency).
• Customer.io profile shows correct device count and recent token update timestamps for test users.
• One clear rule for which provider sends which message types (no overlap by default).

Expert Implementation Tips

These are the small operator moves that keep push performance stable when you’re juggling multiple providers and real-world app behavior.

• Instrument “push enabled” as a first-class attribute: update it on permission changes. Then gate journeys on it so you don’t waste sends or skew metrics.
• Send a diagnostic event on token updates: even if you don’t use it for messaging, it helps you debug “why did push stop working last week?” without guessing.
• Prefer server-confirmed purchase for suppression: app purchase events can be delayed. If you can, also send a server-side purchase event to Customer.io and use it to exit cart recovery journeys fast.
• Use “most recent device” logic for high-intent flows: for cart and checkout, sending to the last active device typically converts better and reduces duplicate notifications.
• During migration, run shadow sends before full cutover: keep Customer.io building audiences and logging events while the legacy provider still sends. Compare token coverage and open rates before switching.

Common Mistakes to Avoid

Most issues aren’t dramatic failures—they’re slow leaks that show up as declining push revenue over time. These are the patterns behind that decline.

• Only registering tokens on first install: token rotation is guaranteed. If you don’t handle refresh, your reachable audience decays.
• Identifying with an unstable ID: using email as the primary identifier sounds convenient until users change emails or you have duplicates. Use an internal customer ID.
• Forgetting logout/reset flows: shared devices and account switching can cause cross-account sends—this is both a CX and trust problem.
• Event name drift between app and backend: “AddToCart” vs “Added to Cart” becomes two different triggers. Standardize names and enforce them.
• Running two providers without orchestration rules: you’ll double-send, inflate fatigue, and then blame “push doesn’t work anymore.”
• Not segmenting on device eligibility: sending journeys to people without a valid device makes performance look worse than it is and wastes volume limits.

Summary

If you’re going to run multiple push providers, treat the SDK layer as the system of record for identity and token freshness. Get identify, token refresh, and event tracking right, then build segments that reflect who is actually reachable.

If you can’t confidently answer “which device will receive this cart push and why,” fix the instrumentation before you scale sends.

Implement Multiple Push Providers with Propel

When teams combine multiple push providers with Customer.io, the work usually isn’t in the UI—it’s in the messy reality of token refresh, anonymous-to-known stitching, and making sure only one system owns each message type. If you want help auditing your SDK events/device registry and mapping it to clean retention journeys (cart recovery, replenishment, winback), book a strategy call and we’ll walk through your current implementation and the failure points we see most often.