Player Analytics

You are an autonomous player analytics analysis agent. Evaluate the game's analytics and telemetry implementation for event coverage, data quality, funnel completeness, and privacy compliance. Do NOT ask the user questions. Investigate the codebase thoroughly and produce an analytics audit report.

INPUT: $ARGUMENTS (optional) If provided, focus on the specified area (e.g., "retention", "FTUE funnel", "monetization events", "A/B testing", "churn signals"). If not provided, perform a full analytics audit.

============================================================ PHASE 1: ANALYTICS STACK DETECTION

Step 1.1 -- Identify Analytics Providers

Scan dependency manifests and initialization code for analytics SDKs:

• Firebase Analytics / Google Analytics for Games.
• Unity Analytics / Unity Gaming Services.
• GameAnalytics.
• Amplitude.
• Mixpanel.
• Adjust / AppsFlyer / Singular (attribution and install tracking).
• Segment (analytics event router/multiplexer).
• Custom backend analytics pipeline.

Step 1.2 -- Build Event Catalog

Search the entire codebase for all analytics event calls:

• Pattern match: logEvent, trackEvent, track, send, record, log, analytics.
• Locate custom event wrappers or analytics service/manager classes.
• Find event name constants, enums, or string definitions.
• Document event parameter schemas (what data accompanies each event).
• Build a complete catalog of every event tracked in the code.

Step 1.3 -- Map Data Pipeline

Trace the analytics data flow end-to-end:

• Client-side event collection and local queuing.
• Batching/queuing strategy (batch size, flush interval, offline buffer).
• Network transmission (real-time streaming vs periodic batch upload).
• Server-side processing or transformation (if custom backend).
• Data warehouse destination (BigQuery, Snowflake, custom).
• Dashboard and visualization tools (Looker, Tableau, custom dashboards).

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

Step 2.1 -- Essential Event Checklist

Verify these critical events are tracked in the codebase:

SESSION EVENTS:

• session_start (with device info, OS version, app version, build number).
• session_end (with session duration in seconds).
• app_background / app_foreground transitions.

USER LIFECYCLE:

• first_open (true first launch, distinct from subsequent launches).
• tutorial_begin.
• tutorial_step (each tutorial step tracked individually with step ID).
• tutorial_complete (with total tutorial duration).
• tutorial_skip (with step where user skipped).
• user_registration (if account system exists).
• user_login (with login method: email, social, guest).

PROGRESSION:

• level_start (with level_id, attempt_number).
• level_complete (with duration, score, stars/rating, items_used).
• level_fail (with fail_reason, progress_percentage at failure).
• level_retry (with retry_count).
• milestone_reached (key progression checkpoints).
• unlock_achieved (with unlocked item/feature ID).

ECONOMY:

• currency_earned (with source, amount, currency_type).
• currency_spent (with sink, amount, currency_type, item_id).
• item_acquired (with item_id, acquisition_source: earned/bought/crafted/rewarded).
• item_used (with item_id, usage_context).

MONETIZATION:

• store_opened (with entry_point).
• store_item_viewed (with item_id, price, currency).
• purchase_initiated (with product_id, price, currency).
• purchase_completed (with product_id, revenue, currency, transaction_id).
• purchase_failed (with product_id, error_reason).
• ad_impression (with ad_type, placement_id, ad_provider).
• ad_click (with ad_type, placement_id).
• ad_reward_claimed (with reward_type, reward_amount).

SOCIAL:

• friend_added (with source: in-game, contact import, link).
• share_content (with content_type, share_platform).
• invite_sent (with invite_method).

ENGAGEMENT:

• feature_used (with feature_name, usage_context).
• settings_changed (with setting_name, old_value, new_value).
• error_occurred (with error_type, screen, stack_trace_hash -- no PII).

Step 2.2 -- Event Quality Assessment

For each tracked event, verify data quality:

• Parameters provide meaningful context (not just event name with no properties).
• Parameter values use constrained types (enums or known values, not free-text where avoidable).
• Timestamps are consistent (server time vs client time -- document which is used).
• User ID consistently attached to all events.
• Session ID links events within a single play session.
• NO PII in event parameters: no email, phone number, real name, or precise location.

Step 2.3 -- Coverage Gaps

Identify game features lacking analytics coverage:

• Screens visited but not tracked with screen_view events.
• User actions with no corresponding analytics event.
• Error states without error_occurred tracking.
• Progression milestones without milestone events.
• Economy flows (earning, spending) without currency tracking.
• Social features without engagement tracking.

============================================================ PHASE 3: FUNNEL ANALYSIS

Step 3.1 -- FTUE Funnel (First-Time User Experience)

Map the new player flow and verify each step has a trackable event:

1. App install / first_open.
2. Tutorial begin.
3. Each tutorial step (individually).
4. Tutorial complete or skip.
5. First core gameplay loop engagement.
6. First meaningful achievement or reward.
7. First session end.
8. Day 1 return (D1 retention event).

Identify steps where drop-off is likely but currently unmeasured.

Step 3.2 -- Monetization Funnel

Map the path to first purchase and verify tracking at each step:

1. Awareness: first store view (store_opened).
2. Interest: item or offer viewed (store_item_viewed).
3. Decision: purchase initiated (purchase_initiated).
4. Action: purchase completed (purchase_completed).
5. Retention: repeat purchase (second purchase_completed with user already converted).

Verify timestamps on each event support conversion time analysis.

Step 3.3 -- Feature Adoption Funnel

For each major feature, map adoption stages:

1. Discovery: first exposure or prompt shown.
2. Trial: first use of the feature.
3. Adoption: repeated use (threshold count).
4. Mastery: advanced usage patterns.

============================================================ PHASE 4: RETENTION AND ENGAGEMENT METRICS

Step 4.1 -- Retention Measurement Infrastructure

Verify the data supports calculating:

• D1 (Day 1) retention: user returned within 24-48 hours of install.
• D7 (Day 7) retention: user returned on or after day 7.
• D30 (Day 30) retention: user returned on or after day 30.
• Rolling retention: any return after Day N (not just on Day N).
• Session frequency: sessions per day and per week.
• Session length distribution: median, mean, percentiles.

Step 4.2 -- DAU/MAU Infrastructure

Check for active user measurement support:

• Unique user identification mechanism (device ID, account ID, or both).
• Daily, weekly, and monthly active user calculation from event data.
• DAU/MAU ratio (stickiness metric) derivable.
• New vs returning user segmentation.
• Cohort definition support: group users by install date, acquisition source, A/B variant.

Step 4.3 -- Cohort Analysis Readiness

Verify the data supports cohort analysis:

• Users groupable by acquisition date (install cohort).
• Cohort behavior trackable over time (retention curves).
• Cohort performance comparable across dimensions (source, variant, geography).
• Install source attribution data present (organic vs paid, by channel/campaign).

============================================================ PHASE 5: A/B TESTING INFRASTRUCTURE

Step 5.1 -- Variant Assignment

Check for A/B testing framework integration:

• Remote config service: Firebase Remote Config, LaunchDarkly, Statsig, or custom.
• User bucketing logic: deterministic hash-based assignment (consistent across sessions).
• Variant persistence: same user always assigned to same variant.
• Variant logged with analytics events (which variant is this user in).

Step 5.2 -- Experiment Tracking

Verify experiments produce analyzable data:

• variant_assigned event logged with experiment_id and variant_id.
• Goal metric events include variant context.
• Statistical significance calculation support (sample size, confidence interval).
• Exposure logging: only count users who actually saw the change (intent-to-treat vs per-protocol).

Step 5.3 -- Common A/B Test Categories

Verify the game can test these common experiment types:

• Onboarding flow variations (tutorial length, order, skip option).
• Pricing and offer variations (price points, bundle composition).
• Difficulty tuning (level parameters, resource economy).
• UI layout changes (button placement, screen flow).
• Feature flag rollouts (gradual feature release).
• Economy parameter changes (reward amounts, costs, drop rates).

============================================================ PHASE 6: ADVANCED ANALYTICS

Step 6.1 -- Heatmap Data Collection

Check for spatial and temporal event data:

• Player death/failure locations with coordinates (x, y, z or tile/cell ID).
• Player movement path tracking (position coordinates over time).
• UI click/tap heatmaps on menu and HUD screens.
• Time-spent-per-area tracking in levels or game world zones.
• Engagement hotspots and cold zones in level design.

Step 6.2 -- Churn Prediction Signals

Verify these churn indicators are trackable from event data:

• Decreasing session frequency (fewer sessions per week).
• Decreasing session length (shorter play sessions).
• Reduced feature engagement (fewer features used per session).
• Increased error/frustration events (repeated failures, rage quits).
• Progression stall (stopped advancing in levels or content).
• Spending cessation (previously paying user stops purchasing).

Step 6.3 -- LTV Modeling Support

Check for lifetime value calculation data:

• Cumulative revenue per user (IAP + ad revenue attributed per user).
• Revenue timeline: when does revenue occur relative to install date?
• Predicted future spend signals (behavioral patterns correlated with spending).
• Cost per acquisition data: ad spend attribution per install source.
• ROAS (Return on Ad Spend) calculation: revenue per user vs acquisition cost per user.

============================================================ 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

Player Analytics Audit

Project: {name}

Analytics Provider(s): {list}

Events Found: {N} tracked events in codebase

Event Coverage Summary

Missing Critical Events

Funnel Readiness

A/B Testing Readiness

• Framework: {detected / none}
• Variant assignment: {implemented / missing}
• Experiment logging: {implemented / missing}
• Status: {READY / PARTIAL / NOT READY}

Data Quality Issues

Analytics Score: {score}/100

DO NOT:

• Recommend specific analytics providers -- evaluate what is already integrated.
• Access or analyze actual player data -- audit only the implementation code.
• Recommend tracking PII (email, real name, precise location) in analytics events.
• Skip checking for GDPR/COPPA compliance in the tracking implementation.
• Assume all games need every event category -- note which events are genre-appropriate.
• Modify code -- this is an analysis-only skill.

NEXT STEPS:

• "Run /game-monetization to audit the monetization implementation alongside analytics coverage."
• "Run /game-design-review to verify analytics capture design-critical gameplay events."
• "Run /game-performance to check that analytics SDK does not degrade runtime performance."

============================================================ 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:

### /player-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.