Hi @Rabadash8820 , thanks for the questions, I will try to answer them and give a little bit of context where needed:
- All the methods you mentioned are indeed optional, and you do not need to invoke any of them before initialization of Analytics services and FetchConfigs. However, they had some internal purposes, and I will try to explain those, together with the complexity of many Ids we are sending during the RC request.
Remote Config makes a request to the backend in order to receive corresponding settings. Within the process, we send many Ids for different purposes (analytics, segmentation etc…) and all the methods from above are simply setting those ids for the request, even though in order for RC request to be valid only 2 params are required: projectId and userId.
Payload:
“projectId”: “35ff8616-5c15-45e8-94c6-3add4f02bacb”,
“userId”: “d4739198c1201433385ae222fa86ba01",
“playerId”: “oxbAhqECzRLkqhL9EUjlYHKXPQvs”,
“analyticsUserId”: “my-user-id-123",
“customUserId”: null,
“environmentId”: “11daa94d-0ffa-41e2-8579-f4acbbdb3987”,
Header:
Authorization Bearer eyJhbGciOiJSUzI1NiI0D0norSPCVpb1lDXAibEU5ZpQ8rj3BbQcWD0C6wolQ…
unity-installation-id d4739198c1201433385ae222fa86ba01
unity-player-id oxbAhqECzRLkqhL9EUjlYHKXPQvs
Inside payload:
projectId is retrieved via Application.cloudProjectId, and it is always available
userId is actually installationId coming from Core services, available immediately upon initialization
playerId comes from Auth and it is available upon user signin
analyticsUserId is coming from Core, available immediately, and it can be set from within the app, e.g
await UnityServices.InitializeAsync(options);```
**customUserId** is set by user within remoteConfig, used only for customer segmentation
**environmentId** comes from auth token and it is available upon user signin
Within Header:
Authorization uses **playerToken** as a **Bearer** token coming from auth access token, available upon user signin
**unity-installation-id** is same as installationId, coming from core
**unity-player-id** is same as playerId coming from auth
------------------------
Per example, if user does not set an environment, a default one will be used. However if user wants to force an environment, and knows an **environmentId;**
```RemoteConfigService.Instance.SetEnvironmentID("90593402-dccb-43a5-a09a-d8f17fffa7d4");```
will set the environment in the request, and settings from that environment will be returned.
Same goes for the rest of the rest of the methods, e.g:
```RemoteConfigService.Instance.SetCustomUserID("customer-1234"); ```
Methods like SetPlayerID, SetPlayerIdentityToken and SetUserID are not meant to be used by users, and they are set internally, but they are exposed for special cases, e.g it is useful for consoles to be able to set user id, as for those platforms we can not use certain analytics libraries needed for retrieving those ids.
That goes into your 3rd question, where SetPlayerID() and SetUserID() are meant to be used mostly internally, but SetCustomUserID() and SetAnalyticsUserID() can be used by the developer, and that is documented within Code Integration part in the docs, within the commented part
https://docs.unity3d.com/Packages/com.unity.remote-config@3.3/manual/CodeIntegration.html
and just to re-iterate, ``` SetCustomUserID("some-user-id"); ``` is used if you as a customer want to have your own unique id to track the user, which can be later utilized within the analytics.
SetAnalyticsUserId, however, has a slightly different purpose. It was used internally by old DDNA customers, who already had that id and wanted to use it for the new customers.
4. SetPlayerIdentityToken is only used internally to pass the token we get from Auth and core services, in order to track the player.
2. Remote Config Runtime includes the configAssignmentHash parameter in the request. This parameter can be used to ensure a persistent config in the response to later requests.
After making a request, currently, we get the following JSON block as a response:
{
“configs”: {
“settings”: {
“source”: “fromCampaignTest”,
“rotateY”: 12.0,
“rotSpeed”: 44.0,
“rotateZ”: -23.0,
“jsonCubeCustom”: {
“rotateX”: 20,
“color”: {
“r”: 0.2,
“g”: 0.2,
“b”: 0.3,
“a”: 1
}
},
“rotateX”: 55.0
}
},
“metadata”: {
“configAssignmentHash”: “4d1064c5198a26f073fe8301da3fc5ead35d20d1”,
“assignmentId”: “fda6c830-8f78-4cd1-b3a1-b00139e320bd”,
“environmentId”: “0ea1845e-320b-4004-98c5-b942e430acd3”
}
}
The metadata block returns 3 key-value pairs, with the following purpose:
- assignmentId gets created on each assignment event and it is used to track events and eventual user segmentation
- environmentId represents environment in which assignment happened
- configAssignmentHash is created upon assignment and presents a unique signature of that particular assignment.
Within the app, we can access configAssignmentHash from appConfig via:
``` RemoteConfigService.Instance.appConfig.configAssignmentHash; ```
Once we know the configAssignmentHash we want to use, it can be passed to the backend within the payload by using the SetConfigAssignmentHash() method:
```RemoteConfigService.Instance.SetConfigAssignmentHash("4d1064c5198a26f073fe8301da3fc5ead35d20d1"); ```
If configAssignmentHash is passed to the backend, the backend will return the config present at the time of creation of that particular configAssignmentHash.
This is particularly useful for the use-cases where per example, user paid not to see ads, and it should retrieve same settings (no ads) all the time no matter the level... etc...
TTL for the lifetime of configAssignmentHash is 56 hours. After that time, configAssignmentHash can be requested again, and TTL will reset to 56 hours again.
Caveats:
Usage of configAssignmentHash is very powerful, however, this power has some interesting side effects, e.g,:
- config values in the cache file might look unexpected, as instead of the config which would normally be passed, one sees a fixed config from the time configAssignmentHash was created
- Suppose the developer forgets that they are setting configAssignmentHash within the app. In that case, it might look like we got the wrong response from the backend as the returned config will stay fixed (sticky) even if a user should fall into a new campaign or if the environment has been changed.
------------------------
Sorry for this very long answer, RC was one of the first packages developed, and it had to cater many standards and packages that were developed after, which inadvertently introduced additional unwanted complexity, especially with many ids.
In its true nature, RC should be a simple key-value store, able to retrieve correct settings based on users request, utilizing environments and campaigns.
Hope this helps
.