Introducing Standard Events

«What custom events should I implement?» is a question we get asked a lot at Unity Analytics. Believe it or not, asking this doesn’t mark you as an analytics newb: in our jobs across the industry, we’ve collectively had this conversation on what data to track in every size of organization, from indies to big studios.

Opinions on what to track vary widely, but here at Unity Analytics we believe the answer begins by asking «what questions do I want answered?» While we can’t precisely answer that question for each and every one of you, we do know some of the most commonly-asked questions that developers have, and can use that knowledge to help you begin exploring your questions. To facilitate this, we’re introducing a new tool: Standard Events.

«Standard» Events

Our new feature quickly points you to areas of player behavior you likely want to explore. Instead of completely freeform custom events, these new standard events are normalized to help you ask some pretty sensible questions, such as «how are my players doing?», «where are they spending money?», and «how engaged are they in my game?» Just by using the SDK’s API, you get a built-in checklist of questions you should probably be asking.

The Standard Events – and their associated questions – are broken into the following five groups:

How well are players onboarding?

How are players progressing?

How effectively are players monetizing?

Which UI screens do they visit?

How actively are players engaging and socializing?

We’ve captured these five areas in the acronym A POEM, as explained in the short video below.

«Standard Events cover 90% of what we normally track, so that works really well. The programmers also like this approach as it’s less error prone and serves as a nice guideline of what events should get tracked.»Karol Drzymała, Orbital Knight

«Standard Events are exactly what we need. The API gives us the exact analytics calls we’ve been using on our own, and the integration was fast and simple.»Kyle Yamamoto, MochiBits

Not sure what inconsistency you’re seeing here. «store_item_click» would surely refer to the user actively selecting an item in the store (be it selecting for more info, or selecting for purchase). «store_opened» refers to the completely different event that a «store» page in your UI has been activated, this might be from a click, it might be as a response to a purchase attempt when you didn’t have enough currency, etc. Which is probably why it doesn’t refer to «click» in the event name unlike the first one which is almost certainly occurring through direct user selection.