Mobile Analytics & Crash Reporting Expert
Expert in mobile analytics instrumentation, crash reporting with symbolication, and actionable event tracking across iOS and Android.
Decision Points
Stack Selection Decision Tree
High crash volume (>1000/day) OR complex error debugging needed?
├─ YES: Choose Sentry
│ ├─ Need user sessions? → Add Sentry Session Replay
│ └─ Enterprise budget? → Consider Bugsnag for enterprise features
│
└─ NO: Evaluate based on primary use case
├─ Need product analytics + basic crashes? → Firebase (free tier generous)
├─ Advanced funnel analysis required? → Mixpanel + Crashlytics
└─ Real-time user behavior insights? → Amplitude + Sentry
Budget considerations:
├─ <$50/month: Firebase Analytics + Crashlytics
├─ $50-500/month: Sentry Team + basic product analytics
└─ $500+/month: Full stack (Sentry + Mixpanel/Amplitude)
Sample Rate Tuning
Production traffic volume:
├─ <1K daily sessions:
│ ├─ Crash sampling: 100%
│ ├─ Transaction tracing: 50%
│ └─ Session replay: 25%
│
├─ 1K-10K daily sessions:
│ ├─ Crash sampling: 100%
│ ├─ Transaction tracing: 20%
│ └─ Session replay: 10%
│
└─ >10K daily sessions:
├─ Crash sampling: 100% (never sample crashes)
├─ Transaction tracing: 5-10%
└─ Session replay: 1-5%
Cost optimization triggers:
├─ Monthly bill >$200 → Reduce transaction sampling by 50%
├─ Storage quota exceeded → Lower session replay rate
└─ Performance impact detected → Disable replay in low-memory scenarios
Error Volume Handling
Incoming crash rate assessment:
├─ <0.1% of sessions → Normal monitoring, weekly review
├─ 0.1-1% of sessions → Daily triage, investigate top 3 crashes
├─ 1-5% of sessions → Emergency mode: stop releases, hotfix priority
└─ >5% of sessions → App store removal risk, immediate rollback
Symbolication status check:
├─ Symbolicated within 5 minutes → Continue normal flow
├─ Pending 5-30 minutes → Check CI upload job status
└─ Missing after 30 minutes → Manual dSYM/mapping upload required
Failure Modes
1. "Symbol Upload Amnesia"
Detection: Stack traces show memory addresses (0x1a2b3c4d) instead of function names Diagnosis: dSYM/ProGuard mapping upload failed or incomplete Fix:
- Check CI upload job logs for failures
- Manually upload:
sentry-cli upload-dif --org X --project Y ./dSYMs/ - Verify upload:
sentry-cli releases files <version> list
2. "PII Leak Catastrophe"
Detection: Analytics events contain email addresses, phone numbers, or names in Sentry dashboard Diagnosis: Missing or broken data scrubbing rules Fix:
- Implement
beforeSendhook to strip sensitive fields - Add server-side data scrubbing rules in Sentry settings
- Audit recent events and purge PII data
3. "Development Data Pollution"
Detection: Sentry shows crashes from simulator/emulator or local dev builds Diagnosis: Analytics initialized in development environment Fix:
- Gate initialization:
if (!__DEV__) Sentry.init(...) - Use separate dev DSN or disable entirely
- Filter development events in dashboard
4. "Crash Rate Blindness"
Detection: No alerts triggered despite user complaints about app crashes Diagnosis: Missing crash-free rate monitoring or misconfigured thresholds Fix:
- Set up Sentry alert rule: crash-free rate drops below 99.5%
- Configure daily/weekly crash summary reports
- Add crash-free rate to primary dashboard
5. "Sample Rate Death Spiral"
Detection: Analytics bill spikes unexpectedly or performance degrades Diagnosis: Sample rates too high for actual traffic volume Fix:
- Reduce transaction sampling to 10% of current rate
- Lower session replay to 5% or disable temporarily
- Implement dynamic sampling based on user tier/feature flags
Worked Examples
Example 1: High Crash Volume Response (iOS Production App)
Scenario: iOS app crash-free rate drops from 99.6% to 97.2% over 24 hours
Step 1 - Rapid Assessment:
Check Sentry dashboard:
- 847 new crashes in last 24h (was 45 average)
- Top crash: EXC_BAD_ACCESS in PaymentViewController
- Affected: iOS 17.1+ users (67% of crash volume)
- Release: v2.1.4 (deployed 18 hours ago)
Step 2 - Decision Tree Navigation:
- Crash rate >1% → Emergency mode activated
- Symbolicated traces available → Continue investigation
- Single method concentrated (PaymentViewController) → Code change likely cause
Step 3 - Root Cause Analysis:
Stack trace shows:
PaymentViewController.processPayment()
└─ crashes on line 142: cardNumber.formatWithSpaces()
Git blame reveals: v2.1.4 added cardNumber nil check removal
"Optimization" introduced force unwrapping
Step 4 - Immediate Actions:
- Rollback v2.1.4 to v2.1.3 via App Store Connect
- Hotfix branch created with proper nil checking
- Alert stakeholders: "Payment crashes resolved, hotfix deploying in 2 hours"
Expert vs. Novice:
- Novice: Waits for crash reports to accumulate, manually investigates each crash
- Expert: Triggers emergency protocol at 1% threshold, immediately correlates with recent release
Example 2: Symbolication Recovery Process
Scenario: React Native Android app showing obfuscated crash traces after R8 enabled
Problem Detection:
Sentry crash report shows:
com.example.a.b.c.a() (Unknown Source)
com.example.d.e.f.b() (Unknown Source)
Instead of readable class/method names
Decision Process:
- Symbolicated? NO → Check mapping upload
- R8 enabled recently? YES → ProGuard mapping issue
- CI job status? FAILED → Manual upload required
Recovery Steps:
# 1. Locate mapping file in build artifacts
find ./android/app/build -name "mapping.txt"
# 2. Upload mapping for specific release
sentry-cli upload-proguard \
--org mycompany \
--project mobile-app \
--release 2.1.5 \
./android/app/build/outputs/mapping/release/mapping.txt
# 3. Verify upload
sentry-cli releases files 2.1.5 list | grep mapping.txt
# 4. Reprocess existing crashes
sentry-cli issues reprocess --query "release:2.1.5"
Prevention Setup:
- Add CI step to auto-upload mapping files
- Monitor symbolication status in Sentry webhook
- Set up alert for unsymbolicated crashes >10 per hour
Quality Gates
Analytics Implementation Validation:
- Crash reporting initializes before any user code execution
- dSYM upload automated in iOS CI pipeline with verification step
- ProGuard/R8 mapping upload automated in Android CI with success check
- Source maps uploaded for React Native releases with version tagging
- PII scrubbing verified: no email/phone/name fields in last 100 events
- Crash-free rate monitoring configured with 99.5% threshold alert
- Development builds excluded from production analytics data
- Event taxonomy documented with object_action naming convention
- Session replay enabled for error sessions only (not all sessions)
- Sample rates configured appropriately for current traffic volume
- Legal compliance verified: user consent obtained before tracking
- Performance impact measured: <50ms startup overhead
- Symbolication tested: can resolve production crashes to source lines
- Dashboard access granted to relevant team members with proper permissions
NOT-FOR Boundaries
This skill handles: Mobile app analytics, crash reporting, symbolication, session tracking, conversion funnels
Delegate elsewhere:
- Server-side logging/monitoring → Use
log-aggregation-architect - Web application analytics → Use
frontend-architect - A/B testing frameworks → Use
environment-config-manager - App store optimization (ASO) → Use
app-store-submission-automator - Backend API performance monitoring → Use
logging-observability - Database query analytics → Use
database-architect - Infrastructure cost optimization → Use
cloud-cost-optimizer
Boundary cases:
- Mobile backend services logging → Split: mobile events stay here, server logs go to
log-aggregation-architect - React Native web builds → If primarily mobile app, handle here; if web-focused, delegate to
frontend-architect