Screen tracking (screen events) with Customer.io SDKs

Overview

If you’re serious about retention on mobile, screen tracking is one of the fastest ways to make Customer.io behave like a real-time behavioral engine instead of a batch email tool—because it tells you what customers actually looked at, in order, on the device. If you want help designing the event taxonomy and tying it to revenue outcomes (cart recovery, replenishment, winback), book a strategy call and we’ll pressure-test your tracking plan before you ship it.

In most D2C apps, “screen viewed” data ends up being the backbone for product discovery flows (PDP views), checkout rescue (cart/checkout screens), and reactivation (high-intent browsing without purchase). The win is simple: you stop guessing intent and start messaging off the last thing they did.

How It Works

Screen tracking is just event tracking with one important difference: you’re standardizing a specific class of events (screen views) so they’re consistent enough to segment and orchestrate against. On the app side, you send a screen event whenever the user lands on a meaningful screen—home, collection, PDP, cart, checkout, order confirmation, account, etc.

• Anonymous first, identified later: A lot of mobile traffic starts anonymous. The SDK can track screen events immediately, then you stitch that activity to a known person when you call identify after login, account creation, or email capture.
• Identity stitching is the retention unlock: If you don’t merge anonymous screen history into the known profile, your “viewed PDP → didn’t buy” segments will be incomplete and your cart recovery will underperform.
• Screen event payloads matter: Don’t just send screen_name. Attach the context you’ll need later—product_id, variant_id, collection, price, currency, cart_value, etc. In practice, this tends to break when teams rely on URLs or UI labels that change every release.
• Customer.io uses events to build segments and trigger campaigns: Once the events land, you can build segments like “Viewed Checkout screen in last 2 hours AND no Purchase event” and trigger push/SMS/email accordingly.

Step-by-Step Setup

The goal here is to get clean, stable screen events flowing from your app into Customer.io, tied to the right person, and usable for segmentation without rewriting everything in 30 days. Start small (core commerce screens), validate identity stitching, then expand coverage.

1. Install the Customer.io SDK for your platform
   Add the iOS/Android/React Native/Flutter SDK and confirm you can see basic activity land in Customer.io. Don’t move on until you’ve validated events show up for test devices.
2. Decide your screen naming convention (before engineering ships)
   Use a stable, human-readable key like screen_name = ProductDetail (not a localized title like “Shop” / “Comprar”). Keep it consistent across iOS and Android.
3. Instrument screen events in your navigation layer
   Fire an event on screen impression (not on render retries). Common pattern:
   • Event name: Screen Viewed (or screen_viewed)
   • Properties: screen_name, plus context (see next step)
4. Add the commerce context you’ll actually need for retention
   For a PDP screen, include product_id, sku, variant_id, category, price, and in_stock. For cart/checkout screens, include cart_value, item_count, and ideally cart_id.
5. Call identify as soon as you have a durable identifier
   Do this at login, account creation, and email/SMS capture. Pass your canonical customer ID and set key attributes (email/phone, timezone if you have it). If you wait until after purchase, you’ll lose most pre-purchase intent.
6. Validate anonymous-to-known stitching
   Test flow: open app anonymously → view PDP → view cart → then log in. Confirm those earlier screen events appear on the identified profile in Customer.io.
7. Create 2–3 “money segments” right away
   Examples:
   • Viewed Checkout screen in last 1 hour AND no Purchase event
   • Viewed ProductDetail with product_id X in last 24 hours AND no Add to Cart
   • Viewed any PDP 3+ times in 7 days AND no purchase in 30 days

When Should You Use This Feature

Screen events shine when you need high-signal intent without waiting for a hard conversion event. If your retention program relies on “last purchase date” only, you’ll miss the window where customers are browsing and persuadable.

• Cart and checkout recovery on mobile: If someone hits Cart or Checkout screens but doesn’t purchase, you can trigger a push within minutes (and escalate to SMS/email later).
• Product discovery → PDP follow-up: If someone views a PDP twice but never adds to cart, you can send a “need help choosing?” message, a review snippet, or a comparison guide.
• Reactivation based on browsing, not opens: If an “inactive” customer suddenly browses a collection screen, that’s a reactivation moment—treat it like intent, not noise.
• Repeat purchase timing: For replenishable products, watching customers revisit Order History or ProductDetail for their last purchased SKU is often the earliest repeat-purchase signal.

Real D2C scenario: A skincare brand sees a customer view ProductDetail for “Vitamin C Serum” twice, then hits Cart but bounces on Checkout. With screen tracking, you trigger a push 15 minutes later (“Still thinking about Vitamin C? Here’s how to layer it.”), then an SMS 4 hours later if no purchase, and suppress both if a Purchase event comes in.

Operational Considerations

Screen tracking is easy to ship and easy to mess up. The operational work is making sure the data is segmentable, deduped, and orchestrated cleanly across channels without spamming customers.

• Segmentation hygiene: Build segments off stable keys (like screen_name and product_id), not UI labels or URLs that change. If the same screen is named PDP on iOS and ProductDetail on Android, your segments will silently undercount.
• Event volume and noise: Don’t track every modal and micro-step. Track “decision screens” that correlate with revenue. Too many screen events makes it harder to debug and can inflate costs depending on your setup.
• Data flow timing: Mobile events can arrive late (offline mode, background restrictions). For cart recovery, use short waits plus a second check (e.g., “wait 20 minutes, then confirm no purchase”).
• Orchestration realities: If push and email both trigger off the same screen event, you need channel prioritization and suppression logic. In practice, this tends to break when each channel owner builds flows independently.
• Identity stitching edge cases: Users can log out, reinstall, or use multiple devices. Make sure your identify call always uses the same canonical customer ID so Customer.io doesn’t fragment profiles.

Implementation Checklist

Use this list to keep engineering and retention aligned. The goal is not “events exist,” it’s “events are usable for revenue-driving orchestration.”

• SDK installed and sending test events from all supported platforms
• Standardized screen_name list agreed across iOS/Android (and web if applicable)
• Screen Viewed event includes required properties (at minimum: screen_name)
• PDP screen events include product_id and variant_id (or SKU)
• Cart/Checkout screen events include cart_value and item_count
• identify implemented at login + email/phone capture (not just post-purchase)
• Anonymous activity successfully merges into identified profiles during testing
• At least 2 core segments built and validated against live profiles
• At least 1 triggered flow uses screen events with suppression on Purchase

Expert Implementation Tips

These are the small operator moves that keep screen tracking from becoming “data we collect but never use.”

• Create a “screen dictionary” doc: One row per screen: screen_name, when it fires, required properties, and owner. This prevents drift when the app UI evolves.
• Prefer app-level IDs over display names: Send product_id/variant_id and render names later in messages via your catalog or template logic. Names change; IDs don’t.
• Deduplicate on navigation events: Some frameworks fire multiple times during state changes. Add a lightweight guard (e.g., only fire when route actually changes) so you don’t trigger flows twice.
• Use screen events to power “intent scoring”: A simple score like PDP view (+1), Cart view (+3), Checkout view (+5) gives you a clean segment for “high intent, no purchase.”
• Build suppression first: Before you launch any screen-triggered campaign, add a purchase exit condition and a frequency cap. Screen data is high volume and will happily spam customers if you let it.

Common Mistakes to Avoid

Most failures aren’t technical—they’re taxonomy and identity problems that make the data impossible to use in Customer.io segments and flows.

• Tracking screens but not calling identify early enough: You end up with lots of anonymous intent that never ties to an email/phone, so your recovery flows can’t reach anyone.
• Inconsistent screen names across platforms: Your segments undercount and your reporting looks “fine” until you compare to analytics.
• No properties beyond screen_name: You can’t personalize or target (e.g., “which product did they view?”), so the messages stay generic and conversion stays low.
• Firing events on every render: This creates duplicate triggers, inflated event volume, and messy customer timelines.
• Launching flows without orchestration: Push + SMS + email all firing from the same behavior is how you burn opt-ins fast—especially during cart/checkout recovery.

Summary

If you want retention flows that react to intent, screen tracking is the cleanest SDK-level signal to start with. Get naming consistent, stitch identity early, and only track screens that map to revenue decisions. Once that’s in place, your cart recovery and reactivation campaigns stop feeling like guesswork.

Implement Screen Events with Propel

If you’re already running Customer.io, the highest-leverage move is usually not “track more,” it’s “track the right screens with the right properties and stitching,” then wire that into a tight orchestration plan (push first, then SMS/email with smart suppression). If you want a second set of operator eyes on your SDK plan and the downstream segments/flows, book a strategy call and we’ll map screen events to the exact recovery and repeat-purchase plays you’re trying to run.