Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

The introduction of gamification can be considered successful when the desired psychological and behavioural outcomes have been achieved. Understanding requires collecting and analysing gamification related data and is a non-trivial task that should receive attention when planning a gamification project. The process of developing a gamification design entails a creative aspect and must incorporate many aspects such as the personas of involved users, the application’s domain, properties of the gamified application itself, or legal constraints. These variable parameters mean that gamification designs are not rigid artefacts, but subject to change over time. The particular reasons for changes are manifold, for example:

  • The gamification design might not help to achieve the defined goals as expected;

  • Certain gamification elements might not influence the behaviour of all targeted users in the intended way;

  • Changes to the goal setting (e.g., due to organisational changes) might make an adaptation of the gamification design necessary;

  • User engagement might slowly decrease in relevant metrics and as a result, existing gamification elements might be adjusted.

By monitoring and analysing gamification related data, gamification experts can gain valuable insights and take corresponding actions towards goal achievement. Relevant data sources comprise user behaviour data, user properties, and gamification data. User behaviour data describes user actions in the gamified application, e.g., creating a new message thread in an online community. User properties describe known properties of the end users of the gamified application, e.g., gender or geographical location. Finally, gamification data represents gamification element-related information, comprising the gamification state and user progression over time.

We define gamification analytics as the data-driven processes of monitoring and adapting gamification designs. Gamification experts have agreed that these activities are crucial to the long-term success of gamification projects (Kumar and Herger 2013). However, gamification analytics have not yet received significant attention from academics nor from a practical perspective. To address this gap, this chapter advocates for and describes activities for monitoring and adapting gamification designs. The presented concepts are mainly based on a requirements study which was conducted with 10 gamification experts from various domains and functions (Heilbrunn et al. 2014a). The remainder of this chapter is structured as follows: Sect. 3.2 presents and discusses gamification analytic related activities in gamification projects. Section 3.3 identifies and assesses tools for gamification analytics. Finally, Sect. 3.4 provides a summary and an outlook.

2 Activities in Gamification Analytics

This section describes and discusses analytic related activities in the context of gamification projects. The presented activities extend the gamification process model of Herzig et al. (2014). The process model consists of the following phases: (1) Business Modelling and Requirements, (2) Design Workflow, (3) Implementation, (4) Monitoring and Adaptation. To illustrate the activities, a hypothetical scenario of gamifying an IT-ticket system is used.

2.1 Business Modelling and Requirements

The business modelling and requirements workflows are conducted at the beginning of a gamification project. In this phase, experts analyse the context and relevant issues of the application that should be gamified. As a result of the phase ‘business modelling and requirements’, a common understanding of the business goals behind the planned introduction of gamification should be achieved. Moreover, these goals should not only be documented in textual form, but also in the form of operationalisations that unambiguously define how the achievement of business goals will be measured. Accordingly, the defined operationalisations establish the basis for continuously monitoring the success of the gamification design, which will be developed later. In the following we will use the gamification of an imaginary IT-ticket system to exemplify the presented activities. The purpose of the IT-ticket system is aimed at helping customers in IT-related issues. For this, customers can create IT-tickets. Those tickets are processed by IT service engineers who are responsible for helping the customers with their IT issues. To avoid the duplication of tickets due to common IT problems, a FAQ-site is maintained to provide solutions for frequent IT issues. Given this hypothetical scenario, Table 3.1 presents a set of three relevant business goals and their corresponding operationalisations.

Table 3.1 Example of business goals and their operationalisations in the context of an IT-Ticket System
Full size table

2.2 Design Workflow

The process step ‘design workflow’ builds on the results of the process step ‘business modelling and requirements’. It deals with the construction of a meaningful gamification design that addresses the earlier identified issues in an appealing way by incorporating the findings of the first phase. Prototypes may be built and play-tested for early validation.

One of the main activities in the process step ‘design workflow’ is to creatively apply a set of gamification elements and mechanics that are likely to increase user engagement in the goal metrics. When envisioning gamification elements, designers often have particular intentions about how those elements should work in practice. For example, by envisioning which fraction of the users should complete a gamification element, or how much time people should spend to complete a gamification element. These intentions can be documented and thus monitored after releasing the gamification design. Deviations from these intentions are valuable insights and indicators for the fact that the gamification design does not work in the initially expected way. Consequently, adaptations might be necessary.

Assuming that IT service engineers receive points for satisfied customers with which they can advance in levels, the gamification designer could, for example, define that the final level in the gamification design should not be achieved by more than 5 % of the users. A violation of this threshold might result in an adaptation which increases the difficulty or extends the design by new levels, thus reintroducing motivation to the users who are on the formerly highest level. Another example could be that users should not reach the final level in less than one month. A violation of this threshold might as well lead to an adaptation of the gamification design.

2.3 Implementation

During the ‘implementation’ phase, the conceptual gamification design is transformed into executable software artefacts and functionally tested. Typically, a gamification platform will be used to implement gamification related functionality. If not done earlier, the application that is being gamified has to be instrumented to provide events for user actions of relevance for gamification mechanics or gamification analytics. From the perspective of gamification analytics, these events have to comprise all information which is needed to calculate the previously defined business goal operationalisations. Additionally, the application should emit events that inform the gamification analytics solution about relevant user properties such as gender or geographical location. This data can help to optimise a gamification design for specific target groups within the end users. Table 3.2 shows a set of event definitions that can be used to measure the business goal operationalisations from Table 3.1.

Table 3.2 Necessary events for measuring business goals
Full size table

The operationalisations of business goals can be implemented in the form of formulas or queries in the history of collected application events. In the following, such formulas will be called application KPIs (i.e., key performance indicators).

Given the IT-ticket system scenario with the event definitions given in Table 3.2, experts can define the application KPIs shown in Table 3.3. For illustrative purposes, we assume that events are stored in a SQL-Database. Accordingly, calculating application KPIs is implemented by querying event tables.

Table 3.3 Application KPI Implementations based on events in a SQL Database
Full size table

2.4 Monitoring and Adaptation

The phase ‘monitoring and adaptation workflows’ embodies the core of gamification analytic related activities. While the activities of previous phases establish prerequisites for conducting analyses, this phase eventually leverages those efforts to provide benefit to gamification experts. It comprises the activities of monitoring business goal achievement, analysing the gamification state, and adapting the gamification design in case of deviations, or changes to the goal setting.

2.4.1 Inspection and Exploration of Application Data

The status of the business goal achievement is measured by application KPIs which are operationalisations of business goals. Application KPIs are calculated on the basis of user behaviour events originating from the gamified application. Unfulfilled goals or negative trends within application KPIs can be starting points for a deeper investigation of user behaviours. If lower level issues, such as usability flaws can be discarded as reasons for the observed goal deviation, an adaptation of the gamification design might be necessary.

Figure 3.1 shows a hypothetical situation in the IT-ticket system scenario. One can see that for each of the business goals one application KPI is being monitored. The goals concerning (1) ticket processing time and (2) customer satisfaction are currently fulfilled. In particular, the development of the average customer satisfaction shows a positive trend after the gamification design was extended with a new mission. However, business goal (3) ‘FAQ duplicate issues’ shows a strong and continuous deviation from the targeted goal value. In particular, last month’s average deviated by +27 % from the goal of a maximum of 5 %. Assuming, that there are no other issues which hold people back from viewing the FAQ before opening a ticket, this might be a good starting point to consider the introduction of gamification elements that encourage users to check the FAQs before creating a new ticket.

Fig. 3.1
figure 1

Hypothetical application KPI setting

Full size image

It is important to note that by only measuring application KPIs it is not possible to infer causal relations between gamification design elements and the resulting application KPI values. Any factor such as technical problems, usability flaws, or even seasonal trends can cause changes in application KPIs. Application KPIs alone are only indicators which can be the start for deeper investigations. With A/B testing, gamification experts can overcome this limitation and start making evidence-based design decisions.

2.4.2 Inspection and Exploration of Gamification Data

Gamification metrics embody the second important aspect to be monitored in gamification designs. By investigating how users progress in the gamification design, experts can validate their initial design intentions, identify issues, and gain an understanding of how particular user groups interact with gamification elements in the application. In the following, metrics which have been identified as relevant will be presented and discussed.

  • Gamification Feedback Rate

Feedback is an important element of games (Tekinbaş and Zimmerman 2004; Zichermann and Cunningham 2011; Werbach and Hunter 2012). Gamification feedback is any state change in the game that the user perceives as a success, e.g., by gaining points or receiving a badge. Correspondingly, the feedback rate describes the total amount of feedback per time users spent in the gamified application. Inspecting charts and statistics of the feedback rate can help experts to qualify further observations and can be a starting point for investigating surprising observations. For example, noticing that the gamified IT-ticket system has an average rate of 0.1 feedbacks per hour could be an indicator that the current gamification design lacks comprehensiveness.

  • Point Distributions

Inspecting the distribution of points over users can help experts to detect flaws in the balance of point amounts for gamified actions. For example, noticing that 1 % of the users own 90 % of the points might be an indicator that the point amount for gamified actions should be reconsidered.

  • Achievable Gamification Elements

Gamification experts can explore user progression statistics of achievable gamification elements such as badges, levels, or missions to see the overall progression of users in the gamification design. This can help to understand how attractive particular gamification elements are and to identify aspects of the gamification design where adaptations may make sense. A gamification design might, for example, require adaptation, when already 60 % of the users have reached the highest level. Assuming that gamification experts defined their design intentions, the system could also automatically inform them about violations of design intentions.

  • Detailed Gamification Element Statistics

An option to drill down to particular gamification elements can give experts the chance to better understand detailed aspects of user behaviour in the context of a particular gamification element.

  • User Distribution on Gamification Element State: Users can have multiple states in relation to a particular gamification element. For missions, typical states, for example, comprise Mission Completed, Mission Active, and Not Assigned to Mission (Dormans 2012). Furthermore, gamification elements can have inner progress in the form of scaled intermediate goals or interval-scaled progression towards its achievement. By visualising the distribution of users in these states, gamification experts can understand how the users progress in the context of the gamification element. Experts could, for example, notice that only a few users completed a particular mission while most others are stuck in one particular sub-goal of that mission. This might be an indication that the design of the mission needs adjustment.

  • Temporal Statistics: Experts can analyse how long users need for the completion of particular gamification elements. Relevant measures in this aspect are: Time to Completion, the time period between the start of user existence and gamification element completion; Time to Assignment, the time period between the start of user existence and its assignment to the gamification element; Time Active, the time period between assignment and completion of the gamification element. For example, noticing that users typically complete a mission faster than expected might be an indicator for necessary adjustments to the mission design.

  • User Characteristics: Some gamification elements might be more attractive to particular groups of users than to others. To identify such constellations, gamification experts can explore which properties users have in common, who share the same state on a particular gamification element. Properties can be gamification properties or user properties. Gamification properties originate from the user’s state in the game, e.g., owns badge A, while user properties originate from the information the application has about the user, e.g., from geographical region Europe. By revealing significant factors of user engagement in the context of a particular gamification element, experts have the chance to optimise the gamification design for their individual audience. When experts notice that a mission is significantly more often completed by European users for example, they could start investigating the reasons and adapt it to raise its attractiveness in all relevant geographical regions.

2.4.3 Gamification Design Adaptation

Tests with experimental and control groups (A/B tests) are a widely used method for evaluating the effects of changes in a particular context. They have also been proposed for validating gamification design ideas (Kumar and Herger 2013; Kapp 2014). With A/B testing, the effects of gamification design changes can be verified before activating them for the whole user base. Accordingly, experts can test whether a new version of the gamification design provides a better achievement of business goals.

An A/B test in the gamification domain is characterised by the size of the experimental group, affected application KPIs, the desired impact on those KPIs (increase or decrease), and the actual design changes which are subject to the experiment. After specifying the mentioned parameters and starting the experiment, a user group with the selected experiment size should start interacting with the new design. In the next step, experts can use the recorded behaviour data to analyse whether the experiment was successful. The size of the experimental group is of particular interest since it carries a trade-off between expected confidence and potential damage of the experiment. Bigger experimental groups will usually help to achieve more reliable results. However, they also embody a higher potential damage since unsuccessful changes will immediately affect a larger user base.

As an intermediate and final result of A/B tests, experts can analyse the measured effects in observed user behaviour for the experimental group as well as the control group. This helps to understand the effects and side effects of conducted changes. Together with statistical significance tests, which help to avoid misinterpretations based on sampling errors, A/B testing supports objective decision-making in the design adaptation process. As a result of keeping a new design idea, a new annotation should be created in all relevant graphical charts (see Fig. 6.1). Such change annotations in charts can help experts to keep track of historical changes and their corresponding effects. Besides changes after A/B testing, other events of relevance to user behaviour might be recorded as well. This can include major changes to the application itself or direct changes to the gamification design. The latter might be necessary in cases when A/B tests are not suitable, e.g., with small user groups or when time constraints apply.

2.4.4 User Groups of Interest

The behaviour of particular segments within the group of users might be of special interest for gamification experts. Therefore, experts can filter statistical overviews, such as application KPIs, gamification element statistics, or the result presentation of A/B tests using earlier defined user groups. When defining user groups, the group criteria can be known a priori, or may be discovered dynamically.

  • Criteria Based Definition

Criteria based user groups are determined based on a set of conditions which are evaluated against the user’s properties. This approach is applicable when the exact criteria are well known before creating the user group. In the IT-ticket scenario, experts might be interested in defining user groups for each of the involved roles: customers who create tickets and service engineers who process tickets.

  • Cluster Analysis-Based Discovery and Definition

Cluster analysis aims at finding similar groups in a set of objects (Everitt et al. 2011). In the field of gamification, this can be applied to discover sets of users who show similar behaviour. Experts can conduct cluster analyses on relevant properties of users to discover groups which are of interest to them. This approach is applicable when the exact criteria of the user group are not known a priori. In the IT-ticket scenario, experts might be interested in discovering user groups based on their role in the system, the amount of earned points, or geographical region.

2.4.5 Simulation

Simulations are a common tool in the game design phase (Dormans 2012). In gamification design they are also considered as useful in supporting early design decisions (Rimon 2013). Gamification experts can simulate their early design ideas with existing user and behaviour data. Given that an appropriate dataset of historical user behaviour exists, a simulation can help to identify major flaws in the mechanics of a new gamification design. In the IT-ticket system scenario, experts might be interested in testing the first draft of point amounts for gamified actions. Based on the resulting point distribution across players they could then decide whether the concept is reasonable.

3 Tool Support for Gamification Analytics

The previous section presented gamification analytics related activities as part of the gamification process. It is evident that a holistic support of gamification analytics is complex. Therefore, sophisticated tool support is necessary to leverage the presented concepts in practice. The aspect of implementing gamification designs in software applications is well supported by gamification platforms such as Bunchball, Badgeville, or the SAP Gamification Platform (Herzig et al. 2012; Badgeville 2014; Bunchball 2014a). However, as shown in a previous survey, so far the use of specialised tools to monitor and adapt gamification designs is not common (Heilbrunn et al. 2014a). Instead, many interviewed experts have reported that they are making use of customised, narrowly focused solutions for reporting purposes. Those solutions are expensive to implement and maintain and do not address a majority of relevant requirements. To address this issue, we conducted a survey among potentially relevant tools for gamification analytics (Heilbrunn et al. 2014b). First, we considered solutions that directly advertise gamification analytics. Candidates were identified by querying internet search engines and the digital libraries of IEEE, ACM as well as Google Scholar with the terms gamification analytics and gamification data analysis. The search resulted in the identification of only two relevant tools. Thus, we decided to also consider tools from the similar game analytics domain (El-Nasr et al. 2013). The search was analogously conducted by querying IEEE, ACM, and Google Scholar with the terms game analytics and game data analysis and resulted in the identification of five relevant tools. In the following, the seven identified candidate solutions will be presented and briefly discussed with regards to their applicability in gamification projects as determined by the requirements which were identified in the preceding study.

3.1 Bunchball Nitro Analytics

Bunchball Nitro Analytics is part of the Bunchball Nitro Gamification Platform. Its assessment took place on the basis of its documentation (Bunchball 2014b). The tool offers a set of pre-defined reports and a user segmentation feature. Reports include metrics such as number of new users, number of total users, or points awarded. The tool can help experts to obtain a high-level understanding of user behaviour. However, from the perspective of gamification analytics activities that are discussed in this chapter, it does not provide appropriate support: The aspects of defining and monitoring application KPIs are not supported. Furthermore, the discussed gamification metrics and detailed gamification element statistics are also mostly unsupported. Bunchball merely provides a documented report with regards to the Points Balance. Since there was no sufficient evidence to assume the opposite, the activity of inspecting the point distribution is probably fulfilled. Finally, the adaptation of gamification designs, identification and persistent definition of user groups of interest, as well as simulation are also not supported by the tool.

3.2 Gigya Gamification Analytics

Gigya Gamification Analytics is part of the Gigya Gamification Platform which mainly targets gamification of online communities. It was assessed based on its documentation (Gigya 2014). The embedded analytics offer a set of predefined reports which focus on standard metrics and social metrics such as new registered users, new social network connections, or the most influential users (key influencers). The tool can help experts to obtain a very high-level understanding of user behaviour. However, from the perspective of gamification analytics activities that are discussed in this chapter, it does not provide appropriate support: The aspects of defining and monitoring application KPIs, gamification design adaptation processes, identification and persistent definition of user groups of interest, as well as simulation are not supported by the tool. The discussed gamification metrics are partially supported. Gigya Gamification Analytics supports progression reports for levels and missions. However, support for badges is missing on this level. The solution provides no mechanism for investigating how many users own a particular badge. Detailed gamification element statistics are also not supported.

3.3 DeltaDNA

DeltaDNA is a game analytics tool which mainly targets monetisation in Free-to-Play (F2P) games. It was assessed based on its documentation and a demo account (deltaDNA 2014). It comes with a predefined set of event types and dashboards which are specialised to relevant metrics of the F2P domain. The solution can be populated with events of arbitrary structures and retrieved events are stored in a data warehouse. There they can be queried through an integrated Business Intelligence tool which allows multidimensional analysis of recorded event data by executing queries in Multidimensional Expressions (MDX) language. The BI tool can be leveraged for defining custom KPIs or implementing gamification metrics. However, each metric needs to be defined and maintained manually which radically reduces the comfort that an automated solution could have.

The tool supports the process of A/B testing in a generic form, which requires the actual variation logic to reside in the client application. Accordingly, an adaptation of the gamification design from within the analytics solution is not possible. Experts can analyse A/B test results by comparing gamification metric values of previously defined user groups. DeltaDNA provides significance testing for the frequency-difference of an initially defined conversion event. However, measuring the impact of changes on application KPIs is not possible. In consequence, A/B testing is considered to not be supported in the expected way. Applying changes and creating corresponding change annotations are also not supported.

DeltaDNA supports the persistent definition of user groups of interest based on criteria and cluster analysis, however with major limitations. Criteria based user groups can only be defined based on DeltaDNA’s predefined user model and predefined metrics. Accordingly, a user’s gamification metrics or application KPI values, such as an engineer’s average ticket processing time, cannot be taken into account. Furthermore, the tool supports interactive 3-dimensional plots based on the set of predefined user properties and metrics which should help users to identify interesting user clusters. However, no algorithm for cluster analysis is available for automatic cluster detection. Finally, simulation is also not supported in DeltaDNA.

3.4 GameAnalytics

GameAnalytics is a game analytics tool which mainly targets monetisation in F2P games. It was assessed based on its documentation and a demo account (GameAnalytics 2014). GameAnalytics comes with a predefined set of event types and dashboards which are specialised to relevant metrics of the F2P domain. Custom events are supported, however they must comply with a predefined structure. In consequence, they cannot be adapted for specific use cases. The event structures presented in Table 3.2 could, for example, not be realised in GameAnalytics.

The solution comes with a query editor that can be used for the definition of custom KPIs. The query editor provides the functions sum, mean, count and histogram. GameAnalytics is therefore capable of calculating the application KPI (3) average satisfaction rating. However, more complex examples which require basic arithmetical operations or event correlation such as (1) fraction of FAQ duplicates and (2) average processing time cannot be implemented. Modelled application KPIs can be visualised in customisable dashboards which support charts as well as descriptive statistics.

GameAnalytics supports customised metrics that count the frequency of a particular event. The number of gamification feedbacks, as well as the progress of users in achievable gamification elements can be measured. However, since GameAnalytics cannot normalise the event count by the session length of users, the feedback rate measure is not implementable. Furthermore, the manual implementation of progress monitoring requires a high initial effort and also causes high maintenance effort when the gamification is adapted.

A/B testing can be realised partially by leveraging the build attribute in GameAnalytics’ predefined event structure. This attribute can be used to distinguish events originating from different versions of the gamified application. Metrics of each version can then be compiled together in one chart to compare them with each other. However, creating experiments, significance testing, applying changes, or creating corresponding change annotations are not supported. The persistent definition of user groups of interest is not supported. However, similar functionality exists in some aspects, because overviews can be filtered by properties of a predefined user model. Finally, simulation is not supported in GameAnalytics.

3.5 GAMEhud

GameHud is a game analytics tool which mainly targets monetisation in F2P games. It was assessed based on its set of advertised features (GAMEhud 2014). The tool comes with a predefined set of event types and dashboards which are specialised to relevant metrics of the F2P domain. Moreover, it can be populated with events of arbitrary structures. These events can be analysed by a manual criteria-based query tool and a funnel analysis tool. Assuming that explicit events exist for each metric, the query tool can be leveraged for counting the frequency of gamification feedbacks and the number of completions of a particular achievable gamification element. The funnel tool can be used to measure the distribution of users on the state of sequential gamification elements. However, queries cannot be saved or visualised in charts that have a time dimension. Complex expressions, for example, normalising the number of feedbacks by average session length, or normalising the number of achievers by the total number of users are not supported. Finally, user groups of interest, A/B testing, and simulation are not supported by GameHud.

3.6 HoneyTracks

HoneyTracks is a game analytics tool which mainly targets monetisation in F2P games. It was assessed based on its documentation and a demo account (HoneyTracks 2014). The tool comes with a predefined set of event types and dashboards which are specialised for relevant metrics of the F2P domain. Custom events are supported, however, they must comply with a predefined structure. In consequence, they cannot be adapted for specific use cases. The event structures presented in Table 3.2 could, for example, not be realised in HoneyTracks. Customised KPIs can be created and visualised in charts; however, they are limited to counting event frequency. Aggregation functions, complex expressions, or event correlation as required for the application KPI examples from Table 3.3 are not supported. HoneyTracks supports visual change markers in charts.

Assuming that explicit events exist for each metric, the number of gamification feedbacks as well as the progress of users in achievable gamification elements can be measured by counting the frequency of corresponding events. However, since HoneyTracks cannot normalise the event count by the session length of users, the feedback rate measure cannot be implemented. Furthermore, the manual implementation of progress monitoring requires high initial effort and also causes high maintenance effort when the gamification design is adapted. HoneyTracks partially supports A/B testing by allowing gamification experts to manually assign users to groups. These groups can then be used for direct comparison within charts. The persistent definition of user groups of interest is not supported. However, similar functionality exists in some aspects, because overviews can be filtered by properties of a predefined user model. Finally, simulation is not supported in HoneyTracks.

3.7 Upsight

From gamification analytics perspective, Upsight’s features are almost equivalent to the features of HoneyTracks. The only difference is that Upsight does not provide mechanisms for analysing A/B test data.

3.8 Assessment Result Summary

Table 3.4 provides an overview of the assessment results for the discussed tools. The assessment shows that the integrated solutions of gamification vendors (Bunchball, Gigya) provide rather simplistic analytics support. The available functionality addresses only a minority of relevant requirements for the activities that were outlined in Sect. 3.2. The activities relating to application KPI monitoring, gamification design adaptation, user groups of interest, and simulation are completely unsupported by both assessed gamification platforms. Even the category of gamification element analytics is almost completely unsupported. We conclude that gamification platforms currently do not leverage their potential of offering well-integrated gamification analytics. In consequence, they fall short in supporting the whole development cycle of gamification projects.

Table 3.4 Tool assessment results
Full size table

On the side of the standalone game analytics solutions (DeltaDNA, GameAnalytics, GameHud, HoneyTracks, Upsight) we see a diverse picture. Especially deltaDNA and Upsight provide decent support with regards to the discussed activities. However, direct support for concepts from the gamification domain and important functions such as A/B testing or simulation lack appropriate support. These game analytics tools can be leveraged to implement many aspects of the assessed requirements. However, the corresponding implementation effort, maintenance effort, and the resulting new data silo embody many disadvantages compared with the amount of support they currently provide.

4 Summary and Outlook

In this chapter, we introduced and advocated for the concept of gamification analytics. We described a process for gamification analytics. The presented analytic related activities were based on the results of a study with experts who actively work in the field of gamification. By following the presented process, gamification professionals can plan their projects with the end in mind and ensure that project success can be quantified.

As a second aspect of this chapter, we presented the results of a study that assessed seven analytics tools regarding their applicability in the gamification domain. The results showed that proficient tool support for monitoring and adapting gamification designs is not available yet. While certain requirements can be covered with existing tools, there is no single tool which supports a significant fraction of the relevant requirements. However, gamification experts can still leverage the presented results to make informed technology decisions in the context of individual projects. After technological support for the implementation of gamification is broadly available, technology providers should start elaborating on support for monitoring and adapting gamification designs after their implementation. Appropriate tool support will help gamification experts to establish a feedback loop between measured user behaviour and the design of gamified experiences without the high cost of setting up and maintaining custom solutions.