## 3 Methods  
### Usage Measurement and Its Challenges  
System usage data reflect the actual use of a system by measuring how often, when, and by whom an ICT-system was used [14; 20]. Automatic recorded usage data are quantitative data that are automatically collected when a system is used [5; 14; 35]. Automatic usage data can be measured on two levels of the ICT system: on the system/application level via application usage measuring [36] and on the feature level via in-app logging of events [37]. Measuring usage data on the application level enables the comparison of different applications by assessing which applications are used, how often, and when they are used. Thus, usage prediction and recommendations for new applications can be derived [38]. For logging the usage data of mobile applications, a range of tools exists, e.g., AppTracker [36] or ProfileDroid [39]. The usage data at the application level, however, do not tell anything about which features or subfeatures of a system/application are used. On the feature level, insights into the take-up of application features can be gained, user profiles can be created or adapted, and information for further feature development and redesign can be derived [9; 19; 37]. Usage data on the feature level are measured by instrumenting source code to automatically log user interactions [14]. This can either be done using existing usage mining tools [40] or applying one's own implementation [14]. No matter whether usage data are measured at the application or feature level, large amounts of data will be generated. If usage data evaluation is not planned carefully, a mass of data is produced, which challenges both the data processing and the generation of reliable results. Previous work addressed parts of the usage data evaluation process. They focused on tools and software for usage measurement [13; 14; 15; 36]. Other work in the field of software development point to the need for estimating the expected amount of data and data transmissions beforehand, and to calculate the capacities required [41]. In addition to the amount of data to be processed, protocols also need to be defined on how to merge different data sources, e.g., to evaluate the usage of multicomponent systems. For the purposeful analysis of usage data, the measures for \"use\" have to be appropriately defined, which may turn out not to be trivial. While in some cases, it is sufficient to know that a user just \"clicked\" a button, in other cases, it might also be of interest how long a certain application or feature has been used. This implies that not every user interaction may have a meaningful interpretation. First, raw usage records can contain corrupted data (errors in logging) or unintended duplicates (e.g., data like walking are logged automatically with an activity tracker and can also be entered by a user manually using an app interface), which require careful data preparation [42]. Second, measures are needed that provide meaningful information for answering the research questions. Examples for such measures are groupings/classifications of usage patterns that either result from data-driven or concept-driven approaches. In order to measure the actual take-up, an application or feature should be used repeatedly, which also needs to be reflected in an appropriate measure. Additionally, data sources may be needed for creating user profiles (e.g., sociodemographic characteristics of frequent users). Usage data collection has been rarely discussed in the context of data protection and ethical considerations. Most of the previous literature does not consider the ethical appropriateness of the usage measurement approaches chosen [43]. Such considerations are, however, relevant as usage data may reveal personal details of user behavior while its collection is not obvious and visible for users. Data collection has to abide by the principle of data minimization according to the General DataProtection Regulation (GDPR) of the European Union.