Event Tracking and Cardinality Limits
Event tracking limits
GameAnalytics encourages flexible event tracking but enforces limits to maintain system reliability and performance. If these limits are exceeded, you’ll receive an alert via the Game Overview or Integration pages.
Event tracking limits thresholds
| Total number of events per active user (per day) | 500 |
| Cardinality of Design Events (per day) | 15000 |
| Cardinality of Progression Events (per day) | 8000 |
| Cardinality of Resource Events (per day) | 4000 |
Cardinality limits explained
Cardinality refers to how many unique combinations of event parameters are sent into our systems. In GameAnalytics, this is most relevant for Design, Progression and Resources events, which use hierarchical structures in their schemas.
Using too many unique parameter combinations–especially ones that include things like timestamps, coordinates or procedurally generated IDs–can:
- Make your data harder to analyze (e.g. lots of rows with 1–2 hits each)
- Slow down dashboard performance and API responses
- Lead to cardinality limit violations, which can stop data processing
Cardinality example: do vs don't
| Event type | Do (low cardinality) | Don't (high cardinality) |
|---|---|---|
| Design | ui:click_start_button, weapon:picked_sword, shop:open | ui:click_button_1693247890 (timestamp), enemy:defeated_42.5:89.3 (coords), item`:picked_#user12345 |
| Progression | world_1:level_2, world_3:level_5, tutorial:step_1 | world_randomseed_4287:level_custom_483, level_userGen_948 |
| Resource | source=quest_reward:item=gold, sink=shop_purchase:item=gem | source=loot_crate_user987:item=gear_83924, item=item_timestamp_12345 |
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 that exceed their daily cardinality limits will still be collected, but their event identifiers will be set to “null” in our system.
- As such, any metrics derived from these events will not be accurate in the AnalyticsIQ 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 PipelineIQ 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.
| Platform / Feature | Impact when breaching cardinality limits |
|---|---|
| AnalyticsIQ UI | Not available / not included in metrics calculations |
| MetricsAPI | Not available / not included in metrics calculations |
| Data Export | No impact |
| Data Warehouse | No impact |
Best Practices and 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.
If you’re tracking player position or movement (e.g. XYZ coordinates), use Custom Event Fields to record these values. Analyzing this data via PipelineIQ is ideal to avoid inflating event cardinality within the AnalyticsIQ UI.