“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.
Our beta users have had some great reactions to Standard Events:
“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
If you think Standard Events might help you, you can download it right away from our asset store page.
We’ll dive deep on each Standard Event in a future post, but for now let’s just list them all by category, including a quick explanation of what each event is for.
Onboarding/First-time User Experience
Event name | Event function |
first_interaction | The first voluntary action a player takes after install. |
tutorial_start | The player began a tutorial. |
tutorial_step | The player passed a key stage in a tutorial. |
tutorial_skip | The player skipped past a tutorial. |
tutorial_complete | The player concluded a tutorial. |
Game Progress
Event name | Event function |
level_start | The player entered into a new level. |
level_fail | The player failed to complete a level. |
level_quit | The player quit a level before completing it. |
level_skip | The player skipped past a level so they could carry on with the game. |
level_complete | The player successfully completed a level. |
game_start | The player began a game. This event is especially useful where a game has a distinct beginning and ending (e.g., arcade, endless runner). |
game_over | The player concluded a game. This event is especially useful where a game has a distinct beginning and ending (e.g., arcade, endless runner). |
level_up | The player leveled up, as might happen through an increase in experience (not to be confused with the completion of a game level). |
Monetization
Event name | Event function |
store_opened | The player opened an in-game store. |
store_item_click | The player selected an item within the store. |
iap_transaction | The player spends real-world money to make an In-App Purchase. |
item_acquired | The player acquires an item within the game. |
item_spent | The player expends any resource within the game. |
ad_offer | The player was given the option to watch an ad. |
ad_start | The ad started. |
ad_skip | The user skipped the ad. |
ad_complete | The user finished watching the ad. |
post_ad_action | The user completed a desired action (e.g., an install click or purchase) at the end of an ad. |
Application Navigation
Event name | Event function |
screen_visit | The player navigated to a UI screen. |
cutscene_start | A cutscene began to play. |
cutscene_skip | The player opted to skip past a cutscene. |
Engagement/Social
Event name | Event function |
push_notification_enable | The player activated push notifications. |
push_notification_click | The player reacted to a push notification. |
chat_msg_sent | The player sent a chat message. |
achievement_step | The player completed a milestone on the way to an achievement. |
achievement_unlocked | The player successfully completed an achievement. |
user_signup | The player registered through a login system. |
social_share | The player shared something (e.g., an image, invitation, or challenge) with a friend. |
social_share_accept | One player reacted to the social share of another. |
相关文章
Comments are closed.
9 replies on “Introducing Standard Events”
Do standard events count towards the 100 events per user per hour limit?
Yes they do. Note, though, that we’re currently reviewing that limit and expect to raise it soon. There will be an announcement on this subject, likely later this month.
Why are the calls inconsistent? ‘store_item_click’ vs ‘store_opened’? This is some serious madness going on here…
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.
Just my thoughts though, perhaps I’m missing something here.
Possibly referring to the verb usage: open / opened, click / clicked?
I have not yet used analytics, but I keep a close eye on its features and I can tell you, once I start adding analytics it will be so easy that I will not stop using them!
And I got all hyped up think you’ve finally implemented proper C# events such as “OnMonoBehaviourAdded/Removed” or “OnTransformChanged/Moved”.
Ahah I had the same feeling ;) …
Looks very useful!