Docs

iOS Live Activities: The Engagement Data Most Apps Skip

Live Activities now reach the vast majority of iPhones, but most apps ship them without tracking start rate, tap-through, or how long they survive.

Engagement

Live Activities — the persistent, glanceable widgets that sit on the Lock Screen and in the Dynamic Island for things like delivery tracking, live scores, or ride status — are no longer a niche feature. With most active iPhones now on an iOS version that supports them, they’re a mainstream engagement surface for any app with a real-time or ongoing status to show. They’re also one of the least instrumented parts of most apps’ analytics. It’s common to see a team ship a Live Activity, confirm it renders correctly on a test device, and move on without ever wiring up tracking for whether users actually interact with it, ignore it, or end it early.

That gap matters because a Live Activity behaves nothing like a normal in-app screen. It runs outside your app’s process, can be dismissed or expire without the user ever reopening the app, and its value proposition is being seen and acted on without a full app launch. If you’re only counting sessions and screen views, a Live Activity driving real engagement — repeated Dynamic Island taps, faster reactions to a status change — looks invisible in your data, indistinguishable from one nobody notices at all.

Data Points to Track

  • Live Activity start rate, the share of eligible sessions or events (an order placed, a ride requested) that actually trigger a Live Activity, since a low start rate often points to a permissions or eligibility issue rather than a design problem
  • Tap-through from Lock Screen and Dynamic Island, tracked separately from each other, since the two surfaces have different visibility and interaction patterns and users may favour one over the other
  • Update delivery success and latency, measuring whether push-driven Live Activity updates land promptly, since a stale Live Activity showing outdated status actively erodes trust in the feature
  • Dismissal vs. natural expiration, distinguishing a user manually ending a Live Activity early from one that simply reaches its end state, since early dismissal is a signal the activity stopped being useful before its content said it was done
  • Downstream app open rate following a Live Activity interaction, comparing users who tapped into the app from a Live Activity against those who opened it independently, to measure whether the Live Activity is a genuine re-engagement channel or a passive display only

Setup Steps

  1. Log a start event whenever ActivityKit successfully requests a Live Activity, including the triggering action and eligibility state, so a low start rate can be traced back to permission denial, feature flag state, or an eligibility check failing.
  2. Instrument tap targets on both the Lock Screen presentation and the Dynamic Island’s compact and expanded states separately, since ActivityKit deep links can be tagged with the specific surface the tap came from.
  3. Track every push-driven content update, timestamping both the send and the confirmed on-device render, to build a latency metric rather than assuming updates always arrive promptly.
  4. Capture the end reason (ActivityKit’s dismissal vs. expiration states) for every Live Activity that concludes, rather than only logging that it ended.
  5. Tag app-open events that originate from a Live Activity deep link distinctly from other open sources, so re-engagement value can be measured against notification-driven and organic opens on the same dashboard.

Actionable Insights

A high start rate paired with a low tap-through rate usually means the Live Activity’s glanceable content is already answering the user’s question — they don’t need to tap because the status update alone was enough, which is a sign the feature is working as intended rather than underperforming. A rising early-dismissal rate, especially concentrated around a specific update stage, points to the content becoming irrelevant or wrong at that stage — worth checking against update latency, since a stale Live Activity is a common cause of users dismissing it manually. And if app opens sourced from Live Activity taps show stronger downstream engagement than opens from push notifications for the same event type, that’s a case for prioritising Live Activities over traditional notifications for time-sensitive updates going forward, backed by a direct engagement comparison rather than assumption.

Expert help

Need help tracking this in your app?

Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.

Talk to an expert