How do I stop test or unauthorized builds from sending data to Unity Analytics?

To stop test builds, old versions, or copied WebGL builds from sending data to Unity Analytics, don't start Analytics until Remote Config approves the build. Unapproved builds send nothing, so they don't distort your dashboards or add to the user counts that billing is based on.

The approach is deny by default:

1. Store an allowlist in Remote Config settings, with Analytics off by default.
2. On each launch, your game fetches the settings and checks its own version, platform, and (for WebGL) host domain against them.
3. Your game starts Analytics only if it passes every check.

Because the allowlist lives in Remote Config, you can change it from the Unity Dashboard without releasing a new build.

This doesn't secure your data. It stops builds that run your check. A modified build can skip it. See "What if a modified build ignores the check?" below.

Step 1: Create the settings

In Remote Config, create these settings in each environment:

Remote Config has no list type, so store the lists as json.

Leave analytics_enabled set to false until you're ready, and set it to true only once the other settings describe the builds you approve.

Step 2: Check the build before starting Analytics

On each launch, after you initialize Unity Services and fetch Remote Config, check the build against the settings. Start Analytics only if the check passes.

using System;
using System.Linq;
using Unity.Services.RemoteConfig;
using UnityEngine;

[Serializable]
class Allowlist { public string[] values; }

static bool IsAnalyticsApproved()
{
    var config = RemoteConfigService.Instance.appConfig;

    // Only trust settings fetched from the service this session, not cached ones.
    if (config.origin != ConfigOrigin.Remote) return false;

    if (config.GetBool("kill_switch")) return false;
    if (!config.GetBool("analytics_enabled")) return false;

    // Compare versions numerically, so 1.10.0 counts as newer than 1.9.0.
    if (!Version.TryParse(Application.version, out var current) ||
        !Version.TryParse(config.GetString("min_supported_version"), out var minimum) ||
        current (config.GetJson("allowed_platforms")).values;
    if (platforms == null || !platforms.Contains(Application.platform.ToString())) return false;

#if UNITY_WEBGL && !UNITY_EDITOR
    var host = new Uri(Application.absoluteURL).Host;
    var domains = JsonUtility.FromJson(config.GetJson("allowed_domains")).values;
    if (domains == null || !domains.Contains(host)) return false;
#endif

    return true;
}

 Every check fails closed. If a setting is missing, empty, or can't be parsed, the build isn't approved.

If Remote Config can't be reached: Remote Config applies the settings it cached from the last successful fetch. The sample treats cached settings as not approved, so a build stays off until it reaches the service. If you'd rather let a previously approved build keep sending data while offline, remove that check.

Starting Analytics doesn't replace player consent. The Remote Config check is a second condition, on top of whatever consent your game needs:

• Analytics SDK 6.1 and later: Analytics starts when AnalyticsIntent consent is granted through EndUserConsent.SetConsentState(). Grant it only when the player has consented and IsAnalyticsApproved() returns true.
• Earlier SDKs: call AnalyticsService.Instance.StartDataCollection() under the same two conditions.

Can I use Game Overrides too?

Yes, for anything that should vary by audience or time. A Game Override can give a different value of any of these settings to a group of players, for example to turn analytics_enabled on for a staged rollout percentage, or only between a start and end date.

Game Override conditions can't read other settings, so an override can't check the allowlist itself. The game does that, as above. See Game Overrides and Settings.

How do I check it works?

Before you ship, test in a non-production environment:

• An approved build starts Analytics.
• An unapproved build doesn't: a version below min_supported_version, an unlisted platform, or a WebGL build on an unlisted domain.
• Setting kill_switch to true stops Analytics in an approved build on its next launch.
• A build that can't reach Remote Config stays off, or behaves the way you chose above.

How do I keep test data out of production?

• Use a separate Remote Config environment for QA and test builds, so their data never reaches production.
• Use the production environment for live builds only.
• After each release, raise min_supported_version and tidy the lists as you drop old versions and hosts.

To see what is still sending data, break your Analytics dashboards down by the clientVersion and platform event fields. Analytics doesn't record the WebGL host by default. To see it, send it yourself as an event parameter.

What if a modified build ignores the check?

The check only works in builds that run your code unchanged. A modified build can skip it and send events anyway.

If you suspect a modified build is sending data, you can either work around it, or consider more drastic steps like building to a new Unity Cloud environment.