Update to version 3.4 (Mobile SDK) for retention-ready tracking

Overview

If your app events are even slightly off, your retention automations will quietly underperform—cart recovery won’t trigger, browse follow-ups fire late, and repeat purchase nudges hit the wrong person. Updating your mobile SDK to v3.4 is mostly about tightening the data contract between your app and Customer.io, so identity stitching and event timing stay reliable when you scale.

If you want a second set of eyes on your tracking plan (especially around anonymous-to-known merges and purchase attribution), book a strategy call and we’ll pressure-test it like we would for a live retention program.

How It Works

In practice, the SDK update matters because your app is the source of truth for the moments that drive revenue: product views, add-to-cart, checkout start, and purchase. v3.4 keeps the same core model—identify a person, attach a device, and send events—but the real win is consistency: the same user should look like one user across sessions, devices, and “anonymous browsing → logged in → purchased” flows.

• Installation/upgrade: You update the iOS/Android (or React Native/Flutter wrapper) dependency to the v3.4 SDK package so the app can send events and manage device tokens for push.
• Identity: The SDK maintains an anonymous profile until you call identify(). Once you identify, events should attach to the known profile going forward. This is the single biggest lever for accurate cart recovery and post-purchase flows.
• Event tracking: You send named events (e.g., product_viewed, added_to_cart, checkout_started, order_completed) with properties. Those properties become segmentation and branching inputs inside Customer.io campaigns.
• Device + push: The SDK links the device token to the person so push can be targeted correctly. If identity is wrong, push goes to the wrong profile or gets suppressed.

Real D2C scenario: A shopper opens your app from an Instagram ad, views two products, adds one to cart, then creates an account at checkout. If you don’t handle the anonymous → identified transition cleanly, the “cart abandon” push/email can fire to the anonymous profile (which has no email) and your recovery rate tanks—even though the user did everything “right.”

Step-by-Step Setup

Don’t treat this like a version bump. Treat it like a tracking release: upgrade, validate identity, validate events, then only after that touch your automations. That sequencing avoids the common trap where marketing “fixes” a journey when the real issue is app instrumentation.

1. Upgrade the SDK dependency to v3.4
   • Update your iOS dependency (SPM/CocoaPods) or Android dependency (Gradle/Maven) to the Customer.io SDK version 3.4.
   • If you’re on a wrapper (React Native/Flutter/Expo), confirm the wrapper version actually pulls in the native 3.4 SDKs—this is where mismatches happen.
2. Confirm initialization happens once, early
   • Initialize the SDK in the app entry point (AppDelegate/Application class) so early-session events don’t get dropped.
   • Avoid re-initializing on every screen—duplicate initialization is a quiet source of duplicated events and messy attribution.
3. Implement a strict identity rule with identify()
   • Call identify(customer_id) immediately after login/signup.
   • Use a stable internal ID (not email) as the primary identifier. Emails change; IDs shouldn’t.
   • When a user logs out, call the SDK’s reset/clear identity method (your exact method name depends on platform) so the next user on the device doesn’t inherit the prior user’s events.
4. Track the retention-critical commerce events
   • product_viewed with sku, product_id, category, price.
   • added_to_cart with sku, quantity, cart_id, value.
   • checkout_started with cart_id, value, item_count.
   • order_completed with order_id, revenue, currency, items.
5. Validate in a real device session (not just logs)
   • Run: anonymous browse → add to cart → login → purchase.
   • Confirm events land on the same person profile after identification.
   • Confirm the purchase event includes the properties your segmentation actually needs (revenue, SKU, etc.).
6. Only then: update/launch journeys that depend on these events
   • Cart recovery, browse abandon, post-purchase cross-sell, replenishment, winback.
   • Re-check entry criteria and exit conditions using the new/verified event schema.

When Should You Use This Feature

SDK updates matter most when you’re using app behavior as a trigger—not just for “nice-to-have” personalization. If app events drive your revenue automations, you want v3.4 in place before you optimize creative or offers.

• Cart recovery on mobile: Trigger within minutes of added_to_cart or checkout_started, then suppress if order_completed arrives.
• Browse abandon/product discovery: Follow up when someone views 2–3 PDPs but doesn’t add to cart. This only works if product_viewed is clean and deduped.
• Post-purchase upsell: Use order_completed items to recommend complements (e.g., cleanser → moisturizer) and avoid recommending what they just bought.
• Reactivation: Combine “no purchase in 60 days” with “no app open in 14 days” to separate churned buyers from just-email-only customers.

Operational Considerations

This is where most retention programs break: the SDK is “installed,” events are “sending,” but segmentation and orchestration are built on shaky assumptions. Tighten these now and your campaigns stop leaking.

• Segmentation depends on stable properties: If you change product_id formats or sometimes send sku and sometimes don’t, your “viewed X but didn’t buy” segments will miss people.
• Event timing impacts recovery: Mobile events can arrive late on poor networks. For cart recovery, build a short delay buffer (e.g., 10–20 minutes) and rely on exit conditions (purchase) rather than assuming perfect ordering.
• Identity stitching is the real unlock: Anonymous browsing is common in D2C apps. If you only identify on purchase confirmation, you’ll lose the entire pre-purchase intent trail for personalization and recovery.
• Cross-channel orchestration: If email is triggered off app events, make sure the identified profile actually has an email attribute at the time the journey evaluates. Otherwise you’ll see “entered journey, no message sent” and think deliverability is the issue.
• Deduplication strategy: If your app can fire order_completed multiple times (retry logic, app relaunch), you need an idempotency key like order_id and segmentation logic that treats duplicates safely.

Implementation Checklist

Use this like a pre-flight before you declare the update “done.” Most teams ship the version bump and only notice weeks later that cart recovery volume dropped.

• SDK dependency updated to v3.4 across all platforms you ship
• SDK initialized once per app lifecycle (not per screen)
• identify() called on login/signup with a stable internal customer ID
• Logout clears identity/device association appropriately
• Core commerce events tracked with consistent names and property types
• Anonymous → identified flow validated end-to-end on a physical device
• Journeys updated to use exit conditions (purchase) and a small timing buffer
• Duplicates tested: purchase event won’t inflate revenue or trigger multiple post-purchase flows

Expert Implementation Tips

These are the small choices that compound into better repeat purchase and cleaner recovery performance.

• Identify earlier than you think: If you have “continue with email” or “save favorites,” identify at that moment. Waiting until purchase is leaving money on the table for browse/cart journeys.
• Standardize event naming across app + web: In most retention programs, you eventually want unified segments like “Added to cart in last 4 hours” regardless of platform. Keep names/properties aligned now to avoid a migration later.
• Send item arrays thoughtfully: For order_completed, include an items array with SKU and quantity. That unlocks suppression (“don’t recommend purchased SKU”) and smarter replenishment logic.
• Use a single source for revenue: If app sends estimated cart value but backend sends final revenue, decide which event is authoritative for LTV reporting and post-purchase branching.

Common Mistakes to Avoid

Most issues aren’t “SDK bugs.” They’re implementation gaps that show up as retention underperformance.

• Using email as the identifier: It works until it doesn’t—then you get duplicate profiles and broken attribution.
• Not clearing identity on logout: Shared devices and account switching will contaminate events, and your winback flows will target the wrong person.
• Tracking too late in the funnel: If you only track order_completed, you can’t run high-intent recovery (browse/cart) with confidence.
• Inconsistent property types: Sending price as a string sometimes and a number other times will break segments and comparisons.
• No dedupe on purchase: Duplicate purchase events trigger duplicate post-purchase messages and inflate “repeat purchase” metrics.

Summary

Updating to SDK v3.4 is worth doing when app events drive revenue automations. Get identity and core commerce events rock-solid first, then tune journeys—otherwise you’ll optimize messaging on top of bad data.

Implement Update To 3.4 with Propel

If you’re updating to v3.4 because you want better cart recovery and repeat purchase performance, treat the release like an instrumentation project—not a dependency bump. We’ll help you validate the anonymous-to-known path, event schema, and journey dependencies inside Customer.io so your segments and triggers hold up under real traffic.

If that’s useful, book a strategy call and we’ll map the minimum tracking changes needed to unlock the retention flows you actually care about.