userAttributes vs appAttributes (and misc)

[Maeslezo]

Hello,

I’ve been studying the Remote Config Documentation (Unity Remote Config | Remote Config | 3.3.2) and I have a few questions. I can split these questions in smaller threads if requested

userAttributes vs appAttributes
I understand you can use this structs to add information to be used in the Game Overrides rules.
In the documentation, it says:

• Use the userAttributes structure to provide custom user-category attributes.
• Use the appAttributes structure to provide custom app-category attributes.

But then, they are used like this:

For example, if you want to define a Game Override that targets users with a score greater than 10, you can define a score property from the app context using dot notation:

app.score >= 10

You can also reference multiple attributes within the same Game Override:

user.score >= 10 && app.level == 5

So score is used in the app structure and in the user structure.
Taking into account that any value can be used in both structures, what is the point of having two structures? What is the difference, semantically speaking?

Unity Attributes
There are several attributes that you can use in your rules (unity.country, unity.cpu,
unity.appVersion, etc.) You don’t need to send these attributes, right? They are sent automatically by the remote config service

RemoteConfigService.Instance.GetConfig
In the documentation, you can find

        var settings = RemoteConfigService.Instance.GetConfig("settings");
        var specialConfigType = RemoteConfigService.Instance.GetConfig("specialConfigType");

What does it mean different types of config? I understand that settings are the actual settings we’re fetching, but what else could it be? Is there any other type of config (“specialConfigType”)?

Options.SetEnvironmentName vs RemoteConfigService.Instance.SetEnvironmentID
I’ve found that you can set the environment in two ways, one with the environment name and other with the environment id. Are they equivalent? Or do I need to set both? Could it be possible (although incorrect by design), to set an environment for analytics and other environment for remote settings? Or the second call is going to override the first one?

        var options = new InitializationOptions()
            .SetEnvironmentName("environmentName");

        await UnityServices.InitializeAsync(options);

        RemoteConfigService.Instance.SetEnvironmentID("environmentId"); //equivalent?

SchemaId
I’ve seen you can define a filter in the fetch call. The filter definition is

    public struct filterAttributes {
      // Optionally declare variables for attributes to filter on any of following parameters:
        public string[] key;
        public string[] type;
        public string[] schemaId;
    }

I understand that key is to filter by key names and type is to filter by key types. But, what are we filtering with schemaId?

Thank you

[vd_unity]

Hi Maeslezo,

thanks for your questions!
I will try to answer those to the best of my understanding:

1. userAttributes vs appAttributes
As you correctly stated, there is no difference in priority when adding those attributes to your request.
Basically, both of those attributes are there to help you with the segmentation for the Game Overrides,
therefore separation into two categories is only there for organizational purposes, as some of them might pertain more to the user (e.g. customId) or the app (e.g. level).

2. Unity Attributes
Those are indeed sent by Unity, and you do not need to worry about setting those, however, you can use them for the segmentation, here is the list of typical Unity attributes in the request:

"attributes": {
    "unity": {
      "osVersion": "Mac OS X 13.6.0",
      "appVersion": "0.1",
      "rootedJailbroken": false,
      "model": "MacBookPro16,1",
      "cpu": "Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz",
      "cpuCount": 16,
      "cpuFrequency": 2300,
      "ram": 32768,
      "vram": 8176,
      "screen": "3840 x 2160 @ 30.0000003Hz",
      "dpi": 72,
      "language": "en",
      "appName": "com.DefaultCompany.rotatingCubeCCD",
      "appInstallMode": "Editor",
      "appInstallStore": "",
      "graphicsDeviceId": 0,
      "graphicsDeviceVendorId": 0,
      "graphicsName": "AMD Radeon Pro 5500M",
      "graphicsDeviceVendor": "Apple",
      "graphicsVersion": "Metal",
      "graphicsShader": 50,
      "maxTextureSize": 16384,
      "platform": "OSXEditor"
    },

so you can segment on any of them e.g unity.platform == 'iOS'
more details here

3. RemoteConfigService.Instance.GetConfig
The majority of developers only use one configuration type, “settings” by default.
For specific internal users, we developed a unique configuration type, however despite being documented, this capability is not generally accessible.

4. Options.SetEnvironmentName vs RemoteConfigService.Instance.SetEnvironmentID
As you correctly stated, there are two ways to set the environment
.SetEnvironmentName(environmentName) vs .SetEnvironmentID(environmentId).

The first method comes from the core services, and it takes the name string as a parameter, and core provides environmentId which in turn calls the .SetEnvironmentID(environmentId) from RC anyways, and sets up the payload for RC request.
They both do the same thing, but the one provided by RC is more direct, however, not everyone knows the environmentId, as it is easier to remember the name.

Of course, it is enough to use only one of those methods, and if you know the environmentId, SetEnvironmentID(environmentId) is more direct. If you omit both methods, you will get the default environment.

One small caveat - if you use SetEnvironmentName, the environmentId is only obtained in core when signing in to a player. If you fetch your remote config prior to signing in, it will by default always send you back your production values.

5. SchemaId
Using schemas is also a feature that is currently available only to some internal customers, but will be publicly available very soon.
In simple terms, using a web dashboard, user will be able to define a schema for single-level JSON keys, so errors when updating a key can be prevented (let’s say we define one type for the key and someone tries to update that key with another type - if schema is applied to that setting, an update will be rejected)

In the context of filtering attributes during the Fetch call, that schema filter serves the purpose of reducing the response payload only to settings under certain schema

---

Sorry for this somewhat long answer, RC was one of the first packages developed, and it had to cater to many standards and packages that were developed after, which inadvertently introduced additional unwanted complexity.
In its true nature, RC is a simple key-value store, able to retrieve correct settings based on users’ requests, utilizing environments and campaigns.

Hope this helps,
Vlatko

[Maeslezo]

Thank you for your kind response, it has been very enlightening.

Very interesting this paragraph:

One small caveat - if you use SetEnvironmentName, the environmentId is only obtained in core when signing in to a player. If you fetch your remote config prior to signing in, it will by default always send you back your production values.

Actually we were having a bug because our analytics were all to the production environment no matter which environment we set. I think this explain the issue.

Can we get which environment are we using in runtime? So we can check that we’re actually using the intended environment

await UnityServices.InitializeAsync(options) doesn’t return anything

We would rather use RemoteConfigService.Instance.SetEnvironmentID(“environmentId”), so we don’t have to anonymously signIn, but unfortunally there’s not an awaitable version of the method ( RemoteConfigService.Instance.SetEnvironmentIDAsync)

[vd_unity]

Thanks, @Maeslezo for the follow-up!

The environment is set during the runtime, as both .SetEnvironmentName(environmentName) and .SetEnvironmentID(environmentId) are just setting the environmentId in the payload which will be used within RC request later by the Fetch() method.
Of course, if you do not set the environment by using any of those, the config from the default environment (“production”) will be returned.
After the payload is sent back and consumed by the backend, the response will look something like this:

{
  "configs": {
    "settings": {
      "colorRed": 0.9,
      "rotateY": 23.0,
      "rotSpeed": 27.0,
      "colorGreen": 0.1,
      "rotateZ": 120.0,
      "colorBlue": 0.9,
      "rotateX": 12.0
    }
  },
  "metadata": {
    "configAssignmentHash": "f242cd5faf3851f344b393b2a7e2e317e44a782e",
    "assignmentId": "477b17a6-dcf5-4305-b07c-0ba3f3489ca0",
    "environmentId": "0d39eef9-c96b-486d-bbc0-7219b8554e51"
  }
}

where you can see the corresponding environmentId among the metadata.

If you need to check the environmentId after the RC request in the runtime, there is a runtime config variable which stores the current environmentId, and can be accessed via:

RemoteConfigService.Instance.appConfig.environmentId

---

To your point regarding awaitable version of the method SetEnvironmentIDAsync,
instead of setting the environment in an asynchronous manner, we should probably unify Remote Config with the “sign-in” flow of the rest of the services.

Thanks again for the follow-up, I hope this clarifies things a bit!
Vlatko

[Maeslezo]

@vd_unity

Of course, if you do not set the environment by using any of those, the config from the default environment (“production”) will be returned.

What I meant is that you get the default environment ALTOUGHT you set any environment, if you don’t sign anonymously.

In other words, signing is mandatory in order to set the environment correctly

For example:

var options = new InitializationOptions();
options.SetEnvironmentName("not default environment");
await Unity.Services.Core.UnityServices.InitializeAsync(options);

RuntimeConfig remoteConfig = await RemoteConfigService.Instance.FetchConfigsAsync(new userAttributes(), new appAttributes());

//remoteConfig.environmentId is the default environment, altought "not default environment" has been set

However

var options = new InitializationOptions();
options.SetEnvironmentName("not default environment");
await Unity.Services.Core.UnityServices.InitializeAsync(options);
if (!AuthenticationService.Instance.IsSignedIn)
{
   await AuthenticationService.Instance.SignInAnonymouslyAsync();
}

RuntimeConfig remoteConfig = await RemoteConfigService.Instance.FetchConfigsAsync(new userAttributes(), new appAttributes());

//remoteConfig.environmentId is the "not default environment", which was the environment set

[vd_unity]

Thanks @Maeslezo !
Yes, you are correct - if you are using options.SetEnvironmentName() method from the Core, setting a non-default environment will not work without the player signing in.

Unfortunately, the only current way to have a non-default environment set and not sign in the player is if you use the RCs method
RemoteConfigService.Instance.SetEnvironmentID(), but in that case you have to know the environmentId.

Although this flow is not ideal, we are aware of it and will work to improve it.

[Maeslezo]

@vd_unity

Thanks @Maeslezo !
Yes, you are correct - if you are using options.SetEnvironmentName() method from the Core, setting a non-default environment will not work without the player signing in.

Unfortunately, the only current way to have a non-default environment set and not sign in the player is if you use the RCs method
RemoteConfigService.Instance.SetEnvironmentID(), but in that case you have to know the environmentId.

Although this flow is not ideal, we are aware of it and will work to improve it.

All clear.

Thank you for your help