DOCSEARCHbyAlgolia
Submit Docs

Quest Data Documentation

website·Indexed 29 days ago

https://quest-data-docs.vercel.app

A game analytics and Live Ops platform providing real-time insights into player behavior, revenue, and device performance. Features include a Godot 4 SDK, event tracking, A/B testing, remote logging, leaderboards, and live game balancing tools to update game data without redeploying.

Tokens
55.9K
Snippets
269
Records
411
Agent score
75%

What's inside Quest Data

  1. Overview of Quest Data Dashboard capabilities

    The Quest Data dashboard provides real-time visibility into game analytics, player behavior, and revenue. It is divided into the following functional areas:

    • Analytics: Real-time tracking of player behavior, engagement (feature usage, heatmaps), conversion funnels, spatial tracking (X/Y/Z coordinates), and hardware performance (FPS/RAM, crash rates).
    • Live Ops: Remote game management including data table balancing (spreadsheet UI/CSV), changelog management across branches, A/B testing (traffic splitting), and remote configuration/feature flags.
    • Monetization: Revenue tracking (ARPPU, timelines) and IAP catalog conversion rates.
    • Players: Player base management including achievement tracking, cloud save inspection, leaderboard moderation, player-specific event timelines (Player Explorer), and segment tagging.
    • Configuration: Administrative tools for setting up Discord/email alerts for crashes or revenue drops, managing API keys, and viewing remote logs with full-text search.

  2. Overview of Quest Data SDK Integration Concerns

    The Quest Data SDK is organized into six orthogonal concerns. Integration is designed to be non-invasive: you only touch the parts of your codebase related to the specific concerns you enable. Most concerns are 'touch-once-and-forget' (implemented in 1-2 central files), while Event Tracking and Logging are 'disperse-by-design' and should be placed directly within the domain code that triggers them.

  3. Overview of Alert Types and Trigger Conditions

    Alerts monitor critical metrics by comparing current values against a configurable baseline window. Available alert types include:

    • Crash Spike: Triggers when error count exceeds X% of baseline (e.g., detecting crash loops after updates).
    • Revenue Drop: Triggers when daily revenue falls below X% of baseline (e.g., catching payment issues).
    • DAU Drop: Triggers when active users drop below X% of estimated average (e.g., spotting retention problems).
    • Retention Drop: Triggers when Day-7 retention of recent cohorts is below X% of baseline (e.g., onboarding regressions).
    • Log Error Spike: Triggers when log errors and warnings exceed X% of baseline (e.g., remote logging anomalies).

  4. Understand Quest Data Godot SDK versioning and migration process

    The Quest Data Godot SDK follows Semantic Versioning (SemVer). Breaking changes occur in minor version bumps (e.g., 0.x → 0.(x+1)). When upgrading across multiple versions, migrations must be applied sequentially from the current version forward. Detailed migration steps, including 'Before/After' code snippets and search patterns, are maintained in the client/CHANGELOG.md file.

  5. Navigate the Quest Data Dashboard

    The Quest Data dashboard is organized into five primary functional sections accessible via the sidebar:

    • Analytics: Used for understanding player behavior through event charts, retention tables, funnels, and heatmaps.
    • Live Ops: Used for real-time game adjustments without requiring a client update, including remote configuration, balancing, and A/B tests.
    • Monetization: Used for tracking revenue, including purchases, ARPPU (Average Revenue Per Paying User), top-selling products, and subscriptions.
    • Players: Used for player management, including searching for players, creating segments, managing achievements, leaderboards, and cloud saves.
    • Configuration: Used for technical setup and debugging, such as managing API keys, configuring alerts, and viewing remote logs.

  6. Understand the Remote Config and Game Data lifecycle

    Remote Config and Game Data follow a fetch-cache-read pattern:

    Remote Config Flow:

    1. fetch_remote_config() sends a GET request with the player's ID.
    2. Server returns configs merged with segment overrides and experiment variants.
    3. Values are cached in memory and persisted to disk at user://quest_config.save.
    4. get_config() reads instantly from the in-memory cache.

    Game Data Flow:

    1. get_game_data() checks the local cache first.
    2. On cache miss or force_refresh, it fetches from GET /v1/gamedata/:table_name.
    3. Response includes rows, columns, and a version number.
    4. Data is cached in memory and persisted to disk at user://quest_gamedata.save.
    5. Concurrent calls to the same table are batched via a callback queue.

  7. Update player presence and activity

    Use QuestData.update_presence() to send real-time updates about a player's current state. This data flows via WebSocket to the dashboard and can be used for social features or moderation. Presence entries expire and are marked as 'Offline' after 10 minutes of inactivity.
    # Update presence during general gameplay
QuestData.update_presence({
  "status": "playing",
  "activity": "dungeon_run",
  "level": 5,
  "party_size": 3,
  "last_action": "combat"
})

# Update presence when entering a boss fight
QuestData.update_presence({
  "status": "playing",
  "activity": "boss_fight",
  "boss_name": "Dragon Lord",
  "hp_remaining": 45.5
})

# Update presence while waiting for matchmaking
QuestData.update_presence({
  "status": "waiting",
  "activity": "matchmaking",
  "queue_time_seconds": 30,
  "queue_position": 15
})

# Update presence when idle in menus
QuestData.update_presence({
  "status": "idle",
  "activity": "menu"
})

  8. Use the Flight Recorder for pre-crash telemetry

    The Flight Recorder acts as a black box, continuously capturing the following data every second in a 60-second circular buffer: FPS, Memory usage (MB), Active scene, and Recent events. This data is automatically attached to any error reported via QuestData.track_error(); no additional configuration is required.

  9. Analyze crashes with the Flight Recorder

    The Flight Recorder maintains a circular buffer of telemetry snapshots taken every second for the last 60 seconds. When an error is tracked, this buffer is attached to the event, allowing developers to see the state of the game immediately preceding the crash.

    Captured Metrics:

    • FPS
    • Memory usage (MB)
    • Active scene name
    • Recent events tracked within that second

    Dashboard View: In Analytics > Dashboard, you can view error groups by error_name, occurrence counts, full stack traces, and FPS/Memory graphs from the Flight Recorder.

  10. Understand Device Performance Telemetry tracking

    The SDK automatically tracks performance data without requiring manual setup. It uses three primary lifecycle events to feed the dashboard:

    • session_start: Triggered at SDK initialization; captures device_model, cpu_cores, gpu_name, and total_ram.
    • session_ping: Triggered every 60 seconds during gameplay; captures fps, ram_bytes, and the current scene. This event (introduced in v1.6.0) ensures telemetry is captured even if the session ends abruptly (e.g., crashes or browser tab kills).
    • session_end: Triggered when the window closes; captures min/avg/max_fps, max_ram, and session duration.

  11. Track player progression through levels and quests

    Use the Progression Tracking system to monitor how players move through sequential content. The SDK automatically calculates the duration_seconds between the call to start_progression() and the subsequent call to either complete_progression() or fail_progression(). If a completion or failure is recorded without a preceding start call, the duration defaults to 0.

  12. Understand Ad Revenue dashboard metrics

    The Ad Revenue dashboard provides the following performance indicators:

    KPI Cards:

    • Impressions: Total ad views in the selected period.
    • Ad Revenue: Total revenue from all ads.
    • Avg eCPM: Weighted average eCPM across all ad types.
    • Rewarded: Count and revenue specifically for rewarded ads.
    • Interstitial: Count and revenue specifically for interstitial ads.

    Visualizations:

    • Daily Ad Revenue Chart: A bar chart showing revenue trends over time.
    • Placement Performance Table: A breakdown of impressions, revenue, and average eCPM per placement location.