> For the complete documentation index, see [llms.txt](https://wiki.playgama.com/playgama/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.playgama.com/playgama/guides/custom-analytics-and-optimization-with-mcp.md).

# Custom Analytics and Optimization with MCP

Publishing your game is the start of the feedback loop. What do players do next? Where do they get stuck? Does the game run smoothly?

With Playgama MCP, you can ask your AI coding agent to add custom analytics, inspect data from real players, and improve the game using that evidence.

### 1. Connect your agent

Open your game project in an AI coding agent that supports MCP, then follow the [Playgama MCP setup guide](https://playgama.com/mcp/) to connect your Playgama account.

Your agent needs access to the game's source code to add tracking. The game sends events through the Playgama Bridge SDK; MCP lets the agent read the integration instructions and retrieve analytics later.

### 2. Track the decisions you want to make

Start with a question, such as: **“Where do players stop progressing through the first three levels?”**

Ask your agent:

> Read the current Playgama Bridge SDK documentation and telemetry guide. Inspect this game and add the smallest set of custom events needed to understand tutorial completion, progression, and failure. Reuse the initialized Bridge instance and avoid duplicating events already recorded by the SDK. Add the recommended performance sampling and include the build version.

A simple progression game might use:

| Event                   | When it fires                  | Example fields          |
| ----------------------- | ------------------------------ | ----------------------- |
| `tutorial_completed`    | The player finishes onboarding | `tutorial_version`      |
| `progression_started`   | A progression step begins      | `step_id`, `step_index` |
| `progression_completed` | The step is completed          | `step_id`, `step_index` |
| `progression_failed`    | The player fails the step      | `step_id`, `reason`     |

These are examples: choose events that match your game. Keep event names stable and put changing values in their fields. Use short, consistent failure reasons rather than free-form messages.

The [Bridge analytics documentation](https://wiki.playgama.com/playgama/bridge-sdk/api/analytics) explains how custom events are sent. Avoid personal information, secrets, and unnecessary identifiers.

Before releasing, have the agent test each tracked action and check for duplicate emissions, missing fields, and incorrect outcomes.

### 3. Collect traffic and inspect the results

Release the build, wait for a while for organic players or use Boost in the developer dashboard to acquire traffic.

Once the build has collected real sessions, ask:

> Analyze telemetry for \[game] from \[start date] to \[end date]. Start with the overview and check data freshness, coverage, and sample size. Inspect the relevant progression events and performance samples. Identify the strongest evidence of friction, explain any limitations, and suggest one focused improvement.

The agent starts with `get_game_telemetry_analytics`, then uses event details, time series, or filtered session facts when needed.

Ask it to distinguish event counts from player or session counts: repeated attempts can produce several events from one player. Missing data should remain “unavailable,” not become zero.

Performance also needs enough coverage. Fewer than 30 sessions contributing performance samples is an early signal, not a reliable conclusion. The available summaries do not establish that low FPS caused players to quit.

### 4. Make one change and measure again

Suppose the evidence points to repeated failures at an early progression step. Ask the agent to inspect the relevant code and validate the likely cause:

> Investigate this finding and implement one focused improvement. Preserve the core gameplay and existing event definitions, assign a new build version, and test the change. Prepare it for release.

After releasing the update and collecting more traffic:

> Compare the baseline and updated build using compatible measurement windows and available version information. Show sample sizes and relevant rates, account for repeated attempts, and explain whether the evidence supports an improvement.

Keep traffic conditions as comparable as practical. If the data cannot separate the builds, collect a cleaner comparison window before drawing conclusions.

Repeat this cycle: **ask a question, instrument, collect data, improve, and measure again.**