Provisional Push (SDK): how to capture early opt-ins without breaking identity or attribution

Overview

If you run push as a real retention channel, the biggest leak is the first session: customers browse, add to cart, then disappear before they ever accept notifications. Customer.io Provisional Push is how you start delivering notifications earlier (where supported) while you earn the full opt-in—without sacrificing tracking or identity stitching. If you want a second set of eyes on your permission + identity flow before you scale cart recovery and winback, book a strategy call.

Operationally, provisional is less about “sending earlier” and more about getting your app-side data and device registration correct so Customer.io can target the right device, then upgrade cleanly when the user grants full permission.

How It Works

Provisional push is an OS-level permission state (most commonly iOS) that lets you deliver notifications quietly before the user explicitly taps “Allow.” In retention programs, we’ve seen it work best when you treat it as a separate audience state with separate messaging rules—not as a replacement for a real opt-in prompt.

• App requests provisional authorization during onboarding or right after a value moment (e.g., “Track your order,” “Back-in-stock alerts”). The OS may grant a provisional state without showing the full prompt.
• The SDK registers the device token with Customer.io. This is the critical part: your device must be tied to the correct person record, or your cart recovery push will land on the wrong profile later.
• You track permission state as data (attribute and/or event). This is what powers segmentation: provisional vs fully opted-in vs denied.
• When the user upgrades to full permission, the OS state changes and the SDK updates the device record. Your journeys should react to that change (e.g., swap from “quiet” messaging to higher-intent pushes).
• Identity stitching happens via Identify. Anonymous browsing + add-to-cart events can be merged into the known profile once login/email capture happens—if you call identify correctly and consistently.

Step-by-Step Setup

The setup is straightforward, but the details matter. Most issues come from calling identify too late, not tracking permission state, or letting anonymous and known users fragment into multiple profiles.

1. Install the Customer.io SDK for your platform (iOS/Android/React Native/etc.) and confirm basic initialization in the app lifecycle (app start).
2. Implement Identify early.
   • When you have a stable identifier (login, account creation, or verified email/phone), call identify with your customer_id (or your canonical user ID).
   • If you support guest checkout or email capture before account creation, identify at email capture and later update the profile when the account is created—don’t wait until “first purchase.”
3. Request provisional push permission (where supported).
   • Trigger it after a value moment (e.g., after “Track shipment” tap), not on first launch.
   • Keep your full opt-in prompt for later, once you’ve delivered value and have a reason to ask.
4. Register the device token with Customer.io.
   • On iOS, ensure your APNs token is captured and passed to the SDK.
   • On Android, ensure your FCM token registration is wired and refreshed properly.
5. Track permission state as a first-class field.
   • Set a person attribute like push_permission_state = provisional | authorized | denied.
   • Also track an event like push_permission_updated with properties (old_state, new_state, timestamp) so you can trigger journeys reliably.
6. Track the retention events that actually drive push journeys.
   • product_viewed (include SKU, category, price)
   • added_to_cart (SKU, qty, cart_value)
   • checkout_started (cart_value, items_count)
   • order_placed (order_id, total, items)
7. Validate identity stitching.
   • Run a test: browse anonymously → add to cart → then log in → confirm the same person record in Customer.io shows the pre-login events and the device.
   • If you see two profiles, fix identify timing and any duplicate IDs before you scale sends.

When Should You Use This Feature

Provisional push is most valuable when your business relies on fast follow-up and you can’t afford to wait for a perfect opt-in rate. In practice, it’s a lever for earlier reach, but only if your SDK events and device registration are clean.

• Cart recovery on mobile: A shopper adds a $78 bundle to cart, gets distracted, and closes the app. Provisional push lets you send a gentle reminder (“Your cart’s saved”) within an hour—even if they haven’t fully opted in yet.
• Back-in-stock / price drop discovery loops: Customers who browse a sold-out SKU can receive quiet alerts without you burning the full permission prompt too early.
• Early lifecycle repeat purchase setup: For replenishable products, you can start setting expectations (“Want a reminder in 21 days?”) while still in provisional, then upgrade to full opt-in when they engage.
• Reactivation for lapsed app users: If a user previously granted provisional but never upgraded, you can tailor a low-frequency reactivation track that nudges them back without spamming.

Operational Considerations

Where teams get burned is assuming “push enabled” is a single boolean. You’ll get better performance (and fewer complaints) when you segment by permission state and orchestrate messaging intensity accordingly.

• Segmentation
  • Build separate segments for push_permission_state = provisional vs authorized vs denied.
  • Layer in intent: provisional + added_to_cart in last 4 hours behaves very differently than provisional + last session 14 days ago.
• Data flow and timing
  • Device token registration must happen after the OS issues a token and after you have a stable identity (or you risk orphan devices tied to anonymous profiles).
  • Permission state changes should be evented, not inferred. OS-level state can change outside your app session; capture updates on app open.
• Orchestration realities
  • Throttle provisional messaging. Quiet notifications can still annoy people if you hit them like a fully opted-in audience.
  • Use exit conditions aggressively: once order_placed fires, kill cart recovery immediately across push/email/SMS.
  • Coordinate channels: if push is provisional, lean more on email for heavier content and use push as the nudge.

Implementation Checklist

If you want this to work in the real world, you need to confirm the basics end-to-end: identity, device, permission state, and the events that drive revenue journeys.

• Customer.io SDK installed and initialized on app start
• identify called with a canonical user ID at login/account creation (and at email capture if applicable)
• APNs/FCM token registration wired and verified in Customer.io device records
• Permission state stored as push_permission_state and updated on app open
• push_permission_updated event tracked with old/new state
• Core commerce events tracked: product_viewed, added_to_cart, checkout_started, order_placed
• Test flow confirms anonymous events merge into known profile after identify
• Segments created for provisional vs authorized with intent overlays

Expert Implementation Tips

Most retention programs we’ve seen win with provisional push treat it like a “warm-up lane.” You’re earning the right to ask for full permission, not trying to squeeze maximum volume out of a quieter permission state.

• Use a two-step permission strategy: provisional after a value moment, then a full opt-in prompt after the user engages with at least one push-driven action (or after a second session).
• Send different creative to provisional: shorter copy, fewer promos, more utility (“Cart saved,” “Order update,” “Back in stock”). Save discounts for fully opted-in users or high-intent moments.
• Trigger upgrade asks off behavior, not time: e.g., after added_to_cart twice in 7 days or after viewing the same SKU 3x.
• Instrument “push delivered” and “push opened” cleanly: if opens look abnormally low, you might be sending to provisional audiences expecting full-notification behavior.
• Keep identity stable across platforms: if a customer logs in on web and mobile, make sure the same customer_id is used so Customer.io doesn’t split their history and suppress the wrong profile.

Common Mistakes to Avoid

These are the issues that usually show up after you’ve already launched—and they’re painful because they look like “push doesn’t work” when it’s really instrumentation.

• Calling identify after sending events and expecting those events to stitch automatically. If the anonymous profile never merges, your cart recovery triggers won’t find the right device.
• Not tracking permission state explicitly. Teams end up blasting provisional users with the same frequency as opted-in users and wonder why engagement tanks.
• Device token not refreshed (especially on Android). You’ll see silent delivery failures and misattribute it to creative.
• Using email as the primary ID in the app when you also support email changes. Pick a stable internal ID and treat email as an attribute.
• No exit rules for purchase events. You end up sending “Still thinking it over?” after the order is already placed.

Summary

Provisional push is a retention unlock when your SDK identity and device tracking are tight. Segment by permission state, keep messaging utility-first, and use behavior to graduate customers into full opt-in. If your data is messy, provisional just amplifies the mess faster.

Implement Provisional with Propel

If you’re rolling this out across iOS/Android and want confidence that identity stitching, permission state, and cart-to-purchase attribution won’t break under scale, we typically start by auditing the SDK calls and the event taxonomy feeding Customer.io. From there, we map provisional vs authorized segments into real revenue journeys (cart recovery, replenishment, winback) with clean exit rules and channel coordination. If that’s useful, book a strategy call.