Mobile product analytics

Mobile products add lifecycle constraints that web dashboards can hide: applications background and terminate, devices go offline, releases roll out through app stores, permissions can be denied, and a crash may prevent the final event from being delivered.

This recipe defines the analytical model and dashboards. Use Native mobile instrumentation for iOS, Android, and React Native delivery patterns.

Define portable identity#

Keep separate:

An installation is not a person. Reinstalling may create a new installation, one person may use several devices, and one shared device may serve several people.

Do not use advertising IDs, hardware serials, or unstable device fingerprints as general product identity.

Use one mobile context#

Attach a bounded context to meaningful events:

{
  "event": "report_shared",
  "event_id": "evt_mobile_01J...",
  "installation_id": "install_782",
  "session_id": "session_204",
  "user_id": "usr_91",
  "account_id": "acct_42",
  "platform": "ios",
  "app_version": "8.14.0",
  "build_number": "81403",
  "os_version_major": "19",
  "device_class": "phone",
  "network_class": "wifi",
  "release_channel": "production",
  "schema_version": 1
}

Prefer major OS version and a small device class over a highly identifying hardware profile. Attach values as they were at event time.

Model first observation honestly#

An analytics client rarely knows with certainty that an operating-system installation just occurred. Emit:

{
  "event": "installation_first_observed",
  "installation_id": "install_782",
  "platform": "ios",
  "app_version": "8.14.0",
  "schema_version": 1
}

Call it first observed, not guaranteed install. Reinstallation, restored backups, storage clearing, and identifier migration can create another first observation.

For authoritative acquisition or store-install reporting, reconcile with the app-store or campaign provider and preserve its attribution boundaries.

Define the mobile activation journey#

Example:

installation first observed
  → onboarding started
  → permission decision
  → account linked
  → first value completed
  → second active week

Choose milestones that represent product value, not merely screen views. Store onboarding version and platform so the funnel remains reproducible.

{
  "event": "mobile_first_value_completed",
  "event_id": "evt_value_01J...",
  "installation_id": "install_782",
  "user_id": "usr_91",
  "account_id": "acct_42",
  "value_type": "first_report_shared",
  "onboarding_version": "mobile-v6",
  "app_version": "8.14.0",
  "schema_version": 1
}

Measure permission prompts as product decisions#

For notifications, location, photos, camera, or tracking:

{
  "event": "mobile_permission_resolved",
  "event_id": "evt_permission_01J...",
  "installation_id": "install_782",
  "permission": "notifications",
  "decision": "denied",
  "prompt_context": "after_first_saved_report",
  "prompt_version": "notifications-v3",
  "platform": "ios",
  "schema_version": 1
}

Do not repeatedly prompt merely to improve an analytics rate. Track:

• eligible prompt opportunities
• prompt shown
• allowed, denied, limited, or not determined
• later settings change when observable legitimately
• downstream product value

Operating-system behavior differs by platform and version. Keep taxonomy and test fixtures current.

Define foreground sessions#

Use lifecycle callbacks:

foreground begins
  → meaningful activity
  → background or bounded inactivity
  → session ends

Do not rely on a termination event; mobile operating systems may stop the process without giving the application time to send. Persist the session locally and close or bound it on the next launch when necessary.

Follow Sessionization and engaged-time measurement for heartbeat, inactivity, and identity rules.

Measure release adoption#

Every event should carry app version and build number. Report:

• active installations by version
• active users and accounts by version
• days from store release to 50%, 90%, and 95% active adoption
• crash, failure, and latency outcomes by version
• activation and retention by first version
• users blocked by minimum supported version

An app-store release date is not universal exposure. Store review, staged rollout, automatic updates, device compatibility, and user choice all affect adoption.

SELECT
  JSONExtractString(json, 'app_version') AS app_version,
  uniqExact(JSONExtractString(json, 'installation_id')) AS active_installations,
  uniqExact(JSONExtractString(json, 'user_id')) AS active_users
FROM mobile_events
WHERE
  timestamp >= now() - INTERVAL 7 DAY
  AND JSONExtractString(json, 'release_channel') = 'production'
GROUP BY app_version
ORDER BY active_installations DESC

Treat crashes and application exits carefully#

An event pipeline running inside the crashing process may lose the crash event. Use a mobile crash-reporting or observability system for diagnostic evidence and authoritative crash-free metrics.

GraphJSON can receive:

• compact crash-provider exports
• next-launch detection that the prior session ended unexpectedly
• release-level crash-free aggregates
• product outcomes joined to safe crash or error context

Do not send stack traces, memory dumps, user input, or complete device state without a separate security and privacy review.

Monitor offline delivery#

Persist important events before transmission and record:

• queued event count
• oldest queued event age
• accepted, retried, and quarantined batches
• event occurrence to acceptance delay
• permanent rejection reason

Do not attach current app or account state when replaying an old event. Preserve the event-time context captured when the action occurred.

Segment product metrics by delay when late arrival could change a decision.

Connect notifications to mobile outcomes#

Separate:

notification eligible
notification requested
provider accepted
device delivery signal where available
opened
product outcome

Notification opens are not the final product value. Use Email, push, and notification analytics for provider and consent boundaries.

Measure durable mobile engagement#

Recommended measures:

• activation by platform and onboarding version
• time to first mobile value
• active users and accounts
• engaged sessions and meaningful actions per active entity
• return interval and retention
• feature breadth and repeat value
• permission coverage
• version adoption
• crash-free or failure outcomes
• offline queue health

Do not optimize raw session count when the product's natural cadence is weekly or task-based.

Build the dashboard#

1. first-observed installations and identified activation
2. onboarding and first-value funnel
3. retention and return interval
4. platform, app-version, and build adoption
5. permission funnel
6. reliability and crash-provider outcomes
7. offline delivery health
8. notification-assisted outcomes
9. instrumentation completeness by platform

Launch checklist#

• Installation, anonymous, user, account, session, and event IDs are distinct.
• Device context is bounded and privacy-reviewed.
• “First observed” is not mislabeled as authoritative install.
• Activation represents product value.
• Permission opportunities and decisions use platform-aware taxonomies.
• Sessions do not depend on a guaranteed termination callback.
• App version and build number travel with every meaningful event.
• Crash diagnostics remain in a specialized system.
• Important events persist through offline operation.
• Replayed events preserve occurrence time and event-time context.
• Notification opens are connected to later product outcomes.
• Mobile dashboards reconcile with store and observability sources where needed.