We just rolled out a new feature for Unity Analytics Remote Settings. Starting today, you can now use Segments to serve different values for your Remote Settings.
Segmented Remote Settings
Unity Analytics introduced Remote Settings to make it easy and fast to update games on-the-fly. With Segmented Remote Settings, your game can now adapt dynamically to a player’s behavior and characteristics.
Segmented Remote settings is not working for my app. I am only getting the value assigned to All Current Users and not getting the respective segment values. I am not sure how to debug this issue. Can you please help me in solving this problem.
It can take some time (8-16 hours) for a particular device to be recognized as belonging to a segment. We are working to improve this. It’s the same processing time required for funnels for example. Please test again after some time?
1 very simple question:
How to duplicate the tested key-value pairs from development to release? I couldn’t find any button for it, or I need to manually do it?!?
This feature does not work if there are segments with conflicts, for example:
SomeStringValue
iOS User = “Value1”
iOS User & From China = “Value2”
All users = “Value3”
So, now we have only Value1 for all iOS and Value3 for other platforms =\ Value2 is overridden by the value from “iOS User”
And so it happens with all segments, you need either priorities for segments or logical operations between them.
Otherwise, we have to make composite keys of the type: “[PLATFOM][APP_VERSION]_ValueName”
@afftar I just checked with engineering here, and a user can only be in a single iOS segment. All iOS users (including those from China) would fall into the first iOS segment (only). If you set the priority of the iOS + China segment higher, it should work as expected. There is more information here https://docs.unity3d.com/Manual/UnityAnalyticsRemoteSettingsCreating.html
Hi!
I need to do just this - roll out some feature to random 10% of all users, and then study their behaviour, and change this percent accordingly. In the way FireBase does it Firebase Tutorial iOS AB Testing - Google Chrome (42 kb) закачан 13 декабря 2017 г. Joxi
This is basic functionality for A/B testing, where users being assigned some random but persistent IDs on the first start, and then segment is built using these IDs. Don’t Unity Analytics have solution for this kind of task? RemoteConfig is great, but without this it can’t be really used for A/B testing.
Edited: Or, can i create segments from custom events parameters? In this case i can assign player a random number from 1 to 10 at a first start, store it, send it to analytics in event UserGroupId(X) and build segment with some “AND” logic to achive needed percent. But it would be better to have such functionality from the box.
Hi!
As i wrote earlier, i hope to make A/B testing working with Unity Analytics. I thought this can be achieved using segments built upon custom events, but now i am not so sure, and i need confirmation of my thoughts.
How do i think it should work:
On application first start each user given a random integer number X from 1 to 10. After this, for each A/B test device sends custom event to analytics like “ABtest1(X)”
In the analytics control panel i make a segment with this logic “ABTest1 = 1 OR ABTest1 = 2”, that gives me random 20% of all users.
I make remote config variable for this segment, and another one for other users (i believe i don’t need to make special segment with logic where test don’t equal 1 or 2, but just create a rule for all users below the rule for specific users)
But, for this to work, user should became the part of segment at once, right after sending the event. So when we have a new user, he sends the event on app start, and right after that he requests remote config for the segment built upon this event, he already should receive correct value. But, somewhere above you have mentioned, that it needs several hours for cloud to recognize the device as a part of segment? Is this still the case? In such case this feature completely unusable for A/B testing, and maybe also for all other segment use cases. Cause even if we consider not custom events, but internal segment variables (such as country), user still not falls into segment at once, so he will get a default value at start, and another value somewhen later, which is unacceptable behavior.
RemoteSettings is cool but it needs more work and adjustments…
Apparently this is a show stopper, no go. Our game NEED accurate segmented remote value at build time, since for example the android download app store download link WILL BE different from the iOS app store download link. It will be redundant to direct android user to an iOS app store link and vice versa. Now this is just an example to prove a point, I believe there are many more such examples that timing will actually be rather crucial for segmented remote values, since we are not talking about pure analytics data, it’s runtime design data that will need to be accurate.
So currently the only solution is to use the old-fashion method:
-have multiple keys instead of one segmented calibrated key, ie, instead of downloadLink, we will have one for each platform: androidDownloadLink, iOSDownloadLink, editorDownloadLink
-use native unity scripting define in our script #if UNITY_EDITOR, #if UNITY_ANDROID, #if UNITY_IOS to grab the right value for each target platform.
-alas, this is a hack because a feature does not work as intended.
One other problem with RemoteSettings that I have encountered is the inability to retrieve value at least once whenever I close and open the app again, even on release build. We NEED RemoteSettings to trigger at least once whenever the user closes and open the app (yes we checked by ensuring the app is fully terminated), not on some undefined uncontrollable basis, so we fixed this by calling RemoteSettings.ForceUpdate() whenever the app is open, once. A debug log check and found out that sometimes RemoteSettings fetched this way will be fetched twice instead of once, since sometimes it will automatically fetch successfully, and then ForceUpdate forces another fetch which we will discard. So it feels kinda hacky. Perhaps a better way is to provide a function to disable automatic fetching, or make sure automatic fetching really does fetch data at least once, mitigating the need to call ForceUpdate() manually.
We generally feel RemoteSettings is still not fully ready for productions yet because of these problems despite the fact that it should really work out of the box. The integration experience feels buggy and we are afraid there may be more bugs that we haven’t discover yet.
Can you elaborate as to your mention of “build time”? We have no way of knowing what the device is until we receive the first event at run time. Also, I’m not clear on your mention of a download link, where is this link displaying, within the game? I do understand that if you have a download link within your game that is platform dependent, I agree it would be a problem to wait for the segment membership. And yes, automatic fetching does occur at app launch, can you elaborate how this is not working for you? If there is no internet access, the default settings will be used. Subsequently on the next app launch, the settings will be retrieved. And if there is no internet access, the previous settings will be used. If this is not the case, please describe how we might reproduce this behavior as you describe. Whenever I relaunch the game, the settings are retrieved. If I change the settings on the Dashboard, the next time I launch the game, these new settings are immediately retrieved.
