Hi. I’m reading through the documentation and am planning to start using Unity Analytics, but I’m a bit concerned that by capping to 100 custom events per user per hour we might be limiting the data we need to track. Take for example a Builder PVP game. Ideally we should track buildings build, resources collected, battles dealt as well as store purchases. By keeping a cap on 100 per hour we might risk going over quota easily if we track everything we need for a hardcore player with a session of 5-10 minutes.
I wanted to understand if there is any way around this other than not tracking things that may be potentially important.
Hi @plailabs-dev - thanks for your comment. Unfortunately, we have to have limits as we do incur a cost for processing the events. That said, we have not finalized the limits and may change them during the beta period (though most likely, there will be different limits for different tiers of service).
One workaround you can do in the meantime is to make sure that you are utilizing parameters. You can attach up to 10 parameters per custom event, and sending Unity Analytics parameter data does not affect the 100 custom events cap.
Really want to use Unity Analytics and we are attempting to use them alongside our google analytics solution at the moment.
We are currently sending 1000’s of events per hour to google analytics… To keep things simple we are sending the same events to Unity. This will not work however because of the limit of 100 per user per hour.
Is there any word on when these limits will be lifted?
I guess what Unity would like us to do is manually batch many of these events ourselves into individual Events. While this is possible I think most developers will just choose other solutions that do the batching for them.
The question above is being responded to via support tickets, but for anyone finding this post:
100 events per user per hour is enough for most users, however if you find yourself in unusual circumstances that require more, please submit a support ticket describing the circumstances of why you need the additional events. Although we can’t make any guarantees about what we can do, and it’s ultimately dependent on what our system can support, it is important to us that our users are happy with our product and we will do our best to help when we can.
From a developer/data analyst perspective, simply trashing data for high usage players is the worst that can happen, as it not only will corrupt data, but it will cut meaningful information with a bias (high usage players are cut more than low usage or short session players). So this limit per player is really bad, not to mention how low this limit is, basically limiting us to Start/EndLevel custom events.
If you want to limit volumetry, there should be other ways like sampling (limiting custom events to an unbiased number of players or events).
We appreciate your feedback about the custom event limits. As mentioned above, these limits are currently necessary for our data processing to perform at a reasonable level. And these limits are suitable for most apps. However, we are happy to work with individual developers to find a way to accommodate specific cases where these limits are not enough. If you find believe you app is hindered by these event limits, you can contact Analytics support and we’ll see what we can do
A follow-up question on this, since the 100 events/hr limit also seems low to us. Other than emailing Unity support and hope to have the limit lifted higher. Is this something that gets higher for companies that are on Pro licenses?
@soaring we do not offer a higher events/hour limit regardless of tier. However, we have heard everyone’s concerns and we are trying to figure out an alternative that allows us to give you guys a higher limit without compromising the performance of our backend servers
100 events per hour is certainly way too low for anything but the most basic of applications. We had to remove almost every event from our game to the point where Analytics data has become not very useful. Tracking player progression choices, in-game purchases, loadouts, etc had to be removed. Depending on the player, anything more than “start game” has the potential to cause the dreaded “TooManyRequests” error causing holes in the data in the back end, making the data untrustworthy and useless.
