Business Context

Uber’s Rider mobile app serves ~30M daily active riders globally. The iOS team shipped a major redesign (new home screen + heavier use of animations) in version v8.12. Within 72 hours, Customer Support tickets tagged “app slow / crashes” increased +18%, and App Store rating dropped from 4.8 → 4.6. Engineering suspects performance regressions—specifically execution speed, binary size, and memory usage—but leadership needs a clear, decision-ready view of what changed, where it changed, and whether to roll forward, hotfix, or roll back.

You are the analytics lead embedded with Mobile Platform. Your job is to define the KPI framework for app performance, specify how you would visualize it for different stakeholders (engineers vs product vs execs), and design a diagnostic approach that connects metric movement to user impact.

Metric Scenario

• After release v8.12, median cold start time worsened, but only on some devices.
• The binary size increased, but download conversion didn’t obviously change—yet.
• Memory usage appears higher during map interactions, and crash-free sessions dipped slightly.

Stakeholders:

• Mobile engineers want actionable breakdowns (which screens, which devices, which build).
• Product wants to understand user impact (do riders abandon booking?).
• Execs want a single dashboard that answers: “Are we within performance SLOs? If not, what’s the business risk?”

Available Data

Your Task (what you must produce)

1. Define the core performance KPIs you would track for this release (execution speed, binary size, memory), including:

   • exact definitions (e.g., cold start p50 vs p90)
   • inclusion/exclusion rules (background starts, prewarmed sessions, etc.)
   • why each KPI matters to riders and to the business

2. Propose a visualization toolkit and dashboard design that would work for:

   • real-time engineering triage (minutes-hours)
   • weekly product review (days)
   • executive health reporting (weeks) Include which tools you’d use (e.g., Grafana/Looker/Tableau/Datadog/Perfetto/BigQuery + custom) and why.

3. Decompose the regressions into actionable drivers. Specify the exact cuts you’d include (device tier, OS, geography, screen, start type, feature flag, etc.) and how those would appear in charts.

4. Connect performance to user outcomes: propose a funnel or causal chain from performance → behavior (e.g., booking conversion, session abandonment, crash rate). Identify leading indicators and guardrails.

5. Decision framework: define thresholds/SLOs and a rule for when you would recommend hotfix vs rollback vs continue rollout.

Constraints:

• You have 1 week to ship a dashboard used in the next release go/no-go.
• Data latency: product analytics tables are daily; engineering telemetry is near-real-time.
• Must support segmentation down to device model and app version without exposing PII.