Deep Links (SDK): Route customers back into the exact in-app moment that drives the next purchase

Overview

If you’re sending push, SMS, or email out of Customer.io, deep links are the difference between “they clicked” and “they bought.” When the tap lands on the right screen (cart, PDP, reorder, subscription management), conversion rates usually jump because you remove navigation friction. If you want help pressure-testing your tracking and routing before you scale, book a strategy call and we’ll sanity-check the implementation like an operator would.

In most retention programs, deep links break quietly: the app opens but the customer lands on home, identity isn’t stitched, or the click never maps back to a campaign. The goal here is simple—make every click resolve to a deterministic in-app destination, and make sure Customer.io can attribute that click to the right person and event.

How It Works

Deep links are just URLs, but in retention they’re really a routing system: a message click should open your app and pass enough context for the app to render the right screen (and for Customer.io to record engagement accurately).

• Link types: you’ll typically use universal links (iOS) / app links (Android) for best reliability, with a custom scheme (e.g., myapp://) as a fallback.
• Message click → OS routing: the OS decides whether to open the app directly (preferred) or fall back to web. This is why domain/app association files matter.
• App receives the URL: your app parses the path + query params (e.g., /cart, /product/123, ?variant=blue) and routes to the correct screen.
• Customer.io attribution: Customer.io tracks the click on the message side. Your job is to make sure the person who clicked is the same person the app identifies (so downstream events like Viewed Product or Checkout Started tie back to the campaign).
• Identity stitching: if someone clicks while not logged in, you’ll often see “anonymous open” behavior until they authenticate. The moment they log in, your SDK identify call should stitch subsequent events to the right profile.

Real D2C scenario: a customer abandons a cart with two SKUs. Your push notification says “Your cart’s waiting—free shipping ends tonight.” If that tap lands on Home, you’ve basically thrown away the urgency. If it lands on /cart with the cart restored, you’re back in the purchase flow in one tap.

Step-by-Step Setup

You’re setting up two things in parallel: (1) OS-level deep link routing so links open your app reliably, and (2) SDK-level identity + event tracking so Customer.io can orchestrate follow-ups based on real behavior.

1. Choose a canonical deep link format your team will stick to
   • Pick a single pattern for retention links (example: https://shop.yourbrand.com/dl/cart or https://link.yourbrand.com/cart).
   • Define destinations you’ll actually use in retention: cart, PDP, collection, reorder, subscription portal, loyalty page.
   • Decide what context you’ll pass (e.g., product_id, variant_id, discount_code, subscription_id).
2. Implement Universal Links (iOS) / App Links (Android)
   • iOS: set up Associated Domains and host the apple-app-site-association file for your link domain.
   • Android: set up intent filters and host the assetlinks.json file for your link domain.
   • Keep a fallback strategy: if the app isn’t installed, route to a mobile web page that mirrors the destination (cart/PDP) and prompts install.
3. Install and initialize the Customer.io SDK (mobile)
   • Initialize the SDK at app start so opens, push interactions, and in-app events are captured consistently.
   • Confirm you’re using the right environment keys (dev vs prod). In practice, mismatched keys are a top reason “it works on my phone” but not in production reporting.
4. Get identity right: call identify at the moment of truth
   • Call identify(userId) immediately after login/account creation.
   • If you support logout, call the SDK reset/clear method so the next user on a shared device doesn’t inherit the prior identity.
   • Pass stable identifiers (your internal customer ID). Email/phone can be attributes, but don’t treat them as the primary key unless your whole stack is built that way.
5. Track the events that prove the deep link worked
   • At minimum, track: Deep Link Opened (with destination), Viewed Product, Added to Cart, Checkout Started, Order Completed.
   • Include properties that let you segment and troubleshoot: campaign_id (if you pass it), message_id, destination, product_id, cart_value.
   • If you can’t pass Customer.io identifiers through the URL safely, don’t force it—use destination-level events to validate routing and let Customer.io handle click tracking on its side.
6. Route the deep link inside the app and handle edge cases
   • If the user is logged out and the destination requires auth (cart, subscription), store the intended destination and send them to login first. After login, route them to the original destination.
   • If the product is unavailable, route to the closest alternative (collection or back-in-stock signup) and track Deep Link Fallback.
7. QA with real devices and real message sends
   • Test iOS + Android with the app installed and uninstalled.
   • Test from each channel you’ll use (push, SMS, email). Some apps handle push deep links differently than browser clicks.
   • Validate that the profile in Customer.io shows the expected event trail after the click (opened → viewed → cart/checkout).

When Should You Use This Feature

Deep links matter most when your message is trying to collapse time-to-value. If the customer has to hunt for the thing you promised, you’ll watch clicks die in-session.

• Cart recovery: send them straight to a restored cart, not the home page.
• Browse abandonment: route to the exact PDP (and variant) they viewed, especially for replenishable or high-consideration products.
• Repeat purchase: route to a “reorder” screen or a pre-filled cart with last order items.
• Reactivation: route to a personalized collection (“Back in stock in your size”) rather than a generic landing page.
• Subscription saves: route to subscription management with the relevant SKU selected (skip the support-ticket loop).

Operational Considerations

Once deep links are live, the hard part becomes operational: keeping segmentation clean, ensuring data arrives in the right order, and making sure journeys don’t misfire because identity wasn’t resolved yet.

• Segmentation depends on event hygiene: if you’re triggering “Cart Recovery” off Checkout Started, but your deep link drops them on Home and they never re-hit checkout, you’ll undercount recovery and over-send reminders.
• Identity stitching timing: clicks can happen before login. Build journeys that wait for an identify moment (or a “Logged In” event) before sending the next step, otherwise you’ll message the wrong profile or miss the user entirely.
• Cross-device reality: a customer might click SMS on their laptop (web) but purchase in-app later. Decide which events are “source of truth” for conversion and make sure both web + app send consistent event names/properties.
• Orchestration and suppression: once deep links increase conversion velocity, you need tighter suppression rules (e.g., suppress cart reminders the moment Order Completed fires, not 2 hours later).
• Link governance: keep a registry of destinations and required params. In practice, ad-hoc deep links from creative teams create silent routing failures.

Implementation Checklist

If you want this to work under real-world conditions (multiple channels, logged-out states, multiple devices), treat this like a small product feature with QA and monitoring.

• Universal Links (iOS) and App Links (Android) configured and verified on production domains
• Fallback behavior defined for “app not installed” and “user logged out”
• Customer.io SDK installed, initialized, and using correct prod keys
• identify called on login/signup; reset/clear identity on logout
• Core events tracked: Deep Link Opened, Viewed Product, Added to Cart, Checkout Started, Order Completed
• Event properties standardized (destination, product_id, cart_value, etc.)
• Customer.io segments/journeys updated to use the new events and suppressions
• Device + channel QA completed (push, SMS, email; installed/uninstalled)

Expert Implementation Tips

Most teams get deep links “working,” then lose performance because they don’t instrument the last 10%: attribution, edge cases, and consistency across platforms.

• Track a dedicated deep link event: fire Deep Link Opened with destination and source_channel. It becomes your early warning system when routing breaks after an app release.
• Use destination-based branching in journeys: if the deep link was /cart, your next message should reference cart value/items; if it was /product, talk about that SKU and social proof.
• Delay follow-ups until the app has a chance to load: for push → app open flows, a short “wait until event” (e.g., Viewed Product within 10 minutes) prevents premature reminders.
• Make logged-out handling intentional: store the intended destination locally and route post-login. Without this, your “cart recovery” deep link becomes a login prompt that kills conversion.
• Keep naming consistent across app and web: if app tracks Added To Cart but web tracks add_to_cart, segmentation gets messy fast and suppression fails.

Common Mistakes to Avoid

These are the issues that show up after you scale sends—when a small percentage of failures becomes thousands of broken sessions.

• Routing everything to Home: it “opens the app,” but it doesn’t recover revenue. Deep link destinations should map to purchase intent.
• Not handling logged-out users: sending a cart deep link without post-login routing creates a dead end.
• Skipping identity reset on logout: shared devices (tablets, family phones) will contaminate profiles and ruin personalization.
• No monitoring after app releases: a single change in route names can break every retention message. If you don’t track Deep Link Fallback, you won’t notice quickly.
• Inconsistent event schemas: if iOS and Android send different properties, you’ll end up building platform-specific segments and doubling ops work.

Summary

Deep links are a retention lever when they land customers back into the exact step that converts—cart, PDP, reorder, or subscription management. The SDK work that matters most is identity stitching and event proof that the route actually happened. If you can’t measure it cleanly, you can’t optimize it.

Implement Deep Links with Propel

If you’re already running retention through Customer.io, deep links are one of the highest-ROI fixes because they improve every click-heavy flow (cart recovery, winback, replenishment) without adding more send volume. When teams want a second set of eyes on SDK identity stitching, event schemas, and journey suppression logic, book a strategy call—we’ll walk through your current routing and show you where it’ll break at scale.