📡 Lesson 8.3: Live-Ops — Analytics, Remote Config & Crash Reporting

The Live-Ops Loop

Live-ops (live operations) is the practice of running a game as an ongoing service after launch: watching how it's played, adjusting it, and repeating. It's a loop, and every tool in this lesson is one arc of it.

Figure 1: The live-ops loop. You ship once, then cycle: measure real behaviour, learn from it, configure the game remotely, and experiment to validate changes — feeding the next measurement. Most iterations never touch the build; only occasionally do you ship a new binary.

The crucial insight is the dashed line: most adjustments loop back through remote configuration, not through a new build. Shipping a binary is slow — store review, player download, version fragmentation. Changing a server-side value is instant and reaches everyone at once. Live-ops is largely the art of moving as much as possible out of the build and onto the server.

Unity Gaming Services

Unity Gaming Services (UGS) is Unity's umbrella of backend, cloud-hosted services you call from the game and administer from the Unity Dashboard. It spans far more than live-ops — authentication, cloud save, matchmaking, lobbies, economy, hosted servers — but this lesson focuses on the four live-ops pillars: Analytics, Remote Config, Cloud Diagnostics, and the experimentation built on top of them.

They share plumbing. You link the project to a UGS project ID, install the relevant packages, and initialise the core services once at startup. From then on each service is a small async API:

using Unity.Services.Core;
using Unity.Services.Analytics;
using UnityEngine;

public class ServicesBootstrap : MonoBehaviour
{
    private async void Start()
    {
        // One-time initialisation of Unity Gaming Services.
        await UnityServices.InitializeAsync();

        // Only start collecting analytics after the player has consented.
        if (PlayerConsent.AnalyticsGranted)
            AnalyticsService.Instance.StartDataCollection();
    }
}

That await UnityServices.InitializeAsync() uses exactly the async/await you learned in Lesson 1.3 — UGS is thoroughly asynchronous because every call is a network round-trip. Note the consent gate on the very first line of real work; we'll return to why it must be there.

Analytics — Events & Funnels

Analytics answers "what are players actually doing?" by recording events — timestamped records of things that happened, each with a name and optional parameters. Some are standard (session start, level complete); most valuable are the custom events you define for your game's own moments:

using Unity.Services.Analytics;

// Record a custom event when a player finishes a level.
void OnLevelComplete(int level, float seconds, int deaths)
{
    var evt = new CustomEvent("levelComplete")
    {
        { "levelIndex", level },
        { "durationSeconds", seconds },
        { "deaths", deaths }
    };
    AnalyticsService.Instance.RecordEvent(evt);
}

One event is a data point; the power comes from aggregating thousands of them. The classic aggregation is a funnel: an ordered sequence of steps, showing how many players reach each one. If tutorialStart → tutorialStep2 → tutorialComplete → firstLevelStart shows 100% → 92% → 61% → 58%, you've just discovered that a third of players abandon on tutorial step 2 — a precise, actionable finding you'd never get from watching a handful of playtesters.

Design your events deliberately: name them consistently, keep parameter types stable (changing a parameter from int to string mid-flight fragments your data), and record the moments that map to real decisions. Analytics you can't act on is just storage cost.

Remote Config

Remote Config is the counterpart to analytics: where analytics reads player behaviour, Remote Config writes game parameters — from the server, live, without a new build. You define keys in the Unity Dashboard (an enemy's health, a drop rate, a feature on/off flag, an event's start date) and the game fetches their current values at runtime. Change the value in the dashboard and every player picks it up on their next fetch.

The code pattern is: fetch once (typically at startup or level load), then read typed values from the returned store.

using Unity.Services.Core;
using Unity.Services.RemoteConfig;
using UnityEngine;

public struct UserAttributes { }    // targeting inputs (empty here)
public struct AppAttributes { }

public class Balancing : MonoBehaviour
{
    public float BossHealth { get; private set; }
    public bool WeekendEventActive { get; private set; }

    private async void Start()
    {
        await UnityServices.InitializeAsync();

        RemoteConfigService.Instance.FetchCompleted += OnFetched;
        await RemoteConfigService.Instance.FetchConfigsAsync(
            new UserAttributes(), new AppAttributes());
    }

    private void OnFetched(ConfigResponse response)
    {
        var cfg = RemoteConfigService.Instance.appConfig;

        // Read typed values, always with a sensible default fallback
        // in case the fetch failed or the key is missing.
        BossHealth        = cfg.GetFloat("boss_health", 500f);
        WeekendEventActive = cfg.GetBool("weekend_event", false);

        Debug.Log($"Boss health from server: {BossHealth}");
    }
}

Two habits make this safe. First, always pass a default to every getter — the fetch can fail (no network) or a key can be absent, and the game must still play. Second, apply values at sensible boundaries, not mid-combat, so a config change doesn't yank a boss's health bar while a player is fighting it.

A/B Testing & Feature Flags

Remote Config plus Analytics unlocks two powerful practices that separate guessing from knowing.

Both rest on the same idea: the build contains the capability, the server decides who gets it and how. That's the payoff of pushing decisions out of the binary — a risky feature can launch to a sliver of your audience and be pulled without an emergency patch. A/B testing then closes the loop from Figure 1's "experiment" arc, feeding a real measurement back into the next decision.

💡 Kill switches are feature flags too. Wrapping a new, risky subsystem (a live event, a matchmaking change) in a flag gives you an instant "off" button when something goes wrong in production — often the difference between a shrug and an outage.

Crash & Exception Reporting

Your game passed every test in Lesson 8.1 and CI shipped it green — and it will still crash for some players, on hardware and OS versions and edge cases you never saw. Cloud Diagnostics (Unity's crash and exception reporting service) captures those failures from the wild and aggregates them in the dashboard, so you learn about them from data rather than from angry reviews.

Once enabled, it automatically reports uncaught exceptions and native crashes, grouping identical stack traces so a bug hitting 10,000 players shows as one issue with a count — not 10,000 noise entries. Each report carries the stack trace, device model, OS, and app version (this is where the versioning from Lesson 8.2 pays off: a report pins to an exact build). You can also log caught issues deliberately:

try
{
    LoadPlayerSave();
}
catch (System.Exception e)
{
    // Report a handled exception with context, without crashing the game.
    UnityEngine.Diagnostics.Utils.ForceCrash(
        UnityEngine.Diagnostics.ForcedCrashCategory.Abort); // (illustrative)
    Debug.LogException(e);   // logged exceptions are captured by Cloud Diagnostics
}

In practice you rarely force anything — you let unhandled exceptions flow to the reporter and use Debug.LogException for handled ones you still want visibility on. The workflow that matters: sort by frequency, fix the crash hurting the most players first, ship the fix through your CI pipeline, and watch the issue's count fall in the dashboard. That's the measure-fix-verify loop applied to stability.

Privacy & Consent

Everything in this lesson collects data about real people, and that carries legal and ethical obligations you cannot treat as an afterthought. Regulations such as the GDPR (Europe) and CCPA (California), plus the app stores' own rules, govern what you may collect, how you disclose it, and the rights players have over it.

The practical requirements for a shipping game:

• Consent before collection. Ask the player's permission before starting analytics data collection — which is why the bootstrap earlier gated StartDataCollection() behind a consent check rather than calling it unconditionally.
• Disclosure. A clear privacy policy stating what you collect and why, linked from the game and the store listing.
• Honour data-subject rights. Support opt-out and data-deletion requests; UGS Analytics exposes APIs (e.g. a data-deletion/opt-out request) to help you comply.
• Extra care for minors. Games likely to be played by children carry stricter rules (COPPA and similar); when in doubt, collect less.

Hands-on Challenge

Summary

🚀 What's Next?

You now have every piece of the professional pipeline — tests, CI, and live-ops. In the finale, Lesson 8.4: A Tested, CI-Built Release — and Where to Go Next, you'll combine them into one build-along release: write tests and a build script, wire a CI workflow, and walk a real release checklist from version bump to smoke test. Then we'll look back over the whole Fundamentals → Intermediate → Advanced journey and point the way to everything still ahead.