This is the third part in a multi-part series discussing best-practices in product management and analytics for mobile games.
- Game Analytics Part I: DON’T Measure Everything
- Game Analytics Part II: Just Track These 6 Behaviors
Standard disclaimer: As before, this discussion will dive into the details quickly, and so will be most relevant to mobile product managers already familiar with the basics of mobile game telemetry.
In the previous post, Just Track These 6 Behaviors, we began our discussion of game analytics design by proposing a minimum-viable game events implementation. In this short article, we will apply a similar approach to our discussion of User Properties Design.
User Properties
While events log actions taken at specific times, User Properties complete the picture by storing up-to-date information about each specific user.
Basic examples include device type (iPhone, Android etc), total number of sessions played, number of friends and total money spent.
The user properties below should be adequate for most games.
Basic Info
total_days_since_install
acquisition_source
current_facebook_connected (true, false)
Note: Other metadata is automatically captured by the SDK (device, OS, country, etc)**
Aggregate Engagement
total_sessions_started total_[progression activity 1]_[verb] total_[progression activity 2]_[verb] etc. (one property per player progression vector)*
Game Progression / Success
highest_[progression vector 1]_achieved
current_[progression vector 1] (if back-slide is possible)
highest_[progression vector 2]_achieved
etc. (one property per player progression vector)*
Value Generation
total_friends_invited total_ads_viewed total_IAP_spend avg_purchase_price highest_purchase_price total_transactions
Player Resources Snapshot
current_wallet_[soft currency] current_wallet_[premium currency] current_wallet_[energy currency] etc.
*Above, “[progression axis 1], [progression axis 2]” etc. should be replaced with the primary vectors along which players progress in your game. Common vectors include “increasing in level,” “completing quests,” “collecting more unique pokemon,” etc.
**Note that many general-use properties (e.g. device type, device OS, country) that aren’t specific to your game are automatically reported by your analytics software by default. You don’t need to include these in your list.
As before, let’s see what this list might look for a specific game.
Sample User-Properties List – Clash Royale
Basic Info
total_days_since_install
acquisition_source (organic or user acquisition campaigns)
current_facebook_connected (true/false)
Aggregate Engagement
total_sessions_started total_matches_started total_cards_collected total_card_upgrade_events
Game Progression / Success
current_player_level
(trophy & Arena back-slide is possible in CR)
current_trophy_count
current_arena
highest_trophy_count_achieved
highest_arena_achieved
total_cardtypes_unlocked
Value Generation
total_IAP_spend avg_purchase_price highest_purchase_price total_transactions
Player Resources Snapshot
current_wallet_gold current_wallet_gems
As with events, ambiguity is not your friend. For example, I recommend using a prefix of “total_”, “current_” and “highest_” to clearly distinguish between properties that track aggregate totals, those storing the “current amount” of a resource that can be gained / lost, and those tracking the highest historical value a player reached.
User Properties and Past User Behavior
User properties are typically implemented in two distinct ways:
1) Current Values:
Each user has a value for each that is overwritten when the value changes, and always reflects the “current” value for that user at present date. For example, when the player first beats Level 5, we overwrite her ‘highest_level_unlocked’ property value (5) with a value of 6.
2) Attach a Historical Snapshot to Every Event:
A snapshot of the current value of all user properties is attached to every game event at the time the event is triggered. This gives us a historical record of what a player’s values were at the point in time at which any past event was triggered. This helps us answer questions such as – how many pokemon have players collected on average, by the time that they beat Level 5.
Great! Now that you’ve created a list of the events and user properties for your game, you can work with engineering to implement them in the game client. Notice the use of work with — a good engineer will likely have questions, and tight communication should yield the best results in the shortest time.
After waiting patiently, you receive a game build that has your game events and user properties embedded for the first time…
Verifying the Implementation
Once your events and properties have been implemented, I can’t stress enough how important it is to thoroughly test them. In 13 years in games I have yet to work on a product where the analytics implementation came out perfectly baked on the first try. And, without 100% confidence in your data, analysis can take many times longer than it should, and beget shaky conclusions.
To test events and user properties:
- Audit the events being sent by the client in real-time to ensure that each is triggered by the correct user action, and at the right time. I highly recommend roughing-in a debug feature that prints event names directly to the device screen when events are triggered.
- Validate that the User Properties are being set and updated correctly when the user state (e.g. coin wallet) changes. You’ll want to take some in-game actions, view an event log for your device (as above) and inspect the properties attached to each event.
- Confirm the naming conventions / spelling of all event and property names
Note that the primary analyst should do this work themselves, and not delegate to QA, another PM, etc.
Launch!
That’s it! If you’ve also read Part I and Part II, we’ve covered the background and necessary analytics work to get your game build instrumented for a product launch. If you got this far, I hope that you found some of these ideas to be helpful.
Though these first articles were admittedly more “in the weeds” than I would have liked, we are now one step closer to the fun part – using live game data to inform our game and monetization designs.
Stay tuned for Part IV: Which KPIs (Key Performance Indicators) actually matter?
Comments, criticism, better ideas? – Email me at [email protected]. I’m always happy to riff on game and monetization design, analytics, or anything related to mobile Product Management.
