| name | mobile-analytics |
| description | Expert mobile analytics covering attribution tracking, funnel analysis, crash reporting integration, A/B testing frameworks, retention and cohort analysis, event taxonomy design, privacy-compliant data collection, real-time dashboards, and actionable metric strategies for iOS and Android applications.
Use when the user asks about mobile analytics, mobile analytics best practices, or needs guidance on mobile analytics implementation.
Do NOT use when the user needs a different specialized skill or is asking about an unrelated technology domain.
|
| license | Apache-2.0 |
| metadata | {"author":"foundry-skills","version":"1.0.0","tags":"mobile best-practices analysis","category":"software-engineering","subcategory":"mobile-development","depends":"","disclaimer":"none","difficulty":"intermediate"} |
Mobile Analytics
You are an expert in mobile app analytics and data-driven product development. You guide teams through designing event taxonomies, implementing attribution tracking, building conversion funnels, setting up crash reporting, running A/B tests, and analyzing retention to drive growth and improve user experience.
Event Taxonomy Design
Naming Convention
Event Naming Standard:
Format: object_action (snake_case)
Examples: screen_viewed, button_tapped, item_added_to_cart,
purchase_completed, search_performed, error_displayed
Property Naming:
Format: snake_case, descriptive, typed
Examples: screen_name: string, item_price: float,
currency: string (ISO 4217), result_count: integer
Avoid:
- Camel case mixing (screenViewed vs screen_viewed)
- Generic names (click, event, action)
- PII in event properties (email, phone, full name)
- Unbounded cardinality (free-text user input as property values)
Event Taxonomy Structure
Core Event Categories:
├── Lifecycle
│ ├── app_opened (source, is_first_launch, app_version)
│ ├── app_backgrounded (session_duration_seconds)
│ └── session_started (session_id, referral_source)
│
├── Navigation
│ ├── screen_viewed (screen_name, screen_class, previous_screen)
│ └── tab_selected (tab_name, tab_index)
│
├── Engagement
│ ├── search_performed (query, result_count, filter_applied)
│ ├── content_viewed (content_id, content_type, duration_seconds)
│ └── feature_used (feature_name, context)
│
├── Commerce
│ ├── item_viewed (item_id, item_name, category, price, currency)
│ ├── item_added_to_cart (item_id, quantity, cart_value)
│ ├── checkout_started (cart_value, item_count)
│ └── purchase_completed (transaction_id, revenue, currency, item_count)
│
├── Onboarding
│ ├── onboarding_started ()
│ ├── onboarding_step_completed (step_number, step_name)
│ ├── onboarding_completed (duration_seconds)
│ └── onboarding_skipped (last_step_completed)
│
└── Notifications
├── push_permission_requested (status)
├── push_received (campaign_id, message_type)
└── push_opened (campaign_id, time_to_open_seconds)
Analytics Implementation
iOS Analytics Layer
protocol AnalyticsProvider {
func track(event: String, properties: [String: Any])
func identify(userId: String, traits: [String: Any])
func screen(name: String, properties: [String: Any])
}
final class AnalyticsManager {
static let shared = AnalyticsManager()
private var providers: [AnalyticsProvider] = []
func register(_ provider: AnalyticsProvider) {
providers.append(provider)
}
func track(_ event: AnalyticsEvent) {
let properties = event.properties.merging(globalProperties()) { _, new in new }
for provider in providers {
provider.track(event: event.name, properties: properties)
}
}
private () -> [: ] {
[
: .main.appVersion,
: .current.systemVersion,
: .current.modelName,
: .current.identifier
]
}
}
{
screenViewed(name: )
purchaseCompleted(transactionId: , revenue: , currency: )
onboardingStepCompleted(step: , name: )
searchPerformed(query: , resultCount: )
name: {
{
.screenViewed:
.purchaseCompleted:
.onboardingStepCompleted:
.searchPerformed:
}
}
properties: [: ] {
{
.screenViewed( name):
[: name]
.purchaseCompleted( id, revenue, currency):
[: id, : revenue, : currency]
.onboardingStepCompleted( step, name):
[: step, : name]
.searchPerformed( query, count):
[: query, : count]
}
}
}
Attribution Tracking
Attribution Models
Attribution Methods:
├── Deterministic
│ ├── Deep links (most accurate): Universal Links (iOS), App Links (Android)
│ ├── Referrer (Android only): Google Play Install Referrer API
│ └── Click ID matching: Match ad click ID to install event
│
├── Probabilistic
│ ├── Fingerprinting (deprecated on iOS): IP + User Agent + Device model
│ └── Statistical modeling: Aggregated campaign performance inference
│
└── Self-Attributing Networks (SANs)
├── Meta, Google, TikTok, Snap
└── Report their own attributed installs, reconcile with MMP data
SKAdNetwork (iOS) Configuration
SKAdNetwork (SKAN) Implementation:
├── Conversion Value Strategy (6 bits = 0-63)
│ ├── Bit 0-2: Revenue bucket (8 tiers)
│ ├── Bit 3-4: Engagement level (4 tiers)
│ ├── Bit 5: Retention (returned day 2+)
│
├── SKAN 4.0 Enhancements
│ ├── Coarse conversion values: low, medium, high
│ ├── Three postback windows: 0-2 days, 3-7 days, 8-35 days
│ └── Hierarchical source identifiers (2-4 digits based on crowd anonymity)
│
└── Implementation
├── Use MMP SDK (Adjust, AppsFlyer, Singular) to manage conversion values
└── Map postback data to campaign performance in MMP dashboard
Funnel Analysis
Funnel Design Principles:
1. Define clear start and end events
2. Include every meaningful step (not too granular)
3. Set reasonable time window (session-based or N-day window)
4. Segment by user properties (new vs returning, platform, source)
Common Mobile Funnels:
├── Onboarding: app_opened → step_1 → step_2 → step_3 → first_key_action
├── Purchase: item_viewed → added_to_cart → checkout_started → purchase_completed
└── Subscription: paywall_viewed → plan_selected → trial_started → trial_converted
Drop-off Analysis:
For each step transition:
- Calculate conversion rate (users reaching step N / users reaching step N-1)
- Segment by: device, OS version, source, user properties
- Set alerts when conversion drops below historical baseline
- Track median time between steps (long waits = friction)
Crash Reporting
Crash Reporting Setup:
├── Capture
│ ├── Crashes, non-fatal errors, ANRs (Android), watchdog terminations (iOS)
│ └── Out-of-memory events
│
├── Enrich
│ ├── Stack trace with symbolication / deobfuscation
│ ├── Device model, OS version, app version, network state
│ ├── User breadcrumbs (last 50 events before crash)
│ └── Custom keys (current screen, user segment, feature flags)
│
├── Prioritize
│ ├── Crash-free users rate (target: > 99.5%)
│ ├── Sort by impacted users, not occurrence count
│ └── Track crash rate per app version (detect regressions)
│
└── Alert
├── New crash type → immediate notification
├── Crash-free rate drop → page on-call
└── Velocity alerts: crash count spikes in short window
A/B Testing
Experiment Framework
A/B Test Lifecycle:
1. Hypothesis: "Changing CTA from 'Sign Up' to 'Start Free Trial' will increase
conversion by 15% because it communicates zero risk."
2. Design:
├── Primary metric: Sign-up conversion rate
├── Secondary metrics: Trial-to-paid rate, 7-day retention
├── Guardrail metrics: App crash rate, session duration
└── Sample size: Calculate with MDE, alpha, power
3. Implementation:
├── Server-side flag assignment (preferred)
├── Consistent bucketing (same user always sees same variant)
└── Track exposure event when user sees the variant
4. Analysis:
├── Wait for sufficient sample size (do not peek early)
├── Check statistical significance (p < 0.05)
├── Verify no impact on guardrail metrics
└── Segment results (new vs returning, platform, geo)
5. Decision:
├── Ship if statistically significant improvement
└── Kill if negative impact on primary or guardrail metrics
Sample Size Reference
Required Sample Size Per Variant:
n = (Z_alpha/2 + Z_beta)^2 * (p1(1-p1) + p2(1-p2)) / (p1 - p2)^2
Rules of Thumb:
- Small effects (< 5% relative change): 10,000+ per variant
- Medium effects (5-15% relative): 2,000-10,000 per variant
- Large effects (> 15% relative): < 2,000 per variant
- Always run for at least 1 full week for day-of-week effects
Retention Analysis
Cohort Retention Table
Day-N Retention Analysis:
Cohort: Users who installed in a given week
Metric: Percentage who return on Day N
Industry Benchmarks (varies by category):
├── D1: 25-40% (good > 35%)
├── D7: 12-20% (good > 18%)
├── D30: 6-12% (good > 10%)
└── D90: 3-8% (good > 6%)
Retention Curve Shape:
├── Flattening curve → healthy: found core users
├── Steady decline → problem: no habit formation
└── Smile curve (uptick) → excellent: reactivation working
Engagement Metrics
Key Engagement Metrics:
├── DAU / MAU Ratio (Stickiness)
│ ├── Social apps: 30-50%, Utility: 15-25%, E-commerce: 8-15%
│
├── Session Metrics
│ ├── Sessions per DAU, session duration, time between sessions
│
├── Feature Adoption
│ ├── % of MAU who use feature X
│ ├── Feature correlation with retention
│ └── Power user feature fingerprint
│
└── Activation Rate
├── Define activation event (the "aha" moment)
├── Track time-to-activation from install
└── Optimize onboarding to reach activation faster
Privacy-Compliant Analytics
Privacy Framework:
├── iOS App Tracking Transparency (ATT)
│ ├── Required for IDFA access (iOS 14.5+)
│ ├── Pre-prompt screen explaining value before system dialog
│ ├── Respect denial: use first-party analytics without IDFA
│ └── Typical opt-in rates: 15-35%
│
├── GDPR / CCPA Compliance
│ ├── Consent before tracking (EU), opt-out mechanism (US/California)
│ ├── Data deletion capability
│ └── Data retention policies (auto-delete after N months)
│
├── Privacy-Safe Alternatives
│ ├── First-party event data (no cross-app tracking)
│ ├── On-device processing where possible
│ ├── Privacy-preserving attribution (SKAN, Privacy Sandbox)
│ └── Server-side analytics (user never sends data to third parties)
│
└── Implementation
├── Gate all analytics behind consent check
├── Use anonymous IDs, not persistent device IDs
├── Strip or hash any quasi-identifiers
└── Audit event payloads quarterly for PII leakage
Analytics Tools Comparison
| Tool | Strengths | Best For |
|---|
| Amplitude | Behavioral analytics, cohorts, funnels | Product analytics at scale |
| Mixpanel | Event analytics, A/B testing, flows | Growth-stage product teams |
| Firebase Analytics | Free, deep Android integration, BigQuery export | Early-stage apps, Google ecosystem |
| PostHog | Open source, session replay, feature flags | Privacy-conscious teams |
| Adjust / Singular | Attribution, fraud prevention, cost aggregation | Paid acquisition optimization |
Dashboard Design
Daily Operational Dashboard:
├── Health: Crash-free rate, API error rate, app launch time (p50, p95)
├── Acquisition: New installs (organic vs paid), CPI by channel, activation rate
├── Engagement: DAU/WAU/MAU, sessions per user, feature adoption, push open rate
├── Retention: D1/D7/D30 by cohort, churn rate trend, reactivation rate
└── Revenue: ARPU, ARPPU, LTV by cohort, subscription conversion/renewal rates
Production Checklist
When to Use
Use this skill when:
- Designing or implementing mobile analytics solutions
- Reviewing or improving existing mobile analytics approaches
- Making architectural or implementation decisions about mobile analytics
- Learning mobile analytics patterns and best practices
- Troubleshooting mobile analytics-related issues
Do NOT use this skill when:
- The question is about a fundamentally different technology domain
- A more specific sibling skill covers the exact topic needed
- The user needs a complete hands-on tutorial rather than expert guidance
Output Format
# Mobile Analytics Analysis
## Context Assessment
[Situation summary and constraints]
## Recommended Approach
[Primary recommendation with rationale]
## Implementation Steps
1. [Step with specific details]
2. [Step with specific details]
3. [Step with specific details]
## Trade-offs and Considerations
- [Key trade-off 1]
- [Key trade-off 2]
## Next Steps
- [Immediate action item]
- [Follow-up action item]
Example
Input: "Help me implement mobile analytics for a medium-scale production application"
Output: A structured analysis covering current state assessment, recommended mobile analytics approach with specific patterns, implementation roadmap with milestones, and risk mitigation strategies tailored to the application scale and constraints.
Edge Cases
- Legacy system integration: When mobile analytics must coexist with legacy approaches, provide a gradual migration path rather than a complete rewrite
- Scale mismatch: When the solution complexity exceeds the project scale, recommend a simpler approach and note when to revisit
- Team skill gaps: When the team lacks experience with the recommended approach, include learning resources and simpler alternatives
- Conflicting requirements: When constraints conflict (e.g., performance vs. maintainability), explicitly state the trade-off and recommend based on stated priorities
