Event Tracking Limits

One of our aims is to allow developers to freely track as many events as necessary to enable useful insights. When working on a game instrumentation, the focus should ideally be on making sure the instrumentation will provide the data you need to understand your players’ behavior, rather than whether you are going to generate too many data points and get a surprise bill (as it happens with many other analytics services). The GameAnalytics systems and SDKs are designed to make it easy to implement a good instrumentation, so in most cases (especially if you follow our detailed guides for each SDK guide) the GA SDK implementation in your game will not result in an excessive number or cardinality of events.

Despite this, a suboptimal implementation can sometimes result in an excessive number of events that can cause strain in GameAnalytics backend and require remediation.

Event Limits Definitions

The following table depicts the current limit numbers that need to be considered and can be reached with a suboptimal instrumentation.

Metric	Hard Limit Threshold
Total number of events per active user (per day)	500
Cardinality of Design Events (per day)	15,000
Cardinality of Progression Events (per day)	8,000
Cardinality of Resource Events (per day)	4,000

Total number of events per active user (per day)

This limit refers to the total number of events sent by the game to GameAnalytics’ servers every day. It is tracked in relation to the amount of players in the game.

Cardinality of Design Events (per day)

Design events follow a tree structure, allowing for different combinations of values to be tracked and sent to GameAnalytics. Having too many values for each of the parameters can result in a number of combinations that would make the cardinality, or number of different Design events tracked everyday excessive. This is covered in detail in our integration guides providing tips on how to avoid this from happening. We also have a section in our design event article explaining this further.

Cardinality of Progression Events (per day)

Progression events are used to track the steps a player takes when experiencing the game. As with Design events, the events are composed of different elements. Creating an excessive amount of possible values will not only make it more difficult to analyze the progression data but also might generate too many permutations.

Cardinality of Resource Events (per day)

Resource events are used to manage the flow of virtual resources in the game. Similarly to progression events, too many variants or values could result in a cardinality that's too high.

What happens when limits are exceeded?

When your event tracking limits are exceeded, GameAnalytics will alert you via the Game Overview → Integrations page.

Starting October 1st, 2025, the following behavior will apply:

• Design, Progression and Resource events will have their unique event combinations tracked over a 24-hour basis (resetting at midnight UTC).
• Events sent that exceed the daily cardinality limits will still be collected, but their event identifiers will be set to null in our system.
• After reaching the limit, event combinations that have already been sent the same day will continue to be processed as normal, with no change to the event identifiers.
• As such, any metrics derived from these events will not be accurate in the Explore Tool interface (e.g. Dashboards, Explore, Funnels or other UI-based analysis). They will also not be accurate when queried with the MetricsAPI.
• No data will be lost. The full event payload will still be included in Data Warehouse and Data Export for DataSuite users.
• There is no penalty or cost associated with exceeding the limits, however we strongly advise avoiding breaching cardinality limits so that there is no disruption or confusion to your GameAnalytics dashboards.

Best Practices & Tips

• Batch or aggregate frequent actions: Combine similar events into single summaries per session–for example, “level1:play_count” instead of one event per play.
• Aim for structured, reusable event parameters: Stick to consistent naming, and avoid using dynamic values like user IDs, timestamps or coordinates.
• Test your SDK integration early: Run sample sessions in your dev environment to confirm event volumes and structure are within limits.
• Monitor your thresholds: Use the Game Overview → Integration page to track daily events and cardinality
• Utilize the value field for any dynamic data, e.g. time, damage, scores.