Provisional Push (iOS) for Customer.io: SDK Setup That Actually Holds Up in Retention

Overview

If you run push-heavy retention, iOS Provisional Push is one of the cleanest ways to increase reachable audience without forcing an immediate “Allow Notifications” decision. With Customer.io, the win isn’t just more opt-ins—it’s getting a reliable first push touchpoint early enough to recover carts and drive the second order, then upgrading to full authorization later. If you want a second set of eyes on your event + identity setup before you scale sends, book a strategy call.

Provisional authorization delivers notifications quietly to Notification Center first. In practice, that means you can start learning who responds to push and build segments off real behavior—without burning the relationship with a hard prompt on day one.

How It Works

Provisional Push is an iOS permission state where the user hasn’t explicitly opted in, but Apple still lets you deliver notifications in a “quiet” mode. From a retention ops standpoint, the important part is that your app still needs to register the device token correctly, and Customer.io still needs a stable identity to stitch device activity to the right customer profile.

• App requests provisional authorization via iOS notification permission APIs (provisional option). The user doesn’t see the standard blocking prompt.
• iOS returns an authorization status (provisional vs authorized vs denied). You should track this as an attribute/event so you can segment and time your upgrade prompt.
• Device token registration still happens. Your app must register for remote notifications and pass the token to the Customer.io Mobile SDK so Customer.io can route pushes to that device.
• Identity stitching is the difference between “nice” and “useful”. If the device is anonymous at token registration time and you don’t identify later, your cart recovery push might go to an anonymous profile that never receives email/SMS follow-ups.
• Customer.io uses the device + person mapping to target pushes from campaigns/journeys. Your segmentation logic (e.g., “has provisional push but not full push”) depends on you sending clean permission-state signals.

Where this tends to break in real programs: token registration fires before login, then the team forgets to call identify after authentication. Result: pushes “work” in QA but your retention journeys underperform because the reachable audience is fragmented across anonymous profiles.

Step-by-Step Setup

The goal here is simple: request provisional permission at the right moment, register the token, and make sure Customer.io can tie that device to the eventual customer record. Do this once, and your cart recovery + repeat purchase flows get a bigger push-eligible pool with fewer prompt-related drop-offs.

1. Install and initialize the Customer.io Mobile SDK
   Do this at app start so the SDK can manage device state consistently. Confirm you’re on a supported SDK version and that push is enabled in your Customer.io workspace settings.
2. Request iOS notification permission using the “provisional” option
   Trigger this after the user has seen value (e.g., after they browse 2–3 products or save an item), not on first launch. Store the returned authorization status locally so you can avoid re-request loops.
3. Register for remote notifications and capture the device token
   When iOS provides the APNs token, pass it to the Customer.io SDK using the SDK’s push registration method for your platform (iOS / React Native / Flutter wrappers as applicable).
4. Send permission state to Customer.io as an attribute and/or event
   At minimum, set something like push_permission_state to provisional, authorized, or denied. If you also send an event (e.g., push_permission_updated), you can trigger journeys off the change.
5. Call identify as soon as you have a real customer ID
   This is the stitching step. After login/account creation/checkout, identify the user so Customer.io merges the device into the known profile. If you support logout, also handle reset/anonymous behavior cleanly so devices don’t drift between profiles.
6. Track the retention events you’ll actually message off
   For D2C, that’s typically product_viewed, added_to_cart, checkout_started, order_completed, and sometimes back_in_stock_requested. Push is only as good as the event timing and payload.
7. QA with a real device and real journey entry
   Confirm: (1) device shows as push-enabled in Customer.io, (2) the profile is the identified customer (not anonymous), (3) the permission state attribute matches iOS status, and (4) a campaign can target the device.

When Should You Use This Feature

Provisional Push is worth it when you want earlier push reach without paying the conversion tax of an immediate hard prompt. In most retention programs, it’s especially useful when you have high-intent moments where speed matters, but you don’t want to gamble on a one-time permission ask.

• Cart abandonment on mobile: A shopper adds a product, gets distracted, and never hits checkout. With provisional enabled, you can still deliver a quiet reminder (“Your cart is waiting”) within 30–60 minutes, then escalate to email/SMS if they don’t return.
• Back-in-stock and low-inventory nudges: These are time-sensitive and perform well via push. Provisional lets you start sending without forcing the user to commit up front.
• Second-order conversion: After order #1, you can send shipping updates transactionally and then test a replenishment nudge later—using engagement to decide when to ask for full authorization.
• Content/product discovery loops: If you run drops, bundles, or routine launches, provisional gives you a wider top-of-funnel for push-based discovery, then you graduate engaged users to full push.

Operational Considerations

Once you roll this out, the “marketing” work is mostly data discipline. Your segments and orchestration only stay clean if permission state, identity, and event flow are consistent across app versions.

• Segmentation needs explicit permission states: Treat provisional, authorized, and denied as separate cohorts. Don’t lump “not denied” together—you’ll lose the ability to time your upgrade prompt.
• Identity stitching is non-negotiable: If token registration happens pre-login, you must identify post-login. Otherwise, your cart recovery push might hit an anonymous profile while your email hits the known profile—two parallel journeys, half the conversion rate.
• Event payloads matter for dynamic content: For cart recovery, include product name, variant, price, and image URL in the event so push can be specific. Generic pushes (“Come back!”) underperform and train users to ignore Notification Center.
• Orchestration reality: push is rarely the only channel: Build your journeys so push is the first touch when provisional/authorized is present, but always backstop with email/SMS. Use Customer.io frequency controls to avoid double-tapping within the same hour.
• Version drift: If you change permission tracking logic in a new app release, expect mixed-state data for a while. Segment by app version when you’re validating rollout.

Implementation Checklist

If you want this to drive incremental revenue (not just “more pushes sent”), lock these basics before you start scaling campaigns.

• Customer.io Mobile SDK installed and initialized at app start
• iOS provisional permission request implemented and returns status reliably
• APNs device token captured and passed to Customer.io SDK
• push_permission_state stored on the person profile (and kept up to date)
• identify called after login/account creation/checkout with stable customer ID
• Core D2C events tracked: product view, add to cart, checkout start, purchase
• QA confirms device is attached to the identified profile (not anonymous)
• Journeys/campaigns use segments that distinguish provisional vs authorized vs denied

Expert Implementation Tips

The biggest gains usually come from how you time provisional and how you graduate users to full push—not from the permission API itself.

• Ask for provisional after an intent signal: For example, after added_to_cart or after a user favorites/saves a product. The audience is warmer and more likely to engage with the first quiet push.
• Use engagement to trigger the upgrade prompt: If a user clicks a provisional push or returns to the app from Notification Center, that’s your moment to request full authorization. Track push_clicked (or your deep link open event) and branch a journey.
• Build a “push-capable cart recovery” segment: push_permission_state in (provisional, authorized) AND has_device = true AND last_seen <= 24h. This prevents wasted sends to profiles that can’t actually receive push.
• Keep anonymous browsing, but don’t let it stay anonymous: If your app supports guest checkout or email capture later, make sure you identify and merge quickly so early cart events still power follow-ups.

Common Mistakes to Avoid

Most teams don’t fail on “how to request provisional.” They fail on the data plumbing that makes the permission state actionable inside Customer.io.

• Tracking permission once and never updating it: Users move from provisional → authorized (or deny later). If you don’t update the attribute, your segments rot.
• Device token registered before identify, then never stitched: This is the classic. It looks fine in a device test, but performance is inconsistent at scale.
• Sending cart pushes without cart context: If your event doesn’t include product details, your message becomes generic and engagement tanks—especially in Notification Center where users skim.
• No channel coordination: Push + email firing at the same time for the same cart is a quick way to spike unsubscribes and notification disables.
• Ignoring app version and environment differences: Sandbox vs production tokens and mixed app versions can create false negatives when you QA.

Summary

Provisional Push is a practical way to expand your push-reachable audience on iOS without burning users on a hard prompt. The retention upside comes from clean identity stitching, explicit permission-state tracking, and journeys that treat provisional as a distinct cohort—not a footnote.

Implement Provisional with Propel

If you’re rolling out Provisional Push and want it to translate into measurable lift (cart recovery, second order, reactivation), focus on the stitching + segmentation layer as much as the SDK calls. We’ll usually validate the device-token flow, the identify timing, and the permission-state taxonomy inside Customer.io, then map it to a push-first journey that doesn’t spam other channels. If you want to sanity-check your implementation and targeting rules, book a strategy call.