Event Browser#

Use the Event Browser feature in Analytics to debug events coming in from your game. You can see up to the last 100 events sent by your game in the last 48 hours.

You can toggle between valid events that are processed successfully and invalid events to show which aren’t processed. This might be due to setting up events in your game incorrectly, such as sending the wrong data type, wrong format, or invalid enumeration values.

Note that event processing time varies. Legacy Analytics events should be available in UGS within two hours after being sent.

You can also filter by userID and unityPlayerID:

• userID: Every event must contain a userID, which is a unique string that identifies the player and is consistent across their subsequent play sessions.
• unityPlayerID: an optional parameter. The authenticated playerID is provided by the Unity authentication service. This can be useful to link analytics data to player accounts if you're using other Unity services (such as Cloud Save). If you're not using the Unity authentication service, this field should be left blank.

The list is currently view-only and cannot be exported. Contact support if you require a bulk raw data export.

Valid Events.

Event Browser shows the following information:

• Loaded timestamp (UTC): When the Event is received.
• UserID: The user ID sent by the SDK.
• Event name: Event name sent by the user.
• Main Event ID: The generated ID when the Event came in. Useful for bulk Event uploads; the user can see all Events contained in a single bulk Event call.
• Invalid Event Reason: The reason for the failed Event.

You can view the event payload in the flattened json format by clicking <> at the end of the row.

Event details.

A detailed breakdown of invalid events will be shown in a dialog. Notices inform of errors and warnings. For example, if there is no format on a parameter such as a UUID, you’ll get an invalid notice.

Invalid events with a reason for failure.

You can also filter by Event name:

Filter by Event name.

Note: Nested events (for example, transaction) are flattened (have their nesting removed) by splitting the event into multiple, separate events. These events will have the same mainEventId field, with the "parent" event having an eventLevel=0, and the "child" events having an eventLevel=1. Only the parent event contributes towards user metrics. This can be seen in the Event Browser when multiple rows in the table share the same event ID.