Do You Speak Metrics?

ARRPU

We may be interested in finding out the revenue generated from each paying player and this is where the Average Revenue Per Paying User metric comes into play. This is calculated by dividing total revenues by the number of paying players. Unlike the ARPU calculation, we ignore the free and trial players in this calculation as they don't contribute directly to revenue.

LTV

Lifetime value of a player refers to the amount of revenue attributed to an on-going relationship with a player. That is, given a single player, how much have they spent with us from the time they first played our game? A prime use of this metric is in calculating what our acquisition costs are in relation to it. For example, if the LTV is significantly lower than our customer acquisition cost then we have a problem! In this case we're not earning enough revenue from customers to account for the acquisition spend in obtaining them in the first place. The LTV can be calculated as: Monthly ARPU x Lifetime of player in months. We can integrate K-Factor using a first order approximation to give the LNV (Lifetime Network Value) which takes into account the other players that a player may invite via viral channels: 1 / (1-k) x Monthly ARPU x Lifetime of player in months where 'k' is the K-Factor (see below).

K-Factor

K-Factor is a measure of virality for applications/games that utilise viral methods for player acquisition.  Given a customer base (C), number of invites sent (S) and % of invites accepted (A), K is calculated as (S x A) / C.  If K is lower than 1 then your player acquisition is decreasing exponentially, a value of 1 implies steady state and K of greater than 1 indicates exponential player acquisition.

Durations

Duration refers to a time between game events - often 'start' and 'end' event types. It is used to answer questions of the nature 'how long did the player do x for?' For example, 'how long did it take the player to complete level 5?' or 'how long did it take for the player to get the reward after purchasing an item?' Measuring player behavioural durations indicates whether players are acting within the timelines that we expect them to.

Sessions

A session starts when the player starts to play the game and finishes when they decide to do something else. Sessions tell you how frequently a player plays your game (three times a day, six times a month etc) and by measuring the duration of sessions we can work out the average time that they spend playing the game in any given period. Sessions give a very useful high level metric for game activity and engagement. The end of session is usually marked by a period of event sending inactivity. For example, if a game hasn't sent any events for the last 30 minutes then we can assume that the session has ended. This has the effect of quantizing session durations. Only if the game has a persistent socket connection to the metric servers is it possible to detect precise session end times upon disconnect but as most metric systems are REST based, that is they send simple web requests to log events, this is usually not the case.

Conversions

One of the main reasons for using metrics is to refine your game to deliver better entertainment to players. As an entertainment experience your game should have high level objectives that you wish the player to fulfill. The purpose or objectives of the game can be design related ('we want our players to finish all levels/build a city/make friends') and they can also be financial ('we want the player to buy virtual goods after finishing level 1' or 'we want the player to subscribe after a free trial'). Either way, you're wanting your players to convert from one state to another, from inexperienced to experienced, from free to paying etc. That's a conversion.

Funnels

A funnel is a multi-stepped filter where a given number of units (often a unit is a player in game metrics) start out at the first step and are then filtered away in subsequent steps. Each step is illustrated in the funnel graph along with the number of players that make it to each step. The number of players associated with each step can also be shown as a percentage - either a percentage of the whole or the percentage of players from the last funnel step. Each funnel step can be specified with appropriate filtering logic leading to a final conversion figure at the last step. For example, we may have 543,343 players at the top of the funnel but only 12,000 are present at the last step yielding a 2.2per cent conversion. A funnel may be set up to show conversion for financial game transaction event or they may be set up to show pure game play conversions. For example, 'how many people got to level 10 (1st Step), then how many bought the big gun (2nd Step) and then finally how many went on to kill the end of level boss (3rd Step).

Cohort Analysis

A cohort is defined as a group of players who share common attributes. Cohort analysis provides the ability to track the churn/attrition rate of these players. Cohort charts are often represented as a two dimensional matrix showing a time period split into smaller division along each axis. The cells of the matrix contain the player count. For example, a row of the Cohort chart for a six week period, split into weeks, will show the player counts at week one through week six.  The player count will decrease in each column cell along the row showing our attrition rate from the count at week one. The next row will show week two to week six, the next will show one week three to week six and so on. A Cohort chart gives detailed figures on player attrition although in Playmetrix we can calculate Cohort analysis for any given custom event, not just attendance. This allows the measurement of game feature adoption and repeat play.

Split Testing

Sometimes called multi-variant testing or A/B testing (although we might be splitting on A,B,C and D!), Split Testing is a feature optimising technique. It's implemented by randomly providing the player with a differing version of a particular feature and then measuring the effectiveness of that version. It may be purely cosmetic - for example one kind of button style against another - or it may be a split on player interface features or even deeper game mechanics. The important thing is that the effectiveness of each variant is measured and, at some point in the future, based on effectiveness, a split can be chosen as the surviving feature/version. Applied effectively, this technique allows a game or app to be continuously refined according to majority player tastes and preferences.