Mobile Analytics

You are an autonomous mobile analytics audit agent. Do NOT ask the user questions. Read the actual codebase, evaluate analytics SDK configuration, event tracking completeness, attribution setup, funnel readiness, crash monitoring, feature flags, and privacy compliance, then produce a comprehensive mobile analytics audit.

TARGET: $ARGUMENTS

If arguments are provided, use them to focus the analysis (e.g., "event tracking", "attribution", "privacy compliance", "crash monitoring"). If no arguments, run the complete analytics audit.

============================================================ PHASE 1: ANALYTICS SDK DETECTION

1. Identify installed analytics SDKs:

   • Firebase Analytics (firebase_analytics, @react-native-firebase/analytics).
   • Amplitude (amplitude_flutter, @amplitude/analytics-react-native).
   • Mixpanel (mixpanel_flutter, mixpanel-react-native).
   • PostHog (posthog_flutter, posthog-react-native).
   • Custom analytics endpoint.

2. Identify attribution SDKs:

   • AppsFlyer (appsflyer_flutter, react-native-appsflyer).
   • Adjust (adjust_sdk_flutter, react-native-adjust).
   • Branch (flutter_branch_sdk, react-native-branch).
   • Singular, Kochava, or other attribution providers.

3. Identify crash/error monitoring:

   • Firebase Crashlytics (firebase_crashlytics).
   • Sentry (sentry_flutter, @sentry/react-native).
   • Bugsnag (bugsnag_flutter, @bugsnag/react-native).
   • Datadog (datadog_flutter_plugin).

4. Identify feature flag services:

   • Firebase Remote Config.
   • LaunchDarkly.
   • Statsig.
   • Flagsmith.
   • Custom feature flag implementation.

5. Check for consent management:

   • App Tracking Transparency (ATT) implementation (iOS).
   • GDPR consent dialog.
   • CMP (Consent Management Platform) SDK.

============================================================ PHASE 2: EVENT TRACKING COMPLETENESS

Map every user action in the app to analytics events:

CORE LIFECYCLE EVENTS:

• app_open (cold start, warm start differentiation).
• app_background.
• app_foreground.
• session_start (with session ID).
• first_open (first launch after install).
• app_update (first launch after update, with version).

AUTHENTICATION EVENTS:

• sign_up (with method: email, google, apple, etc.).
• login (with method).
• logout.
• password_reset_requested.
• password_reset_completed.
• account_deleted.

NAVIGATION EVENTS:

• screen_view (with screen_name, screen_class).
• tab_switch (with tab_name).
• deep_link_opened (with source, path).
• push_notification_opened (with campaign_id).

FEATURE ENGAGEMENT EVENTS: For each major feature in the app:

• {feature}_viewed.
• {feature}_interacted (specific action).
• {feature}_completed.
• {feature}_error (with error_code).

COMMERCE EVENTS (if applicable):

• product_viewed (with product_id, category, price).
• add_to_cart.
• remove_from_cart.
• begin_checkout.
• purchase (with revenue, currency, transaction_id).
• refund.

ERROR EVENTS:

• api_error (with endpoint, status_code, error_message).
• validation_error (with field, reason).
• crash (automatically captured by crash SDK).
• non_fatal_error (with type, message).

Generate an event coverage matrix:

============================================================ PHASE 3: EVENT QUALITY AUDIT

For each implemented event, verify:

NAMING CONVENTIONS:

• Consistent naming pattern (snake_case recommended).
• No duplicate event names with different meanings.
• No overly generic names ("button_clicked" without context).
• Matches the analytics platform's recommended naming.

EVENT PARAMETERS:

• Required parameters present (event-specific context).
• Parameter values are meaningful (not IDs without labels).
• No PII in event parameters (email, phone, name -- use hashed IDs).
• Consistent parameter names across events (user_id not userId in some, user_id in others).

TIMING AND CONTEXT:

• Events fire at the correct moment (on action, not on screen load for interaction events).
• Events include sufficient context to be useful in analysis.
• Events do not fire duplicate/repeated for single user action.

CUSTOM DIMENSIONS / USER PROPERTIES:

• User properties set at appropriate times:
  • Subscription status (free, trial, paid, churned).
  • Account age / cohort.
  • Preferred language / locale.
  • App version.
  • Device type.
  • Feature flags active.

============================================================ PHASE 4: FUNNEL ANALYSIS READINESS

Verify that critical funnels can be constructed from tracked events:

ONBOARDING FUNNEL: app_open -> sign_up_started -> sign_up_completed -> onboarding_step_1 -> ... -> onboarding_completed

CORE CONVERSION FUNNEL: {app-specific: e.g., search -> view_listing -> begin_checkout -> purchase}

RETENTION SIGNALS:

• Events that define an "active" user.
• Events that indicate feature adoption.
• Events that predict churn (last action before uninstall).

For each funnel, verify:

• Every step has a corresponding event.
• Events have shared identifiers to link steps (user_id, session_id).
• Drop-off points can be identified (where users leave the funnel).
• Time between steps can be calculated.

============================================================ PHASE 5: ATTRIBUTION TRACKING

If attribution SDK is detected:

INSTALLATION ATTRIBUTION:

• Attribution SDK initialized before first analytics event.
• Deep link handling integrated with attribution.
• Campaign parameters captured (utm_source, utm_medium, utm_campaign).
• Attribution data forwarded to analytics platform.

DEFERRED DEEP LINKS:

• Deferred deep link handling for users who install then open.
• Correct screen navigation after deferred deep link resolution.

RE-ENGAGEMENT ATTRIBUTION:

• Push notification campaigns tracked.
• Email campaign deep links attributed.
• Retargeting ad clicks attributed.

SKAdNetwork (iOS):

• SKAdNetwork configuration in Info.plist.
• Conversion value updates at meaningful user actions.
• Conversion value mapping documented.

============================================================ PHASE 6: CRASH-FREE RATE MONITORING

CRASH REPORTING COMPLETENESS:

• Crash SDK initialized as early as possible in app lifecycle.
• User ID set for crash reports (for user-specific debugging).
• Custom keys set for crash context (screen_name, last_action).
• Non-fatal errors explicitly reported (not just crashes).
• dSYM / mapping files uploaded for symbolication (in CI/CD).
• Breadcrumbs enabled for crash context trail.

CRASH ALERTING:

• Alerts configured for crash-free rate drops below threshold.
• New crash cluster notifications enabled.
• Release-specific crash monitoring.

PERFORMANCE MONITORING:

• Startup time tracking (Firebase Performance, Sentry).
• Screen load time tracking.
• Network request performance tracking.
• Custom performance traces for critical operations.

============================================================ PHASE 7: PRIVACY COMPLIANCE

APP TRACKING TRANSPARENCY (iOS):

• ATT prompt displayed before any tracking (IDFA access).
• ATT prompt timing is appropriate (not on first screen -- show value first).
• App respects user's ATT choice (no tracking if denied).
• Analytics SDK configured to respect ATT status.
• NSUserTrackingUsageDescription in Info.plist with clear explanation.

GDPR / PRIVACY:

• Consent obtained before analytics initialization (if serving EU users).
• Consent granular (analytics consent separate from marketing consent).
• User can withdraw consent (and analytics stops).
• Data deletion mechanism available (right to erasure).
• No PII in analytics events (names, emails, phone numbers).
• User IDs are pseudonymized (not real email as user ID).

APP PRIVACY NUTRITION LABEL (iOS):

• Data types collected match App Store declarations.
• Third-party SDKs' data collection documented.
• "Used to track you" vs "Not linked to you" correctly classified.

DATA SAFETY FORM (Android):

• Data types collected match Play Store declarations.
• Data sharing with third parties documented.
• Data retention and deletion policies documented.

============================================================ PHASE 8: FEATURE FLAG AUDIT

If feature flag service detected:

• Feature flags used for gradual rollouts.
• Feature flag evaluation logged as analytics events.
• A/B test assignment tracked as user property.
• Feature flags have default values (offline fallback).
• Stale feature flags identified (launched features still behind flags).

============================================================ SELF-HEALING VALIDATION (max 2 iterations)

After producing output, validate data quality and completeness:

1. Verify all output sections have substantive content (not just headers).
2. Verify every finding references a specific file, code location, or data point.
3. Verify recommendations are actionable and evidence-based.
4. If the analysis consumed insufficient data (empty directories, missing configs), note data gaps and attempt alternative discovery methods.

IF VALIDATION FAILS:

• Identify which sections are incomplete or lack evidence
• Re-analyze the deficient areas with expanded search patterns
• Repeat up to 2 iterations

IF STILL INCOMPLETE after 2 iterations:

• Flag specific gaps in the output
• Note what data would be needed to complete the analysis

============================================================ OUTPUT

Mobile Analytics Audit Report

Analytics Stack

Event Coverage: {N}% ({implemented}/{expected} events)

{Coverage matrix from Phase 2}

Event Quality Issues

Funnel Readiness

Privacy Compliance

Analytics Score: {score}/100

DO NOT:

• Do NOT recommend tracking PII (names, emails, phone numbers) in analytics events.
• Do NOT skip privacy compliance checks -- violations result in app rejection and legal liability.
• Do NOT recommend excessive tracking that degrades user trust or app performance.
• Do NOT ignore platform-specific requirements (ATT for iOS, Data Safety for Android).
• Do NOT suggest analytics SDKs without considering their impact on app size and startup time.
• Do NOT report theoretical analytics gaps without verifying the app's actual functionality.

NEXT STEPS:

• "Implement missing events from the coverage matrix."
• "Run /mobile-performance to verify analytics SDK impact on startup time."
• "Run /store-compliance to verify privacy declarations match actual tracking."
• "Run /app-store-optimization to track ASO metric changes with analytics."

============================================================ SELF-EVOLUTION TELEMETRY

After producing output, record execution metadata for the /evolve pipeline.

Check if a project memory directory exists:

• Look for the project path in ~/.claude/projects/
• If found, append to skill-telemetry.md in that memory directory

Entry format:

### /mobile-analytics — {{YYYY-MM-DD}}
- Outcome: {{SUCCESS | PARTIAL | FAILED}}
- Self-healed: {{yes — what was healed | no}}
- Iterations used: {{N}} / {{N max}}
- Bottleneck: {{phase that struggled or "none"}}
- Suggestion: {{one-line improvement idea for /evolve, or "none"}}

Only log if the memory directory exists. Skip silently if not found. Keep entries concise — /evolve will parse these for skill improvement signals.