I do not need to use the Unity Analytics and disable it in the Package Manager, but the new input system ask for it. I think it could be better not depend to the Unity Analytics.
Except if there’s a bug (the code there hasn’t been tested much yet), if analytics are disabled for your project, all analytics code should get culled from players (it sits behind the UNITY_ANALYTICS #define).
We do have analytics that we gather as part of editor analytics (unlike the old system, the new one runs in both edit and play mode). The intent here is for us to understand how the system is actually used out there in practice. Without that, it’s that much harder to understand what actually happens out there in user projects vs what we think is happening.
1 Like
Just to give a concrete example of what this is used for… when thinking about making the old system go away at some point, we will want to be able to say with confidence that we’ve obsoleted the old system. For that, we need numbers showing us that usage numbers for the old system are indeed plummeting towards zero percent. Stuff like that.
2 Likes
Well, I disable the Unity Analytics and there is a compile error report:
C:/WorkSpace/wind_game/Packages/com.unity.inputsystem/InputSystem/NativeInputRuntime.cs(171,41): error CS1070: The type `UnityEngine.Analytics.AnalyticsResult' has been forwarded to an assembly that is not referenced. Enable the built in package 'Unity Analytics' in the Package Manager window to fix this error.
I think maybe there codes is not warped by UNITY_ANALYTICS?
I see the condition is:
#if UNITY_ANALYTICS || UNITY_EDITOR
so why the UNITY_EDITOR is still run this code?
I see. That’s a bug. Filed a ticket here: Disabling analytics leads to compile error · Issue #163 · Unity-Technologies/InputSystem · GitHub. We’ll take a look.
The reason for UNITY_ANALYTICS || UNITY_EDITOR is that editor analytics is separate from player analytics. Both should function independently.
Wait, are you using the same analytics system for editor analytics as the one you’re shipping for people to use in their games?
So… that’s not communicated in any way shape or form. Whenever I start a new project these days, I nuke all of the mobile crap that’s automatically added in the package manager. If that causes analytics data to not get sent to Unity, that should be noted in some way.
Or can you turn on “Enable Unity Analytics” when you make a new project, delete the “Analytics Library” and “Analytics Standard Events” from the package manager, and still have the analytics for usage sent to you?
The tech stack is indeed the same, but the data funnels aren’t. Editor analytics go to an API separate from player analytics even though underneath it uses the same tech to actually transmit the data.
Yes, that should work.
To elaborate a bit more… in the world before packages, this is all simple. That switch only governs whether you want to use Unity analytics yourself. It does not govern Unity’s own usage analytics. Meaning that you can leave that set to off and we’ll still get usage data for Unity players and editors (answering stuff like “how many users are using a particular version of Unity”). Editor usage analytics can be turned off independently when having a Pro license (in the Preferences window), though.
For packages, we don’t have an equivalent setup yet. Package code lives entirely in the same space as your normal project code (which is somewhat different to C# code we ship precompiled with Unity). So if you turn off Unity analytics for your project, usage data from packages is also affected. Meaning the input system won’t collect usage data from players. It will still collect usage data from the editor (if that is not disabled).
Hopefully that will get less confusing as we establish packages better.
2 Likes