Registering Device Tokens in Customer.io

Overview

Registering device tokens in Customer.io is the plumbing that makes mobile push notifications dependable for commerce moments like cart recovery, back-in-stock alerts, and post-purchase replenishment reminders. If you cannot tie a shopper’s device token to the right customer profile, your push program turns into guesswork and you lose easy repeat revenue. Propel typically helps D2C teams get token collection, identity, and event timing aligned so push can perform like a real channel, not an afterthought. If you want help pressure testing your mobile data and push strategy, book a strategy call. We implement push programs end to end on Customer.io.

How It Works

Registering device tokens in Customer.io works by collecting a unique token from Apple Push Notification service (APNs) or Firebase Cloud Messaging (FCM) and attaching it to the correct person profile so Customer.io knows where to deliver push messages.

In practice, your mobile app SDK requests push permission, receives a token from APNs or FCM, then sends that token to Customer.io along with an identifier that matches your customer record. Customer.io stores the device on the profile, and can target messages to the most recent device, all devices, or specific platforms depending on your channel settings and campaign logic. When tokens rotate (common on iOS and Android), your app must re-register the new token so sends do not silently fail.

Step-by-Step Setup

Registering device tokens in Customer.io is straightforward, but the details matter if you want cart recovery push to land within minutes, not hours.

1. Decide your identity strategy: pick the primary customer identifier you will use for push targeting (usually your internal customer ID, sometimes email). Make sure it is consistent across app, website, and Customer.io.
2. Implement push permission prompts in your mobile app with a commerce-first moment (for example, after a shopper favorites an item or opts into back-in-stock). Avoid asking on first open unless your brand already has strong app loyalty.
3. Capture the APNs (iOS) or FCM (Android) device token after permission is granted (and also on app reopen, because tokens can change).
4. Send the token to Customer.io via the appropriate mobile SDK method to register the device on the person profile. Ensure the call includes the same identifier you use to identify the person in Customer.io.
5. Handle logged-out behavior: if a shopper logs out, decide whether you will keep the device tied to the last known profile, or disassociate it until the next login. Document the choice so your team does not chase “wrong person got the push” issues later.
6. Validate in Customer.io that the device appears on the person profile (platform, token, and last updated time). Test with both iOS and Android.
7. Run a controlled test campaign to a small internal segment (employees, QA devices) and confirm delivery, deep links, and conversion events are tracked.

When Should You Use This Feature

Registering device tokens in Customer.io is most valuable when you have time-sensitive shopping moments where push can beat email and SMS on speed and cost.

• Abandoned cart recovery in-app first: A shopper adds a moisturizer and sunscreen to cart in your app, then drops. A push 30 minutes later with a deep link back to checkout often converts higher than email alone, especially for mobile-heavy brands.
• Back-in-stock and price drop alerts: Push is ideal when inventory moves fast and you want the shopper back in checkout before the item sells out again.
• Post-purchase replenishment: If your average reorder window is 21 to 35 days, push can nudge at the right time without the inbox fatigue of extra emails.
• Winback for app buyers: For customers who purchased in-app before, push can re-engage with new arrivals or bundles without paying per message like SMS.

Operational Considerations

Registering device tokens in Customer.io touches identity, data flow, and orchestration, so it needs the same rigor you apply to checkout tracking.

• Identity resolution: Token registration is only as good as your identify call. If anonymous app sessions are not merged into the logged-in customer correctly, you will undercount devices and mis-target pushes.
• Token refresh and churn: Treat token updates as a recurring event, not a one-time setup. In retention programs we’ve implemented for D2C brands, a common cause of “push performance decline” is simply stale tokens after an app update.
• Cross-channel orchestration: Decide your channel priority for key flows. Example: cart recovery might be push first for app users, then email, then SMS only if the customer is high intent or high AOV.
• Platform differences: iOS permission rates can be sensitive to timing and value framing. Android delivery is usually easier, but deep link handling still breaks often unless QA is disciplined.
• Measurement: Make sure your purchase event and attribution windows are consistent. If you send a push and cannot reliably tie it to a checkout event, you will not know what to scale.

Implementation Checklist

Registering device tokens in Customer.io goes live cleanly when these pieces are checked off.

• Mobile app captures APNs and FCM tokens reliably (including token refresh)
• Token registration call ties the device to the correct identified person
• Clear handling for logout, account switching, and shared devices
• Deep links open the right screen (cart, PDP, collection, checkout)
• QA segment exists for internal devices and test sends
• Cart, checkout started, and purchase events are tracked consistently
• Suppression logic exists for recent purchasers (avoid “complete your order” after purchase)
• Delivery and conversion reporting reviewed after first week

Expert Implementation Tips

Registering device tokens in Customer.io is where small technical decisions show up as big revenue differences later.

• Ask for push permission after intent, not on app open: Tie the prompt to a shopper action like “Save to wishlist” or “Notify me when back in stock.” You will get fewer opt-ins, but they tend to be higher intent and convert better.
• Build a “push-eligible” segment: Segment on “has a registered device” plus recent engagement (for example, app opened in last 30 days). This protects deliverability and keeps your push metrics honest.
• Use push for speed, email for detail: For cart recovery, push should be short and direct with a deep link. Follow with an email that includes richer content like reviews, bundles, and FAQs.
• Instrument token changes as a diagnostic: Track an event when a token is registered or updated. In programs we’ve implemented for D2C brands, this becomes the fastest way to detect broken SDK releases before revenue is impacted.

Common Mistakes to Avoid

Registering device tokens in Customer.io fails quietly when teams skip the unglamorous parts.

• Registering tokens before identifying the shopper: If you attach devices to anonymous profiles and never merge, your best customers may never receive pushes.
• Not handling token refresh: Tokens change. If you only register once, delivery will decay over time and you will assume “push just doesn’t work for our brand.”
• No suppression for purchasers: Cart pushes that fire after a purchase create immediate trust damage and increase opt-outs.
• Sending the same push to all devices: If a customer has multiple devices, you can annoy them fast. Be deliberate about targeting the most recently active device for urgency flows.
• Broken deep links: A push that opens the app home screen instead of the cart is a conversion killer. QA deep links every release.

Summary

Register device tokens when you want push to drive fast conversions in moments like cart recovery, back-in-stock, and replenishment. Done right, it turns mobile engagement into repeat revenue inside Customer.io.

Implement with Propel

Propel can implement device token registration, identity merging, and push-first revenue flows in Customer.io so your app becomes a repeat purchase engine. book a strategy call.