Tracking events correctly
If an app has broken the event per day or cardinality limit, there are some ways to improve tracking to reduce the number of events.
Using Design Events to track the number of items being picked up in a map
The correct way to track this is to have a counter that is incremented each time a user picks up a certain item. When the user exits the game a Design Event should be implemented, to which the counter is attached as a numerical value.
E.g: GameAnalytics.NewDesignEvent ("PickUp:Item", itemCounter);
In the above example the numerical value corresponds to "itemCounter". It can be seen that it is separed from the event ID by a comma.
The reason for this is because sometimes games can have a large number of items available, and the number of events per user per day could easily exceed the 500 limit that we have in place, if an event is sent every time one item is picked up.
Using Design Events to track coordinates on a map
You might want to track where your players are walking the most throughout your maps. A way to achieve this would be to use Design Events.
At first glance an obvious way to achieve this would be to track each X, Y coordinate and report the pixel locations.
E.g: GameAnalytics.NewDesignEvent ("X_Coord:Y_Coord");
The problem with this event is two-fold.
If it's sent every second while X or Y coordinates change, there will quickly be more than 500 events per user per day on average.
Another issue with tracking coordinates this way is that the cardinality for events will potentially be very high.
For the previous example, assuming users are running a 2K resolution of 2560x1440, that’s a possible 3686400 unique values for the event.
The best way to track players on the map would be to split the map in more areas, and track those areas. The map could be split into: Spawn, Forest, Beach, Neutral Creeps #5 and so on.
E.g: GameAnalytics.NewDesignEvent ("TrackPosition: MapArea");
Implementing the event this way will drastically reduce both the total number of events, and the cardinality.
Keep in mind that even if you have a cardinality that in theory is over the limit, in reality users might not send all combinations per day to reach that limit. Keep this in mind to instrument events accordingly.