Design Events
Design events are used to track any custom, game-specific interaction not covered by our other event types (e.g. tutorial steps, feature use, player choices).
- Using our other, prescriptive event types (like Ad, Business or Resource) gives you access to dashboards that are pre-populated with relevant KPIs. Design events, by contrast, are fully custom. You’ll need to create your own dashboards and visualizations to analyze them.
- Tracking levels, worlds, or missions? Use Progression events instead — they’re designed specifically for structured progression tracking.
These events must be manually implemented. Refer to the SDK Documentation for code examples specific to your platform (Unity, Unreal, Roblox, iOS, Android, etc.).
Design Event Fields
| Field | Description | Type | Possible Values | Required |
|---|---|---|---|---|
| category | Event category | string | design | Yes |
| event_id | A colon-separated string of up to 5 segments that define the event hierarchy. Each level in the hierarchy will form a part in the name of the event. See below for more on event hierarchies | string | e.g. kill:robot:large | Yes |
| value | A field for numeric data, like time, damage or scores | float | Any numeric value | No |
Design Event Examples
| Example | category | eventID | value |
|---|---|---|---|
| A user completes the first step in your tutorial by naming their character | design | tutorial:namedCharacter:complete | - |
| A user chooses to pursue a specific quest option | design | quest1:dialogueChoice:aggressive, quest1:dialogueChoice:neutral | - |
| A user defeats an enemy in an open world game | design | enemyDefeated:normal:orc, enemyDefeated:boss:dragon | 14 (e.g. tracks the hits required to defeat the enemy) |
Example Design Event Hierarchy
A game that rewards players with achievements for reaching certain milestones.
Best Practices for Design Events
Due to cardinality limitations, it is important not to generate an excessive amount of unique nodes in your event tree hierarchies. Below are some tips and best practices to help structure your Design events to avoid this:
- Follow a consistent naming structure, e.g.
[category]:[sub-category]:[outcome] - Use the value field for any dynamic data, e.g. time spent, damage, scores.
- Tracking positions or movement?
Don’t send raw map coordinates in the event_id. Instead, group locations into logical areas (e.g. swamp, forest, forest_house, etc.), and use the value field to report time spent.
Example: event_id = action:shooting:swamp, value = 92.5 (seconds) - Tracking hundreds of items or user-generated content?
Avoid using item names or user IDs in the event_id. Aggregate into types or genres (e.g. ugc_video, ugc_photo, ugc_song) instead. - Tracking levels or game stages?
Use Progression Events, which are optimized for this type of data and will pre-populate your Progression related KPIs in the AnalyticsIQ UI.
If you’re tracking anything likely to cause high cardinality, record it in a Custom Event Field and analyze it in PipelineIQ. This keeps your event structure clean and ensures accurate analysis without UI-side data loss.