Deep Links (SDK): Send customers back into the right in-app moment

Overview

If you’re using Customer.io to drive repeat purchase and recovery, deep links are one of the highest-leverage “plumbing” upgrades you can make—because they remove friction between a message click and the exact screen that converts. If you want a second set of eyes on your tracking + routing approach, book a strategy call and we’ll pressure-test it like an operator would.

In practice, deep links matter most when your customer intent is already high (cart, replenishment, back-in-stock) and your app experience is where conversion happens. The goal isn’t “send traffic to the app”—it’s “land them on the right product/cart/account state with identity intact.”

How It Works

Deep links are just URLs with rules. The rules live in your app (and sometimes your website), and they decide what happens after a click: open the app if installed, route to a specific screen, and preserve attribution/identity so Customer.io can correctly credit the campaign and continue the customer journey.

• Message link → app routing: Your email/SMS/push contains a link (often a universal link/app link). When tapped, iOS/Android resolves it to your app and passes the full URL to your app’s router.
• Deep link payload: The URL typically includes a path (e.g., /product/sku_123) plus query params (e.g., cart_id, variant, utm_*, cio_id or your own tracking token).
• Identity stitching: The click might happen before login. Your app should capture the deep link parameters on first open, then—after the user logs in or you resolve the customer—call identify and attach the click context to the now-known profile (or fire an event that includes the stored deep link params).
• Event tracking accuracy: If the deep link lands on a cart or PDP, you want deterministic events like Viewed Product, Viewed Cart, Checkout Started, Order Completed fired from the app with consistent IDs (product_id, cart_id, order_id). This is what makes cart recovery and repeat purchase orchestration actually work in Customer.io.

Step-by-Step Setup

The setup usually breaks when teams treat deep links as “just a URL.” Treat it as a tracking surface: define the routes, define the parameters, then make sure the SDK identity + events reflect what actually happened.

1. Define your deep link destinations (routes) for retention flows.
   Start with the screens that drive revenue: cart, checkout, product detail, collection, reorder, subscription management, and account.
2. Implement universal links/app links in your app.
   iOS: Universal Links; Android: App Links. Ensure your domain association files are correct so links open the app reliably (not a browser).
3. Add a deep link router that parses path + query parameters.
   Your router should handle things like /cart?cart_id=... and /product/sku_123?variant=..., and gracefully fall back if data is missing.
4. Install and initialize the Customer.io mobile SDK.
   Do this early in app startup so you can capture attribution/context as soon as the app opens from a link.
5. Call identify as soon as you have a stable customer identifier.
   Use your internal customer ID (not email) when possible. If the user is anonymous at click/open, store the deep link context locally and attach it after login.
6. Track deep-link-driven events with consistent IDs.
   Example events:
   • Deep Link Opened (properties: destination, campaign/source params, sku/cart_id)
   • Viewed Product (product_id/sku, variant_id)
   • Viewed Cart (cart_id, item_count, value)
   • Checkout Started (cart_id, value)
   • Order Completed (order_id, value, items)
7. Use those events in Customer.io to orchestrate recovery and repeat purchase.
   Your campaigns should branch on “deep link opened but no checkout started,” “checkout started but no order,” etc. This is where deep links stop being a UX nice-to-have and become a retention lever.

When Should You Use This Feature

Deep links are worth the effort when you’re trying to reduce steps between message click and the action you care about. In most retention programs, we’ve seen the biggest lift when the destination is transactional (cart/checkout) or high-intent (reorder, back-in-stock).

• Cart abandonment recovery (app-first): Send an SMS like “Your cart’s still saved” and deep link directly to /cart?cart_id=... so they don’t have to rebuild it.
• Browse abandonment: If someone viewed a specific SKU in-app, deep link back to that exact PDP with selected variant preloaded.
• Replenishment / repeat purchase: For consumables, deep link to a “Reorder” screen or a pre-filled cart (e.g., /reorder?last_order_id=...).
• Reactivation: If a lapsed customer clicks “Come back for 15% off,” deep link to a curated collection or their account offers page—then track whether they actually viewed the offer in-app.

Real D2C scenario: A skincare brand runs a 4-hour cart recovery SMS. Without deep links, customers land on the homepage, search for the cleanser again, and drop. With a cart deep link + Viewed Cart and Checkout Started events, the team can (1) suppress anyone who resumed checkout, (2) send a second nudge only to “opened link but didn’t start checkout,” and (3) accurately attribute the recovery in Customer.io.

Operational Considerations

Deep links touch routing, identity, and measurement—so the operational risks are usually data-related, not creative-related. Plan for how the link context flows through your app and back into Customer.io, otherwise your segments and suppression logic will drift.

• Segmentation depends on clean event semantics: Decide whether “clicked message” is enough, or whether you require Deep Link Opened (app confirmed) to qualify as engagement. For app-first brands, we typically optimize on app-confirmed opens.
• Identity stitching is the make-or-break: If a user opens from a deep link while logged out, you need a plan to associate that open with the eventual identified user. Store deep link params locally, then fire Deep Link Opened after identify (or fire a second event like Deep Link Attributed post-login).
• Orchestration realities: Your campaign should assume imperfect routing (app not installed, link opens web, user bounces). Build fallback branches: web landing → prompt app open; or continue the journey based on web events if you track them.
• Deduping events: Deep links can cause double-fires (router fires twice, app resumes, etc.). Add idempotency keys (e.g., deeplink_id) and dedupe server-side or in your analytics pipeline.
• Parameter hygiene: Don’t shove everything into query params. Keep a small, stable contract: destination + primary entity IDs + attribution token.

Implementation Checklist

If you want this to hold up under real campaign volume (and not just in QA), treat the checklist below as your “definition of done” before you roll deep links into cart recovery or replenishment.

• Universal Links (iOS) / App Links (Android) verified and opening the app reliably
• Deep link router supports cart, PDP, collection, reorder, account destinations
• Customer.io SDK initialized early in app lifecycle
• identify called with a stable customer ID; logout resets identity appropriately
• Anonymous deep link context stored and stitched post-login
• Deep Link Opened (or equivalent) event implemented with destination + entity IDs
• Commerce events standardized (Viewed Product, Viewed Cart, Checkout Started, Order Completed) with consistent IDs
• Dedupe strategy in place for deep-link-driven events
• Customer.io segments and suppression rules built off app-confirmed events
• Fallback behavior defined for “app not installed” (web landing or store redirect)

Expert Implementation Tips

The difference between “we added deep links” and “deep links increased recovered revenue” usually comes down to identity and event design, not the link itself.

• Track the destination, not just the click: A click is marketing; a routed destination is product reality. Use a dedicated event when the app successfully navigates to the intended screen.
• Use a single deep link contract across channels: Email, SMS, and push should share the same destination schema so your Customer.io reporting and segments don’t fragment.
• Attach cart_id/order_id everywhere: For recovery flows, IDs beat timestamps. Customer.io orchestration gets cleaner when you can say “this cart” instead of “a cart sometime today.”
• Design for logged-out opens: In practice, this tends to break when the app opens to a gated screen and loses the deep link. Cache the intent, route after auth, then fire the event.

Common Mistakes to Avoid

Most teams don’t fail because they can’t create a link—they fail because the link doesn’t reliably result in measurable, attributable behavior inside the app.

• Sending everyone to the homepage: You’ll see “clicks” but not recovery. Route to cart/PDP/reorder with the right IDs.
• Relying on UTMs as your only attribution: UTMs help, but they don’t solve identity stitching inside the app. You still need consistent identify + events.
• Double-counting conversions: If your app fires Order Completed twice (resume + confirmation), Customer.io reporting and suppression logic will get messy fast.
• No fallback for app-not-installed: A deep link that dead-ends on mobile web is a silent revenue leak, especially for SMS.
• Inconsistent identifiers: Switching between email, phone, and internal IDs across SDK calls leads to split profiles and broken journeys.

Summary

If your retention revenue depends on the app, deep links are table stakes for cart recovery, replenishment, and reactivation. Implement them with a clear routing contract, app-confirmed events, and disciplined identity stitching. If you can’t measure “opened → routed → checkout,” you can’t reliably optimize.

Implement Deep Links with Propel

If you’re already running retention in Customer.io, the fastest path is usually tightening the deep link contract + SDK identity/events so your segments and suppressions behave the way you think they do. When you’re ready to sanity-check your routing, dedupe, and attribution approach against real-world failure modes, book a strategy call and we’ll map it to your highest-impact flows (cart recovery, reorder, and winback).