New Custom Event Limits - Please Read

Unity Services
,
1

This post is now deprecated. We have removed the Analysis Point system.

See this thread for more details:

Hello Unity Analytics users!

Here’s an overview of how Analytics Points work.

Please note that we will never charge you if you exceed your Analysis Points allocation, though certain events may not be tracked. But fear not - you can always manage your Analysis Points via the Event Manager.

Let’s break this down with a few examples:

Example 1: Custom Events with No Parameters
For Custom Events with No Parameters, the cost for each Custom Event = 1 Analysis Point

LevelStart
Custom Event with No Parameters = 1 Analysis Point

LevelEnd
Custom Event with No Parameters = 1 Analysis Point

PurchaseItem
Custom Event with No Parameters = 1 Analysis Point

Total of 3 Points
1000 - 3 = 997
I have 997 points left.

Example 2: Custom Events with Numeric Parameters Only
For Custom Events with Numeric Parameters only, the total Analysis Point cost is equal to the number of Numeric Parameters + 1 for the event itself.

Let’s build out our example below (assuming all parameters are numeric only):
LevelStart
coins
Custom Event with 1 Numeric Parameter = 2 Analysis Point

LevelEnd
coins
levelnum
Custom Event with 2 Numeric Parameters = 3 Analysis Points

PurchaseItem
levelnum
cost
gold
Custom Event with 3 Numeric Parameters = 4 Analysis Points

Total of 9 Points
1000 - 9 = 991
I have 991 points left.

Example 3: Custom Events with Numeric and Non-Numeric Parameters
Now this is where things get a bit tricky. Non-Numeric Parameters (strings and booleans) cost more Analysis Points than Numeric Parameters. Non-Numeric Parameters cost more because we need to run individual calculations on these in order to show you how they break down. The cost of Non-Numeric parameters is equal to the possible values they can assume.

Here are a few more examples:
LevelStart
coins (numerical)
levelname (string) > For levelname, let’s assume there are 10 possible values.

Custom Event = 1 Analysis Point
coins: 1 Numeric Parameter = 1 Analysis Point
levelname: 1 String Parameter (with 10 possible values) = 10 Analysis Points
Custom Event with 1 Numeric Parameter and 1 String Parameter = 12 Analysis Points

LevelEnd
hitpoints (numerical)
coins (numerical)
levelname (string) > For levelname, let’s assume there are 10 possible values.

Custom Event = 1 Analysis Point
hitpoints: 1 Numeric Parameter = 1 Analysis Point
coins: 1 Numeric Parameter = 1 Analysis Point
levelname: 1 String Parameter (with 10 possible values) = 10 Analysis Points
Custom Event with 2 Numeric Parameters and 1 String Parameter = 13 Analysis Points

PurchaseItem
name (string) > For name, let’s assume there are 100 possible values.
cost (numerical)
on_sale (boolean) > on_sale is a boolean (i.e., True or False), so it can take at most 2 possible values.

Custom Event = 1 Analysis Point
name: 1 String Parameter (with 100 possible values) = 100 Analysis Points
cost: 1 Numeric Parameter = 1 Analysis Point
on_sale: 1 Boolean Parameter (with 2 possible values) = 2 Analysis Points
Custom Event with 1 String Parameter, 1 Numeric Parameter, and 1 Boolean Parameter = 104 Analysis Points

Total of 129 Points
1000 - 129 = 871
I have 871 points left.

As you can see, it’s very important to keep track of your Analysis Points and not let any part of the equation get out of control. You can track your usage through the Event Manager tab.

Some recommendations:

  • Use numbers when possible
  • Spend your points wisely! Don’t send parameters you don’t need.
  • Avoid sending highly variable (string) parameter values. For example, a user or device ID is probably a pretty useless thing to include, and will cost a lot of points.
  • Think about how you want to analyze your data as you structure your events and parameters.

Hope that helps explain things! Feel free to ask clarifying questions below, we’re here for you guys so feedback is always welcome and appreciated :slight_smile:

1 Like
2

do these limits apply per Unity account? or per project?

1 Like
3

Per project - will update the post accordingly :slight_smile:

2 Likes
4

Chiming in on Angelo’s post- we know Analysis Points is a new concept and folks have already established custom events and parameters, so we will not vigorously enforce the 1,000 point limit while we’re in Beta. That’s not to say, we won’t ping you if you are getting close or exceed your allowance. :smile:

We’d like for folks to start thinking about this, to ask us questions, and to provide feedback on what you think of this framework. As Angelo mentioned, our team is thinking of creative ways to make our product powerful and give you guys the flexibility to implement custom events the way you want to (and keep our data processing costs reasonable). :slight_smile:

5

This only applies to the number of different events, nothing changed for the limit of event/hour, right?

EDIT: Just saw the widget on the project page, could it be possible to have a breakdown of our points usage by events? As you realise it could be not that intuitive to see which one costs a lot or not, so having more details could be useful for the users.

6

Like the new system but there’s one big hole in it - exception tracking, which is a pretty common requirement these days. Obviously you’re going to get a lot of different strings showing stacktraces and it’s going to be a really quick way of using up your analysis points.

The thing is exceptions don’t need to be tracked like other events. They don’t need to be cross referenced and queried in the same way. A big list sorted by build number and perhaps log type is more than adequate. For these reasons, I suggest eventually it would be good to have a separate special event called and ExceptionEvent or something which just takes a log type (debug, warning, error, exception), a string for the error message and stack trace and a build number. The data for this would be shown in new dashboard just for that.

If a developer chooses to use this special event type it could cost a fixed number of analysis points that you guys can choose but the key is that because you shouldn’t need to cross reference the error message it shouldn’t cost you guys more server time for each message that’s different, right?

2 Likes
7

The new data explorer that comes with this change is amazing. Thanks and good job!

1 Like
8

@khan-amil

This only applies to the number of different events, nothing changed for the limit of event/hour, right?
Correct.
…to have a breakdown of our points usage by events?
Absolutely! In fact, we had one, but decided at the last minute that the way we had it structured was a bit misleading. We’ll push a proper one soon-ish.

@Twice-Circled

The thing is exceptions don’t need to be tracked like other events
You’re correct. Exception tracking is a different beast, and we’ll be handling that through a different service (not Unity Analytics, but Unity Perf). We suggest you not use UA for exceptions tracking for exactly this reason.

@SeashellsRacer Thanks!

9

Will we be able to manually remove certain events or parameters from being tracked? If at some point in our game’s development we decide metric A wasn’t as useful as we thought and that we really ought to be tracking metric B, it would be nice to have the flexibility to simply discard the old metric (even if it means it’s gone forever) and not worry about having wasted our points on useless data. This would also help with string parameters since a typo or error might cause more possible values for a parameter to be recorded than we had intended.

Also, regarding the two-point cost for boolean parameters. If we want to save points it’s obviously twice as efficient to just send a 1 or a 0, but is there a benefit in UA to using an actual boolean instead of a number?

10

Hi @Alex2539 !

Will we be able to manually remove certain events or parameters from being tracked?

This is on our roadmap, currently we envision having some sort of check-box where you can check and un-check custom events you don’t find useful anymore. Open to any additional suggestions :slight_smile:

Also, regarding the two-point cost for boolean parameters. If we want to save points it’s obviously twice as efficient to just send a 1 or a 0, but is there a benefit in UA to using an actual boolean instead of a number?

For booleans you’ll want to send the data as True or False. If you send it as a 1 or 0, UA will treat it as a numeric parameter, and you’ll only be able to see counts/sums/averages, and not the pie chart or bar chart distributions.

11

The point system is nice, it’s super flexible then.
As it’s supposed to reflect what we’re really using on your servers, could it be possible down the road to factor in some of the standard metrics?

For example, we have no in-game monetisation, so that’s a whole branch of metrics that we’ll never use, so maybe there could be some way to set it up on the project page, and if you don’t use monetisation events, you get more points to use for custom events?

So for now, how is it working? when you send a custom event once, it’s on the system forever?

12

Hey @khan-amil !

Thanks for the feedback - we’ll definitely take it into consideration :slight_smile:

So for now, how is it working? when you send a custom event once, it’s on the system forever?

Currently, yes. If you stop sending Unity Analytics the custom event, it will still be counted towards your analysis points allowance (though as Salley mentioned we won’t be vigorously enforcing the Analysis Point cap during the Beta). We are planning on building functionality to allow you to trim events you no longer use.

13

Having string values (like level names, reward types or products, etc) use up points in the way described seems like a recipe for using a ton of points quickly. I could maintain some numeric mapping of these enumerations - an ugly duplication of data really - and make it use less points as you describe, but that makes the UA interface/reports a lot less readable. Do you have any suggestions for compensating on the reporting side for the string->int mapping we will now need to do to keep in budget? Do you have ideas on future payment plans for points where this cap becomes less of an issue because by spending $X a month we have “plenty” of said points?

1 Like
14

The advantage of strings is that beside doing averages, they keep track of each occurences of these events, so you’d loose a bunch of information that way.

15

Hey @renanse !

Our goal with Analysis Points is to give developers the flexibility to choose which data points they want to analyze. Unfortunately, there are additional processing costs associated with string parameters vs. numerical parameters (hence the extra points), but we are taking a deep look at usage and we will be using feedback from the beta to determine what limits are reasonable (and more importantly, still provide value!) for the free tier of analytics. In the future, there will likelt be premium tiers, which will have a higher number of Analysis Points.

Also, to echo @khan-amil l, I’d actually recommend against numeric mappings: for example, if you have a custom event ClassType, and you send 1 instead of “Warrior” and 2 instead of “Mage”, Unity Analytics will treat the 1 and 2 as numerical parameters, which are processed differently from string parameters.

For numeric parameters UA will calculate the sum, count and average. We do more complicated calculations on string parameters so we can show you distributions (useful for answering questions like “Which class is played the most?”). See this forum post for more info on string vs. numeric parameter visualizations.

16

The new data explorer looks pretty sweet! Wanted to confirm that you can now indeed download all the raw event data via the csv download?

And I have to second the request for some sort of int to string mapping since the points system (which does make a lot of sense) discourages string use.

What about a fourth type, which I think most naturally might be called Enum, that was transmitted as an int but for which each int value was understood to be some string? I’d be fine with having to enter those string values via the web interface if necessary, but you could also set up a way for Analytics to accept enums and even do a one time update of enum values when needed (using things like System.Enum.GetNames(typeof(YourEnumType))).

1 Like
17

Hi @Jazon-Burnell !

The CSV export option gives (at the segment level) the count, average, and sum of your numeric parameters, and the count for string & boolean parameters. Export of raw event level data is not currently available, though this is a feature we’re looking at.

some sort of int to string mapping since the points system … discourages string use
…set up a way for Analytics to accept enums…

We don’t currently support Enums (though we are considering this also). But this doesn’t really address the problem you’re looking to solve. Even with Enum support (or strings mapped to ints), we still need to evaluate categorical values. Any “category” (i.e., something you want to categorize, rather than sum up), whether expressed as string, Enum, bool or number, requires a unique pass to calculate and distribute.

It’s not our intention to discourage string use - in fact we built out the new custom events visualizations specifically so developers could get value out of their string parameters :smile:!

However, because of the additional calculations required for string vs. numeric parameters, we introduced Analysis Points to encourage developers to track their string (bool/Enum) parameters carefully.

18

Okay, thanks for the explanation @angeloferro ! After re-reading the points explanation it did occur to me that unique enums might not be any different than unique strings in calculation effort if you’re just comparing hashes or whatever. Which makes me glad I asked, might have used ints where not beneficial.

And definitely a strong request for the raw event export functionality, there’s some AB testing scenarios I’d like to be able to do that I’m pretty sure couldn’t be derived from ordinary visualizations of data.

One other suggestion I wanted to throw out there is supporting versions of analytics data, separate from app game version. What I’m picturing is that you assign Analytics some version on the code side and on the web interface side you could view data separated by that version (so on the web side if you had multiple versions, you’d select the version before viewing your data).

My main motivation here is that the way I’d like to start using Analytics is to just throw up a bunch of events, get a feel for what I can do with it and how everything on the web interface side works, then restructure and finalize those events based on that. But right now I feel like I should be close to final the first time, otherwise I’m wasting points and clustering the data with a bunch of old no longer used events.

With version numbers you could set things up so that your first experiments are in one version, then your closer to final setup could be in a different version. And most importantly, I think this could be a potentially simpler way to deal with deleting old events. Let every active version cost it’s sum of analytics points, but be able to disable a version on the web side so that data is no longer collected for that version, releasing the points associated with it (if that addresses the analysis cost).

19

Hey @Jazon-Burnell ,

Thanks for the suggestions! We are planning on building out an easy way to de-select custom events and parameters that you no longer care to track, so they would no longer count towards your Analysis Points allowance. Until that feature is live, here’s a rough workaround: create a test app with all your custom events integrated. Once you have a better feel for which events you want to track, create a new app which just the custom events you care about.

there’s some AB testing scenarios I’d like to be able to do that I’m pretty sure couldn’t be derived from ordinary visualizations of data.

Speaking of AB testing, we’re working on an update to Segment Builder that will allow you to create segments based on custom event data. This means that if you are able to tag users as “A” or “B” users via custom events, you’ll soon be able to create custom segments (i.e., “A Players” and “B Players”). Once you’ve created these segments, in Data Explorer, you’ll be able to compare metrics and KPIs of the “A Players” segment vs. the “B Players” segment.

20

Okay, yeah, I suppose just creating separate test apps would work well enough in the meantime. And would still strongly push for raw data export, but the AB testing you describe does sound pretty neat, looking forward to seeing that.