Whitepaper Analytics driven game design: A developer's guide to designing effective F2P games

Whitepaper

Analytics driven game design:A developer's guide to designing effective F2P games

© 2013 GamesAnalytics Limited. All Rights Reserved. Confidential and Not For Distribution

contents page


Executive Summary

Recommendations for Analytics Driven Game Design

1______Build in analytics in from day one

2______Effort vs. Pain: Make event data available in the game upfront

3______Build a single player view

4______Synchronise timestamps

5______Create a single session ID

6______Always collect outcomes

7______Do not forget to collect status data

8______Create custom events

9______Be clear on game versions and using cohorts

10_____Consider data completeness vs. operational investment:

Conclusions

1 executive summary

With Free-2-Play (F2P) games attracting a broader more diverse range of player

types, it’s never been more important for publishers and developers to

understand different player behaviours in order to design an experience which is

responsive to varying levels of competency and playing styles.

The games industry is starting to embrace analytics and use player data in more

sophisticated ways. However, delivering real player insight is not

straightforward. It needs to be integrated into the game design from the start of

development and executed with clear focus and objectives. In reality, today,

analytics is often tagged onto the end of the development cycle as an

afterthought. This inevitably results in short-cuts and compromises the ability to

really understand the different types of players that exist in a particular game

and what experiences they are having.

GamesAnalytics works with publishers and developers helping them to develop

robust Player Relationship Management (PRM) strategies that create solid

analytics environments in-game. Its PredictTM technology supports player

segmentation and in-game messaging enabling players to participate in a

personalised gaming experience.

GamesAnalytics’ industry review programme BenchmarkTM has seen hundreds of

hours invested in examining the anatomy of some of the biggest F2P games

across different genres. It highlights today’s realities of the games industry’s

analytics deployments and expertise. Key findings include:

This Developer’s Guide presents 10 essential design and implementation

recommendations to ensure a game is optimised for analytics beyond the metrics

dashboard. It provides best practice advice on how best to make player behaviours

integral to the design decision making and development processes so that the

player experience can be enhanced with retention and monetisation maximised.


• The average score for monetisation loops and techniques implemented in today’s F2P games is only 46% • Only 22% of games currently deliver a good experience aimed at first time payers; by

building in items aimed specifically at encouraging this critical player behaviour

• 83% of games make no attempt to communicate with players on an individual basis; they treat players exactly the same no matter if they are new, engaged or whales

Data taken from GamesAnalytics’ Benchmarket findings, April 2013

The reality is the implementation of data collection to support analytics is often a

low priority amongst all the other tasks on a developer’s to-do list. It is

inevitable that, as the game moves towards launch, developer time is rightly

focused on bug fixing and feature enhancement. Data tagging gets squeezed

into schedules, becoming rushed and potentially compromised.

And we all know from experience there is never time to catch up.

On average, where data collection is integrated at the end of the

development phase, it takes three to five times longer to

implement. Planning data collection into the development

lifecycle, with milestones set at the Game Design

Documentation (GDD) stage, ensures analytics is integral

to the successful development of the game.

By defining the events to be collected in the GDD, the

development team can then make sure the information is

available at the correct point in the game. For example, at

the end of a mission a key metric to understand would be the

number of enemies killed during that mission. If this event defined

up front it makes implementing the data collection seamless.

2 effort vs. pain: make event data available in the game upfront

With events and their parameters well defined, a developer can then determine

what data is required and when. Building this data structure into the code from

the start ensures that the data is easily available at the right point in the code

where the data needs to be sent.

Events often require a number of pieces of information both specific to the

current game action and general information on the status of the player or the

overall game. For example when a revenue event is triggered, the information on

the player’s XP, score and current level are sent to the analytics system along

with the revenue data.

10 recommendations foranalytics driven game design


1 build analytics in from day one

p

d of the

t

t

e the

t defined

Wheredata collectionis integrated at the end of the development

phase, it takes3-5 times

longer


This information is vital for the analyst to understand the

player behaviour at the point of the transaction. In the

game, this data is not required during a transaction,

but making sure it is available upfront makes

creating the event simple. To send an event is

generally very easy and requires only a few lines of

code; what is much more challenging is having all

the data available at the point the event structure

has to be instantiated.

On average, games, where event collection is retro-fitted

into the development process, only collect 60% of valuable

game data; which is the equivalent to leaving money on the table.

3 build a single player view

Analytics looks at player behaviours across the whole game. However, as games

become more complex there are often multiple systems involved. For example,

the registration system might be different from the payment system or in-game

match making platform. This means data is often sent from both servers and

game clients.

It is therefore imperative to build a single player view by having a consistent

concept of a User ID and session. The session is a unique ID for a user that links

all the events together between the point a player starts and ends the game.

This session is extremely useful to understand player behaviour so that the

analyst can derive not only what actions a players has done, but the order of

those actions.

If data is coming from different servers, it is important that they are still

identified to be part of the same session. Ideally, the timestamp will also be

synchronised so the order of events and the single view of the player journey is

maintained. This is often not easy as servers can be separated by time zones.

The additional complexity of data being sent from a client as well as the server

means data will come in with a wide range of timestamps and therefore the User

ID and session are vital to tie these events together into a consistent player journey.

Building a single player view allows information to be brought together in the

analytics system no matter where the data originates.

This in

play

g

h

On ave

into the dev

On

Where event collection is

retro-fitted intothe development process collect 60% of valuable

game data


4 it’s important to synchronise timestamps

Similarly, with event data coming from multiple sources, it is essential to

synchronise timestamps to ensure a single consistent view of player behaviour

can be maintained. Client data is often sent using a local timestamp, whereas

server data will most likely be time stamped where the data is stored.

There are two approaches to achieving synchronisation; either all systems must

synchronise to a single universal clock and data is sent with the relevant timestamp,

or data is sent to the analytics system that timestamps the data on receipt. As

long as there is no batching of data then time stamping at the point of the

analytics server is often the simplest solution to achieve a consistent view of time.

If timestamps are not the same, it makes it very hard to understand the true

order of events, which is vital in building a player behaviour profile.


5 create a single session ID for effective analysis

Having a unique Session ID that ties all the events in a single session together is

vital in allowing effective analysis. The alternative is to retro-fit data after the fact

which is inevitably inaccurate and introduces errors.

A great deal of the initial retention analysis is focused on the first session, so

having a consistent and accurate way of defining sessions is essential.

6 always collect outcomes

Events should aim to collect outcomes rather than changes. In other words, it is

much better to collect the outcome of a mission rather than each change that

happened during the mission. For example, collecting what the player achieved

when they complete a mission that is how many points they were rewarded or

enemies they killed is much more useful than collecting every shot fired or,

player killed.

Similarly, when collecting the results of an upgrade, it is better to secure a

snapshot of the result rather than each element of the upgrade. As

players upgrade their character they may make a number of

changes, for example trying on different clothes and weapons.

Although this is interesting information, the valuable data

is the status of the player at the end of the process. By

only collecting the outcomes of any changes and not each

individual change, there is both a reduction in the data

collected, which impacts costs, and the analyst gets only

useful information rather than having to manually create the

status from each individual change.

It is always possible to collect every piece of information on the view that it

might be useful. However, too much information can be as dangerous as too

little. It is important that the data collected is useful or it will rapidly become

unmanageable and more time will be spent wading through huge amounts of

data to find actual useful nuggets and less time on the important analysis that

delivers real insight.

too much information can be as dangerous as too little

7 don’t forget to also collect status data

It is still vital to also collect general information such as player score, XP and

currency balances.

These updates should be collected at the end of each event requiring the data to

be available to send this information. Collecting such status data allows the

developer to view the changes in gameplay stats without having to collect every

change which would be far too much information to collect and store.

8 create custom events; but use them wisely

Standard event lists ensure that implementation is as easy and quick as possible.

However, there will always be some bespoke events in a game that do not fit

with the standard events. It is important to define the custom events that need

to be captured up front, but they should only be used when standard events are

exhausted. Significantly, standard events allow easy comparison across games,

which is critical when considering player behaviours cross-game.

9 be clear on game versions and using cohorts

Ultimately, player insight is delivered by segmenting individual groups of players

– not by looking at the player base as a homogenous entity. By strategically

isolating player cohorts, taking account of game versions and acquisition

strategy, it is possible to define a meaningful cohort of new players to analyse

their playing experience, specifically looking at key retention and monetisation

behaviours such as defection, time to first payment and lifetime value.

By defining cohorts it is possible to create personalised game experiences which

drive player engagement and on average increases retention by 90% and

monetisation by 23%.


drive player engagement and increase retention by 90% and monetisation by 23%


10 data completeness vs. operational investment: where’s the balance?

If events are implemented during the design and development process, the aim

should be to implement data collection for all the events. For games that

integrate analytics at a later stage, practical decisions need to be made to

balance data completeness with development overhead and it is often pragmatic

to phase the event collection.

For all developers, there is always a balance to be struck on the depth

of data collection.

Retention is often the most important aspect of a F2P game to get right, so

making sure events that support retention analysis are implemented first

ensures analytics can start to deliver value quickly and support retention

optimisation. Monetisation events should be next, with complex gameplay

events left to last as these are used to support segmentation and deliver

customised and personalised messaging.

conclusions

This Developer’s Guide is designed to offer publishers and developers practical

tips and best practice recommendations for analytics driven game design.

It is clear that analytics delivers the maximum insight and value when it is

planned and integrated from the start of the development process. There is also

a balance to be achieved around events to be collected and know-how required

around the complexities of today’s F2P games to make the process as efficient

as possible to generate robust and appropriate data.

collection phasing examples

Retention events

Transaction & Social events

Custom – game specific

Install, Game Start/End, Mission Start/End

Transaction, Invite, Message, Gifting, Guilds

E.g. Dock spaceship


about GamesAnalytics

GamesAnalytics improves player satisfaction and increases game revenues. Our

technology platform Predict™ uses advanced data mining and predictive model-

ling to identify and segment significant player behaviours. Through this insight,

game design can be optimised and players targeted with real-time individual

in-game messages to offer personalised experiences that build engagement and

increase retention to drive significant revenue growth.

For more information visit www.gamesanalytics.com

or follow us on Twitter @gamesanalytics

Whitepaper Analytics driven game design: A developer's guide to designing effective F2P games

Documents

Transcript of Whitepaper Analytics driven game design: A developer's guide to designing effective F2P games