## 3 Materials and Methods
### Personalization Level Improvement in MoveUp  
The MoveUp module has been tested in a real experiment, during which 60 users were monitored for eight weeks in performing PA tasks suggested by the system. The starting point for each user was 120 MET per week (equivalent to 30 min of moderate physical activity). The wearable device to get heartbeat rate was a \(PulseOn^{T}M\) smartwatch. The users were 25 female and 35 male subjects in the 35-45 age range. A profile for each of them was developed, combining eight values of PA (numeric values from \(MET_{min}\in[120,240,360,480,600]\)) and \(SE\) (numeric integer values in the range [2; 8] obtained during the test, for a total of 16 features.  
These features have been analyzed with experts [53] to define groups of people according to the comparison with an _optimal profile_ exploiting the case-based reasoning (CBR) paradigm [54]. Such a profile characterizes a user capable of increasing their goal every week, thanks to the highest levels of both _MET_ and _SE_ variables. Such user would reach the maximum amount of MET, i.e., 600, at the 5 th week of training, maintaining the goal for the last three weeks. Four classes have been determined based on the similarity percentage to the optimal profile, which are summarized in Figure 1.  
Further details about the conceptual model of MoveUp are out of paper scope; they can be found in [9]. Here, the challenge is understanding how results obtained from the study can address useful extensions of MoveUp from the mHealth standpoint. The main idea is to exploit user profiling to increase the acceptance level of the app using new functionalities tailored to user characteristics. The CBR method adopted in the analysis described so far allowed us to identify four classes of users, characterized by different levels of performance, decreasing from _capable_ to _static_. Anyway, some crucial issues can be identified that do not make CBR the best choice to develop a profiling function in MoveUp:  
* some cases are not clearly attributable to a specific class;
* classes numerosity could diverge in case of different case characterization.  
Regarding the first point, let's consider, for example, the case numbers 29 and 6, depicted in Table 1. Case 29 has a similarity value of 60% with the optimal case, thus, it has been attributed to _Slow but gradual_ set. Case 6 is 59% similar to the optimal case, thus, it has been categorized as _Complicated_. Looking at their concrete MET and _SE_ values, they are equal from the physical point of view, both reaching one week the maximum amount of 600 MET per week and very similar from the _SE_ perspective (user #29 overperforms user #6 one week more). Indeed, this different classification can be acceptable, and CBR can  
Figure 1: Users’ profiling based on the comparison with an optimal profile.  
be considered a good method to cluster MoveUp users, but borderline situations like the one described so far are difficult to manage. About the second point, the current model of MoveUp reasoning strategies does not consider real physical performance obtained by people. The system is interested in _MET_ values included in the [120, 240, 360, 480, 600] set, with possible variations of 120 MET per week, according to the experts' knowledge. This means that in case a user would accomplish 387 MET of PA at the end of a given week, the system will not record that value, being only interested to understand if the user will reach the prescribed amount of PA (i.e., 360 MET or less) or not (i.e., 480 or 600 MET) that week. If this strategy changed in future implementations, CBR would not probably be able to give a good clustering of users because the identification of clusters would be problematic and the graphical distribution of cases similarity with respect to the optimal profile will be more sparse.  
For these reasons, we have decided to exploit CBR as a method to specify possible classes of users in MoveUp, but we moved to different choices for effective profiling implementation.